All of lore.kernel.org
 help / color / mirror / Atom feed
From: Samium Gromoff <deepfire@ibe.miee.ru>
To: linux-kernel@vger.kernel.org, gcc-bugs@gcc.gnu.org
Subject: [GCC] gcc vs. indentation
Date: Mon, 30 Jun 2003 09:20:15 +0400	[thread overview]
Message-ID: <20030630092015.49dd6969.deepfire@ibe.miee.ru> (raw)

[-- Attachment #1: Type: text/plain, Size: 3381 bytes --]

	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

[-- Attachment #2: gcc-hrmph.tar.gz --]
[-- Type: application/octet-stream, Size: 2070 bytes --]

             reply	other threads:[~2003-06-30  6:04 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-06-30  5:20 Samium Gromoff [this message]
2003-06-30  7:04 ` [GCC] gcc vs. indentation Hugh Dickins
2003-06-30  6:13   ` Samium Gromoff
2003-07-01 13:12 ` Horst von Brand

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20030630092015.49dd6969.deepfire@ibe.miee.ru \
    --to=deepfire@ibe.miee.ru \
    --cc=gcc-bugs@gcc.gnu.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.