[PATCH 0/3] Introduce internal_error_cont and exclude it from pot files

[PATCH 0/3] Introduce internal_error_cont and exclude it from pot files

[Martin Liška]

Hello.

Following small series exclude some strings from pot files via
introduction of internal_error_cont function.

Patch can bootstrap and survives regression tests.

(Sorry for broken threading because my cover letter was rejected).

Martin

marxin (3):
   Introduce internal_error_cont function and use it in cfgrtl.c (PR
     rtl-optimization/79856).
   Replace error with internal_error_cont in cgraph.c (PR ipa/79857).
   Regenerate gcc.pot.

  gcc/cfgrtl.c          |   349 +-
  gcc/cgraph.c          |   139 +-
  gcc/diagnostic-core.h |     1 +
  gcc/diagnostic.c      |    16 +
  gcc/diagnostic.def    |     1 +
  gcc/po/exgettext      |     6 +-
  gcc/po/gcc.pot        | 14892 ++++++++++++++++++++++++------------------------
  7 files changed, 7589 insertions(+), 7815 deletions(-)

Re: [PATCH 0/3] Introduce internal_error_cont and exclude it from pot files

[David Malcolm]

On Wed, 2017-03-15 at 14:53 +0100, Martin Liška wrote:
> Hello.
> 
> Following small series exclude some strings from pot files via
> introduction of internal_error_cont function.
> 
> Patch can bootstrap and survives regression tests.
> 
> (Sorry for broken threading because my cover letter was rejected).
> 
> Martin
> 
> marxin (3):
>    Introduce internal_error_cont function and use it in cfgrtl.c (PR
>      rtl-optimization/79856).
>    Replace error with internal_error_cont in cgraph.c (PR ipa/79857).
>    Regenerate gcc.pot.
> 
>   gcc/cfgrtl.c          |   349 +-
>   gcc/cgraph.c          |   139 +-
>   gcc/diagnostic-core.h |     1 +
>   gcc/diagnostic.c      |    16 +
>   gcc/diagnostic.def    |     1 +
>   gcc/po/exgettext      |     6 +-
>   gcc/po/gcc.pot        | 14892 ++++++++++++++++++++++++-------------
> -----------
>   7 files changed, 7589 insertions(+), 7815 deletions(-)

[For some reason I only received the 0/3 and 3/3 mail, not 1/3 and 2/3]

In patch 1:

2017-03-13  Martin Liska  <mliska@suse.cz>

	PR rtl-optimization/79856
	* cfgrtl.c (try_redirect_by_replacing_jump): Fix GNU coding
	style.
	(fixup_partition_crossing): Likewise.
	(fixup_new_cold_bb): Likewise.
	(emit_barrier_after_bb): Likewise.
	(force_nonfallthru_and_redirect): Likewise.
	(last_bb_in_partition): Likewise.
	(rtl_split_edge): Likewise.
	(commit_one_edge_insertion): Likewise.
	(print_rtl_with_bb): Likewise.
	(find_partition_fixes): Use internal_error_cont instead of
	error.
	(verify_hot_cold_block_grouping): Likewise.
	(rtl_verify_edges): Likewise.
	(rtl_verify_bb_insns): Likewise.
	(rtl_verify_bb_pointers): Likewise.
	(rtl_verify_bb_insn_chain): Likewise.
	(rtl_verify_fallthru): Likewise.
	(purge_dead_edges): Fix GNU coding style.
	(fixup_abnormal_edges): Likewise.
	(fixup_reorder_chain): Likewise.
	(duplicate_insn_chain): Likewise.
	* diagnostic-core.h (internal_error_cont): Declare new
function.
	* diagnostic.c (diagnostic_action_after_output): Handle
	newly added DK_INTERNAL_ERROR.
	(internal_error_cont): New function.
	* diagnostic.def (DK_INTERNAL_ERROR): New enum value.

...the cfgrtl.c changes are a mixture of hunks that are (mostly)
whitespace fixes, combined with hunks that move over to using
internal_error_cont.

Please can you split this patch up to move the cfgrtl.c coding style
fixes into a separate patch, since this obscures the diagnostic
changes?

Also, as Joseph notes, if a function accepts a string param that isn't
to be translated, don't use "gmsgid" or "msgid" as the param name (just
call it "msg" or somesuch).

Thanks
Dave

Re: [PATCH 0/3] Introduce internal_error_cont and exclude it from pot files

[Martin Liška]

[-- Attachment #1: Type: text/plain, Size: 2975 bytes --]

On 03/15/2017 07:33 PM, David Malcolm wrote:
> On Wed, 2017-03-15 at 14:53 +0100, Martin Liška wrote:
>> Hello.
>>
>> Following small series exclude some strings from pot files via
>> introduction of internal_error_cont function.
>>
>> Patch can bootstrap and survives regression tests.
>>
>> (Sorry for broken threading because my cover letter was rejected).
>>
>> Martin
>>
>> marxin (3):
>>    Introduce internal_error_cont function and use it in cfgrtl.c (PR
>>      rtl-optimization/79856).
>>    Replace error with internal_error_cont in cgraph.c (PR ipa/79857).
>>    Regenerate gcc.pot.
>>
>>   gcc/cfgrtl.c          |   349 +-
>>   gcc/cgraph.c          |   139 +-
>>   gcc/diagnostic-core.h |     1 +
>>   gcc/diagnostic.c      |    16 +
>>   gcc/diagnostic.def    |     1 +
>>   gcc/po/exgettext      |     6 +-
>>   gcc/po/gcc.pot        | 14892 ++++++++++++++++++++++++-------------
>> -----------
>>   7 files changed, 7589 insertions(+), 7815 deletions(-)
> 
> [For some reason I only received the 0/3 and 3/3 mail, not 1/3 and 2/3]

Hello.

Thanks for notifying me, I'm going to rebase it to just a single patch.

> 
> In patch 1:
> 
> 2017-03-13  Martin Liska  <mliska@suse.cz>
> 
> 	PR rtl-optimization/79856
> 	* cfgrtl.c (try_redirect_by_replacing_jump): Fix GNU coding
> 	style.
> 	(fixup_partition_crossing): Likewise.
> 	(fixup_new_cold_bb): Likewise.
> 	(emit_barrier_after_bb): Likewise.
> 	(force_nonfallthru_and_redirect): Likewise.
> 	(last_bb_in_partition): Likewise.
> 	(rtl_split_edge): Likewise.
> 	(commit_one_edge_insertion): Likewise.
> 	(print_rtl_with_bb): Likewise.
> 	(find_partition_fixes): Use internal_error_cont instead of
> 	error.
> 	(verify_hot_cold_block_grouping): Likewise.
> 	(rtl_verify_edges): Likewise.
> 	(rtl_verify_bb_insns): Likewise.
> 	(rtl_verify_bb_pointers): Likewise.
> 	(rtl_verify_bb_insn_chain): Likewise.
> 	(rtl_verify_fallthru): Likewise.
> 	(purge_dead_edges): Fix GNU coding style.
> 	(fixup_abnormal_edges): Likewise.
> 	(fixup_reorder_chain): Likewise.
> 	(duplicate_insn_chain): Likewise.
> 	* diagnostic-core.h (internal_error_cont): Declare new
> function.
> 	* diagnostic.c (diagnostic_action_after_output): Handle
> 	newly added DK_INTERNAL_ERROR.
> 	(internal_error_cont): New function.
> 	* diagnostic.def (DK_INTERNAL_ERROR): New enum value.
> 
> ...the cfgrtl.c changes are a mixture of hunks that are (mostly)
> whitespace fixes, combined with hunks that move over to using
> internal_error_cont.
> 
> Please can you split this patch up to move the cfgrtl.c coding style
> fixes into a separate patch, since this obscures the diagnostic
> changes?

Agree, I'll leave formatting stuff to next stage1.

> 
> Also, as Joseph notes, if a function accepts a string param that isn't
> to be translated, don't use "gmsgid" or "msgid" as the param name (just
> call it "msg" or somesuch).

I see, please look at second version of patch I've been currently testing.

Martin

> 
> Thanks
> Dave
> 


[-- Attachment #2: 0001-Introduce-internal_error_cont-function-and-use-it.patch.bz2 --]
[-- Type: application/x-bzip, Size: 127110 bytes --]

Re: [PATCH 0/3] Introduce internal_error_cont and exclude it from pot files

[Martin Liška]

I would like to ping that. I'm not sure what's agreement after I read
discussion in: https://gcc.gnu.org/ml/gcc/2017-03/msg00070.html

Martin Sebor may know, CC'ing him.

Thanks,
Martin

Re: [PATCH 0/3] Introduce internal_error_cont and exclude it from pot files

[Martin Sebor]

On 03/24/2017 03:29 AM, Martin Liška wrote:
> I would like to ping that. I'm not sure what's agreement after I read
> discussion in: https://gcc.gnu.org/ml/gcc/2017-03/msg00070.html
>
> Martin Sebor may know, CC'ing him.

I haven't seen any followup posts after the one above.  The other
(and I think more important point, one with a bearing on the whole
patch series) to consider is the one made by translator Frederic
Marchal in comment #2 in bug 80055.

Martin

Re: [PATCH 0/3] Introduce internal_error_cont and exclude it from pot files

[Jeff Law]

On 03/24/2017 09:37 AM, Martin Sebor wrote:
> On 03/24/2017 03:29 AM, Martin Liška wrote:
>> I would like to ping that. I'm not sure what's agreement after I read
>> discussion in: https://gcc.gnu.org/ml/gcc/2017-03/msg00070.html
>>
>> Martin Sebor may know, CC'ing him.
>
> I haven't seen any followup posts after the one above.  The other
> (and I think more important point, one with a bearing on the whole
> patch series) to consider is the one made by translator Frederic
> Marchal in comment #2 in bug 80055.
It's on the list of things to evaluate.  The non-gcc stuff on my plate 
is just about wrapped up, at which point I can give more attention to 
gcc stuff.


Jeff

Re: [PATCH 0/3] Introduce internal_error_cont and exclude it from pot files

[Jeff Law]

On 03/24/2017 03:29 AM, Martin Liška wrote:
> I would like to ping that. I'm not sure what's agreement after I read
> discussion in: https://gcc.gnu.org/ml/gcc/2017-03/msg00070.html
>
> Martin Sebor may know, CC'ing him.
Not sure if you're pinging the internal_error_cont stuff, or the ODR 
diagnostics changes.

WRT the ODR diagnostics, I'd say let's go with the C++17 style 
(all-lowercase with a hyphen).

If you've got a pointer to the internal_err_cont changes, please pass it 
along.

jeff

[wwwdocs, PATCH v2] C++ terminology: the One Definition Rule in diagnostics

[David Malcolm]

[-- Attachment #1: Type: text/plain, Size: 929 bytes --]

On Thu, 2017-04-06 at 10:44 -0600, Jeff Law wrote:
> On 03/24/2017 03:29 AM, Martin Liška wrote:
> > I would like to ping that. I'm not sure what's agreement after I
> > read
> > discussion in: https://gcc.gnu.org/ml/gcc/2017-03/msg00070.html
> > 
> > Martin Sebor may know, CC'ing him.
> Not sure if you're pinging the internal_error_cont stuff, or the ODR 
> diagnostics changes.
> 
> WRT the ODR diagnostics, I'd say let's go with the C++17 style 
> (all-lowercase with a hyphen).

Here's an updated version of the patch for the coding conventions page
of the website, which makes that recommendation (with a leading "the").

For easy of review, the pertinent table headings are:

    <th>Use...</th><th>...instead of</th><th>Rationale</th>

OK to commit?

(I've got a followup patch to update the diagnostics accordingly)

> If you've got a pointer to the internal_err_cont changes, please pass
> it 
> along.
> 
> jeff
> 

[-- Attachment #2: odr.patch --]
[-- Type: text/x-patch, Size: 752 bytes --]

Index: htdocs/codingconventions.html
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/codingconventions.html,v
retrieving revision 1.80
diff -u -p -r1.80 codingconventions.html
--- htdocs/codingconventions.html	13 Mar 2017 22:01:05 -0000	1.80
+++ htdocs/codingconventions.html	6 Apr 2017 20:55:51 -0000
@@ -448,6 +448,12 @@ and code.  The following table lists som
     <td>"Objective C"</td>
   </tr>
   <tr>
+    <td>"the one-definition rule"</td>
+    <td>"One Definition Rule", "the C++ One Definition Rule",
+      or "one definition rule"</td>
+    <td>Style used in the C++17 standard</td>
+  </tr>
+  <tr>
     <td>"prologue"</td>
     <td>"prolog"</td>
     <td>Established convention</td>

Re: [PATCH 0/3] Introduce internal_error_cont and exclude it from pot files

[Martin Liška]

On 04/06/2017 06:44 PM, Jeff Law wrote:
> On 03/24/2017 03:29 AM, Martin Liška wrote:
>> I would like to ping that. I'm not sure what's agreement after I read
>> discussion in: https://gcc.gnu.org/ml/gcc/2017-03/msg00070.html
>>
>> Martin Sebor may know, CC'ing him.
> Not sure if you're pinging the internal_error_cont stuff, or the ODR diagnostics changes.
> 
> WRT the ODR diagnostics, I'd say let's go with the C++17 style (all-lowercase with a hyphen).
> 
> If you've got a pointer to the internal_err_cont changes, please pass it along.

Yep, I was interested in internal_err_cont. It's next stage1 material, but I'm willing to have
a feedback whether separation of internal messages is desired to be excluded from translation or not?

Martin

> 
> jeff
> 

Re: [wwwdocs, PATCH v2] C++ terminology: the One Definition Rule in diagnostics

[Gerald Pfeifer]

On Thu, 6 Apr 2017, David Malcolm wrote:
> OK to commit?

If that's what the standard uses, yes, thanks.  (We still may
want to add "C++" in there, unless you feel the context is always
clear enough anyway, which I could well see...)

Gerald

Re: [PATCH 0/3] Introduce internal_error_cont and exclude it from pot files

[Jeff Law]

On 04/07/2017 04:30 AM, Martin Liška wrote:
> On 04/06/2017 06:44 PM, Jeff Law wrote:
>> On 03/24/2017 03:29 AM, Martin Liška wrote:
>>> I would like to ping that. I'm not sure what's agreement after I read
>>> discussion in: https://gcc.gnu.org/ml/gcc/2017-03/msg00070.html
>>>
>>> Martin Sebor may know, CC'ing him.
>> Not sure if you're pinging the internal_error_cont stuff, or the ODR diagnostics changes.
>>
>> WRT the ODR diagnostics, I'd say let's go with the C++17 style (all-lowercase with a hyphen).
>>
>> If you've got a pointer to the internal_err_cont changes, please pass it along.
>
> Yep, I was interested in internal_err_cont. It's next stage1 material, but I'm willing to have
> a feedback whether separation of internal messages is desired to be excluded from translation or not?
As stage1 stuff, I'll largely be ignoring.

I'm torn on translating this stuff.  It's hard enough for a 
non-developer to interpret an ICE message, if it's not in their native 
language it'd be impossible.

OTOH, if we translate and the user forwards the translated message to 
us, we may not be able to interpret.

That probably argues there's some part that should be translated to be 
easier for the users, but the real guts of the message should not be 
translated.

jeff

Re: [PATCH 0/3] Introduce internal_error_cont and exclude it from pot files

[Richard Biener]

On Mon, Apr 10, 2017 at 5:42 PM, Jeff Law <law@redhat.com> wrote:
> On 04/07/2017 04:30 AM, Martin Liška wrote:
>>
>> On 04/06/2017 06:44 PM, Jeff Law wrote:
>>>
>>> On 03/24/2017 03:29 AM, Martin Liška wrote:
>>>>
>>>> I would like to ping that. I'm not sure what's agreement after I read
>>>> discussion in: https://gcc.gnu.org/ml/gcc/2017-03/msg00070.html
>>>>
>>>> Martin Sebor may know, CC'ing him.
>>>
>>> Not sure if you're pinging the internal_error_cont stuff, or the ODR
>>> diagnostics changes.
>>>
>>> WRT the ODR diagnostics, I'd say let's go with the C++17 style
>>> (all-lowercase with a hyphen).
>>>
>>> If you've got a pointer to the internal_err_cont changes, please pass it
>>> along.
>>
>>
>> Yep, I was interested in internal_err_cont. It's next stage1 material, but
>> I'm willing to have
>> a feedback whether separation of internal messages is desired to be
>> excluded from translation or not?
>
> As stage1 stuff, I'll largely be ignoring.
>
> I'm torn on translating this stuff.  It's hard enough for a non-developer to
> interpret an ICE message, if it's not in their native language it'd be
> impossible.
>
> OTOH, if we translate and the user forwards the translated message to us, we
> may not be able to interpret.
>
> That probably argues there's some part that should be translated to be
> easier for the users, but the real guts of the message should not be
> translated.

Message number and catalogue.

/me runs...

> jeff

Re: [PATCH 0/3] Introduce internal_error_cont and exclude it from pot files

[Martin Liška]

On 04/10/2017 05:44 PM, Richard Biener wrote:
> On Mon, Apr 10, 2017 at 5:42 PM, Jeff Law <law@redhat.com> wrote:
>> On 04/07/2017 04:30 AM, Martin Liška wrote:
>>>
>>> On 04/06/2017 06:44 PM, Jeff Law wrote:
>>>>
>>>> On 03/24/2017 03:29 AM, Martin Liška wrote:
>>>>>
>>>>> I would like to ping that. I'm not sure what's agreement after I read
>>>>> discussion in: https://gcc.gnu.org/ml/gcc/2017-03/msg00070.html
>>>>>
>>>>> Martin Sebor may know, CC'ing him.
>>>>
>>>> Not sure if you're pinging the internal_error_cont stuff, or the ODR
>>>> diagnostics changes.
>>>>
>>>> WRT the ODR diagnostics, I'd say let's go with the C++17 style
>>>> (all-lowercase with a hyphen).
>>>>
>>>> If you've got a pointer to the internal_err_cont changes, please pass it
>>>> along.
>>>
>>>
>>> Yep, I was interested in internal_err_cont. It's next stage1 material, but
>>> I'm willing to have
>>> a feedback whether separation of internal messages is desired to be
>>> excluded from translation or not?
>>
>> As stage1 stuff, I'll largely be ignoring.
>>
>> I'm torn on translating this stuff.  It's hard enough for a non-developer to
>> interpret an ICE message, if it's not in their native language it'd be
>> impossible.
>>
>> OTOH, if we translate and the user forwards the translated message to us, we
>> may not be able to interpret.
>>
>> That probably argues there's some part that should be translated to be
>> easier for the users, but the real guts of the message should not be
>> translated.
> 
> Message number and catalogue.
> 
> /me runs...
> 
>> jeff

I there any discussion going on this topic? If not, I'll probably leave it as it is.

Thanks,
Martin

Re: [PATCH 0/3] Introduce internal_error_cont and exclude it from pot files

[Jeff Law]

On 06/30/2017 04:31 AM, Martin Liška wrote:
> On 04/10/2017 05:44 PM, Richard Biener wrote:
>> On Mon, Apr 10, 2017 at 5:42 PM, Jeff Law <law@redhat.com> wrote:
>>> On 04/07/2017 04:30 AM, Martin Liška wrote:
>>>>
>>>> On 04/06/2017 06:44 PM, Jeff Law wrote:
>>>>>
>>>>> On 03/24/2017 03:29 AM, Martin Liška wrote:
>>>>>>
>>>>>> I would like to ping that. I'm not sure what's agreement after I read
>>>>>> discussion in: https://gcc.gnu.org/ml/gcc/2017-03/msg00070.html
>>>>>>
>>>>>> Martin Sebor may know, CC'ing him.
>>>>>
>>>>> Not sure if you're pinging the internal_error_cont stuff, or the ODR
>>>>> diagnostics changes.
>>>>>
>>>>> WRT the ODR diagnostics, I'd say let's go with the C++17 style
>>>>> (all-lowercase with a hyphen).
>>>>>
>>>>> If you've got a pointer to the internal_err_cont changes, please pass it
>>>>> along.
>>>>
>>>>
>>>> Yep, I was interested in internal_err_cont. It's next stage1 material, but
>>>> I'm willing to have
>>>> a feedback whether separation of internal messages is desired to be
>>>> excluded from translation or not?
>>>
>>> As stage1 stuff, I'll largely be ignoring.
>>>
>>> I'm torn on translating this stuff.  It's hard enough for a non-developer to
>>> interpret an ICE message, if it's not in their native language it'd be
>>> impossible.
>>>
>>> OTOH, if we translate and the user forwards the translated message to us, we
>>> may not be able to interpret.
>>>
>>> That probably argues there's some part that should be translated to be
>>> easier for the users, but the real guts of the message should not be
>>> translated.
>>
>> Message number and catalogue.
>>
>> /me runs...
>>
>>> jeff
> 
> I there any discussion going on this topic? If not, I'll probably leave it as it is.
No ongoing discussion -- I'm working through my backlog of items that
were deferred for gcc-8 stage1 as well as items that I couldn't get to
while focused on stack-clash.

jeff