> I really really don't see why anyone would think that those '...' bring
> any additional information. Since Rainer has changed this, I see zero
> point in changing it back.
Yet doing it revealed an oversight in the first patch...
> It wasn't overlooked, there was a bug that I've fixed already
On Sat, Oct 08, 2016 at 07:04:41PM +0200, Eric Botcazou wrote:
> > testing completed successfully, so I've installed the patch with this
> > ChangeLog entry:
> >
> > 2016-09-26 Rainer Orth
> >
> > gcc:
> > * config/i386/i386.c (ix86_print_operand)
> > [HAVE_AS_IX86_CMOV_SUN_SYNTAX]
> testing completed successfully, so I've installed the patch with this
> ChangeLog entry:
>
> 2016-09-26 Rainer Orth
>
> gcc:
> * config/i386/i386.c (ix86_print_operand)
> [HAVE_AS_IX86_CMOV_SUN_SYNTAX]: Add gcc_fallthrough.
> * config/sparc/sparc.c (check_pic): Add fa
> "Jakub" == Jakub Jelinek writes:
>> default:
>> {
>> complaint (&symfile_complaints,
>> _("Storage class %d not recognized during scan"),
>> sclass);
>> }
>> /* FALLTHROUGH */
>>
>> /* C_FCN is .bf and .ef symbols. I think it is sufficient
>> to handle only the C_FUN and C_EXT. */
>> cas
On 09/28/2016 02:15 PM, Michael Matz wrote:
P.S.: Initially I even wanted to argue that the mere existence of _any_
comment before a case label would disable the warning. I don't have the
numbers but I bet even that version would have found the very same bugs
that the picky version has.
Sounds
On Wed, Sep 28, 2016 at 09:29:01AM -0600, Tom Tromey wrote:
> > "Michael" == Michael Matz writes:
>
> Michael> Not accepting
> Michael> /* And here we intentionally fall through because ... */
> Michael> and forcing users to replace this by:
> Michael> /* fallthrough */
> Michael> is not
> "Michael" == Michael Matz writes:
Michael> Not accepting
Michael> /* And here we intentionally fall through because ... */
Michael> and forcing users to replace this by:
Michael> /* fallthrough */
Michael> is not robust either. It's actually actively lowering robustness of
code,
Mich
Hi,
On Tue, 27 Sep 2016, Tom Tromey wrote:
> The point of the warning is to make code more robust. But accepting any
> comment like "Don't fall through" is not more robust, but rather an
> error waiting to happen; as IIUC the user has no way to detect this
> case.
>
> I think it's better for
On Tue, Sep 27, 2016 at 01:31:15PM +0200, Jakub Jelinek wrote:
> On Tue, Sep 27, 2016 at 12:56:29PM +0200, Marek Polacek wrote:
> > On Tue, Sep 27, 2016 at 12:47:50PM +0200, Jakub Jelinek wrote:
> > > On Tue, Sep 27, 2016 at 12:39:41PM +0200, Markus Trippelsdorf wrote:
> > > > On 2016.09.27 at 10:4
> "Michael" == Michael Matz writes:
Michael> All those bugs would also have been found as well when it had simply
Michael> accepted
Michael> /fall.*thr/i
Michael> anywhere in the preceding comment on one line. But all the recent
Michael> spelling changes of comments to cater for the stri
Hi,
On Tue, 27 Sep 2016, Marek Polacek wrote:
> > Perhaps we want -Wimplicit-fallthrough{,=1,=2,=3,=4}, where =1 would
> > match indeed /fall.*thr/i (note, it will be really costly in this
> > case, one will have to parse all comments in detail in the
> > preprocessor, so I'd be against making
On Tue, Sep 27, 2016 at 05:19:10PM +0200, Bernd Schmidt wrote:
> On 09/27/2016 05:04 PM, Jakub Jelinek wrote:
> >>>On Tue, Sep 27, 2016 at 9:56 AM, Michael Matz wrote:
> All those bugs would also have been found as well when it had simply
> accepted
> /fall.*thr/i
> anywhere in t
On Tue, Sep 27, 2016 at 05:04:23PM +0200, Jakub Jelinek wrote:
> On Tue, Sep 27, 2016 at 04:54:28PM +0200, Marek Polacek wrote:
> > On Tue, Sep 27, 2016 at 10:48:50AM -0400, Jason Merrill wrote:
> > > On Tue, Sep 27, 2016 at 9:56 AM, Michael Matz wrote:
> > > > On Tue, 27 Sep 2016, Jakub Jelinek w
On 09/27/2016 05:04 PM, Jakub Jelinek wrote:
On Tue, Sep 27, 2016 at 9:56 AM, Michael Matz wrote:
All those bugs would also have been found as well when it had simply
accepted
/fall.*thr/i
anywhere in the preceding comment on one line. But all the recent
spelling changes of comments to cater
On Tue, Sep 27, 2016 at 04:54:28PM +0200, Marek Polacek wrote:
> On Tue, Sep 27, 2016 at 10:48:50AM -0400, Jason Merrill wrote:
> > On Tue, Sep 27, 2016 at 9:56 AM, Michael Matz wrote:
> > > On Tue, 27 Sep 2016, Jakub Jelinek wrote:
> > >
> > >> Just compare that to the number of real bugs the war
On Tue, Sep 27, 2016 at 10:48:50AM -0400, Jason Merrill wrote:
> On Tue, Sep 27, 2016 at 9:56 AM, Michael Matz wrote:
> > On Tue, 27 Sep 2016, Jakub Jelinek wrote:
> >
> >> Just compare that to the number of real bugs the warning found in gcc
> >> codebase. It is really worth it for -Wextra.
> >
On Tue, Sep 27, 2016 at 9:56 AM, Michael Matz wrote:
> On Tue, 27 Sep 2016, Jakub Jelinek wrote:
>
>> Just compare that to the number of real bugs the warning found in gcc
>> codebase. It is really worth it for -Wextra.
>
> All those bugs would also have been found as well when it had simply
> ac
On Tue, Sep 27, 2016 at 03:53:25PM +0200, Bernd Schmidt wrote:
> What's the ratio of comments "fixed" to actual bugs found? IMO this is not
> something we should inflict on users unasked.
One might argue that users actually *asked* for this by turning on -Wextra.
Marek
On 09/27/2016 03:49 PM, Jakub Jelinek wrote:
On Tue, Sep 27, 2016 at 03:48:07PM +0200, Bernd Schmidt wrote:
On 09/27/2016 02:01 PM, Marek Polacek wrote:
On Tue, Sep 27, 2016 at 01:55:22PM +0200, Bernd Schmidt wrote:
On 09/27/2016 01:51 PM, Marek Polacek wrote:
But the C/C++ keywords are all E
On Tue, Sep 27, 2016 at 03:53:25PM +0200, Bernd Schmidt wrote:
> On 09/27/2016 03:49 PM, Jakub Jelinek wrote:
> >On Tue, Sep 27, 2016 at 03:48:07PM +0200, Bernd Schmidt wrote:
> >>On 09/27/2016 02:01 PM, Marek Polacek wrote:
> >>>On Tue, Sep 27, 2016 at 01:55:22PM +0200, Bernd Schmidt wrote:
>
Hi,
On Tue, 27 Sep 2016, Jakub Jelinek wrote:
> Just compare that to the number of real bugs the warning found in gcc
> codebase. It is really worth it for -Wextra.
All those bugs would also have been found as well when it had simply
accepted
/fall.*thr/i
anywhere in the preceding comment o
On Tue, Sep 27, 2016 at 03:48:07PM +0200, Bernd Schmidt wrote:
> On 09/27/2016 02:01 PM, Marek Polacek wrote:
> >On Tue, Sep 27, 2016 at 01:55:22PM +0200, Bernd Schmidt wrote:
> >>On 09/27/2016 01:51 PM, Marek Polacek wrote:
> >>>But the C/C++ keywords are all English, too; lint tools only accept
On 09/27/2016 02:01 PM, Marek Polacek wrote:
On Tue, Sep 27, 2016 at 01:55:22PM +0200, Bernd Schmidt wrote:
On 09/27/2016 01:51 PM, Marek Polacek wrote:
But the C/C++ keywords are all English, too; lint tools only accept English,
and so it wouldn't seem unreasonable to only accept English keywo
On Tue, Sep 27, 2016 at 01:58:54PM +0200, Jakub Jelinek wrote:
> > Any comment with text
> >
> > ^[^_[:alnum:]]*(else )?fall(s | |-)?thr(ough|u)[^_[:alnum:]]*$
> >
> > perhaps? Case-insensitive. Or allow any amount of space, or even any
> > interpunction. Just don't allow any alphanumerics exc
On Tue, Sep 27, 2016 at 02:27:12PM +0200, Florian Weimer wrote:
> * Marek Polacek:
>
> > On Tue, Sep 27, 2016 at 01:46:08PM +0200, Markus Trippelsdorf wrote:
> >> I'm also wondering about the situation where not a single break is used
> >> in all of the cases. It would be best not to warn here.
>
On Tue, Sep 27, 2016 at 02:27:12PM +0200, Florian Weimer wrote:
> * Marek Polacek:
>
> > On Tue, Sep 27, 2016 at 01:46:08PM +0200, Markus Trippelsdorf wrote:
> >> I'm also wondering about the situation where not a single break is used
> >> in all of the cases. It would be best not to warn here.
>
* Marek Polacek:
> On Tue, Sep 27, 2016 at 01:46:08PM +0200, Markus Trippelsdorf wrote:
>> I'm also wondering about the situation where not a single break is used
>> in all of the cases. It would be best not to warn here.
>
> This is tricky and I'm afraid all I can offer here is to use the diagnos
On Tue, Sep 27, 2016 at 12:12:30PM +0100, Kyrill Tkachov wrote:
>
> On 27/09/16 11:41, Jakub Jelinek wrote:
> > On Tue, Sep 27, 2016 at 11:32:42AM +0100, Kyrill Tkachov wrote:
> > > where the code is:
> > > 2156 /* Fall through - if the lane index isn't a constant
> > > then
> > > 2
On Tue, Sep 27, 2016 at 01:46:08PM +0200, Markus Trippelsdorf wrote:
> I'm also wondering about the situation where not a single break is used
> in all of the cases. It would be best not to warn here.
This is tricky and I'm afraid all I can offer here is to use the diagnostics
pragma to suppress t
On Tue, Sep 27, 2016 at 01:55:22PM +0200, Bernd Schmidt wrote:
> On 09/27/2016 01:51 PM, Marek Polacek wrote:
> > But the C/C++ keywords are all English, too; lint tools only accept English,
> > and so it wouldn't seem unreasonable to only accept English keywords in the
> > comments. And in any ca
On Tue, Sep 27, 2016 at 06:51:31AM -0500, Segher Boessenkool wrote:
> On Tue, Sep 27, 2016 at 01:31:15PM +0200, Jakub Jelinek wrote:
> > I think it is important to think in terms of what regexps we still want to
> > match, even when the matching is actually implemented in C, not using
> > regexps.
On 09/27/2016 01:51 PM, Marek Polacek wrote:
But the C/C++ keywords are all English, too; lint tools only accept English,
and so it wouldn't seem unreasonable to only accept English keywords in the
comments. And in any case, I don't see how a compiler can be expected to
be able to parse non-Engl
On Tue, Sep 27, 2016 at 01:47:07PM +0200, Bernd Schmidt wrote:
> On 09/27/2016 01:09 PM, Richard Biener wrote:
> > On Tue, Sep 27, 2016 at 1:06 PM, Eric Botcazou
> > wrote:
> > > > The accepted style is already very permissive, we don't allow just one
> > > > spelling as various lint tools.
> > >
On Tue, Sep 27, 2016 at 01:31:15PM +0200, Jakub Jelinek wrote:
> I think it is important to think in terms of what regexps we still want to
> match, even when the matching is actually implemented in C, not using
> regexps. And yes, you list one reason why arbitrary text with fall and
> through som
On 09/27/2016 01:09 PM, Richard Biener wrote:
On Tue, Sep 27, 2016 at 1:06 PM, Eric Botcazou wrote:
The accepted style is already very permissive, we don't allow just one
spelling as various lint tools.
Well, it cannot even handle the variations of a single codebase, GCC itself,
so I'm afraid
On 2016.09.27 at 12:56 +0200, Marek Polacek wrote:
> On Tue, Sep 27, 2016 at 12:47:50PM +0200, Jakub Jelinek wrote:
> > On Tue, Sep 27, 2016 at 12:39:41PM +0200, Markus Trippelsdorf wrote:
> > > On 2016.09.27 at 10:46 +0200, Eric Botcazou wrote:
> > > > > The intent has been that we catch the most
On Tue, Sep 27, 2016 at 12:56:29PM +0200, Marek Polacek wrote:
> On Tue, Sep 27, 2016 at 12:47:50PM +0200, Jakub Jelinek wrote:
> > On Tue, Sep 27, 2016 at 12:39:41PM +0200, Markus Trippelsdorf wrote:
> > > On 2016.09.27 at 10:46 +0200, Eric Botcazou wrote:
> > > > > The intent has been that we cat
On 27/09/16 11:41, Jakub Jelinek wrote:
On Tue, Sep 27, 2016 at 11:32:42AM +0100, Kyrill Tkachov wrote:
where the code is:
2156 /* Fall through - if the lane index isn't a constant then
2157 the next case will error. */
2158
2159 case NEON_ARG_CONSTAN
On Tue, Sep 27, 2016 at 1:06 PM, Eric Botcazou wrote:
>> The accepted style is already very permissive, we don't allow just one
>> spelling as various lint tools.
>
> Well, it cannot even handle the variations of a single codebase, GCC itself,
> so I'm afraid very permissive is not exactly the app
> The accepted style is already very permissive, we don't allow just one
> spelling as various lint tools.
Well, it cannot even handle the variations of a single codebase, GCC itself,
so I'm afraid very permissive is not exactly the appropriate wording here.
Anyway, we'll see whether Bugzilla is
On Tue, Sep 27, 2016 at 12:47:50PM +0200, Jakub Jelinek wrote:
> On Tue, Sep 27, 2016 at 12:39:41PM +0200, Markus Trippelsdorf wrote:
> > On 2016.09.27 at 10:46 +0200, Eric Botcazou wrote:
> > > > The intent has been that we catch the most common forms, but still
> > > > require
> > > > it not to
On Tue, Sep 27, 2016 at 12:47:50PM +0200, Jakub Jelinek wrote:
> On Tue, Sep 27, 2016 at 12:39:41PM +0200, Markus Trippelsdorf wrote:
> > On 2016.09.27 at 10:46 +0200, Eric Botcazou wrote:
> > > > The intent has been that we catch the most common forms, but still
> > > > require
> > > > it not to
On Tue, Sep 27, 2016 at 12:39:41PM +0200, Markus Trippelsdorf wrote:
> On 2016.09.27 at 10:46 +0200, Eric Botcazou wrote:
> > > The intent has been that we catch the most common forms, but still require
> > > it not to be complete free form. Because, as experience shows, people are
> > > extremely
On Tue, Sep 27, 2016 at 11:32:42AM +0100, Kyrill Tkachov wrote:
> where the code is:
> 2156 /* Fall through - if the lane index isn't a constant then
> 2157 the next case will error. */
> 2158
> 2159 case NEON_ARG_CONSTANT:
>
>
> Is there supposed to be
On 2016.09.27 at 10:46 +0200, Eric Botcazou wrote:
> > The intent has been that we catch the most common forms, but still require
> > it not to be complete free form. Because, as experience shows, people are
> > extremely creative in these comments, and it is not very good idea to
> > support ever
Hi Marek,
On 27/09/16 10:44, Marek Polacek wrote:
On Tue, Sep 27, 2016 at 10:03:10AM +0200, Andreas Schwab wrote:
This breaks building with gcc-4.3.
g++ -std=gnu++98 -fno-PIE -c -DUSE_LIBUNWIND_EXCEPTIONS -g -DIN_GCC
-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wwrit
On Tue, Sep 27, 2016 at 10:03:10AM +0200, Andreas Schwab wrote:
> This breaks building with gcc-4.3.
>
> g++ -std=gnu++98 -fno-PIE -c -DUSE_LIBUNWIND_EXCEPTIONS -g -DIN_GCC
> -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall
> -Wwrite-strings -Wcast-qual -Wno-format -Wmissing
On Tue, Sep 27, 2016 at 09:50:17AM +0200, Gerald Pfeifer wrote:
> Hi Marek,
>
> On Sat, 24 Sep 2016, Marek Polacek wrote:
> > All right. I'll commit the patch on Monday.
>
> my thrice a week bootstrap on old (but still "supported")
> i?86-unknown-freebsd9 broke as follows:
>
> cc1plus: error
> The intent has been that we catch the most common forms, but still require
> it not to be complete free form. Because, as experience shows, people are
> extremely creative in these comments, and it is not very good idea to
> support everything. For ... fall through ... , what is the purpose of
On Tue, Sep 27, 2016 at 10:13 AM, Jakub Jelinek wrote:
> On Tue, Sep 27, 2016 at 10:03:10AM +0200, Andreas Schwab wrote:
>> This breaks building with gcc-4.3.
>>
>> g++ -std=gnu++98 -fno-PIE -c -DUSE_LIBUNWIND_EXCEPTIONS -g -DIN_GCC
>> -fno-exceptions -fno-rtti -fasynchronous-unwind-tables
On Tue, Sep 27, 2016 at 08:49:00AM +0200, Eric Botcazou wrote:
> > It seems unfortunate that the warning doesn't accept /* ... fall
> > through ... */ as a fallthrough comment.
>
> Seconded. The warning should take into account existing practices instead of
> forcing the user to make completely
On Tue, Sep 27, 2016 at 10:03:10AM +0200, Andreas Schwab wrote:
> This breaks building with gcc-4.3.
>
> g++ -std=gnu++98 -fno-PIE -c -DUSE_LIBUNWIND_EXCEPTIONS -g -DIN_GCC
> -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall
> -Wwrite-strings -Wcast-qual -Wno-format -Wmissing
This breaks building with gcc-4.3.
g++ -std=gnu++98 -fno-PIE -c -DUSE_LIBUNWIND_EXCEPTIONS -g -DIN_GCC
-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wwrite-strings
-Wcast-qual -Wno-format -Wmissing-format-attribute -Woverloaded-virtual
-pedantic -Wno-long-long -Wno-vari
> Seconded. The warning should take into account existing practices instead
> of forcing the user to make completely bogus changes to the code (and Ada
> should have been tested before the patch was approved).
I have a bootstrap failure on x86-64/Linux:
/home/eric/svn/gcc/gcc/combine.c: In funct
Hi Marek,
On Sat, 24 Sep 2016, Marek Polacek wrote:
> All right. I'll commit the patch on Monday.
my thrice a week bootstrap on old (but still "supported")
i?86-unknown-freebsd9 broke as follows:
cc1plus: error: unrecognized command line option "-Wno-implicit-fallthrough"
gmake[3]: *** [Ma
> It seems unfortunate that the warning doesn't accept /* ... fall
> through ... */ as a fallthrough comment.
Seconded. The warning should take into account existing practices instead of
forcing the user to make completely bogus changes to the code (and Ada should
have been tested before the pa
Hi Marek,
> On Mon, Sep 26, 2016 at 03:34:40PM +0200, Rainer Orth wrote:
>> Hi Marek,
>>
>> > All right. I'll commit the patch on Monday.
>>
>> this patch caused quite some breakage: Ada, Solaris/x86 and SPARC don't
>> bootstrap any longer.
>
> Sorry about that. I had tested Ada + x86_64/pp
Hi Jakub,
> On Mon, Sep 26, 2016 at 03:34:40PM +0200, Rainer Orth wrote:
>> Ok for mainline if the bootstraps pass (with appropriate changelog
>> entries, of course)?
>
> Yes.
testing completed successfully, so I've installed the patch with this
ChangeLog entry:
2016-09-26 Rainer Orth
It seems unfortunate that the warning doesn't accept /* ... fall
through ... */ as a fallthrough comment.
Jason
> this patch caused quite some breakage: Ada, Solaris/x86 and SPARC don't
> bootstrap any longer.
>
> The following patch allows i386-pc-solaris2.12 and
> sparc-sun-solaris2.12
> bootstraps continue.
>
> Strangely, I needed to use gcc_fallthrough () in i386.c; a mere /* FALLTHRU
> */
> had no ef
On Mon, Sep 26, 2016 at 03:34:40PM +0200, Rainer Orth wrote:
> Hi Marek,
>
> > All right. I'll commit the patch on Monday.
>
> this patch caused quite some breakage: Ada, Solaris/x86 and SPARC don't
> bootstrap any longer.
Sorry about that. I had tested Ada + x86_64/ppc64/aarch64, but couldn
On Mon, Sep 26, 2016 at 03:34:40PM +0200, Rainer Orth wrote:
> Ok for mainline if the bootstraps pass (with appropriate changelog
> entries, of course)?
Yes.
> diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
> --- a/gcc/config/i386/i386.c
> +++ b/gcc/config/i386/i386.c
> @@ -17917,6
Hi Marek,
> All right. I'll commit the patch on Monday.
this patch caused quite some breakage: Ada, Solaris/x86 and SPARC don't
bootstrap any longer.
The following patch allows i386-pc-solaris2.12 and sparc-sun-solaris2.12
bootstraps continue.
Strangely, I needed to use gcc_fallthrough () in
On Fri, Sep 23, 2016 at 10:12:00PM +, Joseph Myers wrote:
> On Fri, 23 Sep 2016, Marek Polacek wrote:
>
> > On Fri, Sep 23, 2016 at 10:22:15AM -0400, Jason Merrill wrote:
> > > On Thu, Sep 22, 2016 at 9:59 AM, Marek Polacek wrote:
> > > >> This is very close, thanks. Let's give a more helpfu
On Fri, 23 Sep 2016, Marek Polacek wrote:
> On Fri, Sep 23, 2016 at 10:22:15AM -0400, Jason Merrill wrote:
> > On Thu, Sep 22, 2016 at 9:59 AM, Marek Polacek wrote:
> > >> This is very close, thanks. Let's give a more helpful warning about
> > >>
> > >> [[fallthrough]] 0;
> > >> __attribute__ ((
On Fri, Sep 23, 2016 at 04:23:29PM +0200, Jakub Jelinek wrote:
> On Fri, Sep 23, 2016 at 10:22:15AM -0400, Jason Merrill wrote:
> > On Thu, Sep 22, 2016 at 9:59 AM, Marek Polacek wrote:
> > >> This is very close, thanks. Let's give a more helpful warning about
> > >>
> > >> [[fallthrough]] 0;
> >
On Fri, Sep 23, 2016 at 10:22:15AM -0400, Jason Merrill wrote:
> On Thu, Sep 22, 2016 at 9:59 AM, Marek Polacek wrote:
> >> This is very close, thanks. Let's give a more helpful warning about
> >>
> >> [[fallthrough]] 0;
> >> __attribute__ ((fallthrough)) 0;
> >>
> >> both here and in cp_parser_s
On Fri, Sep 23, 2016 at 10:22:15AM -0400, Jason Merrill wrote:
> On Thu, Sep 22, 2016 at 9:59 AM, Marek Polacek wrote:
> >> This is very close, thanks. Let's give a more helpful warning about
> >>
> >> [[fallthrough]] 0;
> >> __attribute__ ((fallthrough)) 0;
> >>
> >> both here and in cp_parser_s
On Thu, Sep 22, 2016 at 9:59 AM, Marek Polacek wrote:
>> This is very close, thanks. Let's give a more helpful warning about
>>
>> [[fallthrough]] 0;
>> __attribute__ ((fallthrough)) 0;
>>
>> both here and in cp_parser_statement, something like "fallthrough attribute
>> not followed by ';'"
>
> D
It occurred to me that I should also handle the
__has_cpp_attribute(fallthrough) part. But I hope that can be done after the
main -Wimplicit-fallthrough is committed.
Marek
On Wed, Sep 21, 2016 at 03:14:07PM -0400, Jason Merrill wrote:
> On 09/21/2016 02:59 PM, Marek Polacek wrote:
> > + if (statement == NULL_TREE
> > + && attr != NULL_TREE
> > + && maybe_attribute_fallthrough_p (attr))
> > +{
> > + /* Turn [[fallthrough]]; into FALLTHROUGH ();. *
On 09/21/2016 02:59 PM, Marek Polacek wrote:
+ if (statement == NULL_TREE
+ && attr != NULL_TREE
+ && maybe_attribute_fallthrough_p (attr))
+{
+ /* Turn [[fallthrough]]; into FALLTHROUGH ();. */
+ statement = build_call_expr_internal_loc (loc, IFN_FALLTHROUGH,
+
On Wed, Sep 21, 2016 at 10:06:07AM -0400, Jason Merrill wrote:
> On 09/21/2016 08:44 AM, Marek Polacek wrote:
> > @@ -10733,12 +10758,35 @@ cp_parser_expression_statement (cp_parser*
> > parser, tree in_statement_expr)
> > statement. */
> >if (cp_lexer_next_token_is_not (parser->lexer,
On 09/21/2016 08:44 AM, Marek Polacek wrote:
@@ -10733,12 +10758,35 @@ cp_parser_expression_statement (cp_parser* parser,
tree in_statement_expr)
statement. */
if (cp_lexer_next_token_is_not (parser->lexer, CPP_SEMICOLON))
{
+ /* This might be attribute fallthrough. */
+
On Tue, Sep 20, 2016 at 12:26:11PM -0400, Jason Merrill wrote:
> On 09/20/2016 11:33 AM, Marek Polacek wrote:
> > @@ -5135,6 +5135,30 @@ cp_parser_primary_expression (cp_parser *parser,
> > case RID_AT_SELECTOR:
> > return cp_parser_objc_expression (parser);
> >
> > + case RID_ATTRIBUT
On 09/20/2016 11:33 AM, Marek Polacek wrote:
@@ -5135,6 +5135,30 @@ cp_parser_primary_expression (cp_parser *parser,
case RID_AT_SELECTOR:
return cp_parser_objc_expression (parser);
+ case RID_ATTRIBUTE:
Attribute handling doesn't belong in this function; we don't want
76 matches
Mail list logo
