Quoting Lev Yudalevich :
First, thank you very very much for your reply!
Next, would you be so kind to give me a hint where can I find any info
about what you called "required conversions patterns from / to
PSImode" please?
doc/rtl.texi, section Standard Pattern Names For Generation, most nota
First, thank you very very much for your reply!
Next, would you be so kind to give me a hint where can I find any info
about what you called "required conversions patterns from / to
PSImode" please?
Sincerely,
-- Lev.
On Mon, Dec 7, 2009 at 6:10 AM, Joern Rennecke wrote:
> Quoting Robert Dewar :
Quoting Robert Dewar :
Lev Yudalevich wrote:
However, when the resulting gcc compiler crashes (ICE) when it tries
to convert any integer into my new type.
Plase report the specific crash as a bug report with full details,
in particular a full compilable example that shows the ICE. Obviously
g
>
> You might start by monitoring emit_reload_insns's behavior when it handles
> your insn.
I just debug the source code with your advice. Check the function
emit_reload_insns.
That insn was deleted before entering funcion emit_reload_insns. It
was deleted in reload(...) in reload1.c file just bef
Snapshot gcc-4.3-20091206 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20091206/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.3 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
Thanks
I am submitting patch to drop count to 10,000 for 16 bit int target.
Using 32 bit counter of 1 million takes a minute or so on simulator -
which is high.
The lower count is quick and only requires a (16bit) stack limit to be
lower than 10MB - which is pretty safe.
Andy
Joseph S. My
On Sun, 6 Dec 2009, Robert Dewar wrote:
> Plase report the specific crash as a bug report with full details,
> in particular a full compilable example that shows the ICE. Obviously
> gcc should never crash, no matter whether your code is right or wrong.
But if the crash is in a modified version o
On Sun, 6 Dec 2009, Andrew Hutchinson wrote:
> The test appears to be unsafe. The original fault was failure to deallocate
> VLA on the jump - thus with the fault present the test would appear to perform
> 1 million new allocation - and fail presumably due to either execution time or
> run time er
Bug 42310 has been added to the database
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42310
Thank you very much!
Below is a copy of the bug report:
The exact version of GCC: 4.4.1
The system type: Linux version 2.6.9-67.EL (Red Hat 3.4.6-8)
The options given when GCC was configured/built: ../../
Lev Yudalevich wrote:
Hi,
I asked this question about a month ago at gcc-help, but got no answer, so...
Well you are always depending on volunteer help when you send in
a question like this, so if no one feels like answering, you
won't get an answer. Nothing very unusual there.
I'm trying to
Hi,
I asked this question about a month ago at gcc-help, but got no answer, so...
I'm trying to define a nonstandard type for 12-bit scalar variables
based on a target-dependent PSI mode.
In my TARGET-modes.def file I have PARTIAL_MODE_INT(SI) defined.
During the backend's init_builtins processin
I need advise before I submit pathc to fix the test
gcc-torture/execute/vla-dealloc-1.c (attached below)
The test appears to be unsafe. The original fault was failure to
deallocate VLA on the jump - thus with the fault present the test would
appear to perform 1 million new allocation - and fa
12 matches
Mail list logo
