> Note that I opened PR ada/26296: "cxg2007 cxg2012 verify_flow_info
> failed" I'm seeing on x86_64-linux, may be something was recently broken
> on exception handling code and this could show up differently on hppa.
No, that's a different problem.
--
Eric Botcazou
H. J. Lu wrote:
I have got massive FORFRAN test failures on Linux/ia64 and
Linux/x86-64:
It looks like the patch for fortran/25045
http://gcc.gnu.org/ml/fortran/2006-02/msg00111.html has affected
stability of 178.galgel, 187.facerec and 189.lucas benchmarks of cpu2000
suite and caused these
Note that I opened PR ada/26296: "cxg2007 cxg2012 verify_flow_info
failed" I'm seeing on x86_64-linux, may be something was recently broken
on exception handling code and this could show up differently on hppa.
Laurent
On Mon, 2006-02-13 at 10:04 +0100, Rainer Emrich wrote:
> -BEGIN PGP SIGNE
I have got massive FORFRAN test failures on Linux/ia64 and
Linux/x86-64:
http://gcc.gnu.org/ml/gcc-testresults/2006-02/msg00730.html
http://gcc.gnu.org/ml/gcc-testresults/2006-02/msg00729.html
Most of failures look like:
/net/gnu-13/export/gnu/src/gcc/gcc/gcc/testsuite/gfortran.dg/char_result_11
Aldy Hernandez wrote:
> Do we keep a hash of functions that have been written out somewhere?
Not to my knowledge.
> I'd hate to walk the entire hash table each time we write out a function
> searching for the types that function uses.
Agreed.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(6
> The final reason are immediates. I can't have 16 bits immediates in my
> opecode,
Not a problem; gcc knows how to use two insns to load immediates like
that. MIPS does it. Actually, most RISC processors end up doing
that. What you *would* want, though is a "load sign-extended
immediate" for
DJ Delorie wrote:
>> * 8 bit RISC microcontroller
>
> Not 16?
Well, at first it was to save space in the FPGA (basically, the regs and
ALU takes twice the space) and because many 16 bits ops can be done with
8 bits regs and lots of the code I do can live with that.
But I had a quick glance
> * 8 bit RISC microcontroller
Not 16?
> * 16 general purpose registers
> * 16 level deep hardware call stack
If you have RAM, why not use it? Model calls like the PPC - put
current $pc in a register and jump. The caller saves the old $pc in
the regular stack. GCC is going
Hello,
I'm currently considering writing my own microcontroller to use on
a FPGA. Since I'd like to be able to use C to write
"non-timing-critical" parts of my code, I thought I'd include a gcc port
as part of the design considerations.
I've read the online manual about gcc backend and googled
Snapshot gcc-3.4-20060214 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/3.4-20060214/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 3.4 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
On Tue, Feb 14, 2006 at 01:59:21PM -0800, Jim Wilson wrote:
> H. J. Lu wrote:
> >PR rtl-optimization/25603
> >* reload.c (reg_inc_found_and_valid_p): New.
> > (regno_clobbered_p): Handle REG_INC as 25603 workaround.
>
> I don't believe this is safe. If you look at the uses of
Hans-Peter Nilsson wrote:
PS. No, I don't know why the simple "some search terms" doesn't work.
Probably because simple search only looks at the summary field (and a
few other usually useless fields), and the summary field often doesn't
have the info you are searching for. If you click on th
H. J. Lu wrote:
PR rtl-optimization/25603
* reload.c (reg_inc_found_and_valid_p): New.
(regno_clobbered_p): Handle REG_INC as 25603 workaround.
I don't believe this is safe. If you look at the uses of
regno_clobbered_p in reload.c, the comments clearly indicate that we
On Tue, Feb 14, 2006 at 11:48:36AM -0800, Mark Mitchell wrote:
> Richard Guenther wrote:
>
> >>PR26258: wrong code caused by incorrect alias analyis.
> >
> > This is now fixed on both the branch and the mainline.
>
> Good.
>
> > I guess you meant 26258, the patch for 26029 is by Zdenek and stil
Richard Guenther wrote:
>>PR26258: wrong code caused by incorrect alias analyis.
>
> This is now fixed on both the branch and the mainline.
Good.
> I guess you meant 26258, the patch for 26029 is by Zdenek and still
> lacks a review:
> http://gcc.gnu.org/ml/gcc-patches/2006-02/msg00933.html
I
On Tue, 2006-02-14 at 17:42 +0100, Marcin Dalecki wrote:
> On 2006-02-14, at 11:21, Rainer Emrich wrote:
>
> > ICE in stage2:
> >
> > 'tree_duplicate_sese_region':
> > /SCRATCH/gcc-build/HP-UX/hppa2.0w-hp-hpux11.00/src/gcc/tree-cfg.c:
> > 4430: internal
> > compiler error: in do_compare_rtx_and_j
On 2006-02-14, at 11:21, Rainer Emrich wrote:
ICE in stage2:
'tree_duplicate_sese_region':
/SCRATCH/gcc-build/HP-UX/hppa2.0w-hp-hpux11.00/src/gcc/tree-cfg.c:
4430: internal
compiler error: in do_compare_rtx_and_jump, at dojump.c:945
Precisely the same problem can be observed on ppc as wel
Zdenek,
you forgot to add tree-ssa-loop-prefetch.c in your latest commit, which breaks
bootstrap.
Regards,
- Tobi
Hi!
Building for VAX is broken again (this is already the cross-compiler
building a vax-hosted gcc):
:
:
vax-linux-uclibc-gcc -c -static -DIN_GCC -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-overlength-strings -Wold-s
> You could combine the two ideas: a global hash table of types used in
> casts, where each entry had a list of functions using those types. That
> should take up no more storage than the per-function vectors. Then,
> you'd have to walk the entire hash table, writing out each type for
> which at
ICE in stage2:
/SCRATCH/gcc-build/HP-UX/hppa2.0w-hp-hpux11.00/gcc-4.2/gcc-4.2/./prev-gcc/xgcc
-B/SCRATCH/gcc-build/HP-UX/hppa2.0w-hp-hpux11.00/gcc-4.2/gcc-4.2/./prev-gcc/
-B/SCRATCH/gcc-build/HP-UX/hppa2.0w-hp-hpux11.00/install/hppa2.0w-hp-hpux11.00/bin/
-c -g -O2 -DIN_GCC -W -Wall -Wwrite-str
On 2/14/06, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> In the last few days, many of the key obstacles to a 4.1 release were
> removed, including, but not limited to:
>
> 1) The -mlong-double-128 patches have gone in.
> 2) Jason fixed some RVO issues.
> 3) Michael fixed the zero-width bitfield vs.
In the last few days, many of the key obstacles to a 4.1 release were
removed, including, but not limited to:
1) The -mlong-double-128 patches have gone in.
2) Jason fixed some RVO issues.
3) Michael fixed the zero-width bitfield vs. #pragma pack issue.
Unfortunately, there are still two PRs for
23 matches
Mail list logo
