And that's with the file installed as /usr/local/include/sys/sdt.h?

I thought -isystem defeated that particular lossage--it certainly did in the tests I did before.  It's only with -pedantic (generally considered useless, though some nutballs do put it in their builds), by the way.

Any such report needs full details about the gcc version.

(In reply to comment #1)
> And that's with the file installed as /usr/local/include/sys/sdt.h?

Yes, I confirmed this with -E.  For this test, it's via testsuite/sys/sdt.h, which does get to /usr/local correctly in the end.

> I thought -isystem defeated that particular lossage--it certainly did in the
> tests I did before.  It's only with -pedantic (generally considered useless,
> though some nutballs do put it in their builds), by the way.

I agree, a compiler message of "I'm not required to support this" is a bit lame, but it is still a regression.  SDT V2 and V1 work fine with -pedantic.

> Any such report needs full details about the gcc version.

Sorry - this is on Fedora 13, both i686 and x86_64.
gcc (GCC) 4.4.4 20100630 (Red Hat 4.4.4-10)

An example from -E:

static void call4(int a, int b, int c, int d)
{
  __asm__ __volatile__ ("990: nop""\n" ".pushsection .note.stapsdt"",""\"\""",""\"note\"""\n" ".balign 4""\n" ".4byte 992f-991f"",""994f-993f"",""3""\n" "991: .asciz \"stapsdt\"""\n" "992: .balign 4""\n" "993: .8byte 990b""\n" ".8byte _.stapsdt.base""\n" ".8byte 0""\n" ".asciz \"test\"""\n" ".asciz \"mark_d\"""\n" ".asciz \"%n[_SDT_S1]@%[_SDT_A1] %n[_SDT_S2]@%[_SDT_A2] %n[_SDT_S3]@%[_SDT_A3] %n[_SDT_S4]@%[_SDT_A4]\"""\n" "994: .balign 4""\n" ".popsection""\n" ".ifndef _.stapsdt.base""\n" ".pushsection .stapsdt.base"",""\"aG\""",""\"progbits\"""," ".stapsdt.base"",""comdat""\n" ".weak _.stapsdt.base""\n" ".hidden _.stapsdt.base""\n" "_.stapsdt.base: .space 1""\n" ".size _.stapsdt.base"",""1""\n" ".popsection""\n" ".endif""\n" :: [_SDT_S1] "n" (((__typeof((a) + 0)) -1L > (__typeof((a) + 0)) 0 ? -1 : 1) * (int) sizeof ((a) + 0)), [_SDT_A1] "nor" ((a) + 0), [_SDT_S2] "n" (((__typeof((b) + 0)) -1L > (__typeof((b) + 0)) 0 ? -1 : 1) * (int) sizeof ((b) + 0)), [_SDT_A2] "nor" ((b) + 0), [_SDT_S3] "n" (((__typeof((c) + 0)) -1L > (__typeof((c) + 0)) 0 ? -1 : 1) * (int) sizeof ((c) + 0)), [_SDT_A3] "nor" ((c) + 0), [_SDT_S4] "n" (((__typeof((d) + 0)) -1L > (__typeof((d) + 0)) 0 ? -1 : 1) * (int) sizeof ((d) + 0)), [_SDT_A4] "nor" ((d) + 0));
}

Is it possible to split that into multiple __asm__ statements?

This is somewhat mysterious.  F13/x86-64 is the system where I tested this when I did it in the first place, though perhaps it was a slightly earlier gcc rpm (I don't recall).  I suppose it's possible I didn't test something I thought I had.

When I first committed the testsuite cleanups associated with sys/sdt.h, I used a space after -isystem and then Stan changed that later for reasons I don't recall ever understanding.  Just in case, try the same file with -isystem /... instead.

It's certainly feasible to rejigger the macro magic to wind up with more separate asm statements, though you'll have to take quite some care to make sure that all the permutations of the macros (the ones for embedding inside asm, e.g.) continue to work.  I really dislike that "solution" however, since it also introduces the opportunity for the compiler to emit other code in between them, which, though it seems unlikely to happen, could very well louse things up thoroughly in nonobvious ways if it did.

(In reply to comment #3)
> Just in case, try the same file with -isystem /... instead.

Adding a space doesn't help, nor does removing -isystem altogether to pick up /usr/local/include naturally.  Is the compiler supposed to ignore these warnings when the macro *expansion* is happening in the user's file?

If splitting the macros might introduce subtle problems, then let's not.  I'd rather disavow -pedantic and keep robust behavior.

Note that in previous versions of sdt.h we used __extension__ to suppress any -pedantic warnings for "weird" constructs:

http://gcc.gnu.org/onlinedocs/gcc/Alternate-Keywords.html

   `-pedantic' and other options cause warnings for many GNU C
extensions.  You can prevent such warnings within one expression by
writing `__extension__' before the expression.  `__extension__' has no
effect aside from this.

But I have some trouble figuring out where the expression starts in this case. Apparently __asm__ isn't an expression. hmmm.

(In reply to comment #5)
> But I have some trouble figuring out where the expression starts in this case.
> Apparently __asm__ isn't an expression. hmmm.

It's a statement.  You can do:  __extension__ ({ __asm__ __volatile__ (...); });
But that doesn't fix this warning. :(

The ".ifndef _.stapsdt.base [...] .endif" block is 198 bytes, and I think it wouldn't matter if the compiler did anything to split that from the rest, right?  So if we can make that a separate __asm__ string, that would take call10's 666 bytes down to 468, within the pedantic 509 limit.

Created attachment 5073 [details]
proposed fix, split out the asm for _.stapsdt.base

commit 5470765

Note that this still occurs on powerpc (f12 tofu.yyz) for the 9 and 10 cases.

(In reply to comment #4)
> Is the compiler supposed to ignore these
> warnings when the macro *expansion* is happening in the user's file?

This is a known gcc bug: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7263

I think the particular case of __extension__ "overlong string" can be handled
more simply.  This GCC patch seems to fix it for me.

diff --git a/gcc/c-parser.c b/gcc/c-parser.c
index 51df188..b0ef249 100644
--- a/gcc/c-parser.c
+++ b/gcc/c-parser.c
@@ -1045,13 +1045,15 @@ disable_extension_diagnostics (void)
 	     | (warn_traditional << 2)
 	     | (flag_iso << 3)
 	     | (warn_long_long << 4)
-	     | (warn_cxx_compat << 5));
+	     | (warn_cxx_compat << 5)
+	     | (warn_overlength_strings << 6));
   cpp_opts->cpp_pedantic = pedantic = 0;
   warn_pointer_arith = 0;
   cpp_opts->cpp_warn_traditional = warn_traditional = 0;
   flag_iso = 0;
   cpp_opts->cpp_warn_long_long = warn_long_long = 0;
   warn_cxx_compat = 0;
+  warn_overlength_strings = 0;
   return ret;
 }
 
@@ -1067,6 +1069,7 @@ restore_extension_diagnostics (int flags)
   flag_iso = (flags >> 3) & 1;
   cpp_opts->cpp_warn_long_long = warn_long_long = (flags >> 4) & 1;
   warn_cxx_compat = (flags >> 5) & 1;
+  warn_overlength_strings = (flags >> 6) & 1;
 }
 
 /* Possibly kinds of declarator to parse.  */

I sent a gcc patch:

http://gcc.gnu.org/ml/gcc-patches/2011-01/msg01230.html

(In reply to comment #12)
> I sent a gcc patch:
> 
> http://gcc.gnu.org/ml/gcc-patches/2011-01/msg01230.html

This was approved.
I am not going to check it in until the next stage 1, but I think
Jakub may include it in the F15 gcc (I asked him to).
In any case, it would not hurt to prefix the long strings with
"__extension__" now.  It won't break anything, even if gcc does
not have the patch.