2.4.7 -- GCC-3.0 -- "multiline string literals deprecated" -- PATCH

2.4.7 -- GCC-3.0 -- "multiline string literals deprecated" -- PATCH

[paulr]

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

Folks,

While building both kernels 2.4.6 and 2.4.7,
I encountered a series of compiler warnings,

warning: multiline string literals are deprecated.

The build environment was gcc3.0 and binutils-2.11.2.

In:
linux/arch/i386/kernel/semaphore.c,
linux/include/asm-i386/checksum.h, and
linux/include/asm-i386/floppy.h,

the placement of "" characters in the asm() directives
appeared to be the source of the messages.

The compiler messages seem harmless.  Unfortunately,
warnings from these asm() constructs flooded the compile
log, making it difficult to locate "real" warnings....

I have attached patches against 2.4.7 for the files
above. " and \n" constructs were added for each asm()
stanza where the messages occurred.  Please note that
this seems to be compiler-related.  The 2.4.7 code worked
fine ;-)

NOTE:

I do *not* have an SMP system to verify the correctness
of the CONFIG_SMP asm() conditionals in

      linux/arch/i386/kernel/semaphore.c

Please verify the SMP case.....

Please cc: me as needed; I am not subscribed to l-k.


Regards,

Paul


-- 
*********************************************
Paul Reich              RF/Microwave Engineer

    Support the "Freedom To Innovate"...
                Just say "No".

*********************************************

[-- Attachment #2: checksum.h.patch --]
[-- Type: application/octet-stream, Size: 2347 bytes --]

--- linux/include/asm-i386/checksum.h.orig	Sat Jul 28 13:43:16 2001
+++ linux/include/asm-i386/checksum.h	Sat Jul 28 14:37:31 2001
@@ -69,25 +69,25 @@
 					  unsigned int ihl) {
 	unsigned int sum;
 
-	__asm__ __volatile__("
-	    movl (%1), %0
-	    subl $4, %2
-	    jbe 2f
-	    addl 4(%1), %0
-	    adcl 8(%1), %0
-	    adcl 12(%1), %0
-1:	    adcl 16(%1), %0
-	    lea 4(%1), %1
-	    decl %2
-	    jne	1b
-	    adcl $0, %0
-	    movl %0, %2
-	    shrl $16, %0
-	    addw %w2, %w0
-	    adcl $0, %0
-	    notl %0
-2:
-	    "
+	__asm__ __volatile__(
+"	   movl (%1), %0\n"
+"	   subl $4, %2\n"
+"	   jbe 2f\n"
+"	   addl 4(%1), %0\n"
+"	   adcl 8(%1), %0\n"
+"	   adcl 12(%1), %0\n"
+"1:	   adcl 16(%1), %0\n"
+"	   lea 4(%1), %1\n"
+"	   decl %2\n"
+"	   jne	1b\n"
+"	   adcl $0, %0\n"
+"	   movl %0, %2\n"
+"	   shrl $16, %0\n"
+"	   addw %w2, %w0\n"
+"	   adcl $0, %0\n"
+"	   notl %0\n"
+"2:"
+
 	/* Since the input registers which are loaded with iph and ipl
 	   are modified, we must also specify them as outputs, or gcc
 	   will assume they contain their original values. */
@@ -102,10 +102,10 @@
 
 static inline unsigned int csum_fold(unsigned int sum)
 {
-	__asm__("
-		addl %1, %0
-		adcl $0xffff, %0
-		"
+	__asm__(
+	"	addl %1, %0\n"
+	"	adcl $0xffff, %0\n"
+
 		: "=r" (sum)
 		: "r" (sum << 16), "0" (sum & 0xffff0000)
 	);
@@ -118,12 +118,12 @@
 						   unsigned short proto,
 						   unsigned int sum) 
 {
-    __asm__("
-	addl %1, %0
-	adcl %2, %0
-	adcl %3, %0
-	adcl $0, %0
-	"
+    __asm__(
+"	addl %1, %0\n"
+"	adcl %2, %0\n"
+"	adcl %3, %0\n"
+"	adcl $0, %0\n"
+
 	: "=r" (sum)
 	: "g" (daddr), "g"(saddr), "g"((ntohs(len)<<16)+proto*256), "0"(sum));
     return sum;
@@ -158,19 +158,19 @@
 						     unsigned short proto,
 						     unsigned int sum) 
 {
-	__asm__("
-		addl 0(%1), %0
-		adcl 4(%1), %0
-		adcl 8(%1), %0
-		adcl 12(%1), %0
-		adcl 0(%2), %0
-		adcl 4(%2), %0
-		adcl 8(%2), %0
-		adcl 12(%2), %0
-		adcl %3, %0
-		adcl %4, %0
-		adcl $0, %0
-		"
+	__asm__(
+	"	addl 0(%1), %0\n"
+	"	adcl 4(%1), %0\n"
+	"	adcl 8(%1), %0\n"
+	"	adcl 12(%1), %0\n"
+	"	adcl 0(%2), %0\n"
+	"	adcl 4(%2), %0\n"
+	"	adcl 8(%2), %0\n"
+	"	adcl 12(%2), %0\n"
+	"	adcl %3, %0\n"
+	"	adcl %4, %0\n"
+	"	adcl $0, %0\n"
+
 		: "=&r" (sum)
 		: "r" (saddr), "r" (daddr), 
 		  "r"(htonl(len)), "r"(htonl(proto)), "0"(sum));

[-- Attachment #3: floppy.h.patch --]
[-- Type: application/octet-stream, Size: 960 bytes --]

--- linux/include/asm-i386/floppy.h.orig	Sat Jul 28 14:20:26 2001
+++ linux/include/asm-i386/floppy.h	Sat Jul 28 14:34:18 2001
@@ -75,28 +75,28 @@
 
 #ifndef NO_FLOPPY_ASSEMBLER
 	__asm__ (
-       "testl %1,%1
-	je 3f
-1:	inb %w4,%b0
-	andb $160,%b0
-	cmpb $160,%b0
-	jne 2f
-	incw %w4
-	testl %3,%3
-	jne 4f
-	inb %w4,%b0
-	movb %0,(%2)
-	jmp 5f
-4:     	movb (%2),%0
-	outb %b0,%w4
-5:	decw %w4
-	outb %0,$0x80
-	decl %1
-	incl %2
-	testl %1,%1
-	jne 1b
-3:	inb %w4,%b0
-2:	"
+"       testl %1,%1\n"
+"	je 3f\n"
+"1:	inb %w4,%b0\n"
+"	andb $160,%b0\n"
+"	cmpb $160,%b0\n"
+"	jne 2f\n"
+"	incw %w4\n"
+"	testl %3,%3\n"
+"	jne 4f\n"
+"	inb %w4,%b0\n"
+"	movb %0,(%2)\n"
+"	jmp 5f\n"
+"4:     movb (%2),%0\n"
+"	outb %b0,%w4\n"
+"5:	decw %w4\n"
+"	outb %0,$0x80\n"
+"	decl %1\n"
+"	incl %2\n"
+"	testl %1,%1\n"
+"	jne 1b\n"
+"3:	inb %w4,%b0\n"
+"2:"
        : "=a" ((char) st), 
        "=c" ((long) virtual_dma_count), 
        "=S" ((long) virtual_dma_addr)

[-- Attachment #4: semaphore.c.patch --]
[-- Type: application/octet-stream, Size: 2570 bytes --]

--- linux/arch/i386/kernel/semaphore.c.orig	Sat Jul 28 13:57:29 2001
+++ linux/arch/i386/kernel/semaphore.c	Sat Jul 28 14:50:50 2001
@@ -181,56 +181,56 @@
 ".text\n"
 ".align 4\n"
 ".globl __down_failed\n"
-"__down_failed:\n\t"
-	"pushl %eax\n\t"
-	"pushl %edx\n\t"
-	"pushl %ecx\n\t"
-	"call __down\n\t"
-	"popl %ecx\n\t"
-	"popl %edx\n\t"
-	"popl %eax\n\t"
-	"ret"
+"__down_failed:\n"
+"	pushl %eax\n"
+"	pushl %edx\n"
+"	pushl %ecx\n"
+"	call __down\n"
+"	popl  %ecx\n"
+"	popl  %edx\n"
+"	popl  %eax\n"
+"	ret\n"
 );
 
 asm(
 ".text\n"
 ".align 4\n"
 ".globl __down_failed_interruptible\n"
-"__down_failed_interruptible:\n\t"
-	"pushl %edx\n\t"
-	"pushl %ecx\n\t"
-	"call __down_interruptible\n\t"
-	"popl %ecx\n\t"
-	"popl %edx\n\t"
-	"ret"
+"__down_failed_interruptible:\n"
+"	pushl %edx\n"
+"	pushl %ecx\n"
+"	call  __down_interruptible\n"
+"	popl  %ecx\n"
+"	popl  %edx\n"
+"	ret\n"
 );
 
 asm(
 ".text\n"
 ".align 4\n"
 ".globl __down_failed_trylock\n"
-"__down_failed_trylock:\n\t"
-	"pushl %edx\n\t"
-	"pushl %ecx\n\t"
-	"call __down_trylock\n\t"
-	"popl %ecx\n\t"
-	"popl %edx\n\t"
-	"ret"
+"__down_failed_trylock:\n"
+"	pushl %edx\n"
+"	pushl %ecx\n"
+"	call  __down_trylock\n"
+"	popl  %ecx\n"
+"	popl  %edx\n"
+"	ret\n"
 );
 
 asm(
 ".text\n"
 ".align 4\n"
 ".globl __up_wakeup\n"
-"__up_wakeup:\n\t"
-	"pushl %eax\n\t"
-	"pushl %edx\n\t"
-	"pushl %ecx\n\t"
-	"call __up\n\t"
-	"popl %ecx\n\t"
-	"popl %edx\n\t"
-	"popl %eax\n\t"
-	"ret"
+"__up_wakeup:\n"
+"	pushl %eax\n"
+"	pushl %edx\n"
+"	pushl %ecx\n"
+"	call  __up\n"
+"	popl  %ecx\n"
+"	popl  %edx\n"
+"	popl  %eax\n"
+"	ret\n"
 );
 
 /*
@@ -238,29 +238,29 @@
  */
 #if defined(CONFIG_SMP)
 asm(
-"
-.align	4
-.globl	__write_lock_failed
-__write_lock_failed:
-	" LOCK "addl	$" RW_LOCK_BIAS_STR ",(%eax)
-1:	cmpl	$" RW_LOCK_BIAS_STR ",(%eax)
-	jne	1b
-
-	" LOCK "subl	$" RW_LOCK_BIAS_STR ",(%eax)
-	jnz	__write_lock_failed
-	ret
-
-
-.align	4
-.globl	__read_lock_failed
-__read_lock_failed:
-	lock ; incl	(%eax)
-1:	cmpl	$1,(%eax)
-	js	1b
-
-	lock ; decl	(%eax)
-	js	__read_lock_failed
-	ret
-"
+
+".align		4\n"
+".globl		__write_lock_failed\n"
+"__write_lock_failed:\n\t"
+"		"LOCK "addl	$" RW_LOCK_BIAS_STR ",(%eax)\n"
+"1:		 cmpl		$" RW_LOCK_BIAS_STR ",(%eax)\n"
+"		jne		1b\n"
+
+"		" LOCK "subl	$" RW_LOCK_BIAS_STR ",(%eax)\n"
+"		jnz		__write_lock_failed\n"
+"		ret\n"
+
+
+".align		4\n"
+".globl		__read_lock_failed\n"
+"__read_lock_failed:\n"
+"		lock ; incl	(%eax)\n"
+"1:		cmpl		$1,(%eax)\n"
+"		js		1b\n"
+
+"		lock ; decl	(%eax)\n"
+"		js		__read_lock_failed\n"
+"		ret\n"
+
 );
 #endif

Re: 2.4.7 -- GCC-3.0 -- "multiline string literals deprecated" -- PATCH

[Gareth Hughes]

paulr wrote:
> 
> Folks,
> 
> While building both kernels 2.4.6 and 2.4.7,
> I encountered a series of compiler warnings,
> 
> warning: multiline string literals are deprecated.
> 
> The build environment was gcc3.0 and binutils-2.11.2.

Yes, unfortunately GCC 3.0 deprecated multiline string literals -- I saw
someone arguing on the GCC mailing lists that writing large chunks of
inline asm shouldn't be "easy", as it interferes with the compiler's
optimization passes.  There were other such braindead arguments
supporting the deprecation.  The thread should be pretty easy to find in
the archives.  Don't know if the deprecation will be removed in future
versions.

-- Gareth

Re: 2.4.7 -- GCC-3.0 -- "multiline string literals deprecated" -- PATCH

[Matti Aarnio]

On Tue, Jul 31, 2001 at 11:52:56PM +1000, Gareth Hughes wrote:
> paulr wrote:
> > Folks,
> > 
> > While building both kernels 2.4.6 and 2.4.7,
> > I encountered a series of compiler warnings,
> > 
> > warning: multiline string literals are deprecated.
> > 
> > The build environment was gcc3.0 and binutils-2.11.2.
> 
> Yes, unfortunately GCC 3.0 deprecated multiline string literals -- I saw
> someone arguing on the GCC mailing lists that writing large chunks of
> inline asm shouldn't be "easy",....

   Those are different things.

   The multiline string literal deprecation comes from people who
   define what the new ANSI-C (C9X, or whatever) is, and inline asm
   just uses literal strings as its input data.

   The inline asm() does essentially want to look like a function call
   with lots of strings as parameters.  It has special __builtin_ meaning,
   of course, but that is way after the lexical input scanner has done
   its work.

> -- Gareth

/Matti Aarnio

Re: 2.4.7 -- GCC-3.0 -- "multiline string literals deprecated" -- PATCH

[Horst von Brand]

Gareth Hughes <gareth.hughes@acm.org> said:

[...]

> Yes, unfortunately GCC 3.0 deprecated multiline string literals 

AFAIU, they are non-standard, and can easily hide bugs (in opening a string
and forgetting to close you are in escence commenting out lines of code)

>                                                                 -- I saw
> someone arguing on the GCC mailing lists that writing large chunks of
> inline asm shouldn't be "easy",

Right. If you use a compiler, you shouldn't need it much. Better make
other, more important, things easy/more foolproof, even at some cost for
the asm() writer. (Hint: Count the lines of asm in the kernel (an
_extremely_ heavy asm user!) vs the lines of plain C)

>                                 as it interferes with the compiler's
> optimization passes.  There were other such braindead arguments
> supporting the deprecation. 

Yep, this is a braindead argument. There must have been others (sensible
ones)... 
 
>                             The thread should be pretty easy to find in
> the archives.  Don't know if the deprecation will be removed in future
> versions.

I hope they disallow multiline strings pretty soon.
-- 
Dr. Horst H. von Brand                Usuario #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

Re: 2.4.7 -- GCC-3.0 -- "multiline string literals deprecated" -- PATCH

[Gareth Hughes]

Horst von Brand wrote:
> 
> AFAIU, they are non-standard, and can easily hide bugs (in opening a string
> and forgetting to close you are in escence commenting out lines of code)

Zack Weinberg, who's post started the thread, gave three main criteria
for their removal in
http://gcc.gnu.org/ml/gcc-patches/2001-07/msg00327.html, including:

<quote>
There is only one argument in my mind for keeping them:

  - It makes it easier to write lengthy chunks of inline assembly.

This is certainly true, however, writing a lengthy chunk of inline
assembly is almost always a mistake; it interferes with the compiler's
ability to do its job.  Therefore I do not think there is any
compelling need to make that easy.
</quote>

If I ever write inline assembly, then it's for a very good reason.  I'd
hesitate to call almost all uses of inline assembly a "mistake",
particlarly in places like the kernel, or math-intensive ones like 3D
graphics.

> Right. If you use a compiler, you shouldn't need it much. Better make
> other, more important, things easy/more foolproof, even at some cost for
> the asm() writer. (Hint: Count the lines of asm in the kernel (an
> _extremely_ heavy asm user!) vs the lines of plain C)

No argument re: lines of code.  However, if I have to write a decent
chunk of inline assembly, multiline strings are much nicer IMHO.

> Yep, this is a braindead argument. There must have been others (sensible
> ones)...

See above ;-)

> I hope they disallow multiline strings pretty soon.

I don't have strong feelings either way.  And I sure don't want to have
this argument again...

-- Gareth