Update: confirmed bug. I'll address it during next week. On Thu, Jul 30, 2015 at 12:26 PM, Daniel Gutson <daniel.gut...@tallertechnologies.com> wrote: > On Thu, Jul 30, 2015 at 11:31 AM, Daniel Gutson > <daniel.gut...@tallertechnologies.com> wrote: >> >> El 30/7/2015 11:27, "Joel Sherrill" <joel.sherr...@oarcorp.com> escribió: >>> >>> >>> >>> On 7/30/2015 9:08 AM, Daniel Gutson wrote: >>>> >>>> IOW, I think that the double parens is only for decltype. >>> >>> >>> Historical convention is to put parens around variable names >>> in macros. What type of impact does this have? >> >> If what I think is correct, then the impact os none since this a bug. But I >> will look at it deeper once I arrive to the office in 1h. I will try with >> different versions of gcc and clang and look into the C++ standard. So far >> the (()) seems to be a decltype only thing, so this would be a frontend bug. > > As I mentioned in the bugzilla, I think this is a bug of the front-end > (since I could not reproduce > it in earlier versions of g++ (4.8.4) and clang (3.5)). I already > asked Ville Voutilainen and Jens Maurer > (from the C++ Committee) to look into it. I will let you know. > > > Daniel. > > >> >>> >>>> El 30/7/2015 11:06, escribió: >>>> >>>> I don't it's a language issue: https://ideone.com/k1vz5d >>>> >>>> El 30/7/2015 10:51, "Gedare Bloom" <ged...@gwu.edu >>>> <mailto:ged...@gwu.edu>> escribió: >>>> >>>> OK, I guess this makes the convention "minimize parentheses" >>>> mandatory >>>> if we want C++11. I guess the basic problem is that constructions >>>> where a single atom is in parens may produce different results >>>> now. At >>>> least an error is emitted rather than silent optimization.. >>>> >>>> -Gedare >>>> >>>> On Thu, Jul 30, 2015 at 2:49 AM, Sebastian Huber >>>> <sebastian.hu...@embedded-brains.de >>>> <mailto:sebastian.hu...@embedded-brains.de>> wrote: >>>> > Hello, >>>> > >>>> > please have a look at the following bug: >>>> > >>>> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67064 >>>> > >>>> > This is really nice in combination with defines and macros >>>> that use ( ) to >>>> > make sure the content stays together. >>>> > >>>> > -- >>>> > Sebastian Huber, embedded brains GmbH >>>> > >>>> > Address : Dornierstr. 4, D-82178 Puchheim, Germany >>>> > Phone : +49 89 189 47 41-16 >>>> > Fax : +49 89 189 47 41-09 >>>> > E-Mail : sebastian.hu...@embedded-brains.de >>>> <mailto:sebastian.hu...@embedded-brains.de> >>>> >>>> > PGP : Public key available on request. >>>> > >>>> > Diese Nachricht ist keine geschäftliche Mitteilung im Sinne >>>> des EHUG. >>>> > >>>> > _______________________________________________ >>>> > devel mailing list >>>> > devel@rtems.org <mailto:devel@rtems.org> >>>> >>>> > http://lists.rtems.org/mailman/listinfo/devel >>>> _______________________________________________ >>>> devel mailing list >>>> devel@rtems.org <mailto:devel@rtems.org> >>>> http://lists.rtems.org/mailman/listinfo/devel >>>> >>> >>> -- >>> Joel Sherrill, Ph.D. Director of Research & Development >>> joel.sherr...@oarcorp.com On-Line Applications Research >>> Ask me about RTEMS: a free RTOS Huntsville AL 35805 >>> Support Available (256) 722-9985 > > > > -- > > Daniel F. Gutson > Chief Engineering Officer, SPD > > San Lorenzo 47, 3rd Floor, Office 5 > Córdoba, Argentina > > Phone: +54 351 4217888 / +54 351 4218211 > Skype: dgutson > LinkedIn: http://ar.linkedin.com/in/danielgutson
-- Daniel F. Gutson Chief Engineering Officer, SPD San Lorenzo 47, 3rd Floor, Office 5 Córdoba, Argentina Phone: +54 351 4217888 / +54 351 4218211 Skype: dgutson LinkedIn: http://ar.linkedin.com/in/danielgutson _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
