This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] c/68966 - atomic_fetch_* on atomic_bool not diagnosed


On Tue, Jan 05, 2016 at 11:46:52AM -0700, Martin Sebor wrote:
> I just downloaded and installed an Emacs equivalent called redspace.
> It does the same thing.  Unfortunately, it also has the effect of
> highlighting in red the one blank inserted by diff at the beginning
> of empty lines. I guess the way to deal with that is to avoid
> inserting blank spaces into changes to begin with rather than trying
> to remove them from the final patch.
 
Maybe some Emacs user can offer some advice (but we're slightly off topic here
;).

> I use the script on bigger patches.  I just haven't trained myself
> to use it consistently, for all of them, and each time I post a new
> revision of a patch for review.  (The script also complains about

I have a script called "P" that generates a patch, runs an ancient version of
mklog, adds "PR c/#" etc. and finally it runs check_GNU_style so that I won't
forget.

> tests where following the convention isn't always possible -- e.g.,
> lines over 80 characters are unavoidable due to dg-error directives,
> and periods can't be preceded by a space when they are part of
> regular expressions in dg- directives..)

Yes, you need to mentally filter out the output for tests.
 
> gcc/testsuite/ChangeLog:
> 2016-01-04  Martin Sebor  <msebor@redhat.com>
> 
> 	PR c/68966
> 	* gcc.dg/atomic-fetch-bool.c: New test.
> 	* gcc.dg/sync-fetch-bool.c: Same.

So the tradition is to repeat "New test." rather than to say "Same."

Otherwise ok, thanks.

	Marek


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]