I've been studying DLX's md file for GCC. I have a question about the following
lines in this
file,
;;
;; Float compares.
;; The RTL for these is also generated in
;; gen_conditional_branch().
;;
(define_insn ""
[(set (match_operand:CCFP 0 "register_operand" "=z")
(match_operator:SF 1
I've been studying DLX's md file for GCC. I have a question about the following
lines in this
file,
;;
;; Float compares.
;; The RTL for these is also generated in
;; gen_conditional_branch().
;;
(define_insn ""
[(set (match_operand:CCFP 0 "register_operand" "=z")
(match_operator:SF 1
(define_insn ""
[(set (match_operand:CCFP 0 "register_operand" "=z")
(match_operator:SF 1 "signed_comparison_operator"
[(match_operand:SF 2 "register_operand" "f")
(match_operand:SF 3 "register_operand" "f")]))]
""
"%C1f\\t%2,%3"
[(set_attr "type" "fp")
(set_a
On Thu, 19 Jan 2006, Paolo Bonzini wrote:
> > (define_insn ""
...
> > "%C1f\\t%2,%3"
> > I don't know the meaning of the
> > numeric character "1" between "%C" and "f" in the output template.
>
> It means that operand 1 (the signed_comparison_operator) is passed to
> the dlx.c routine. Likewis
I've localized the supporting module in GCC for
threads (gthr.h and gthr-xxx.h). These primitives
seems fairly easy to support, but there seems to
be a major flaw in them. While there is an initialization
macro, there is no descruction macro. This is problematic
when these functions need to allocat
ON THE CALL: Shin-ming Liu (HP), Vladimir Makarov (Red Hat), Diego
Novillo (Red Hat), Mark Smith (Gelato), Bob Kidd (UIUC), Andrey
Belevantsev (RAS), Arutyun Avetisyan (RAS)
Dan Berlin (IBM) was not able to join the call but did email an
aliasing update (see below).
We spent some time up front d
> I'm getting a parallel build failure on mainline like so:
>
> > make[3]: *** No rule to make target `gt-c-pragma.h', needed by
> `c-pragma.o'. Stop.
>
> We have c-pragma.o depend on gt-c-pragma.h, but there's no rule to
> build gt-c-pragma.h. I assume gt-c-pragma.h needs to depend on
> > IMHO, the fact that GCC includes /usr/local/include by default in
> > it's system header search path is brain damaged, but it's probably
> > way too entrenched to revisit that. :-(
>
> You can stop this by specifying --with-local-prefix=/not-usr-local
> when configuring GCC.
Aha, --with
Kaveh R. Ghazi wrote:
> PS: --with-local-prefix= wasn't documented in cpp.texi, only in
> install.texi
Why would you expect to find install instructions in the preprocessor
manual, rather than the installation manual?
cheers,
DaveK
--
Can't think of a witty .sigline today
> Why would you expect to find install instructions in the
> preprocessor manual, rather than the installation manual?
Because the problem was caused by the preprocessor. I was looking for
a *runtime* flag to change this behavior, (hence cpp.texi). Only in
hindsight (20/20) did it become clear
Kaveh R. Ghazi wrote:
> > Why would you expect to find install instructions in the
> > preprocessor manual, rather than the installation manual?
>
> Because the problem was caused by the preprocessor. I was looking for
> a *runtime* flag to change this behavior, (hence cpp.texi). Only in
> hin
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Eric Botcazou wrote:
|>Yes the workaround is to add -fexceptions or -shared-libgcc to the
|>command line when linking libgnat but I don't know if that is the correct
|>fix or some hacking to config/darwin.h is needed.
|
|
| Thanks. However, that's no
Hello,
Ioannis E. Venetis wrote:
> Having followed this thread and searched a little bit more, I understand
> that -fstack-usage will dump information into a file at compile time.
Right.
> However, I was wondering whether something similar would be possible at
> run-time.
>
> I am working o
I sent the following to Olivier, but forgot to CC this list.
Ioannis
Hello,
Well, it depends :)
Would __builtin_stack_size (F) retrieve information about F's stack frame
only, or would it also recursively account for every other
On 19/01/2006, at 9:08 AM, Peter O'Gorman wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Eric Botcazou wrote:
|>Yes the workaround is to add -fexceptions or -shared-libgcc to the
|>command line when linking libgnat but I don't know if that is the
correct
|>fix or some hacking to confi
On Jan 18, 2006, at 10:24 PM, [EMAIL PROTECTED] wrote:
I thought some kind of that, yet moved to matrix approach. Reason?
The clarity.
Clarity is not an in-vogue reason for compiler code generation. Size
is, speed is. Sacrificing these two for clarity in generated code
limits the end res
Hello,
Andrew P. wanted me to report the issues I encountered with libgomp and
solaris on head.
In team.c solaris fails due to the fact that alloca is defined in
alloca.h iso stdlib.h, config/posix/proc.c fails in a similar manner due
to the fact that getloadavg is defined in sys/loadavg.h
On Thu, Jan 19, 2006 at 10:45:39PM +0100, Andreas Tobler wrote:
> In team.c solaris fails due to the fact that alloca is defined in
> alloca.h iso stdlib.h ...
Er, *not* defined did you mean? This should probably be fixed
with a #define to __builtin_alloca in libgomp.h or so.
> config/posix/pro
Snapshot gcc-4.0-20060119 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.0-20060119/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.0 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
Hello,
It appears that although the most recent svn update (Revision
109975) of gcc compiles apparently fine, simple OpenMP programs will
only operate when OMP_NUM_THREADS=1. I am compiling and running gcc
on a Dual CPU G5 PowerPC running OS X 10.4.4. If I compile
omp_hello.c from tests
On Tuesday 03 January 2006 17:27, Richard Henderson wrote:
> On Mon, Jan 02, 2006 at 12:45:49AM -0500, Daniel Berlin wrote:
> > ... the real
> > solution is to transfer the information that the stack space sharing
> > knows into some simple set form, and use *that directly* in alias.c, and
> > chec
On Thu, Jan 19, 2006 at 04:35:17PM -0700, Walter Szeliga wrote:
> Hello,
> It appears that although the most recent svn update (Revision
> 109975) of gcc compiles apparently fine, simple OpenMP programs will
> only operate when OMP_NUM_THREADS=1. I am compiling and running gcc
> on a D
[EMAIL PROTECTED] wrote:
Dear Mike, dear Sirs.
Thank you very much for the letter. The idea of runtime linking seems
to be
quite natural, therefore last half a year couple of time I thought
myself a
madman. I am glad to see your letter, it means if it be I am crazy I
am not
alone :-)
Natu
This seems to have gotten forgotten:
> Date: Wed, 14 Dec 2005 21:12:20 -0500
> From: DJ Delorie <[EMAIL PROTECTED]>
> CC: gcc@gcc.gnu.org, ian@airs.com
> It seems like the very next thing it does is generate and emit the
> reload insns via emit_reload_insns().
>
> However, I modified my logic t
> Jakub Jelinek writes:
Jakub> * config/rs6000/rs6000.md (UNSPEC_LWSYNC, UNSPEC_ISYNC,
Jakub> UNSPEC_SYNC_OP, UNSPEC_ATOMIC, UNSPEC_CMPXCHG, UNSPEC_XCHG): Rename
Jakub> to...
Jakub> (UNSPECV_LWSYNC, UNSPECV_ISYNC, UNSPECV_SYNC_OP, UNSPECV_ATOMIC,
Jakub> UNSPECV_CMPXCHG, UNSPECV_XCHG): ... thes
Joe Buck wrote:
> So the answer is that, after consulting with some of the affected people
> (which is why you got mail, Mike) the SC told RMS that it would be
> changed. If it hasn't been done yet, then it's a release blocker,
> because it was a promise the SC made.
Since you seem to have a han
Re-revisiting it...
> Revisiting an old thread...
> > On Fri, Sep 02, 2005 at 09:40:20PM -0400, DJ Delorie wrote:
> > > So... why is it illegal to put a constant into a single bit field?
> >
> > Probably because it was more efficient to use some other pattern
> > for some other target.
>
> That
ZengNan <[EMAIL PROTECTED]> writes:
> (define_insn ""
> [(set (match_operand:CCFP 0 "register_operand" "=z")
> (match_operator:SF 1 "signed_comparison_operator"
> [(match_operand:SF 2 "register_operand" "f")
> (match_operand:SF 3 "register_operand" "f")]))]
> ""
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
Mainline fails to bootstrap for me (revision 110017)
on i686-pc-linux-gnu.
Configured as:
$GCC_SRC_DIR/configure --prefix=$HOME/gcc --enable-languages=c,c++,java \
- --with-as=/home/ranmath/gnu/bin/as --with-gnu-as \
- --with-ld=/home/ranmath/
On Fri, 2006-01-20 at 10:53 +0530, Ranjit Mathew wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi,
>
> Mainline fails to bootstrap for me (revision 110017)
> on i686-pc-linux-gnu.
>
> Configured as:
>
> $GCC_SRC_DIR/configure --prefix=$HOME/gcc --enable-languages=c,c++,java \
>
I guess that the macro NGARDS is relevant to the guard digit. But I
still failed to have a clear conception about what it means. Others
are easy to know by IEEE 754 and "What Every Computer Scientist Should
Know about Floating-Point Arithmetic". Except,
define NGARDS 8L
define GARDROUND 0x7f
defin
Hello,
> Andrew P. wanted me to report the issues I encountered with libgomp and
> solaris
> on head.
> The next issue is the -pthread in the config stuff. Solaris does not like it
> :)
> -pthreads instead.
I have encountered the same problem, perhaps the analysis at
http://gcc.gnu.org/ml/gcc
32 matches
Mail list logo
