mirror of https://lore.kernel.org/lkml/
 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 ` 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®