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

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".

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

@@ -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));

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

Gareth Hughes <[email protected]> said:

[...]

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)

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)

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

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

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.

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

See above ;-)

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

-- Gareth

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.

/Matti Aarnio