On Dec 28, 2005, at 11:08 PM, [EMAIL PROTECTED] wrote:
Is there any options in converting assembly code to c using
gcc as u
convert c code to assmbly.
Yes, but they are all poor to very poor. see google("decompilers").
Anyway, this is off-topic for this list.
On Dec 28, 2005, at 8:49 PM, Domagoj D wrote:
Can anyone explain me the following gcc/c-decl.c code (4.0.2, seems to
be unchanged in 4.2)?
What part was unclear?
#define I_SYMBOL_BINDING(node) \
(((struct lang_identifier *)
IDENTIFIER_NODE_CHECK(node))->symbol_binding)
Yes, each identifie
hi there ...
Is there any options in converting assembly code to c using gcc as u
convert c code to assmbly.
Any comment about this topic will be helpful
Pai
Hi,
Can anyone explain me the following gcc/c-decl.c code (4.0.2, seems to
be unchanged in 4.2)?
...
#define I_SYMBOL_BINDING(node) \
(((struct lang_identifier *)
IDENTIFIER_NODE_CHECK(node))->symbol_binding)
...
static void
warn_if_shadowing (tree new_decl)
{
struct c_binding *b;
...
2005-12-28 Leif Ekblad [EMAIL PROTECTED]
* gcc/config.gcc: Added support for target RDOS
* gcc/config/i386/rdos.h: Added rdos.h file for RDOS definitions
--- /usr/src/toolchain/gcc-4.1-20051008/gcc/config.gcc 2005-09-29
01:50:03.0 +0200
+++ config.gcc 2005-12-13 13:18:17.0
On 27/12/2005, at 3:36 PM, Jakub Jelinek wrote:
On Tue, Dec 27, 2005 at 02:20:44PM -0800, Geoff Keating wrote:
I'm not sure what "just fine" definition you're using here. I don't
think you can say it's been extensively tested, and I'm fairly sure I
can find a bunch of bugs in it. I have alr
> > I still support a reverting of the weakref patch as it was put way too
> > late
> > for 4.1 (stage 3 is not a good idea for a new feature).
>
> Depends on if you consider it a new feature or a bug fix.
>From my perspective, this patch introduced more bugs than it fixed:
http://gcc.gnu.org/b
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Failed in configure of libstdc++:
/bin/sh /raid/tecosim/it/devel/projects/develtools/src/gcc-4.1/mkinstalldirs
i686-pc-mingw32/libstdc++-v3 ; \
rm -f i686-pc-mingw32/libstdc++-v3/Makefile || : ; \
cp multilib.out i686-pc-mingw32/libstdc++-v3/multilib.
On Dec 28, 2005, at 4:33 AM, Jakub Jelinek wrote:
I still support a reverting of the weakref patch as it was put way too
late
for 4.1 (stage 3 is not a good idea for a new feature).
Depends on if you consider it a new feature or a bug fix.
It was a new feature to work around a bug which is o
Liu Haibin <[EMAIL PROTECTED]> writes:
> Hi,
>
> I got a dump of sha.c.27.flow2 from gcc 3.4.1. I don't quite
> understand the LOG_LINKS of insn 498. LOG_LINKS in insn 498 shows that
> it has a data dependence (a read after write dependence) with insn 3.
> Why is it so? I don't see any dependence
Hi,
I got a dump of sha.c.27.flow2 from gcc 3.4.1. I don't quite
understand the LOG_LINKS of insn 498. LOG_LINKS in insn 498 shows that
it has a data dependence (a read after write dependence) with insn 3.
Why is it so? I don't see any dependence between "mov r14 r4" and
"addi r3, r4, 28". The bot
On Tue, Dec 27, 2005 at 06:39:58PM -0500, Andrew Pinski wrote:
>
> On Dec 27, 2005, at 6:36 PM, Jakub Jelinek wrote:
> >It has nothing to do with libgfortran actually, libgfortran only ever
> >uses the weak pthread function aliases within libgfortran.
> >The reason why weakref attribute has been a
12 matches
Mail list logo
