Re: Normalizing the bitmap APIs.
On Thu, Oct 11, 2012 at 11:57 PM, Diego Novillo wrote: > On 2012-10-11 16:25 , Lawrence Crowl wrote: >> >> On 10/11/12, Diego Novillo wrote: >>> >>> On 2012-10-11 13:26 , Lawrence Crowl wrote: My only other concern was that the mapping between those function names and the tasks to be done sometimes seemed less than obvious. So, I proposed the name change. However, I think the current names are workable, assuming an acceptable solution to the above problem. >>> >>> >>> I would say, add both variants and make the empty ones drop the return >>> value. So, for instance, bitmap_ior returns a value, so make >>> bitmap_ior_cg drop it. >> >> >> That convention is opposite from what is used in sbitmap, where _cg >> indicates that it returns the bool. I think returning the value >> will be the less common case. > > > Sorry, I mixed the two up. I meant the version that makes sense. What's the issue with always returning the changed status? bitmap operations (even more so sbitmap operations) are memory-bound, accumulating one more register isn't speed critial. Richard. > > Diego. >
Passing 64-bit function arguments to assembler
Hi, Here's a possible bug in the compiler: As can be seen from the objdump output, 64-bit arguments are passed in 32-bit registers 0040049c : 40049c:55 push rbp 40049d:48 89 e5 movrbp,rsp 4004a0:be 44 44 00 00 movesi,0x 4004a5:bf 33 33 00 00 movedi,0x 4004aa:e8 05 00 00 00 call 4004b4 4004af:90 nop 4004b0:5d poprbp 4004b1:c3 ret 4004b2:66 90xchg ax,ax also the opcodes on line 4004AF and 4004B2 seem obsolete. Best Regards, Mischa. ./a.out: file format elf64-x86-64 Disassembly of section .init: 00400358 <_init>: 400358: 48 83 ec 08 subrsp,0x8 40035c: e8 5b 00 00 00 call 4003bc 400361: 48 83 c4 08 addrsp,0x8 400365: c3 ret Disassembly of section .plt: 00400370 <__libc_start_main@plt-0x10>: 400370: ff 35 ca 04 20 00 push QWORD PTR [rip+0x2004ca] # 600840 <_GLOBAL_OFFSET_TABLE_+0x8> 400376: ff 25 cc 04 20 00 jmpQWORD PTR [rip+0x2004cc] # 600848 <_GLOBAL_OFFSET_TABLE_+0x10> 40037c: 0f 1f 40 00 nopDWORD PTR [rax+0x0] 00400380 <__libc_start_main@plt>: 400380: ff 25 ca 04 20 00 jmpQWORD PTR [rip+0x2004ca] # 600850 <_GLOBAL_OFFSET_TABLE_+0x18> 400386: 68 00 00 00 00 push 0x0 40038b: e9 e0 ff ff ff jmp400370 <_init+0x18> Disassembly of section .text: 00400390 <_start>: 400390: 31 ed xorebp,ebp 400392: 49 89 d1movr9,rdx 400395: 5e poprsi 400396: 48 89 e2movrdx,rsp 400399: 48 83 e4 f0 andrsp,0xfff0 40039d: 50 push rax 40039e: 54 push rsp 40039f: 49 c7 c0 50 05 40 00movr8,0x400550 4003a6: 48 c7 c1 c0 04 40 00movrcx,0x4004c0 4003ad: 48 c7 c7 9c 04 40 00movrdi,0x40049c 4003b4: e8 c7 ff ff ff call 400380 <__libc_start_main@plt> 4003b9: f4 hlt 4003ba: 66 90 xchg ax,ax 004003bc : 4003bc: 48 83 ec 08 subrsp,0x8 4003c0: 48 8b 05 69 04 20 00movrax,QWORD PTR [rip+0x200469] # 600830 <_DYNAMIC+0x1d0> 4003c7: 48 85 c0test rax,rax 4003ca: 74 02 je 4003ce 4003cc: ff d0 call rax 4003ce: 48 83 c4 08 addrsp,0x8 4003d2: c3 ret 4003d3: 66 2e 0f 1f 84 00 00nopWORD PTR cs:[rax+rax*1+0x0] 4003da: 00 00 00 4003dd: 0f 1f 00nopDWORD PTR [rax] 004003e0 : 4003e0: b8 67 08 60 00 moveax,0x600867 4003e5: 55 push rbp 4003e6: 48 2d 60 08 60 00 subrax,0x600860 4003ec: 48 83 f8 0e cmprax,0xe 4003f0: 48 89 e5movrbp,rsp 4003f3: 77 02 ja 4003f7 4003f5: 5d poprbp 4003f6: c3 ret 4003f7: b8 00 00 00 00 moveax,0x0 4003fc: 48 85 c0test rax,rax 4003ff: 74 f4 je 4003f5 400401: 5d poprbp 400402: bf 60 08 60 00 movedi,0x600860 400407: ff e0 jmprax 400409: 0f 1f 80 00 00 00 00nopDWORD PTR [rax+0x0] 00400410 : 400410: b8 60 08 60 00 moveax,0x600860 400415: 55 push rbp 400416: 48 2d 60 08 60 00 subrax,0x600860 40041c: 48 c1 f8 03 sarrax,0x3 400420: 48 89 e5movrbp,rsp 400423: 48 89 c2movrdx,rax 400426: 48 c1 ea 3f shrrdx,0x3f 40042a: 48 01 d0addrax,rdx 40042d: 48 89 c6movrsi,rax 400430: 48 d1 fesarrsi,1 400433: 75 02 jne400437 400435: 5d poprbp 400436: c3 ret 400437: ba 00 00 00 00 movedx,0x0 40043c: 48 85 d2test rdx,rdx 40043f: 74 f4 je 400435 400441: 5d poprbp 400442: bf 60 08 60 00 movedi,0x600860 400447: ff e2 jmprdx 400449:
Re: Passing 64-bit function arguments to assembler
On Fri, Oct 12, 2012 at 1:55 AM, Mischa Baars wrote: > Hi, > > Here's a possible bug in the compiler: > > As can be seen from the objdump output, 64-bit arguments are passed in > 32-bit registers > > 0040049c : > 40049c:55 push rbp > 40049d:48 89 e5 movrbp,rsp > 4004a0:be 44 44 00 00 movesi,0x this is the same as mov rsi, 0x As all instructions which act on the lower 32bit part of the register are zero extended into the full 64bit register. > 4004a5:bf 33 33 00 00 movedi,0x Likewise. Thanks, Andrew Pinski PS this question is more relevant to the gcc-help mailing list than the gcc one. > 4004aa:e8 05 00 00 00 call 4004b4 > 4004af:90 nop > 4004b0:5d poprbp > 4004b1:c3 ret > 4004b2:66 90xchg ax,ax > > also the opcodes on line 4004AF and 4004B2 seem obsolete. > > Best Regards, > Mischa.
Re: Fully flow and context sensitive points-to analysis in GCC 4.6.0
On Fri, Oct 12, 2012 at 7:41 AM, Uday P. Khedker wrote:
>
>
> Andrew Pinski wrote, On Friday 12 October 2012 10:29 AM:
>
>
>>> Here's an example:
>>>
>>> main()
>>> {
>>> int **p;
>>> int *a, *d;
>>> int w, x;
>>>
>>> a = &w;
>>> f1(a);
>>> p = &a;
>>> a = &x;
>>> f2(p);
>>> d = a;
>>>
>>> return *d;
>>> }
>>>
>>> It is clear that d can only point to x and can never point to w.
>>
>>
>> I think you are wrong there.
>>
>> int *a1;
>> void f1(int *a)
>> {
>>a1 = a;
>> }
>>
>> void f2(int **p)
>> {
>>*p = a1;
>> }
>>
>> That will change a to &w after f2 is called. So it looks like your
>> aliasing analysis does not take into account escaping like it should.
>> This is the whole point of marking a as escaped. Maybe I missed
>> something here though but d can point w with my functions for f1 and
>> f2.
>
>
> Ah, you caught me there, but I think I can escape, at least in this
> situation :-)
>
> The call to f1 is not central to the point I am making; I had included it
> only to ensure
> that the assignment a=&w doesn't get eliminated by dead code elimination.
> Since you
> decided to hold the address of a into a1 through function f1, let me
> eliminate the
> call to f1 and make the assignment a=&w live in some other way. Here's the
> changed code:
>
>
> main()
> {
> int **p;
> int *a, *d;
> int w, x;
>
> d = &x;
> a = &w;
> if (f1())
>
> {
> p = &a;
> a = &x;
> f2(p);
> d = a;
> }
>
> return *d + *a;
> }
>
> Now when f2 is called, a definitely does not point to w. Hence d should not
> point to w.
> And yet, the dump shows that d continue to point to w.
>
> In any case, your point about escaping variables strengthens my point about
> inappropriateness
> of SSA for pointer analysis, although not through this example.
The point is we are only ever interested at what SSA names point to
when we use points-to information. Even the current IPA-PTA code
uses internal representation for representing globals and aggregates
(but yes, not flow-sensitively). For
int *a;
foo ()
{
a = ...;
...
use (a);
}
we _always_ see
ssa_name_1 = a;
use (ssa_name_1);
so you have a place to associate your flow-sensitive and context-sensitive
points-to-info with (the SSA name). My point is that for _using_ the
points-to info flow-sensitivity provided by SSA form is enough. For computing
it you of course need to flow-sensitively process assignments to 'a'.
Richard.
> Uday.
>
>
Re: Fully flow and context sensitive points-to analysis in GCC 4.6.0
Richard Biener wrote, On Friday 12 October 2012 02:51 PM: we _always_ see ssa_name_1 = a; use (ssa_name_1); so you have a place to associate your flow-sensitive and context-sensitive points-to-info with (the SSA name). My point is that for _using_ the points-to info flow-sensitivity provided by SSA form is enough. For computing it you of course need to flow-sensitively process assignments to 'a'. This is VERY interesting! I had not thought about the difference between computing and using values. Now that you point it out, I think all we need to do is to map flow-sensitively computed values to ssa names. What about variables that do not have ssa names? Or are you saying that all such variables would be copied into an artificial variables that have ssa names? I seem to observe this in the dumps but I don't know if it holds in general. Uday.
Re: Fully flow and context sensitive points-to analysis in GCC 4.6.0
On Fri, Oct 12, 2012 at 11:46 AM, Uday P. Khedker wrote: > > > Richard Biener wrote, On Friday 12 October 2012 02:51 PM: > >> >> we _always_ see >> >>ssa_name_1 = a; >>use (ssa_name_1); >> >> so you have a place to associate your flow-sensitive and context-sensitive >> points-to-info with (the SSA name). My point is that for _using_ the >> points-to info flow-sensitivity provided by SSA form is enough. For >> computing >> it you of course need to flow-sensitively process assignments to 'a'. > > > This is VERY interesting! I had not thought about the difference between > computing > and using values. Now that you point it out, I think all we need to do is to > map > flow-sensitively computed values to ssa names. > > What about variables that do not have ssa names? Or are you saying that all > such > variables would be copied into an artificial variables that have ssa names? > I seem > to observe this in the dumps but I don't know if it holds in general. Yes, that's what I say. Any pointer that is dereferenced is first copied to an SSA name. Basically everything residing in memory first has to be loaded to an SSA name before it can be dereferenced. That load is explicit in the IL so you should already compute points-to sets for the SSA name destination of the load. Richard. > Uday.
Re: Passing 64-bit function arguments to assembler
On 10/12/2012 10:55 AM, Mischa Baars wrote: As can be seen from the objdump output, 64-bit arguments are passed in 32-bit registers x86_64 clears the upper 32 bit of a 64 bit register if the lower 32 bit are written to, so this isn't a bug. -- Florian Weimer / Red Hat Product Security Team
Re: Fully flow and context sensitive points-to analysis in GCC 4.6.0
Excellent! Thanks. Uday. Richard Biener wrote, On Friday 12 October 2012 03:20 PM: On Fri, Oct 12, 2012 at 11:46 AM, Uday P. Khedker wrote: Richard Biener wrote, On Friday 12 October 2012 02:51 PM: we _always_ see ssa_name_1 = a; use (ssa_name_1); so you have a place to associate your flow-sensitive and context-sensitive points-to-info with (the SSA name). My point is that for _using_ the points-to info flow-sensitivity provided by SSA form is enough. For computing it you of course need to flow-sensitively process assignments to 'a'. This is VERY interesting! I had not thought about the difference between computing and using values. Now that you point it out, I think all we need to do is to map flow-sensitively computed values to ssa names. What about variables that do not have ssa names? Or are you saying that all such variables would be copied into an artificial variables that have ssa names? I seem to observe this in the dumps but I don't know if it holds in general. Yes, that's what I say. Any pointer that is dereferenced is first copied to an SSA name. Basically everything residing in memory first has to be loaded to an SSA name before it can be dereferenced. That load is explicit in the IL so you should already compute points-to sets for the SSA name destination of the load. Richard. Uday.
ARM Broken on Head?
Hi I am trying to test and apply Sebastian Huber's arm-rtems patch and am getting compilation errors in libgcc2.c which originate in arm.h. I am using the binutils head also. This is my configure command: ../gcc-svn/configure --enable-threads=rtems --with-gnu-as \ --enable-multilib --disable-werror --enable-newlib-mb \ --enable-newlib-iconv --with-gnu-ld --with-newlib \ --verbose --with-system-zlib --disable-nls \ --enable-version-specific-runtime-libs \ --enable-languages=c,c++ --target=arm-rtems4.11 \ --prefix=/home/joel/v850/install Attached is a build log with the errors. Any ideas? This seems like something someone else would have encountered. Thanks. -- Joel Sherrill, Ph.D. Director of Research& Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35806 Support Available (256) 722-9985 /home/joel/v850/tools/b-gcc-svn/./gcc/xgcc -B/home/joel/v850/tools/b-gcc-svn/./gcc/ -nostdinc -B/home/joel/v850/tools/b-gcc-svn/arm-rtems4.11/newlib/ -isystem /home/joel/v850/tools/b-gcc-svn/arm-rtems4.11/newlib/targ-include -isystem /home/joel/v850/tools/gcc-svn/newlib/libc/include -B/home/joel/v850/install/arm-rtems4.11/bin/ -B/home/joel/v850/install/arm-rtems4.11/lib/ -isystem /home/joel/v850/install/arm-rtems4.11/include -isystem /home/joel/v850/install/arm-rtems4.11/sys-include-g -O2 -mthumb -O2 -I../../../../gcc-svn/libgcc/../newlib/libc/sys/rtems/include -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fno-inline -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -Dinhibit_libc -fno-inline -I. -I. -I../../.././gcc -I../../../../gcc-svn/libgcc -I../../../../gcc-svn/libgcc/. -I../../../../gcc-svn/libgcc/../gcc -I../../../../gcc-svn/libgcc/../include -DHAVE_CC_TLS -o _muldi3.o -MT _muldi3.o -MD -MP -MF _muldi3.dep -DL_muldi3 -c ../../../../gcc-svn/libgcc/libgcc2.c In file included from ../../../../gcc-svn/libgcc/libgcc2.c:30:0: ../../../../gcc-svn/libgcc/../gcc/coretypes.h:187:3: warning: this decimal constant is unsigned only in ISO C90 [enabled by default] MEMMODEL_RELAXED = 0, ^ ../../../../gcc-svn/libgcc/../gcc/coretypes.h:194:1: warning: enumeration values exceed range of largest integer [enabled by default] }; ^ In file included from ../../.././gcc/options.h:6:0, from ../../.././gcc/tm.h:14, from ../../../../gcc-svn/libgcc/libgcc2.c:31: ../../../../gcc-svn/libgcc/../gcc/flag-types.h:147:3: warning: this decimal constant is unsigned only in ISO C90 [enabled by default] no_graph = 0, ^ ../../../../gcc-svn/libgcc/../gcc/flag-types.h:155:3: warning: this decimal constant is unsigned only in ISO C90 [enabled by default] NO_STACK_CHECK = 0, ^ ../../../../gcc-svn/libgcc/../gcc/flag-types.h:194:1: warning: enumeration values exceed range of largest integer [enabled by default] }; ^ ../../../../gcc-svn/libgcc/../gcc/flag-types.h:198:3: warning: this decimal constant is unsigned only in ISO C90 [enabled by default] FP_CONTRACT_OFF = 0, ^ ../../../../gcc-svn/libgcc/../gcc/flag-types.h:201:1: warning: enumeration values exceed range of largest integer [enabled by default] }; ^ In file included from ../../.././gcc/options.h:8:0, from ../../.././gcc/tm.h:14, from ../../../../gcc-svn/libgcc/libgcc2.c:31: ../../../../gcc-svn/libgcc/../gcc/config/arm/arm-opts.h:42:3: warning: this decimal constant is unsigned only in ISO C90 [enabled by default] ARM_FP16_FORMAT_NONE = 0, ^ ../../../../gcc-svn/libgcc/../gcc/config/arm/arm-opts.h:45:1: warning: enumeration values exceed range of largest integer [enabled by default] }; ^ In file included from ../../.././gcc/tm.h:14:0, from ../../../../gcc-svn/libgcc/libgcc2.c:31: ../../.././gcc/options.h:3842:3: warning: this decimal constant is unsigned only in ISO C90 [enabled by default] OPT = 0, /* -### */ ^ ../../.././gcc/options.h:4997:1: warning: enumeration values exceed range of largest integer [enabled by default] }; ^ In file included from ../../.././gcc/tm.h:15:0, from ../../../../gcc-svn/libgcc/libgcc2.c:31: ../../.././gcc/insn-constants.h:30:3: warning: this decimal constant is unsigned only in ISO C90 [enabled by default] UNSPEC_PUSH_MULT = 0, ^ ../../.././gcc/insn-constants.h:197:1: warning: enumeration values exceed range of largest integer [enabled by default] }; ^ ../../.././gcc/insn-constants.h:202:3: warning: this decimal constant is unsigned only in ISO C90 [enabled by default] VUNSPEC_BLOCKAGE = 0, ^ ../../.././gcc/insn-constants.h:224:1: warning: enumeration values exceed range of largest integer [enabled by default] }; ^ In file included from ../../.././gcc/tm.h:25:0, f
Re: Normalizing the bitmap APIs.
On 2012-10-12 04:26 , Richard Biener wrote: What's the issue with always returning the changed status? bitmap operations (even more so sbitmap operations) are memory-bound, accumulating one more register isn't speed critial. Not a big issue, but it was going to be a behaviour change, which we are trying to minimize. I have no problem in always returning a status change, if you are OK with that. Diego.
Re: Normalizing the bitmap APIs.
On Fri, Oct 12, 2012 at 3:37 PM, Diego Novillo wrote: > On 2012-10-12 04:26 , Richard Biener wrote: > >> What's the issue with always returning the changed status? bitmap >> operations >> (even more so sbitmap operations) are memory-bound, accumulating one more >> register isn't speed critial. > > > Not a big issue, but it was going to be a behaviour change, which we are > trying to minimize. > > I have no problem in always returning a status change, if you are OK with > that. I am ok with that. Richard.
Re: Functions that are CSEable but not pure
On 10/11/2012 03:48 PM, Alexandre Oliva wrote: This is not entirely clear to me; where is i defined in the first place? Um, it's defined where the user writes the definition, like any other variable. Is it i_init that defines and tests i_initialized? Yes. Consider instead the following expansion: __thread void (*i_initialize)(void) = i_init; That would work too, though it wouldn't have the benefit of link-compatibility with __thread (for variables that don't need dynamic initialization) that the current scheme has. I don't know whether it would be more or less efficient. or this: [EXTERN] __thread T *i; Same answer. If we aren't trying to maintain compatibility, this approach seems like it would be more efficient than i_initialize. Jason
Re: encoding all aliases options in .opt files
On Fri, 12 Oct 2012, Manuel López-Ibáñez wrote: > I am trying to encode the relationship between Wstrict-aliasing and > Wstrict-aliasing= in the .opt files, and the same for Wstrict-overflow > and Wstrict-overflow=. However, the parameters of Alias() are taken as > strings, so we get "3" and "WARN_STRICT_OVERFLOW_CONDITIONAL". Do you > have a suggestion how to handle this? I don't see what the problem is supposed to be. Yes, the arguments are strings - they describe how one option that the user might pass on the command line is exactly equivalent to another that they might pass (up to and including the latter form of the option being the one that is used when matching specs and multilibs, because the driver does the translation, including working out the canonical textual form of the option, before processing specs against the command line). If -Wstrict-overflow on the command line is equivalent to -Wstrict-overflow=WARN_STRICT_OVERFLOW_CONDITIONAL on the command line, then specify WARN_STRICT_OVERFLOW_CONDITIONAL in the parameters. If it's equivalent to something else, specify something else. > My next step would be to handle aliases also when internally > generating options, so I can add EnabledBy(Wall) to Wstrict-aliasing. > Does this sound ok to you? That seems reasonable. -- Joseph S. Myers jos...@codesourcery.com
Re: Functions that are CSEable but not pure
On Fri, 12 Oct 2012, Jason Merrill wrote: > > Consider instead the following expansion: > > > > __thread void (*i_initialize)(void) = i_init; > > That would work too, though it wouldn't have the benefit of link-compatibility > with __thread (for variables that don't need dynamic initialization) that the > current scheme has. I'd certainly think that for C, __thread and _Thread_local should be link-compatible (and probably should be treated more or less identically apart from some diagnostics), and that C11 _Thread_local should be link-compatible (in the absence of dynamic initialization) with C++11 thread_local. -- Joseph S. Myers jos...@codesourcery.com
Re: Request for comments on language extension: Safe arrays and pointers for C, September draft.
Here's the September 2012 draft of my "Safe arrays and pointers for C" proposal: http://www.animats.com/papers/languages/safearraysforc43.pdf This incorporates most of the substantive issues raised in previous discussions. Brief summary: - Optional "strict mode" via pragma which prohibits some unsafe pointer usages. - Prevents buffer overflows in strict mode. - Bring C++ references into C, so programmers can talk about arrays. - Expressions allowed in array dimensions (like VLA params, but in a few more contexts.) - Strict code can call non-strict code, and vice versa. - Libraries and APIs with array params can be given strict declarations, and can be called from strict code (safely) and non-strict code (unsafely), allowing gradual conversion. The goal is to eliminate buffer overflows in strict mode code, providing a substantial improvement in security and reliability for security-critical C programs. I'm proposing this as an enhancement to GCC, in two phases. Phase 1: Add language mode flag for this feature set. Support new language features. No bounds checking in this phase. Phase 2: Add optional bounds checking. I'd appreciate comments on how difficult phase 1 would be. John Nagle
Re: Fully flow and context sensitive points-to analysis in GCC 4.6.0
Somewhere it is mentioned that heap is handled conservatively. Does it mean the algorithm can not disambiguate heap objects all all, or it can but does not track pointer values stored in heap objects? How about field sensitivity? For many programs (mostly C++ ones), this is very important. For CS, virtual calls in C++ will be one of the the biggest challenges. How is that dealt with? It can be combined with type propagation/analysis. thanks, David On Wed, Oct 10, 2012 at 10:56 AM, Uday P. Khedker wrote: > > We have designed and implemented a fully flow and context sensitive > points-to analysis in gcc-4.6.0. For simplicity, we have made a dynamic > plugin available at http://www.cse.iitb.ac.in/grc/index.php?page=l-fcpa. > This page also provides an overview of the method, and links to the paper, > slides, and instructions on how to use the plugin. Our method questions the > conventional wisdom that precise flow and context sensitive pointer > information is prohibitively large and hence we cannot hope to compute it > efficiently. We show that the actual usable information is rather small and > sparse and hence an increase in precision actually improves the efficiency > too, rather than worsen it. > > Needless to say, precise pointer information is critical for the > effectiveness of almost all analyses and optimizations in any compiler. Now > that we have some ray of hope of precise points-to analysis in GCC, we would > like to invite collaboration from like minded people. There is a lot of work > that needs to be done further; some details of future work are available on > the given URL and we will be happy to provide more information to the > interested people. > > Looking forward to hearing from people who would like to contribute to this > important project. > > Thanks and regards, > > Uday Khedker. > -- > Dr. Uday Khedker > Professor > Department of Computer Science & Engg. > IIT Bombay, Powai, Mumbai 400 076, India. > Email : u...@cse.iitb.ac.in > Homepage: http://www.cse.iitb.ac.in/~uday > Phone : > Office -91 (22) 2572 2545 x 7717, 91 (22) 2576 7717 (Direct) > Res. -91 (22) 2572 2545 x 8717, 91 (22) 2576 8717 (Direct) > > > > > -- > -- > Dr. Uday Khedker > Professor > Department of Computer Science & Engg. > IIT Bombay, Powai, Mumbai 400 076, India. > Email : u...@cse.iitb.ac.in > Homepage: http://www.cse.iitb.ac.in/~uday > Phone : > Office -91 (22) 2572 2545 x 7717, 91 (22) 2576 7717 (Direct) > Res. -91 (22) 2572 2545 x 8717, 91 (22) 2576 8717 (Direct) > >
macro's and local variables
Hi All, Who can take a first look at this in the morning? Thanks, Mischa. function.o: file format elf64-x86-64 Disassembly of section .text: : 0: c3 ret function.o: file format elf64-x86-64 Disassembly of section .text: : 0: 66 bb 00 00 movbx,0x0 4: 66 bb 00 00 movbx,0x0 8: 66 bb 01 00 movbx,0x1 c: 66 bb 00 00 movbx,0x0 10: 66 bb 01 00 movbx,0x1 14: 66 bb 02 00 movbx,0x2 18: c3 ret .intel_syntax noprefix .global function .code64 .macro A arg1 .seti, 0 .rept \arg1 mov ax, i .seti, i + 1 .endr .endm .macro B arg1 .setj, 0 .rept \arg1 mov bx, j .setj, j + 1 .endr .endm .macro C .seti, 0 .rept 4 // A i B i .seti, i + 1 .endr .endm function: C ret
gcc-4.6-20121012 is now available
Snapshot gcc-4.6-20121012 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.6-20121012/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.6 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_6-branch revision 192415 You'll find: gcc-4.6-20121012.tar.bz2 Complete GCC MD5=18ab7b73c10a407fbecbce2e0df28c89 SHA1=04dc8856bd7649c3dee0461511615330ae9d6f01 Diffs from 4.6-20121005 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.6 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: macro's and local variables
On 12 October 2012 22:43, Mischa Baars wrote: > Hi All, > > Who can take a first look at this in the morning? Hi, I looked, they seem to be some files. Nice. If you want people to look at them properly you should probably send them to the gcc-help list and explain why you want people to look at them.
