Discussion:
Bug#925629: aghermann: ftbfs with GCC-9
(too old to reply)
Matthew Fernandez
2020-01-12 22:20:01 UTC
Permalink
Hi,
I'm wondering how this bug
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.
I think you’re hitting GCC bug #90333 [0]. This claims to have been fixed in r265787, but I can still reproduce this issue with GCC 9.2.1 that includes that commit. 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. You might need to bump that GCC issue with some evidence that the bug still exists and see what the maintainers say. 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.

[0]: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90333
andrei zavada
2020-01-13 06:20:02 UTC
Permalink
Sorry, yes, it was; now cc-ing both.

On Mon, 13 Jan 2020 at 03:36, Matthew Fernandez
Was this meant to also go to Andreas and the tracker?
Indeed, deleting that attribute would be best (perhaps with a link to
the gcc bug in a comment).
On Mon, 13 Jan 2020 at 00:08, Matthew Fernandez
Post by Matthew Fernandez
Hi,
I'm wondering how this bug
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.
I think you’re hitting GCC bug #90333 [0]. This claims to have been fixed in r265787, but I can still reproduce this issue with GCC 9.2.1 that includes that commit. 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. You might need to bump that GCC issue with some evidence that the bug still exists and see what the maintainers say. 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.
[0]: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90333
Andreas Tille
2020-01-13 09:20:01 UTC
Permalink
Hi Matthew,

thanks a lot for all your hints.
Post by Matthew Fernandez
Hi,
I'm wondering how this bug
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.
I think you’re hitting GCC bug #90333 [0]. This claims to have been fixed in r265787, but I can still reproduce this issue with GCC 9.2.1 that includes that commit.
Thanks for this pointer.
Post by Matthew Fernandez
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.
Post by Matthew Fernandez
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.
Post by Matthew Fernandez
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?

Thanks again

Andreas.
Post by Matthew Fernandez
[0]: 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
--
http://fam-tille.de
Matthew Fernandez
2020-01-13 15:30:01 UTC
Permalink
Sorry, I didn’t have much context for the original issue and was probably too terse in my responses. Some more elaboration inline below.
Post by Andreas Tille
Post by Matthew Fernandez
Hi,
I'm wondering how this bug
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
Post by Andreas Tille
Post by Matthew Fernandez
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.
Post by Andreas Tille
Post by Matthew Fernandez
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.
Post by Andreas Tille
Thanks again
Andreas.
Post by Matthew Fernandez
[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/>
Andreas Tille
2020-01-13 16:40:02 UTC
Permalink
Thanks a lot for the very helpful comments, Andreas.
Post by Matthew Fernandez
Post by Andreas Tille
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.
Post by Andreas Tille
Post by Matthew Fernandez
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.
Post by Andreas Tille
Thanks again
Andreas.
Post by Matthew Fernandez
[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/>
_______________________________________________
Debian-med-packaging mailing list
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging
--
http://fam-tille.de
andrei zavada
2020-01-14 02:40:01 UTC
Permalink
Gentlemen,

This is the original author of aghermann. First of all, thanks for
take good care of it. My circumstances have changed quite a bit since
I did my last release -- an age ago. In professional capacity, in 2010
I have turned to Erlang and, since around 2014, my proficiency in C++
has been in steady decline. These days, even as I am looking at this
40k LOC of my own code with a faint sense of some grand achievement, I
find myself totally incapable of carrying on with it. Please consider
this as a letter of retirement.

The other day I wanted to cherry-pick Andreas's changes
(https://salsa.debian.org/med-team/aghermann/commit/3cf06970a18219a327fc79a3580d94959ffd7a9a)
into my repo, but it being a mix of useful gtk3 deprecations and a lot
more, along with massive move/rename, I gave up. But all of them were
good.

I am aware of at least one recent paper where the slow-wave sleep
model as used in aghermann is revived and applied in very much the
same way: https://dx.doi.org/10.1093%2Fsleep%2Fzsy079. (It comes from
the lab of Vlad Viazovsky, who happens to be my old acquaintance, even
though we don't keep in touch.) This has largely vindicated my effort,
and it is my hope it can make your maintainership of it in Debian
worth your time.

Again, thanks a lot, and cheers!
Andrei
Post by Andreas Tille
Thanks a lot for the very helpful comments, Andreas.
Post by Matthew Fernandez
Post by Andreas Tille
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.
Post by Andreas Tille
Post by Matthew Fernandez
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.
Post by Andreas Tille
Thanks again
Andreas.
Post by Matthew Fernandez
[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/>
_______________________________________________
Debian-med-packaging mailing list
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging
--
http://fam-tille.de
Matthew Fernandez
2020-01-14 16:10:02 UTC
Permalink
Thanks for being clear, Andrei. And thanks for your work building and maintaining this package.

I jumped into this thread knowing nothing about this package but merely recognizing a compiler error. Now that I look up what it does, I don’t have the necessary background to fully understand its functionality. It does look like it’s still seeing some usage in Debian though [0]. I’m comfortable with C++, so Andreas, if you still want to proceed with the packaging work, I’m happy to review your changes.

By the way, what is the canonical upstream source for this project? All the repo links on the homepage [1] except SourceForge are broken and I assume no one is using SourceForge these days.

[0]: https://qa.debian.org/popcon.php?package=aghermann <https://qa.debian.org/popcon.php?package=aghermann>
[1]: http://johnhommer.com/academic/code/aghermann/

Loading...