陳韋任 writes:
>> Can I dump other information such as CFG in a similar way as register
>> usage does?
>
> At the end of the link belows,
>
> http://gcc.gnu.org/onlinedocs/gccint/Maintaining-the-CFG.html#Maintaining-the-CFG
>
> It says,
>
> "Note that at present, the representation of contr
Hi, all
> Can I dump other information such as CFG in a similar way as register
> usage does?
At the end of the link belows,
http://gcc.gnu.org/onlinedocs/gccint/Maintaining-the-CFG.html#Maintaining-the-CFG
It says,
"Note that at present, the representation of control flow in the tree
asharif tools writes:
> function:
> call__i686.get_pc_thunk.bx
> addl$_GLOBAL_OFFSET_TABLE_, %ebx
> movl%gs:20, %eax # Stack-guard init
> movl%eax, -12(%ebp) # Stack-guard init
> Now, what I want to do is move stack guard initialization part
> (consisting
Let's say I am compiling for a target that has
TARGET_PAD_SHORT_FUNCTION (example: i386 Atom) and that the
compilation flags are -fPIE -fstack-protector.
For certain functions, the starting code sequence will look like the following:
function:
call__i686.get_pc_thunk.bx
addl
On 6/6/11, Janis Johnson wrote:
> On 06/03/2011 11:14 AM, Lawrence Crowl wrote:
>> The PPH project has tests that compile two different ways, and
>> then compare the assembly. If either of the compiles fails, the
>> comparison will fail. We'd like to simply not run the comparison.
>>
>> We curre
On Wed, 08 Jun 2011 21:54:56 +0200
Andreas Schwab wrote:
> Basile Starynkevitch writes:
>
> > And I also believe that the minuscule patch I am proposing in
> > http://gcc.gnu.org/ml/gcc/2011-06/msg00081.html
> > should work on your system too. Could you try it please?
>
> That's not the point.
Basile Starynkevitch writes:
> And I also believe that the minuscule patch I am proposing in
> http://gcc.gnu.org/ml/gcc/2011-06/msg00081.html
> should work on your system too. Could you try it please?
That's not the point. The point is, if you patch, you should do it
right.
Andreas.
--
Andr
On Wed, 08 Jun 2011 20:52:51 +0200
Andreas Schwab wrote:
> Basile Starynkevitch writes:
>
> > You see, not Ver. string in it.
>
> $ autogen -v
> autogen (GNU AutoGen) - The Automated Program Generator - Ver. 5.11.1
I might believe that could be more a issue in autogen than in GCC.
And I also
Basile Starynkevitch writes:
> You see, not Ver. string in it.
$ autogen -v
autogen (GNU AutoGen) - The Automated Program Generator - Ver. 5.11.1
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something c
On Wed, 08 Jun 2011 10:07:20 +0200
Andreas Schwab wrote:
> Basile Starynkevitch writes:
>
> > Hello
> >
> > With the autogen (GNU AutoGen) 5.11.9 on my Linux/Debian/Sid (or
> > perhaps /Experimental) the genfixes script fail, because of the version
> > test.
> >
> > The following patch corrects
Hi,
If you are using the Linux binutils 2.21.51.0.9, please update as
soon as you can to fix an x86 linker regression: PRs 12833/12837/12859.
---
This is the beta release of binutils 2.21.52.0.1 for Linux, which is
based on binutils 2011 0608 in CVS on sourceware.org plus various
changes. It is
Mingjie Xing writes:
> I find the printable names are both "label decl" for TS_LABEL_DECL and
> TS_TYPE_DECL in treestruct.def (trunk),
>
> DEFTREESTRUCT(TS_LABEL_DECL, "label decl")
> DEFTREESTRUCT(TS_RESULT_DECL, "result decl")
> DEFTREESTRUCT(TS_CONST_DECL, "const decl")
> DEFTREESTRUCT(TS_TYP
Hi,
I find the printable names are both "label decl" for TS_LABEL_DECL and
TS_TYPE_DECL in treestruct.def (trunk),
DEFTREESTRUCT(TS_LABEL_DECL, "label decl")
DEFTREESTRUCT(TS_RESULT_DECL, "result decl")
DEFTREESTRUCT(TS_CONST_DECL, "const decl")
DEFTREESTRUCT(TS_TYPE_DECL, "label decl")
Is it a
Basile Starynkevitch writes:
> Hello
>
> With the autogen (GNU AutoGen) 5.11.9 on my Linux/Debian/Sid (or
> perhaps /Experimental) the genfixes script fail, because of the version
> test.
>
> The following patch corrects that.
>
> Index: fixincludes/genfixes
>
14 matches
Mail list logo