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
>
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
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,
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
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
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 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:
> 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 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.
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
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
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
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
陳韋任 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
14 matches
Mail list logo
