Hello all
If I modified MULTILIB_OPTIONS like this ( I added mlong-calls )
MULTILIB_OPTIONS = mlong-calls msoft-float EL/EB mips32/mips64
I could rebuild all libraries.
But problem is passing G0 option, if I simple put
MULTILIB_OPTIONS = G0 mlong-calls msoft-float EL/EB mips32/mips64
buildin
I think I have a better handle of where the pch regressions with
--enable-mapped-location are coming from. This is a follow-up
to some debugging/experimentation that Zack did - in September!
I agree with Zack that the problem is that the line_table
data structure needs to saved into the gch file a
> add1 r1, segment_base, (a - 40)
> add2 r1, 40
read this as
add2 r1, the value of j
>
> Since 'a' is at the boundary of segment so 'a - 40'
> causes relocation overflow.
>
> But the same code works without -O2, because that
> generates code like
> add1 r1, segment_base,
> Sanjiv Kumar Gupta wrote:
>
> > > What is stopping the value of 'foo' itself being
> > 255?
> > Programmer will get an overflow error for that
> during linking.
>
> For my curiosity, what's the background here? Do you
> really only have 256
> bytes of storage on this system?
>
That was just an
On Mar 30, 2005, at 9:51 PM, zouq wrote:
in gcc3.4.1,i found rest_of_new_handle_regalloc
why in gcc4.0, it has been removed?
or haved changed its name?
because new-ra was ICEing on almost all target and almost all sources.
-- Pinski
in gcc3.4.1,i found rest_of_new_handle_regalloc
why in gcc4.0, it has been removed?
or haved changed its name?
Snapshot gcc-3.3-20050330 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/3.3-20050330/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 3.3 CVS branch
with the following options: -rgcc-ss-3_3-20050330
You'll
Jim Wilson wrote:
Moving trees around has worked for a long time, but it required
manually setting the GCC_EXEC_PREFIX environment variable.
Cygnus got this working reliably sometime in the early '90s I think.
In gcc-3.0 and later, there is code (make_relative_prefix) that
computes and sets G
Aldy Hernandez <[EMAIL PROTECTED]> writes:
> I need options only for certain subtargets. For example, aix.h has
> some options that should not be available by other targets.
Take a look at how this is done for the ia64-hpux port.
zw
Hi Richard.
I've been converting the ppc options to use the .opt machinery, and
am confused as to how to approach subtargets.
What's the deal with these?
I need options only for certain subtargets. For example, aix.h has
some options that should not be available by other targets.
I don't see a
On Mar 30, 2005, at 3:57 AM, Sanjiv Kumar Gupta wrote:
The relocation entry generated for this insn look like
symbol + addend.
The resultant value is beoyond the relocation size,
and results into relocation overflow.
Why is this not a bug in your reloc code in the assembler, OMF?
Dan Kegel wrote:
Moving an installed gcc/glibc crosstoolchain
to a different directory was not allowed
for gcc-2.96 and below, I seem to recall,
but became permissible around gcc-3.0.
Moving trees around has worked for a long time, but it required manually
setting the GCC_EXEC_PREFIX environment v
On Mar 30, 2005, at 11:23 AM, Toon Moene wrote:
The question is: is the total of these testcases (from one source)
within that limit ...
[ recalling from memory of past talks with FSF legal ] By submitting
a testcase to the FSF, the author extends rights to the FSF to
republish the testcase,
On Wed, 2005-03-30 at 14:19 -0500, Kazu Hirata wrote:
> Hi Jeff,
>
> > We'd have to go back and find the PR. I don't remember all the
> > details, but the problem was big enough to make ASSERT_EXPRs a
> > far inferior solution to the others I'd looked at for recording
> > context sensitive equiva
Daniel Berlin wrote:
I think we should just keep on doing what we do, which is produce small
minimized testcases that are well within the "de minimis" limits for
copyright, or even if they aren't, the tests don't actually do anything
useful from a program perspective.
The number of questionable tes
Hi Jeff,
> We'd have to go back and find the PR. I don't remember all the
> details, but the problem was big enough to make ASSERT_EXPRs a
> far inferior solution to the others I'd looked at for recording
> context sensitive equivalences.
Yes, inserting a bunch of ASSERT_EXPRs, updating SSA, run
On Wed, 2005-03-30 at 13:22 -0500, Diego Novillo wrote:
> On Wed, Mar 30, 2005 at 10:58:39AM -0700, Jeffrey A Law wrote:
>
> > Whatever scheme we use to explicitly expose context sensitive
> > equivalences in the IL needs to be a pure expression.
> >
> Well, that's the fundamental mechanism behi
On Wed, Mar 30, 2005 at 10:58:39AM -0700, Jeffrey A Law wrote:
> Whatever scheme we use to explicitly expose context sensitive
> equivalences in the IL needs to be a pure expression.
>
Well, that's the fundamental mechanism behind ASSERT_EXPRs and
VRP. Remember more details about the problem?
On Sun, 2005-03-27 at 20:08 -0500, Kazu Hirata wrote:
> Hi Diego,
>
> > By merging, do you mean *replacing* CCP with VRP? Yes, it's
> > doable. No, it's not a good idea.
>
> Understood.
>
> Also, if we are inserting ASSERT_EXPRs, it seems to be a good idea to
> run copy-prop before VRP. Other
> Richard Henderson
>> Ian Lance Taylor wrote:
>> OK, here is a different approach toward eliminating cc0, based on a
>> combination of my earlier proposal and what Alex described. I'm
>> looking for comments from anybody.
>
> One potential problem: once the NOTICE_UPDATE_CC pass is done, we
> ca
Sanjiv Kumar Gupta wrote:
> > What is stopping the value of 'foo' itself being > 255?
> Programmer will get an overflow error for that during linking.
For my curiosity, what's the background here? Do you really only have 256
bytes of storage on this system?
If you've got eight bit registers in a
Daniel Jacobowitz wrote:
On Tue, Mar 29, 2005 at 10:37:33PM -0800, Dan Kegel wrote:
Since I need to handle old versions of gcc, I'm
going to code up a little program to fix all
the embedded paths anyway, but I was surprised
by the paths in the pch file. Guess I shouldn't
have been, but now I'm a
Peter Barada wrote:
> I figured out how to make it work using LEGITIMIZE_RELOAD_ADDRESS(at
> least for gcc-3.4.3) via:
I seem to recall rth opposing any use of LEGITIMIZE_RELOAD_ADDRESS
to ensure *correctness* of generated code; L_R_A's only purpose
is supposed to provide additional optimizations
Nathan Sidwell wrote:
Sanjiv Kumar Gupta wrote:
calculated by linker. Now
add r1, foo
add r1, 10
add r1, -10
are okay but add r1, foo + 10
add r1, -10 are not, since (foo + 10) may overflow during
relocation, so the value (foo + 10) && 0xff inserted
by linker is not correct.
What is st
Sanjiv Kumar Gupta wrote:
calculated by linker.
Now
add r1, foo
add r1, 10
add r1, -10
are okay but
add r1, foo + 10
add r1, -10
are not, since (foo + 10) may overflow during
relocation, so the value (foo + 10) && 0xff inserted
by linker is not correct.
What is stopping the value of
--- Nathan Sidwell <[EMAIL PROTECTED]> wrote:
> Sanjiv Kumar Gupta wrote:
>
> >
> > Thanks for a prompt reply, Nathan.
> > The add insn can take a symbol_ref, which is
> converted
> > to const_int during relocation. But I don't want
> to
> > allow expressions like (const:SI (plus:SI
> > symbol_r
On Tue, Mar 29, 2005 at 10:37:33PM -0800, Dan Kegel wrote:
> Since I need to handle old versions of gcc, I'm
> going to code up a little program to fix all
> the embedded paths anyway, but I was surprised
> by the paths in the pch file. Guess I shouldn't
> have been, but now I'm a little less conf
On 2005-03-30, at 08:37, Dan Kegel wrote:
Since I need to handle old versions of gcc, I'm
going to code up a little program to fix all
the embedded paths anyway, but I was surprised
by the paths in the pch file. Guess I shouldn't
have been, but now I'm a little less confident
that this will work.
Sanjiv Kumar Gupta wrote:
Thanks for a prompt reply, Nathan.
The add insn can take a symbol_ref, which is converted
to const_int during relocation. But I don't want to
allow expressions like (const:SI (plus:SI
symbol_ref:SI) (const_int)) in the insn.
How should I do that, do I need to implement
LEG
Just FYI x-posted to linuxppc-embedded
Hello, James!
Thank you for your hints...
In the meanwhile as I experienced some other strange issues with my
gcc-3.3.3 toolchain, I concentrated to upgrade to the latest
mainstream gcc-3.4.3. It also failed during bootstrapping in
the beginning, but after a
--- Nathan Sidwell <[EMAIL PROTECTED]> wrote:
> Sanjiv Kumar Gupta wrote:
>
> > add symbol_ref + const_int, r1
> >
> > The relocation entry generated for this insn look
> like
> > symbol + addend.
> >
> > The resultant value is beoyond the relocation
> size,
> > and results into relocation ove
James E Wilson wrote:
Nathan Sidwell wrote:
My inclination is to simply add an additional check in the dwarf
outputter,
verifying that the initializer is indeed an INT_CST.
That is a simple solution, but it causes us to lose debug info.
correct -- but we also don't output such info for out-of-cl
Sanjiv Kumar Gupta wrote:
add symbol_ref + const_int, r1
The relocation entry generated for this insn look like
symbol + addend.
The resultant value is beoyond the relocation size,
and results into relocation overflow.
I guess CSE will not do this if I exclude constants
like symobol_ref + const_i
Hi,
Do we have GNU toolchain for blackfin processor?? Can anybody help me out in
this regard??
Regards,
Vinay
My port have insns like
add symbol_ref, r1
We emit relocation entries for symbol_ref.
Now CSE (-O2) combines insns like below
mov symbol_ref, r0
add const_int, r0
add r0, r1
to
add symbol_ref + const_int, r1
The relocation entry generated for this insn look like
symbol + addend.
The result
35 matches
Mail list logo
