> 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.
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
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 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
> > 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 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,
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 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
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
Ø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
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
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
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
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
> -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
Ø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
> 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
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
> "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
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> 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
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
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, 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
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
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
>
> > 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
> 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
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
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
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
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 )
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
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
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
> "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
> "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
> 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
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
> 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
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
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
>
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, 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
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
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
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
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
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 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.
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
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 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 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.
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
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
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
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
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
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
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
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
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
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
ppc-linux 32-bit.
http://gcc.gnu.org/ml/gcc-testresults/2005-04/msg01370.html
Andreas
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
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.
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
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
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 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'
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
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
#
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
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
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
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
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
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
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
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
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
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-
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
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
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
86 matches
Mail list logo
