Application for maintainer role for mingw
Hello Steering Committee,
I want to sent my application for the role of a maintainer for the
mingw targets in gcc. I spoke with Christopher Faylor and he said that
he would support my application.
Best regards,
Kai Tietz
--
| (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| (")_(") him gain world domination
Re: [BUG] pragma: attempt to use poisoned * in struct member
> "Jiri" == Jiri Slaby <[EMAIL PROTECTED]> writes:
Jiri> while compiling slightly augmented cc1, I've found a poison
Jiri> pragma bug. Here comes a trimmed example of the bug:
Jiri> $ echo -e '#pragma GCC poison malloc\nstruct { int malloc; };'|gcc - -E
-o/dev/null
Jiri> :2:14: error: attempt to use poisoned "malloc"
Could you explain what you think the bug is?
My first reaction is that this is not a bug. #pragma poison works on
identifiers, no matter what context they appear in (outside of system
headers). For this reason, poison is not always useful.
__attribute__((deprecated)) might be closer to what you want, though
it can be hard to use that with system-declared functions like malloc.
Tom
Re: [BUG] pragma: attempt to use poisoned * in struct member
On 11/08/2008 04:46 PM, Tom Tromey wrote:
>> "Jiri" == Jiri Slaby <[EMAIL PROTECTED]> writes:
>
> Jiri> while compiling slightly augmented cc1, I've found a poison
> Jiri> pragma bug. Here comes a trimmed example of the bug:
>
> Jiri> $ echo -e '#pragma GCC poison malloc\nstruct { int malloc; };'|gcc - -E
> -o/dev/null
> Jiri> :2:14: error: attempt to use poisoned "malloc"
>
> Could you explain what you think the bug is?
Either its use in gcc sources or the way how the #pragma keyword is handled
(this can be hardly changed).
> My first reaction is that this is not a bug. #pragma poison works on
> identifiers, no matter what context they appear in (outside of system
> headers). For this reason, poison is not always useful.
> __attribute__((deprecated)) might be closer to what you want, though
> it can be hard to use that with system-declared functions like malloc.
I want to extend cpp to extract some more info (for backward mapping from
preprocessed_code into source_code+line+column) into xml while preprocessing and
I use gdome2 library. If I try to compile it, it fails due to:
struct _GMemVTable
{
gpointer (*malloc) (gsizen_bytes);
gpointer (*realloc) (gpointer mem,
gsizen_bytes);
void (*free)(gpointer mem);
/* optional; set to NULL if not used ! */
gpointer (*calloc) (gsizen_blocks,
from /usr/include/glib-2.0/glib/gmem.h. If I remove this structure compeltely,
everything is OK (it's unused anyway).
At least some option to disable these pragma checks inside cpp would be great.
(I suppose there is none, I found it neither in gcc.info nor cpp.info nor
anywhere else...)
[BUG] pragma: attempt to use poisoned * in struct member
Hi,
while compiling slightly augmented cc1, I've found a poison pragma bug. Here
comes a trimmed example of the bug:
$ echo -e '#pragma GCC poison malloc\nstruct { int malloc; };'|gcc - -E
-o/dev/null
:2:14: error: attempt to use poisoned "malloc"
Re: Application for maintainer role for mingw
On Sat, 8 Nov 2008, Kai Tietz wrote: > Hello Steering Committee, I raised this on the steering committee... Gerald
Cannot understand the reloading code
Hi,
I am working on Itanium and gcc4.1.1. My work is mainly do
instrumentations to enable efficient taint tracking (using NaT bit on
IA-64 to represent tainted data.) on IA-64.(recently i am porting my
code to gcc4.3.2, but that has not been accomplished, because i should
also port my modified glibc to a compatible version with gcc4.3.2).
Some modifications recently is, I move some of my instrumentations up
before life analysis, and I allocate pseudo registers to do the
instrumentation. From the INSN list after my pass, it seems that all
instrumentation is done well. And for each sensitive INSN I care, I
allocate enough pseudo registers to do instrumentation, by calling
gen_reg_rtx to allocate new pseudos. For example, the following is a
sequence for instrumenting a cmp instruction IA-64:
=
the INSN I want to instrument is :
(insn 21 46 47 0 (set (reg:BI 343)
(eq:BI (reg/v:SI 339 [ zipfile ])
(const_int -1 [0x]))) 233 {*cmpsi_normal} (nil)
(nil))
=
=
after instrumentation, it becomes the following INSN list:
r346 is the pseudo register allocated for instrumentation.
//this instruction is the "tnat" instruction I added in ia64.md, it test
the NaT bit of r399
(insn 43 19 44 0 (set (reg:BI 346)
(unspec:BI [
(reg:DI 339)
] 32)) -1 (nil)
(nil))
// st8.spill r399 into [r0] (i allocated memory for NULL), the goal here
is to clear NaT bit
(insn 44 43 46 0 (cond_exec (ne:BI (reg:BI 346)
(const_int 0 [0x0]))
(parallel [
(set (mem:DI (reg/f:DI 0 r0) [0 S8 A64])
(unspec:DI [
(reg:DI 339)
(const_int 0 [0x0])
] 10))
(clobber (reg:DI 330 ar.unat))
])) -1 (nil)
(nil))
// load it again, now r339 won't have NaT bit
(insn 46 44 21 0 (cond_exec (ne:BI (reg:BI 346)
(const_int 0 [0x0]))
(set (reg:DI 339)
(mem:DI (reg/f:DI 0 r0) [0 S8 A64]))) -1 (nil)
(nil))
// do real cmp
(insn 21 46 47 0 (set (reg:BI 343)
(eq:BI (reg/v:SI 339 [ zipfile ])
(const_int -1 [0x]))) 233 {*cmpsi_normal} (nil)
(nil))
// restore the NaT bit for r339
(insn 47 21 22 0 (cond_exec (ne:BI (reg:BI 346)
(const_int 0 [0x0]))
(set (reg:DI 339)
(plus:DI (reg:DI 4 r4)
(reg:DI 339 -1 (nil)
(nil))
=
Now the problem comes, when global allocation completes, there is still
pseudo register. In the dump file .greg, I found the following:
Reloads for insn # 43
Reload 0: reload_in (DI) = (reg:DI 339)
GR_REGS, RELOAD_FOR_INPUT (opnum = 1)
reload_in_reg: (reg:DI 339)
reload_reg_rtx: (reg:DI 14 r14)
the spilling info says:
Spilling for insn 43.
Using reg 14 for reload 0
This is correct, and I found the INSN list above, all r339 have been
replaced by r14.
But there is an extra INSN inserted, that is:
(insn 57 7 43 0 (set (reg:DI 14 r14)
(reg:DI 339)) 5 {*movdi_internal} (nil)
(nil))
how can r339 appears again? this is spilling? I am confused by this.
So any help, I want some advices to help me where I should dig into to
resolve this problem. I have been reading code in reload1.c,
particularly inc_for_reload, I observe it will generate emit_move_insn
for some purpose, but I don't quite understand...
Any help is truly appreciated :-)
Thanks!
yours sincerely
Andrew
