lkml.org 
[lkml]   [2003]   [Jun]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    Patches in this message
    /
    Date
    From
    Subject[GCC] gcc vs. indentation
    	The story begun when i`ve started to make indentation fixes in the DAC960 driver.
    And in order to ensure i didn`t broke anything i was checking a diff between the
    resulting object files.

    Surprisingly enough i`ve realised soon that indeed some indentation changes
    give gcc a reason to produce different code.

    One of the cases is below, all three of them are in the attached .tar.gz file.
    The code in question is the 2.5.72-bk1 kernel, however there was no changes
    in the related code for some time, so plain .72 should be safe.

    The examples are in the form of pairs of a C diff, and a "objdump -d" output diff.

    The C diff:
    diff -X scripts/Xrule -urN 25/drivers/block/DAC960.c 25dac/drivers/block/DAC960.c
    --- 25/drivers/block/DAC960.c 2003-06-17 01:09:50.000000000 +0400
    +++ 25dac/drivers/block/DAC960.c 2003-06-29 22:11:01.000000000 +0400
    @@ -272,8 +272,7 @@
    dma_addr_t RequestSenseDMA;
    struct pci_pool *RequestSensePool = NULL;

    - if (Controller->FirmwareType == DAC960_V1_Controller)
    - {
    + if (Controller->FirmwareType == DAC960_V1_Controller) {
    CommandAllocationLength = offsetof(DAC960_Command_T, V1.EndMarker);
    CommandAllocationGroupSize = DAC960_V1_CommandAllocationGroupSize;
    ScatterGatherPool = pci_pool_create("DAC960_V1_ScatterGather",
    --- ./origDAC960.o.d 2003-06-29 21:02:55.000000000 +0400
    +++ ./newDAC960.o.d 2003-06-29 22:13:46.000000000 +0400
    @@ -1,5 +1,5 @@

    -origDAC960.o: file format elf32-i386
    +./newDAC960.o: file format elf32-i386

    Disassembly of section .text:

    @@ -5837,7 +5837,7 @@
    52a8: 84 c0 test %al,%al
    52aa: 75 14 jne 52c0 <DAC960_V1_ProcessCompletedCommand+0x80>
    52ac: 0f 0b ud2a
    - 52ae: 7d 0d jge 52bd <DAC960_V1_ProcessCompletedCommand+0x7d>
    + 52ae: 7c 0d jl 52bd <DAC960_V1_ProcessCompletedCommand+0x7d>
    52b0: 27 daa
    52b1: 00 00 add %al,(%eax)
    52b3: 00 8d b6 00 00 00 add %cl,0xb6(%ebp)
    @@ -5951,7 +5951,7 @@
    5421: 84 c0 test %al,%al
    5423: 0f 85 97 fe ff ff jne 52c0 <DAC960_V1_ProcessCompletedCommand+0x80>
    5429: 0f 0b ud2a
    - 542b: 8f 0d 27 00 00 00 popl 0x27
    + 542b: 8e 0d 27 00 00 00 movl 0x27,%cs
    5431: e9 8a fe ff ff jmp 52c0 <DAC960_V1_ProcessCompletedCommand+0x80>
    5436: 89 1c 24 mov %ebx,(%esp,1)
    5439: e8 fc ff ff ff call 543a <DAC960_V1_ProcessCompletedCommand+0x1fa>
    @@ -7414,7 +7414,7 @@
    6ba2: 84 c0 test %al,%al
    6ba4: 75 0a jne 6bb0 <DAC960_V2_ProcessCompletedCommand+0xa0>
    6ba6: 0f 0b ud2a
    - 6ba8: bc 11 27 00 00 mov $0x2711,%esp
    + 6ba8: bb 11 27 00 00 mov $0x2711,%ebx
    6bad: 00 89 f6 83 bc 24 add %cl,0x24bc83f6(%ecx)
    6bb3: 84 00 test %al,(%eax)
    6bb5: 00 00 add %al,(%eax)

    Thats it.
    The point is i thought and hoped that gcc abstract syntax tree constructor is
    indentation invariant, and that is seemingly not true.

    regards, Samium Gromoff
    [unhandled content-type:application/octet-stream]
    \
     
     \ /
      Last update: 2005-03-22 13:46    [W:0.023 / U:0.876 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site