[Debian-med-packaging] Bug#925629: aghermann: ftbfs with GCC-9

[Matthew Fernandez]

Sorry, I didn’t have much context for the original issue and was probably too terse in my responses. Some more elaboration inline below.

> On Jan 13, 2020, at 01:14, Andreas Tille <andreas at fam-tille.de> wrote:
> 
> On Sun, Jan 12, 2020 at 02:08:56PM -0800, Matthew Fernandez wrote:
>> 
>>> On Jan 12, 2020, at 12:49, Andreas Tille <andreas at an3as.eu> wrote:
>>> 
>>> Hi,
>>> 
>>> I'm wondering how this bug
>>> 
>>> 
>>> rk1968/rk1968.cc: In lambda function:
>>> rk1968/rk1968.cc:237:103: error: expected '{' before '->' token
>>> 237 |         auto make_error_return = [&L] ( const char* fmt, ...) __attribute__ ((format (printf, 2, 3))) -> int
>>>     |                                                                                                       ^~
>>> 
>>> 
>>> with gcc 9 can be fixed in aghermann.  Any help would be appreciated.
>> 
>> Turning this into a C++11 attribute ([[gnu::format(printf, 2, 3)]]) makes the parse error go away, but -Wattributes still indicates GCC is ignoring it.
> 
> I admit I do not understand your "but -Wattributes ...".  I can confirm
> that this patch[1] builds the package successfully.

-Wattributes is a flag to GCC to enable warnings about attributes. What I did to experiment was extract the code you’d quoted into an isolated context:

    $ cat - >test.cc <http://test.cc/> <<EOT
    void foo(int L) {
      auto make_error_return = [&L] ( const char* fmt, ...) __attribute__ ((format (printf, 2, 3))) -> int
      {
        return 0;
      }
    }
    EOT
    $ g++ -std=c++11 -c -Wattributes test.cc

>> You might need to bump that GCC issue with some evidence that the bug still exists and see what the maintainers say.
> 
> I need to admit that I understand so less from all the gcc issues you
> tried to explain - I do not even have any idea what C++ attributes are.
> I simply cared for that Debian bug since nobody else did. :-(
> So I feel really incompetent to discuss this with gcc maintainers but
> I'd welcome if you bring it up there.

GCC attributes like the __attribute__ example here are a mechanism for annotating C/C++ code with things not covered by the ISO standards, but supported by compiler extensions. Attributes can be applied to many things including variables and functions, and the function attributes are documented at https://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html <https://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html>. These days Clang also understands many of the GCC attributes.

The particular one in question here is telling the compiler that the lambda function being defined has similar behavior to the libc printf function. The integer parameters say a printf format string appears as the second argument and the first varargs parameter is the third argument. This looks off by one, but I think the captured local (&L) counts as the first parameter. The only thing the compiler uses this attribute for is to detect calls to this lambda with incorrect arguments and emit warnings for them.

The C++11 standard brought in a more commonly supported way of declaring attributes using square brackets. Unfortunately the standard does not support many common attributes and you still need to use a “gnu::” prefix to access the GCC-specific attributes. Hence, “[[gnu::format(printf, 2, 3)]]” being the C++11 equivalent of this.

>> If you need to bypass this urgently, I would recommend deleting the attribute as that particular one is only used to aid the compiler in creating warnings.
> 
> Hmmm, as I said my patch[1] works and I just have the gut feeling (as I
> said I have no competence!) that this might be better than to delete the
> attribute.  If not would you mind sending an alternative patch which is
> better in your opinion?

Lambda functions, which are already being used in this code, are a C++11 feature as are this style of attributes. So I imagine it would be acceptable to upstream to take your patch. Having said that, when I did this in my experiment code above the compiler warned that it was ignoring this attribute as it thought it was being applied to the trailing “int”.

I re-read the GCC issue and realized I’d misread Jonathan Wakely’s comments. The issue is actually still open and Jonathan was just noting that r265787 introduced the bug, not fixed it. So I think what we’re seeing is consistent with the GCC maintainers’ view.

I would suggest proposing your patch upstream. Although its primary purpose is working around a compiler bug, it’s also an objective improvement in modernizing the code base.

> Thanks again
> 
>       Andreas.
> 
> 
>>  [0]: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90333 <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90333>
> 
> [1] https://salsa.debian.org/med-team/aghermann/blob/master/debian/patches/workaround_gcc-9_issue.patch <https://salsa.debian.org/med-team/aghermann/blob/master/debian/patches/workaround_gcc-9_issue.patch>
> 
> -- 
> http://fam-tille.de <http://fam-tille.de/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/debian-med-packaging/attachments/20200113/20771cc8/attachment-0001.html>