Patchwork RFA: Testsuite: Fixes for PR44197.c

login
register
mail settings
Submitter Nick Clifton
Date Oct. 11, 2010, 2:08 p.m.
Message ID <4CB31A7B.7020809@redhat.com>
Download mbox | patch
Permalink /patch/67425/
State New
Headers show

Comments

Nick Clifton - Oct. 11, 2010, 2:08 p.m.
Hi Richard,

>> +#define xstr(s) str(s)
>> +#define str(s) #s
>> +#define PREFIX xstr(__USER_LABEL_PREFIX__)
>
> Err, string-izing a string?

Yeah, I know, it does not seem to make much sense, but I found that I 
had to do it that way in order to get the string concatenation to work. 
  I did try just putting __USER_LABEL_PREFIX__ into the asm() statement, 
but it just did not work.  This str() and xstr() nonesense was the only 
way that I found that produced the correct results. :-}

> Surely that default version of U_L_P should be empty,
> or put the ifdef around the entire stringizing bit.

OK, revised patch attached with a simple definition of PREFIX is U_L_P 
is not defined.

OK to apply ?

Cheers
   Nick
Richard Henderson - Oct. 11, 2010, 3:04 p.m.
On 10/11/2010 07:08 AM, Nick Clifton wrote:
> OK, revised patch attached with a simple definition of PREFIX is U_L_P is not defined.

Ok.


r~
Dave Korn - Oct. 11, 2010, 4:06 p.m.
On 11/10/2010 15:08, Nick Clifton wrote:
> Hi Richard,
> 
>>> +#define xstr(s) str(s)
>>> +#define str(s) #s
>>> +#define PREFIX xstr(__USER_LABEL_PREFIX__)
>>
>> Err, string-izing a string?
> 
> Yeah, I know, it does not seem to make much sense, but I found that I
> had to do it that way in order to get the string concatenation to work.
>  I did try just putting __USER_LABEL_PREFIX__ into the asm() statement,
> but it just did not work.  This str() and xstr() nonesense was the only
> way that I found that produced the correct results. :-}

  I don't understand this.  How did the pre-processed sources come out looking
like when you just had plain ULP in the asm?  If it didn't work, doesn't that
mean there is a bug?  Do we know if the preprocessor handles ANSI C string
concatentation inside asms correctly or not?

    cheers,
      DaveK
Nick Clifton - Oct. 11, 2010, 4:37 p.m.
Hi Dave,

>    I don't understand this.  How did the pre-processed sources come out looking
> like when you just had plain ULP in the asm?  If it didn't work, doesn't that
> mean there is a bug?  Do we know if the preprocessor handles ANSI C string
> concatentation inside asms correctly or not?

The answer is that U_L_P is not a string, but a single character. 
(Despite being defined as a string by the various backends that use it). 
  So just using U_L_P in place, like this:

   extern
   __typeof (__C_ctype_b)
     __C_ctype_b __asm__ (__USER_LABEL_PREFIX__ "__GI___C_ctype_b")
     __attribute__ ((visibility ("hidden")));

results in this error message:

   pr44197.c:17:22: error: expected string literal before '_'

when compiled with the any toolchain that defines U_L_P to a non empty 
string.  You can also make it happen on other targets (eg 
i686-pc-linux-gnu) by adding the -fleading-underscore switch to the 
command line.  The preprocessed output looks like this:

   extern
   __typeof (__C_ctype_b)
     __C_ctype_b __asm__ (_ "__GI___C_ctype_b")
     __attribute__ ((visibility ("hidden")));


Hence the shenanigans with the string-izing macros in order to make the 
pr44197.c code compile.

Cheers
   Nick
Kai Tietz - Oct. 11, 2010, 4:56 p.m.
2010/10/11 Nick Clifton <nickc@redhat.com>:
> Hi Dave,
>
>>   I don't understand this.  How did the pre-processed sources come out
>> looking
>> like when you just had plain ULP in the asm?  If it didn't work, doesn't
>> that
>> mean there is a bug?  Do we know if the preprocessor handles ANSI C string
>> concatentation inside asms correctly or not?
>
> The answer is that U_L_P is not a string, but a single character. (Despite
> being defined as a string by the various backends that use it).  So just
> using U_L_P in place, like this:
>
>  extern
>  __typeof (__C_ctype_b)
>    __C_ctype_b __asm__ (__USER_LABEL_PREFIX__ "__GI___C_ctype_b")
>    __attribute__ ((visibility ("hidden")));
>
> results in this error message:
>
>  pr44197.c:17:22: error: expected string literal before '_'
>
> when compiled with the any toolchain that defines U_L_P to a non empty
> string.  You can also make it happen on other targets (eg i686-pc-linux-gnu)
> by adding the -fleading-underscore switch to the command line.  The
> preprocessed output looks like this:
>
>  extern
>  __typeof (__C_ctype_b)
>    __C_ctype_b __asm__ (_ "__GI___C_ctype_b")
>    __attribute__ ((visibility ("hidden")));
>
>
> Hence the shenanigans with the string-izing macros in order to make the
> pr44197.c code compile.
>
> Cheers
>  Nick
>

Yes, I know this issue pretty well. I did in the past some magic here
in i386.h for this. See CRT_MKSTR(__USER_LABEL_PREFIX).

Sadly this magic is necessary for i386.

--
Kai
Kai Tietz - Oct. 11, 2010, 5:35 p.m.
2010/10/11 Dave Korn <dave.korn.cygwin@gmail.com>:
> On 11/10/2010 17:56, Kai Tietz wrote:
>
>> Yes, I know this issue pretty well. I did in the past some magic here
>> in i386.h for this. See CRT_MKSTR(__USER_LABEL_PREFIX).
>
>  Oh, hang on:
>
>> #define CRT_CALL_STATIC_FUNCTION(SECTION_OP, FUNC)            \
>>    asm (SECTION_OP "\n\t"                                     \
>>       "call " CRT_MKSTR(__USER_LABEL_PREFIX__) #FUNC "\n"     \
>>       TEXT_SECTION_ASM_OP);
>
>  Am I wrong, or is it not the case that a) you could use the proper quoted
> USER_LABEL_PREFIX backend definition there, and b) that could go wrong in
> cross, because it would use the build system compiler's definition of
> __U_L_P__, which would be correct for the host system but not necessarily
> right for the target?
>
>    cheers,
>      DaveK
>
>

There can go anything wrong, as this macro is used in libgcc (and
friends only). And it never will be build native target libraries for
cross compilation.
Nevertheless this mixture of host/target stuff within headers is a bit
irretating and somehow a kludge.

Cheers,
Kai
Dave Korn - Oct. 11, 2010, 5:41 p.m.
On 11/10/2010 17:37, Nick Clifton wrote:

> The answer is that U_L_P is not a string, but a single character.
> (Despite being defined as a string by the various backends that use it).

  Ah, so it's not really "stringizing a string" after all; it's quoted in the
definitions of USER_LABEL_PREFIX in the backends, but the predefined
__USER_LABEL_PREFIX__ macro supplied by the resulting generated compiler is
unquoted.  Thanks for going into the details :)

    cheers,
      DaveK
Dave Korn - Oct. 11, 2010, 5:44 p.m.
On 11/10/2010 17:56, Kai Tietz wrote:

> Yes, I know this issue pretty well. I did in the past some magic here
> in i386.h for this. See CRT_MKSTR(__USER_LABEL_PREFIX).

  Oh, hang on:

> #define CRT_CALL_STATIC_FUNCTION(SECTION_OP, FUNC)		\
>    asm (SECTION_OP "\n\t"					\
> 	"call " CRT_MKSTR(__USER_LABEL_PREFIX__) #FUNC "\n"	\
> 	TEXT_SECTION_ASM_OP);

  Am I wrong, or is it not the case that a) you could use the proper quoted
USER_LABEL_PREFIX backend definition there, and b) that could go wrong in
cross, because it would use the build system compiler's definition of
__U_L_P__, which would be correct for the host system but not necessarily
right for the target?

    cheers,
      DaveK
Dave Korn - Oct. 11, 2010, 6:18 p.m.
On 11/10/2010 18:35, Kai Tietz wrote:

> There can go anything wrong, as this macro is used in libgcc (and
> friends only). 

  Ah, indeed, so it's only ever built with the target compiler anyway.
Gotcha, thanks.

    cheers,
      DaveK

Patch

Index: gcc/testsuite/gcc.c-torture/compile/pr44197.c
===================================================================
--- gcc/testsuite/gcc.c-torture/compile/pr44197.c	(revision 165275)
+++ gcc/testsuite/gcc.c-torture/compile/pr44197.c	(working copy)
@@ -1,4 +1,14 @@ 
 /* { dg-require-alias "" } */
+/* { dg-require-visibility "" } */
+
+#ifndef __USER_LABEL_PREFIX__
+#define PREFIX ""
+#else
+#define xstr(s) str(s)
+#define str(s)  #s
+#define PREFIX  xstr(__USER_LABEL_PREFIX__)
+#endif
+
 typedef unsigned short int __uint16_t;
 enum
 {
@@ -12,7 +22,7 @@ 
 extern const __ctype_mask_t *__C_ctype_b;
 extern
 __typeof (__C_ctype_b)
-     __C_ctype_b __asm__ ("" "__GI___C_ctype_b")
+   __C_ctype_b __asm__ (PREFIX "__GI___C_ctype_b")
   __attribute__ ((visibility ("hidden")));
      static const __ctype_mask_t __C_ctype_b_data[] = {
      };