ld either do it with a big bang approach
(making flags static and change all accesses) or gradually by not making
the flags static and gradually introducing the use of the
get_optimization_flag_value function over time.
2009-05-29 Steve Ellcey
PR middle-end/37565
PR target/37106
On Fri, 2009-05-29 at 09:38 -0700, Ian Lance Taylor wrote:
> Steve Ellcey writes:
>
> > So instead of
> > if (flag_var_tracking)
> > we would have
> > if (targetm.get_optimization_flag_value(OPT_fvar_tracking))
>
> I don't particularly want
n's complaint about an indirect function call but it
still means that the decision to do or not do var_tracking is kept in a
single variable that might or might not need to be overridden in some
case. But I guess in your proposal something in the opt file would tell
us if we want to override the default behaviour for var_tracking and
generate the code that would change it's value from the default.
Steve Ellcey
s...@cup.hp.com
don't have this problem.
Steve Ellcey
s...@cup.hp.com
On Thu, 2010-05-06 at 00:36 +0100, Dave Korn wrote:
> On 05/05/2010 18:18, Steve Ellcey wrote:
>
> > During the build libiberty is built in 64 bit mode
>
> But *which* libiberty? Host, build, or target?
That is a good question. I am building in obj and I have:
obj/lib
On Wed, 2010-05-05 at 10:42 -0700, H.J. Lu wrote:
> On Wed, May 5, 2010 at 10:18 AM, Steve Ellcey wrote:
> >
> > I was wondering if anyone has built GCC using a CFLAGS (and CXXFLAGS)
> > setting
> > that causes GCC to generate code that is not compatibile with
lted in a ICE in expand_expr_real_1. Any attempts to
change this function (or the address_mode function) seem to affect
other areas of the compilation and result in various ICE failures.
Any comments on the working patch or on where this change should
be made?
Steve Ellcey
s...@cup.hp.com
I don't see any other
tests in gcc.c-torture/execute that use this directive.
Steve Ellcey
s...@cup.hp.com
eck for TARGET_AUTO_PIC so
this could simplify the logic.
Steve Ellcey
s...@cup.hp.com
on to tm.h. I am testing that now.
Steve Ellcey
[EMAIL PROTECTED]
> > I still get implicitly declared errors for a couple of functions declared
> > in ia64-protos.h. I think the patch needs to be expanded to include
> > tm_p.h in addition to tm.h. I am testing that now.
>
> Shall I help? I have a fast sunfire here where I can cross check.
>
> I wait until you
> On Wed, Jan 25, 2006 at 01:01:17PM -0800, Steve Ellcey wrote:
> >
> > I took Zack's advice and put all the includes from insn-attrtab.c into
> > insn-automata.c. My current problem is that I get:
> >
> > | insn-automata.c: In function 'print_reserva
you go ahead and submit it when
your testing is done. If you don't want to submit it, I can do it.
Steve Ellcey
[EMAIL PROTECTED]
ble to
> fix any issues immediatley if they pop up.
>
> So, Steve, if you do not mind, would you please commit if you get the
> approval?
OK, I will submit this (with a ChangeLog) to gcc-patches and commit
it if/when approved.
Steve Ellcey
[EMAIL PROTECTED]
ata.c: In function 'print_reservation':
insn-automata.c:22466: warning: string length '669' is greater than the length
'509' ISO C89 compilers are required to support
make[3]: *** [insn-automata.o] Error 1
And when I look at the options used to compile insn-automata.c I see
-Werror but no subsequent -Wno-error.
Steve Ellcey
[EMAIL PROTECTED]
gcc.gnu.org) doesn't have a way to use
ssh to access the GCC tree. Is that correct? So how does he or she do
a checkout if the above method doesn't work due to a firewall? Are they
just out of luck?
Steve Ellcey
[EMAIL PROTECTED]
request failed on '/svn/gcc/trunk'
svn: PROPFIND of '/svn/gcc/trunk': could not connect to server
(http://gcc.gnu.org)
Steve Ellcey
[EMAIL PROTECTED]
to server
> > (http://gcc.gnu.org)
>
> It works here. Are you obliged to use a proxy server?
>
> Ben
Yes, I have to use a proxy server on my web browser.
Steve Ellcey
[EMAIL PROTECTED]
OK, I got it now. I edited ~/.subversion/servers and set
http-proxy-host and http-proxy-port and now things are working. I will
continue to use svn+ssh for my own work but it nice to know how to do it
with http when needed.
Steve Ellcey
[EMAIL PROTECTED]
have
libgomp built with the -lgcc_s option.
Any Help/Advice?
Steve Ellcey
[EMAIL PROTECTED]
> From: Richard Henderson <[EMAIL PROTECTED]>
> On Mon, Mar 06, 2006 at 11:32:01AM -0800, Steve Ellcey wrote:
> > | ld: (Warning) Symbol "__udivsi3" is not exported but is imported by a
> > shared library
> > | ld: (Warning) Symbol "__divsi3"
ry
has the necessary dependent libraries linked in to it when it is built.
I could fix this on the 1.4 branch but I am guessing that libtool
doesn't really want 1.4 fixes anymore and the problem is already handled
on the 1.5 branch so I was wondering if there are plans to move GCC to
a 1.5 libt
> On Fri, Mar 17, 2006 at 02:59:26PM -0800, Steve Ellcey wrote:
> >
> > I was wondering if there are any plans to move the libtool that is in
> > the GCC tree to 1.5? The current libtool in GCC appears to be based on
> > the 1.4 version and the real libtool pr
CTED] (CodeSourcery mail)
> [EMAIL PROTECTED] (Bugzilla assignments and CCs)
So when we finally do move to a newer libtool we will move to the
unreleased libtool main line? I guess I was assuming we would move to a
stable released libtool, but that was just an assumption on my part.
Steve Ellcey
[EMAIL PROTECTED]
, and if so,
which one should be used?
Steve Ellcey
[EMAIL PROTECTED]
I wouldn't need to do
any actual checkins for those changes. If we can do that then the only
thing I would need to change by hand would be the intl text that is in
the MAINTAINERS file.
Who maintains this automatic merge process?
Steve Ellcey
[EMAIL PROTECTED]
any
suggestions as to what products or platforms might cause problems?
I did get one reply from a combined-tree user who said they used the gcc
version of intl when building things in a combined-tree.
Steve Ellcey
[EMAIL PROTECTED]
e new intl directory with no problems and
I am willing to try and fix any problems caused by the change if other
platforms have problems with it.
2006-05-19 Steve Ellcey <[EMAIL PROTECTED]>
* MAINTAINERS: Change intl updating instructions.
* config.rpath: Copy fr
you do now.
intl changes even less than libiberty does. The src version of intl has
4 changes since January of 2002. The GCC version has 8 changes since
Zack put the gettext 0.12.1 version in back in July 2003.
Steve Ellcey
[EMAIL PROTECTED]
I am trying to make a configure change in the libstdc++-v3 directory but
when I run aclocal (even on an unmodified libstdc++-v3 directory from
the top-of-tree), I get an error message. Does anyone else see this?
[hpsje] $ aclocal
aclocal:configure.ac:85: warning: macro `AM_PROG_LIBTOOL' not foun
get no errors or warnings when running
aclocal.
Thanks for the tip.
Steve Ellcey
[EMAIL PROTECTED]
-target_board 'unix{-mlp64,-milp32}" to "--target_board
'unix{,-mlp64}" and had problems. I notice that HJ's example
has the -m32 in the first position, not the last.
Jack, does it work for you if you use "unix{-m64,}" instead of
"unix{,-m64}"?
Steve Ellcey
[EMAIL PROTECTED]
us [remote_wait $dest 300]' to 'set status [remote_wait $dest
2000]'
It may not be the right way to do it but it has worked for me.
Steve Ellcey
[EMAIL PROTECTED]
vailable on hppa and ia64 machines so any OS issues found while testing
on hppa might actually affect both hppa and ia64.
Steve Ellcey
[EMAIL PROTECTED]
each block on this path
to make sure it doesn't change the value of 's' since there may be paths
that change 's' as well as paths that don't.
Does anyone have any ideas on a more efficient way to find the paths I am
looking for or have any other comments on this optimization?
Steve Ellcey
sell...@imgtec.com
re into
the GCC implementation and what constraints there are and why they
prevent its use in CoreMark.
Steve Ellcey
sell...@imgtec.com
On Fri, 2013-03-22 at 13:00 -0600, Jeff Law wrote:
> There's a BZ for this issue with a bit more state for this issue.
>
> jeff
Found it. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54742
Steve Ellcey
sell...@imgtec.com
node? Or could the block with the definition be an
indirect predecessor of the block with the phi? Does it matter what
pass in the compiler I am at? I.e. maybe they start out as direct
predecessors and various optimizations could change that.
Steve Ellcey
sell...@imgtec.com
and block 3, and there is an edge
from 8 to 3, does copy_bbs automatically create a new edge pointing from the
copy of block 8 to block 3 and replace that in the copied blocks? I think it
does, but I am not sure.
Steve Ellcey
sell...@imgtec.com
Output from the test program using my new optim
er my pass has changed the code. I think I need to do more to fix
any PHI nodes in B and B' but I am not sure what. I also notice that
copy_bbs in cfghooks (which calls duplicate_block) has calls to
get_immediate_dominator and set_immediate_dominator, maybe I need to
copy that code as well?
Steve Ellcey
sell...@imgtec.com
On Wed, 2013-04-24 at 14:31 -0600, Jeff Law wrote:
> On 04/24/2013 11:38 AM, Steve Ellcey wrote:
> Just do duplicate_block (B, NULL, NULL)
>
> Then I'd remove the switch statement and the outgoing edges from B'
> except the edge B'->C.
>
>
On Wed, 2013-04-24 at 15:54 -0700, Steve Ellcey wrote:
>
> /* Copy the basic block that is the destination block of orig_edge, then
>modify/replace the edge in orig_edge->src basic block with a new edge
>that goes to the new block. Fix up any PHI nodes that may need to
the dominator information so it gets
recalculated from scratch or something like that?
Steve Ellcey
sell...@imgtec.com
erate everything before doing the second block but that didn't seem
to work.
Steve Ellcey
sell...@imgtec.com
I tried putting /home/sellcey/plugin/dynopt.so in single quotes, that
did not help either.
Steve Ellcey
sell...@imgtec.com
rror: unrecognized command line option '-msellcey'
xgcc: error: unrecognized command line option '-mplugin'
xgcc: error: unrecognized command line option '-mdynopt.so'
Steve Ellcey
sell...@imgtec.com
using gimple_duplicate_sese_region as is.
Comments?
Steve Ellcey
sell...@imgtec.com
/* Alias analysis for GNU C
Copyright (C) 2013 Free Software Foundation, Inc.
Contributed by Steve Ellcey (sell...@imgtec.com).
This file is part of GCC.
GCC is free software; you can redistribute it and/or modi
Is anyone else seeing this build failure with ToT GCC? I am
building the mips-mti-linux-gnu target on an x86 linux box and
the libgcc build fails because the newly built GCC is dying.
Before I try to figure out which patch broke this I wanted to see
if anyone already knows about it.
Steve
aused by
libgfortran/intrinsics/time_1.h defining localtime_r as a static function
(because HAVE_LOCALTIME_R is not set) after seeing a non-static definition
from include/time.h (part of newlib).
As anyone run into this or know how to fix it?
Steve Ellcey
sell...@mips.com
I have an instruction scheduling question I was hoping someone could help me
with. Specifically, I am trying to figure out where and how GCC is deciding
to move the add of a constant to a register above the use of that register and
then changing the register usage by change the offsets associated
PENDENCIES flag in the haifa scheduler. As an experiment,
I added DONT_BREAK_DEPENDENCIES to the scheduling flags and it no longer
did that transformation.
Thanks.
Steve Ellcey
sell...@mips.com
void the '-4' offsets that are used.
Ideally, one would think that GCC should generate the same code
for both of these loops but it does not.
Steve Ellcey
sell...@mips.com
lize I should try running my test
with -fno-ivopts. That got rid of the '-4' usage and I wound up getting
the code that I was after. I still hope someone can help me understand
why ivopts made the transformation it did though. I am afraid that just
turning off ivopts may have a larger affect then I am after.
Steve Ellcey
sell...@mips.com
$3. I think what I need to
fix this is a target specific way to modify the cost calculations before
the IV variables are chosen.
Steve Ellcey
sell...@mips.com
during the make process, it
looks like it didn't get made correctly for you. You might be missing
some tool (grep, awk, etc) that is needed when making option.h.
Steve Ellcey
sell...@mips.com
allowing these tests to pass with -mhard-float.
If I run with -msoft-float then -msym32 never gets set and the test fails.
Should addressing=absolute be set here for soft-float in mips.exp
or do you think these two tests should just not be run in soft-float mode?
Steve Ellcey
sell...@mips.com
On Tue, 2013-07-30 at 20:32 +0100, Richard Sandiford wrote:
> "Steve Ellcey " writes:
> > I have noticed that gcc.target/mips/fpr-moves-7.c and
> > gcc.target/mips/fpr-moves-8.c fail when running the GCC
> > testsuite with -msoft-float.
>
> Which configurati
fixed the problem.
Steve Ellcey
sell...@mips.com
re of the
floating point registers that I was hoping for. If I call
__builtin_mips_switch_fp_mode(0) explicitly then I do see the fp
registers get saved and restored.
Steve Ellcey
sell...@mips.com
diff --git a/gcc/config/mips/mips-ftypes.def b/gcc/config/mips/mips-ftypes.def
index 1268c53..7c
e having access to the FPU unit in FR1 mode
may be advantageous enough to accept the cost of saving and restoring
the FP registers but where we still need to be ABI compatible with fp32
code.
Steve Ellcey
sell...@mips.com
ne if $f0
is used for a return value by using mips_return_mode_in_fpr_p but I
can't find something equivalent for argument registers. Any ideas?
Steve Ellcey
sell...@mips.com
no fenv.h in the newlib headers to include.
The problem seems to be that GLIBCXX_CHECK_C99_TR1 is using the C++
compiler to check for fenv.h and not the C compiler. But that choice
seems to be intentional so I am not sure what to do about it.
Steve Ellcey
sell...@mips.com
unds because then, when
GLIBCXX_CHECK_C99_TR1 checks for the headers, it uses the saved values
which will be false if the headers don't exist in C.
Steve Ellcey
sell...@mips.com
char *) finds
the caddr_t type and all is fine. When building a canadian cross on
linux using the mingw compilers then the check for caddr_t fails
and auto-host.h winds up with "#define caddr_t char *" in it and that
causes a build failure later on.
Steve Ellcey
sell...@mips.com
lag and I don't want to override the options used when building the
libraries anyway, only the options used to build executables.
Am I setting the wrong CFLAGS/CXXFLAGS variables? Or is this a bug?
Steve Ellcey
sell...@mips.com
On Fri, 2013-11-22 at 13:48 -0800, H.J. Lu wrote:
> On Fri, Nov 22, 2013 at 1:24 PM, Steve Ellcey wrote:
> >
> > I am building a cross GCC (targeting MIPS) on an x86-64 Linux system but I
> > want to build the compiler as a 32 bit executable. I thought the right way
>
On Mon, 2013-12-09 at 08:21 +1300, Maxim Kuvyrkov wrote:
> I'm looking into this.
>
> Thanks,
>
> --
> Maxim Kuvyrkov
> www.kugelworks.com
My mips-mti-linux-gnu build is working after I applied this patch
locally. I didn't do a test build of mips64-linux-gnu.
I don't have a test case that I can include (EEMBC is licensed).
Steve Ellcey
sell...@mips.com
On Fri, 2013-12-13 at 11:26 +0100, Richard Biener wrote:
> On Thu, Dec 12, 2013 at 8:19 PM, Steve Ellcey wrote:
> > I have a question about the partial pre (-ftree-partial-pre) optimization
> > that was added in GCC 4.8. I have noticed that this optimization is slowing
> &
easier to add new flags later, especially if
someone is just adding a flag temporarily as an experiment to test
something.
Does this sound reasonable to you? If so what flags do you think we
might want to move out of target_flags to a different variable?
Steve Ellcey
sell...@mips.com
be enough for now. Here is the patch I came up with
and tested. I had to tweak a couple of things in
gcc/common/config/mips/mips-common.c so I wouldn't mind if you took a
look at it before I checked it in. Testing looked all right once I
initialized TARGET_FP_EXCEPTIONS and TARGET_FU
he explanation
and change the MIPS scan? Should I leave avr and arc alone (split them
off from mips) since I have no evidence that they are failing?
Steve Ellcey
sell...@mips.com
"the %qs architecture does not support the synci "
"instruction", mips_arch_info->name);
target_flags &= ~MASK_SYNCI;
}
Ideally, this warning should only be printed if the user explicitly asked
for -msynci, not if -msynci was merely set as the default. But I
On Wed, 2012-05-30 at 14:27 -0400, David Edelsohn wrote:
> On Wed, May 30, 2012 at 1:39 PM, Steve Ellcey wrote:
> >
>
> > My question is: When checking the value of TARGET_SYNCI is there anyway
> > to tell if the flag was set explicitly by the user or implicitly by
>
cause the driver added it, even though it is
not on the users gcc command line and I cannot tell if the user had
-msynci on his or her GCC command line or if the driver added it automatically.
Does anyone have any ideas on telling the two cases apart?
Steve Ellcey
sell...@mips.com
e prepended
> special switch or after the appended special switch comes from the driver.
Yuck. I think that suppressing the warning is the right thing to do,
but I am not sure it is worth this much effort. Changing the testsuite
is easier.
Steve Ellcey
sell...@mips.com
AC_PROG_CPP_WERROR in config/acx.m4 and I see it sets
ac_c_preproc_warn_flag to 'yes' but it is not clear to me what affect
that has in the configure script, if any.
I would be happy to submit a patch for this, I am just not sure what
the right fix is.
Steve Ellcey
sell...@mips.com
uld like a MULTILIB_EXTRA_OPTS type variable that could add
extra flags to some multilib versions but not others. That doesn't
seem to exist though.
Anyone have any ideas on how to deal with this problem?
Steve Ellcey
sell...@mips.com
On Tue, 2012-06-19 at 20:59 +, Joseph S. Myers wrote:
> On Tue, 19 Jun 2012, Steve Ellcey wrote:
>
> > I am building a multilib mips compiler using '--with-synci' on the
> > configure line. This means that gcc will pass the '-msynci' option
> >
want using explicit or default flag settings.
Steve Ellcey
sell...@mips.com
an mode, the original bug was found on a little-endian system.
Any advice or help?
Steve Ellcey
sell...@mips.com
registers so I think gcc should just not put out
any debug information for this register variable. Is that
possible? I couldn't find anyway to do it in GCC. Or should
GCC just put out the register number for DBX_REGISTER_NUMBER
instead of INVALID_REGNUM even if gdb may choke on it?
Steve Ellcey
sell...@mips.com
the basis of
bug 54128, a bootstrap failure on MIPS, though the problem seems generic
to any system with delay slots.
Steve Ellcey
sell...@mips.com
bug instructions but Jakub Jelinek thought
that that was not fixing the real bug but compensating for another
problem. He was right and that other problem is the variable tracking /
delay slot conflict.
Steve Ellcey
sell...@mips.com
gnu target
but not with the mips-mti-elf target. I don't see what difference in
these targets is causing the difference in behaviour.
Does anyone know what routines or variables I should be looking at?
Steve Ellcey
sell...@mips.com
g directory
`/local/home/sellcey/gcc/libatomic/obj-mips-mti-linux-gnu/gcc/final/mips-mti-linux-gnu/libatomic'
make[1]: *** [check-recursive] Error 1
make[1]: Leaving directory
`/local/home/sellcey/gcc/libatomic/obj-mips-mti-linux-gnu/gcc/final/mips-mti-linux-gnu/libatomic'
make: *** [che
f we
should change GCC in someway to make the _MIPS_ISA macro more useful.
Or should we just ignore this macro and get people to use __mips or one
of the other macros instead?
Steve Ellcey
steve.ell...@imgtec.com (Previously sell...@mips.com)
was wondering why we don't use something like ARM has.
I.e.:
const int mips_reg_alloc_order[] = REG_ALLOC_ORDER;
memcpy(reg_alloc_order, mips_reg_alloc_order, sizeof (reg_alloc_order));
Steve Ellcey
sell...@imgtec.com
per speed testing. In the end I'm afraid I just let it drop.
>
> Thanks,
> Richard
I'll try your patch on some of my benchmarks and see what happens.
One interesting thing I have noticed (sizewise) is that not using t0-t7
at all in MIPS16 code resulted in a code size reduction of around 1%.
Steve Ellcey
memory while
having GCC recognize that they are not 'normal' registers that you can
do operations on and should not be part of the normal register
allocation scheme.
Steve Ellcey
7;t seem to cause bootstrap problems it does seem to cause
problems when building the older GCC version that is in SPEC2000. Any
advise on how to proceed from here?
Steve Ellcey
[EMAIL PROTECTED]
> Steve Ellcey wrote:
> > I am investigating a bad code generation bug on the 64 bit HPPA platform
> > with GCC 4.3.0 and would like some help and/or ideas on how to analyze
> > and fix it. The failing test is the SPEC 2000 GCC benchmark (version
> > 2.7.2.2) and I h
> From: Peter Bergner <[EMAIL PROTECTED]>
>
> On Wed, 2008-05-07 at 07:45 -0700, Steve Ellcey wrote:
> > I have found that this problem does not occur on the ToT sources and
> > that the problem went away with this patch:
> >
> > 2008-04-07 Peter Bergner
bout the idea of putting Peter's patch (with the revert) on the 4.3
branch as a way to fix the HPPA bad code generation bug. I am going to
test that patch on the branch and verify that it fixes my SPEC/GCC
failure.
Steve Ellcey
[EMAIL PROTECTED]
at patch since it seems to be related to the
other changes. I will include it in my 4.3 branch testing.
Steve Ellcey
[EMAIL PROTECTED]
ight, the use of r8 and r19 in the ldw
instruction are switched around. And in fact, when I created an
assembly language file, swapped them around by hand, and then assembled
the result and built an executable, everything seemed to work OK (I did
not get a segfault).
Steve Ellcey
[EMAIL PROTECTED]
hange to loop-invariant.c, though that change should be
preserving REG_POINTER's during optimization not preventing them.
I have tested a port of Peter's changes (already on the main line) to
the 4.3 branch. It does fix the problem and it causes no regressions on
hppa. My current inclination is to submit that patch to gcc-patches as
a backport to the branch.
Steve Ellcey
[EMAIL PROTECTED]
point and that version number
doesnt' seem to exist:
$ svn update -r138077
svn: Target path does not exist
At least I think that is what this error means.
What is going on?
Steve Ellcey
[EMAIL PROTECTED]
get rid of the unsigned_type langhook. Looks like he is
already working on a partial revert to fix the problem.
See
http://gcc.gnu.org/ml/gcc-patches/2007-05/msg00958.html
Steve Ellcey
[EMAIL PROTECTED]
e the 'W'
suffix for a __float80 constant on HP-UX. HP-UX also uses a lower case
'w' in math names for functions (e.g. sqrtw) for __float80 functions.
Since __float128 == long double on HP-UX we can just use 'L' and 'l' for
those.
None of which helps on Linux.
Steve Ellcey
[EMAIL PROTECTED]
201 - 300 of 310 matches
Mail list logo
