On Fri, Jan 06, 2006 at 02:48:30PM -0800, Richard Henderson wrote:
> What they're looking for is, for functions that don't use
> the pic register, to not reserve the pic register so that
> it's available for computation. This is harder. In theory,
> ppc has some scheme for this, where they elimi
On 5/14/07, Jason Merrill <[EMAIL PROTECTED]> wrote:
Mark Mitchell wrote:
> I agree in principle -- much better the bugs we know than the ones we
> don't. But, IIUC, the patch we'd be reverting is from March, 2006,
> which means that there's potentially a lot more that depends on it. In
> that
"Richard Guenther" <[EMAIL PROTECTED]> writes:
> It was a patch to enable more optimization. Reverting it should be as safe
> or unsafe as exchanging forwprop and dce passes. And I have no idea
> as how to quantify safeness of either ;)
>
> I'd say we better analyze what goes wrong (as the probl
On 5/14/07, Serge Belyshev <[EMAIL PROTECTED]> wrote:
"Richard Guenther" <[EMAIL PROTECTED]> writes:
> It was a patch to enable more optimization. Reverting it should be as safe
> or unsafe as exchanging forwprop and dce passes. And I have no idea
> as how to quantify safeness of either ;)
>
>
Hi All,
I am adding profiling support for a private embedded target (GCC
4.1.1). I have implemented the profiling library, which includes
mcount, mcleanup, monstartup, moncontrol. For Histogram records, i
need to have the "profil" system call. But my target library does not
contain "profil" syste
On 12 May 2007 19:05, Aaron Gray wrote:
> I think I have found some bugs in genautomata.c
>
> regexp = create_node( sizeof( struct decl));
>
> I believe this should be :-
>
> regexp = create_node( sizeof( struct regexp));
>
> Lines :-
>
> 1546
> 1551
>
> Compare with :-
>
>
On 5/14/07, Dave Korn <[EMAIL PROTECTED]> wrote:
On 12 May 2007 19:05, Aaron Gray wrote:
> I think I have found some bugs in genautomata.c
>
> regexp = create_node( sizeof( struct decl));
>
> I believe this should be :-
>
> regexp = create_node( sizeof( struct regexp));
>
> Lines :-
>
>
> Looks like you're right to me. We get away with it because a decl is larger
> than a regexp. Testing a patch now.
this would be fixed by my patch here
http://gcc.gnu.org/ml/gcc-patches/2007-05/msg00814.html
which is not reviewed yet. The patch switches to typesafe memory
allocation, which u
On 14 May 2007 12:40, Wei Chen wrote:
> help~~
> where is the statement?
At the line numbers Aaron mentioned of the latest rev of genautomata.c
> in whichi function?
gen_regexp_el
> i can't confirm them now!
Please see http://gcc.gnu.org/ml/gcc-patches/2007-05/msg00882.html
cheers
On 5/14/07, Dave Korn <[EMAIL PROTECTED]> wrote:
On 14 May 2007 12:40, Wei Chen wrote:
> help~~
> where is the statement?
At the line numbers Aaron mentioned of the latest rev of genautomata.c
> in whichi function?
gen_regexp_el
> i can't confirm them now!
Please see http://gcc.gnu.or
On 5/14/07, Dave Korn <[EMAIL PROTECTED]> wrote:
On 14 May 2007 12:40, Wei Chen wrote:
> help~~
> where is the statement?
At the line numbers Aaron mentioned of the latest rev of genautomata.c
> in whichi function?
gen_regexp_el
> i can't confirm them now!
Please see http://gcc.gnu.or
Running with gdb, it looks like the problem comes from the
ppc_closure.S file of the libffi/src/powerpc directory, at line 32 :
stfd %f1, 48(%r1)
I don't understand anything to powerpc assembly, but after a google
search, "stfd" means "store floating-point double". But the PPC405
doesn't have an
Patrick Olinet wrote:
Running with gdb, it looks like the problem comes from the
ppc_closure.S file of the libffi/src/powerpc directory, at line 32 :
stfd %f1, 48(%r1)
I don't understand anything to powerpc assembly, but after a google
search, "stfd" means "store floating-point double". But the
[top-posting fixed]
Patrick Olinet writes:
> On 5/8/07, Andrew Haley <[EMAIL PROTECTED]> wrote:
> > Patrick Olinet writes:
> > > Hi there,
> > >
> > > I'm running an embedded platform based on a powerpc 405EP CPU and a
> > > gcc 4.1.0 cross-toolchain. My initial problem was that gcj comp
There are problems with :-
print-rtl.c:395
c-common.c:4099
c-pretty-print.c:822
dwarf2asm.c:56
dwarf2out.c:...
It seems to be a unsigned issue to do with HOST_WIDE_INT_PRINT_HEX,
HOST_WIDE_INT_PRINT_DOUBLE_HEX and friends.
Aaron
> I've compiled again my cross toolchain with the "--with-float=soft"
> option, hoping that it would emulate FPU instruction, but this
> unfortunately doesn't help... I'm nevertheless not sure that this
> option is the right one...
If your entire toolchain is compiled with --with-float=soft, then
Patrick Olinet writes:
> > > I've compiled again my cross toolchain with the "--with-float=soft"
> > > option, hoping that it would emulate FPU instruction, but this
> > > unfortunately doesn't help... I'm nevertheless not sure that this
> > > option is the right one...
> >
> > If your entire
On 14 May 2007 18:48, Aaron Gray wrote:
> There are problems with :-
>
> print-rtl.c:395
> c-common.c:4099
> c-pretty-print.c:822
> dwarf2asm.c:56
> dwarf2out.c:...
>
> It seems to be a unsigned issue to do with HOST_WIDE_INT_PRINT_HEX,
> HOST_WIDE_INT_PRI
I'm seeing:
../../gcc/gcc/dwarf2out.c: In function ‘print_die’:
../../gcc/gcc/dwarf2out.c:5772: error: format ‘%4lu’ expects type
‘long unsigne
d int’, but argument 3 has type ‘dw_offset’
../../gcc/gcc/dwarf2out.c:5775: error: format ‘%lu’ expects type ‘long
unsigned
int’, but argument 3 h
On May 13, 2007, at 3:32 AM, Rask Ingemann Lambertsen wrote:
On Fri, Jan 06, 2006 at 02:48:30PM -0800, Richard Henderson wrote:
What they're looking for is, for functions that don't use
the pic register, to not reserve the pic register so that
it's available for computation. This is harder. I
On May 14, 2007, at 8:46 AM, Patrick Olinet wrote:
Running with gdb, it looks like the problem comes from the
ppc_closure.S file of the libffi/src/powerpc directory, at line 32 :
Maybe something like:
#ifndef _SOFT_FLOAT
stfd %f1, 48(%r1)
#endif
but then, you might have to have something li
On May 14, 2007, at 11:27 AM, Mike Stump wrote:
I'm seeing:
If I do this:
it gets farther.
Next error would be:
../../gcc/gcc/sched-vis.c: In function ‘print_value’:
../../gcc/gcc/sched-vis.c:433: error: format ‘%lx’ expects type ‘long
unsigned int’, but argument 3 has type ‘long int’
..
SVN update to revision 124718, configured as:
../../svn/gcc/configure
--prefix=/home/daniel/nfs/packages/i686-pc-linux-gnu/gcc
--with-gmp=/home/daniel/nfs/packages/i686-pc-linux-gnu/gmp-4.2.1/
--with-mpfr=/home/daniel/nfs/packages/i686-pc-linux-gnu/mpfr-2.2.1
--disable-nls --enable-threads=po
On May 14, 2007, at 11:35 AM, Mike Stump wrote:
On May 14, 2007, at 8:46 AM, Patrick Olinet wrote:
Running with gdb, it looks like the problem comes from the
ppc_closure.S file of the libffi/src/powerpc directory, at line 32 :
Maybe something like:
#ifndef _SOFT_FLOAT
stfd %f1, 48(%r1)
#e
On 14 May 2007 19:28, Mike Stump wrote:
> I'm seeing:
>
> ../../gcc/gcc/dwarf2out.c: In function ‘print_die’:
> ../../gcc/gcc/dwarf2out.c:5772: error: format ‘%4lu’ expects type
> ‘long unsigne
> d int’, but argument 3 has type ‘dw_offset’
> ../../gcc/gcc/dwarf2out.c:5775: error: format ‘%lu’ exp
On 5/14/07, Mike Stump <[EMAIL PROTECTED]> wrote:
it gets farther. Anyone want to claim this is obvious? I glanced at
the code and it seems reasonable.
Nothing has changed in dwarf2out.c since April 24.
Now on the other hand c-format.c changed, which might have been the
problem in the first
> I thought that fpu emulation worked by trapping cpu exceptions when a
> fpu instruction is being executed and then emulating this instruction
> on software level.
Yes.
> Isn't the mechanism implemented by the "--with-float=soft" option ?
No. FPU emulation requires no special compile-time
On 14 May 2007 18:48, Aaron Gray wrote:
There are problems with :-
print-rtl.c:395
c-common.c:4099
c-pretty-print.c:822
dwarf2asm.c:56
dwarf2out.c:...
It seems to be a unsigned issue to do with HOST_WIDE_INT_PRINT_HEX,
HOST_WIDE_INT_PRINT_DOUBLE_HEX and
On 5/14/07, Mike Stump <[EMAIL PROTECTED]> wrote:
On May 14, 2007, at 11:27 AM, Mike Stump wrote:
> I'm seeing:
>
> If I do this:
> it gets farther.
Next error would be:
../../gcc/gcc/sched-vis.c: In function 'print_value':
../../gcc/gcc/sched-vis.c:433: error: format '%lx' expects type 'long
On 14 May 2007 20:06, Aaron Gray wrote:
>> On 14 May 2007 18:48, Aaron Gray wrote:
>>
>>> There are problems with :-
>>>
>>> print-rtl.c:395
>>> c-common.c:4099
>>> c-pretty-print.c:822
>>> dwarf2asm.c:56
>>> dwarf2out.c:...
>> Would you mind trying agai
On 5/14/07, Daniel Franke <[EMAIL PROTECTED]> wrote:
SVN update to revision 124718, configured as:
../../svn/gcc/configure
--prefix=/home/daniel/nfs/packages/i686-pc-linux-gnu/gcc
--with-gmp=/home/daniel/nfs/packages/i686-pc-linux-gnu/gmp-4.2.1/
--with-mpfr=/home/daniel/nfs/packages/i686-pc-
On May 14, 2007, at 11:53 AM, Eric Christopher wrote:
On May 14, 2007, at 11:35 AM, Mike Stump wrote:
On May 14, 2007, at 8:46 AM, Patrick Olinet wrote:
Running with gdb, it looks like the problem comes from the
ppc_closure.S file of the libffi/src/powerpc directory, at line 32 :
Maybe so
Mike Stump wrote:
On May 14, 2007, at 11:53 AM, Eric Christopher wrote:
On May 14, 2007, at 11:35 AM, Mike Stump wrote:
On May 14, 2007, at 8:46 AM, Patrick Olinet wrote:
Running with gdb, it looks like the problem comes from the
ppc_closure.S file of the libffi/src/powerpc directory, at l
On 5/14/07, Mike Stump <[EMAIL PROTECTED]> wrote:
it gets farther. Anyone want to claim this is obvious? I glanced at
the code and it seems reasonable.
Nothing has changed in dwarf2out.c since April 24.
Now on the other hand c-format.c changed, which might have been the
problem in the first
I have had the misfortune to discover a reload inheritance bug which,
after a long period of analysis, has turned out to be very similar to
the situation described by Richard Sandiford in
http://gcc.gnu.org/ml/gcc-patches/2007-01/msg01977.html.
This being my first serious foray into reload, I wou
Does anyone have an opinion on the following apparently redundant stuff?
static enum gimplify_status
gimplify_compound_lval (tree *expr_p, tree *pre_p,
tree *post_p, fallback_t fallback)
[...]
So we do this in three steps. First we deal with the annotations
for a
> In order to fix this I think that reload1.c:emit_reload_insns should,
> at the point of discovery of an input reload whose reload register is a
> non-spill hard register H, invalidate all previous reloads involving
> that hard register.
If the reload is inherited, and there is no non-input part
Snapshot gcc-4.1-20070514 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20070514/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.1 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
This isn't that important, but ...
I just noticed the ABOUT-NLS file in the top of the tree. It seems to be
wildly out of date, listing many fewer translations than currently exist.
For example, in gcc/po we have be,ca,da,de,el,es,fr,ja,nl,ru,rw,sr,sv,
tr,zh_CN,and zh_TW. But according to ABOUT-
On Mon, May 14, 2007 at 10:47:13PM +0100, Mark Shinwell wrote:
[snip]
> - the last use of reg2 (in B) is inside a matched input operand;
[snip]
>
> The reload used for the instruction at B looks like this:
>
> Reload 0: reload_in (SI) = (plus:SI (reg/f:SI 9 r9 [3275])
>
Joe Buck wrote:
> the ABOUT-NLS file in the top of the tree. It seems to be wildly out of date
Yes, it is from May 2003.
You find the newest official ABOUT-NLS file in the gettext-0.16.1 distribution
on ftp.gnu.org.
Bruno
On Tue, May 15, 2007 at 02:12:56AM +0200, Bruno Haible wrote:
> Joe Buck wrote:
> > the ABOUT-NLS file in the top of the tree. It seems to be wildly out of
> > date
>
> Yes, it is from May 2003.
>
> You find the newest official ABOUT-NLS file in the gettext-0.16.1 distribution
> on ftp.gnu.org.
The following are failing:
Running /mnt/sdb2/gcc43/gcc/testsuite/gfortran.dg/dg.exp ...
FAIL: gfortran.dg/interface_12.f90 -O2 execution test
FAIL: gfortran.dg/interface_12.f90 -O3 -fomit-frame-pointer execution test
FAIL: gfortran.dg/interface_12.f90 -O3 -fomit-frame-pointer -funroll-loops
With revision 124738:
cc1: warnings being treated as errors
/home/fxcoudert/gfortran_nightbuild/trunk/gcc/print-rtl.c: In
function ‘print_rtx’:
/home/fxcoudert/gfortran_nightbuild/trunk/gcc/print-rtl.c:397: error:
format ‘%lx’ expects type ‘long unsigned int’, but argument 3 has
type ‘long
On Mon, May 14, 2007 at 10:35:42PM -0700, Jerry DeLisle wrote:
> The following are failing:
>
> Running /mnt/sdb2/gcc43/gcc/testsuite/gfortran.dg/dg.exp ...
> FAIL: gfortran.dg/interface_12.f90 -O2 execution test
> FAIL: gfortran.dg/interface_12.f90 -O3 -fomit-frame-pointer execution test
> FA
In handle_aligned_attributes in c-common.c, at line 5146, it does
type = &TREE_TYPE (decl);
Then at 5179 it does
TREE_TYPE (decl) = *type;
In between, type doesn't change so that's really
TREE_TYPE (decl) = * &TREE_TYPE (decl);
or
TREE_TYPE (decl) = TREE_TYPE
46 matches
Mail list logo
