Re: [Patch, Fortran] PR 69495: unused-label warning does not tell which flag triggered it

[Janus Weil]

>> The patch is OK for trunk.
>
> thanks a lot. Will commit soon.

Committed as r241870. Thanks again.

Cheers,
Janus




>> On 5 November 2016 at 10:15, Janus Weil  wrote:
>>> Hi all,
>>>
>>> here is a patch that I had submitted already in February (see
>>> https://gcc.gnu.org/ml/fortran/2016-02/msg00011.html). Unfortunately
>>> it was never approved and I got distracted with other things and
>>> forgot about it.
>>>
>>> It's a diagnostics patch, which makes sure that the responsible flag
>>> is printed in several warning messages (for which this was still
>>> missing). As a small extra the patch also mentions the -Wpedantic flag
>>> in the gfortran documentation.
>>>
>>> Fortunately the patch still applies cleanly and regtests without
>>> failures on x86_64-linux-gnu. Ok for trunk?
>>>
>>> Cheers,
>>> Janus
>>>
>>>
>>> 2016-11-05  Janus Weil  
>>> Manuel Lopez-Ibanez  
>>>
>>> PR fortran/69495
>>> * invoke.texi: Mention -Wpedantic as an alias of -pedantic.
>>> * check.c (gfc_check_transfer): Mention responsible flag in warning
>>> message.
>>> * frontend-passes.c (do_warn_function_elimination): Ditto.
>>> * resolve.c (resolve_elemental_actual): Ditto.
>>> (resolve_operator): Ditto.
>>> (warn_unused_fortran_label): Ditto.
>>> * trans-common.c (translate_common): Ditto.
>>>
>>>
>>> 2016-11-05  Janus Weil  
>>> Dominique d'Humieres  
>>>
>>> PR fortran/69495
>>> * gfortran.dg/elemental_optional_args_6.f90: Use -Wpedantic flag.
>>
>>
>>
>> --
>> The difference between genius and stupidity is; genius has its limits.
>>
>> Albert Einstein

Re: [Patch, Fortran] PR 69495: unused-label warning does not tell which flag triggered it

[Janus Weil]

Hi Paul,

> The patch is OK for trunk.

thanks a lot. Will commit soon.


> PS While you are with us, are you intending to deal with the 14 PRs
> for which you are the assignee or will you unassign yourself?

Good point. I will look through them and see what I can do. In fact I
might have a bit of time for gfortran hacking in the coming weeks, but
I cannot promise anything 

Cheers,
Janus




> On 5 November 2016 at 10:15, Janus Weil  wrote:
>> Hi all,
>>
>> here is a patch that I had submitted already in February (see
>> https://gcc.gnu.org/ml/fortran/2016-02/msg00011.html). Unfortunately
>> it was never approved and I got distracted with other things and
>> forgot about it.
>>
>> It's a diagnostics patch, which makes sure that the responsible flag
>> is printed in several warning messages (for which this was still
>> missing). As a small extra the patch also mentions the -Wpedantic flag
>> in the gfortran documentation.
>>
>> Fortunately the patch still applies cleanly and regtests without
>> failures on x86_64-linux-gnu. Ok for trunk?
>>
>> Cheers,
>> Janus
>>
>>
>> 2016-11-05  Janus Weil  
>> Manuel Lopez-Ibanez  
>>
>> PR fortran/69495
>> * invoke.texi: Mention -Wpedantic as an alias of -pedantic.
>> * check.c (gfc_check_transfer): Mention responsible flag in warning
>> message.
>> * frontend-passes.c (do_warn_function_elimination): Ditto.
>> * resolve.c (resolve_elemental_actual): Ditto.
>> (resolve_operator): Ditto.
>> (warn_unused_fortran_label): Ditto.
>> * trans-common.c (translate_common): Ditto.
>>
>>
>> 2016-11-05  Janus Weil  
>> Dominique d'Humieres  
>>
>> PR fortran/69495
>> * gfortran.dg/elemental_optional_args_6.f90: Use -Wpedantic flag.
>
>
>
> --
> The difference between genius and stupidity is; genius has its limits.
>
> Albert Einstein

Re: [Patch, Fortran] PR 69495: unused-label warning does not tell which flag triggered it

[Paul Richard Thomas]

Hi Janus,

Welcome back!

The patch is OK for trunk.

Best regards

Paul

PS While you are with us, are you intending to deal with the 14 PRs
for which you are the assignee or will you unassign yourself?

On 5 November 2016 at 10:15, Janus Weil  wrote:
> Hi all,
>
> here is a patch that I had submitted already in February (see
> https://gcc.gnu.org/ml/fortran/2016-02/msg00011.html). Unfortunately
> it was never approved and I got distracted with other things and
> forgot about it.
>
> It's a diagnostics patch, which makes sure that the responsible flag
> is printed in several warning messages (for which this was still
> missing). As a small extra the patch also mentions the -Wpedantic flag
> in the gfortran documentation.
>
> Fortunately the patch still applies cleanly and regtests without
> failures on x86_64-linux-gnu. Ok for trunk?
>
> Cheers,
> Janus
>
>
> 2016-11-05  Janus Weil  
> Manuel Lopez-Ibanez  
>
> PR fortran/69495
> * invoke.texi: Mention -Wpedantic as an alias of -pedantic.
> * check.c (gfc_check_transfer): Mention responsible flag in warning
> message.
> * frontend-passes.c (do_warn_function_elimination): Ditto.
> * resolve.c (resolve_elemental_actual): Ditto.
> (resolve_operator): Ditto.
> (warn_unused_fortran_label): Ditto.
> * trans-common.c (translate_common): Ditto.
>
>
> 2016-11-05  Janus Weil  
> Dominique d'Humieres  
>
> PR fortran/69495
> * gfortran.dg/elemental_optional_args_6.f90: Use -Wpedantic flag.



-- 
The difference between genius and stupidity is; genius has its limits.

Albert Einstein

[Patch, Fortran] PR 69495: unused-label warning does not tell which flag triggered it

[Janus Weil]

Hi all,

here is a patch that I had submitted already in February (see
https://gcc.gnu.org/ml/fortran/2016-02/msg00011.html). Unfortunately
it was never approved and I got distracted with other things and
forgot about it.

It's a diagnostics patch, which makes sure that the responsible flag
is printed in several warning messages (for which this was still
missing). As a small extra the patch also mentions the -Wpedantic flag
in the gfortran documentation.

Fortunately the patch still applies cleanly and regtests without
failures on x86_64-linux-gnu. Ok for trunk?

Cheers,
Janus


2016-11-05  Janus Weil  
Manuel Lopez-Ibanez  

PR fortran/69495
* invoke.texi: Mention -Wpedantic as an alias of -pedantic.
* check.c (gfc_check_transfer): Mention responsible flag in warning
message.
* frontend-passes.c (do_warn_function_elimination): Ditto.
* resolve.c (resolve_elemental_actual): Ditto.
(resolve_operator): Ditto.
(warn_unused_fortran_label): Ditto.
* trans-common.c (translate_common): Ditto.


2016-11-05  Janus Weil  
Dominique d'Humieres  

PR fortran/69495
* gfortran.dg/elemental_optional_args_6.f90: Use -Wpedantic flag.
Index: gcc/fortran/check.c
===
--- gcc/fortran/check.c (revision 241869)
+++ gcc/fortran/check.c (working copy)
@@ -5187,7 +5187,8 @@ gfc_check_transfer (gfc_expr *source, gfc_expr *mo
 return true;
 
   if (source_size < result_size)
-gfc_warning (0, "Intrinsic TRANSFER at %L has partly undefined result: "
+gfc_warning (OPT_Wsurprising,
+"Intrinsic TRANSFER at %L has partly undefined result: "
 "source size %ld < result size %ld", >where,
 (long) source_size, (long) result_size);
 
Index: gcc/fortran/frontend-passes.c
===
--- gcc/fortran/frontend-passes.c   (revision 241869)
+++ gcc/fortran/frontend-passes.c   (working copy)
@@ -747,10 +747,12 @@ do_warn_function_elimination (gfc_expr *e)
   if (e->expr_type != EXPR_FUNCTION)
 return;
   if (e->value.function.esym)
-gfc_warning (0, "Removing call to function %qs at %L",
+gfc_warning (OPT_Wfunction_elimination,
+"Removing call to function %qs at %L",
 e->value.function.esym->name, &(e->where));
   else if (e->value.function.isym)
-gfc_warning (0, "Removing call to function %qs at %L",
+gfc_warning (OPT_Wfunction_elimination,
+"Removing call to function %qs at %L",
 e->value.function.isym->name, &(e->where));
 }
 /* Callback function for the code walker for doing common function
Index: gcc/fortran/invoke.texi
===
--- gcc/fortran/invoke.texi (revision 241869)
+++ gcc/fortran/invoke.texi (working copy)
@@ -749,8 +749,10 @@ Check the code for syntax errors, but do not actua
 will generate module files for each module present in the code, but no
 other output file.
 
-@item -pedantic
+@item -Wpedantic
+@itemx -pedantic
 @opindex @code{pedantic}
+@opindex @code{Wpedantic}
 Issue warnings for uses of extensions to Fortran 95.
 @option{-pedantic} also applies to C-language constructs where they
 occur in GNU Fortran source files, such as use of @samp{\e} in a
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c   (revision 241869)
+++ gcc/fortran/resolve.c   (working copy)
@@ -2140,7 +2140,8 @@ resolve_elemental_actual (gfc_expr *expr, gfc_code
  && (set_by_optional || arg->expr->rank != rank)
  && !(isym && isym->id == GFC_ISYM_CONVERSION))
{
- gfc_warning (0, "%qs at %L is an array and OPTIONAL; IF IT IS "
+ gfc_warning (OPT_Wpedantic,
+  "%qs at %L is an array and OPTIONAL; IF IT IS "
   "MISSING, it cannot be the actual argument of an "
   "ELEMENTAL procedure unless there is a non-optional "
   "argument with the same rank (12.4.1.5)",
@@ -3811,7 +3812,8 @@ resolve_operator (gfc_expr *e)
  else
msg = "Inequality comparison for %s at %L";
 
- gfc_warning (0, msg, gfc_typename (>ts), >where);
+ gfc_warning (OPT_Wcompare_reals, msg,
+  gfc_typename (>ts), >where);
}
}
 
@@ -15393,12 +15395,13 @@ warn_unused_fortran_label (gfc_st_label *label)
   switch (label->referenced)
 {
 case ST_LABEL_UNKNOWN:
-  gfc_warning (0, "Label %d at %L defined but not used", label->value,
-  >where);
+  gfc_warning (OPT_Wunused_label, "Label %d at %L defined but not used",
+  label->value, >where);
   break;
 
 case 

Re: [Patch, Fortran] PR 69495: unused-label warning does not tell which flag triggered it

[Janus Weil]

double-ping ...



2016-02-12 0:29 GMT+01:00 Janus Weil :
> ping!
>
> 2016-02-05 19:19 GMT+01:00 Janus Weil :
>> Hi all,
>>
>> I have slightly updated the patch now to avoid string-breaking issues
>> (even if it may not be a problem at all, as mentioned by Jospeh). Also
>> I removed the questionable part in intrinsic.c that I was not sure
>> about.
>>
>> This version of the patch should not be too far from obvious now. Ok for 
>> trunk?
>>
>> Cheers,
>> Janus
>>
>>
>>
>> 2016-02-03 23:27 GMT+01:00 Joseph Myers :
>>> On Wed, 3 Feb 2016, Manfred Schwarb wrote:
>>>
 There are 2 things with translation, and there is a third issue:
 - As you noticed, breaking things differently means translation has to be
   done again.
 - Normally, each string is translated independently, and depending on the
   language there may be lack of context (e.g. adjectives get different
 suffixes
   depending on the noun).
>>>
>>> I believe gettext works fine with (compile-time) string constant
>>> concatenation - that is, extracts the whole concatenated string for
>>> translation, so these are non-issues.  What doesn't work includes:
>>>
>>> * Runtime concatenation of strings or otherwise putting English fragments
>>> together at runtime.
>>>
>>> * String constant concatenation where one of the concatenated pieces comes
>>> from a macro expansion.
>>>
>>> * The argument for translation being a conditional expression:
>>>
>>>   error (cond ? "message 1" : "message 2");
>>>
>>> (in this case, only one of the messages may be extracted for translation,
>>> so you need to mark both of them up with appropriate macros such as G_).
>>>
>>> --
>>> Joseph S. Myers
>>> jos...@codesourcery.com

Re: [Patch, Fortran] PR 69495: unused-label warning does not tell which flag triggered it

[Janus Weil]

ping!

2016-02-05 19:19 GMT+01:00 Janus Weil :
> Hi all,
>
> I have slightly updated the patch now to avoid string-breaking issues
> (even if it may not be a problem at all, as mentioned by Jospeh). Also
> I removed the questionable part in intrinsic.c that I was not sure
> about.
>
> This version of the patch should not be too far from obvious now. Ok for 
> trunk?
>
> Cheers,
> Janus
>
>
>
> 2016-02-03 23:27 GMT+01:00 Joseph Myers :
>> On Wed, 3 Feb 2016, Manfred Schwarb wrote:
>>
>>> There are 2 things with translation, and there is a third issue:
>>> - As you noticed, breaking things differently means translation has to be
>>>   done again.
>>> - Normally, each string is translated independently, and depending on the
>>>   language there may be lack of context (e.g. adjectives get different
>>> suffixes
>>>   depending on the noun).
>>
>> I believe gettext works fine with (compile-time) string constant
>> concatenation - that is, extracts the whole concatenated string for
>> translation, so these are non-issues.  What doesn't work includes:
>>
>> * Runtime concatenation of strings or otherwise putting English fragments
>> together at runtime.
>>
>> * String constant concatenation where one of the concatenated pieces comes
>> from a macro expansion.
>>
>> * The argument for translation being a conditional expression:
>>
>>   error (cond ? "message 1" : "message 2");
>>
>> (in this case, only one of the messages may be extracted for translation,
>> so you need to mark both of them up with appropriate macros such as G_).
>>
>> --
>> Joseph S. Myers
>> jos...@codesourcery.com

Re: [Patch, Fortran] PR 69495: unused-label warning does not tell which flag triggered it

[Janus Weil]

Hi all,

I have slightly updated the patch now to avoid string-breaking issues
(even if it may not be a problem at all, as mentioned by Jospeh). Also
I removed the questionable part in intrinsic.c that I was not sure
about.

This version of the patch should not be too far from obvious now. Ok for trunk?

Cheers,
Janus



2016-02-03 23:27 GMT+01:00 Joseph Myers :
> On Wed, 3 Feb 2016, Manfred Schwarb wrote:
>
>> There are 2 things with translation, and there is a third issue:
>> - As you noticed, breaking things differently means translation has to be
>>   done again.
>> - Normally, each string is translated independently, and depending on the
>>   language there may be lack of context (e.g. adjectives get different
>> suffixes
>>   depending on the noun).
>
> I believe gettext works fine with (compile-time) string constant
> concatenation - that is, extracts the whole concatenated string for
> translation, so these are non-issues.  What doesn't work includes:
>
> * Runtime concatenation of strings or otherwise putting English fragments
> together at runtime.
>
> * String constant concatenation where one of the concatenated pieces comes
> from a macro expansion.
>
> * The argument for translation being a conditional expression:
>
>   error (cond ? "message 1" : "message 2");
>
> (in this case, only one of the messages may be extracted for translation,
> so you need to mark both of them up with appropriate macros such as G_).
>
> --
> Joseph S. Myers
> jos...@codesourcery.com
Index: gcc/fortran/check.c
===
--- gcc/fortran/check.c (Revision 233182)
+++ gcc/fortran/check.c (Arbeitskopie)
@@ -5180,7 +5180,8 @@ gfc_check_transfer (gfc_expr *source, gfc_expr *mo
 return true;
 
   if (source_size < result_size)
-gfc_warning (0, "Intrinsic TRANSFER at %L has partly undefined result: "
+gfc_warning (OPT_Wsurprising,
+"Intrinsic TRANSFER at %L has partly undefined result: "
 "source size %ld < result size %ld", >where,
 (long) source_size, (long) result_size);
 
Index: gcc/fortran/frontend-passes.c
===
--- gcc/fortran/frontend-passes.c   (Revision 233182)
+++ gcc/fortran/frontend-passes.c   (Arbeitskopie)
@@ -715,10 +715,12 @@ do_warn_function_elimination (gfc_expr *e)
   if (e->expr_type != EXPR_FUNCTION)
 return;
   if (e->value.function.esym)
-gfc_warning (0, "Removing call to function %qs at %L",
+gfc_warning (OPT_Wfunction_elimination,
+"Removing call to function %qs at %L",
 e->value.function.esym->name, &(e->where));
   else if (e->value.function.isym)
-gfc_warning (0, "Removing call to function %qs at %L",
+gfc_warning (OPT_Wfunction_elimination,
+"Removing call to function %qs at %L",
 e->value.function.isym->name, &(e->where));
 }
 /* Callback function for the code walker for doing common function
Index: gcc/fortran/invoke.texi
===
--- gcc/fortran/invoke.texi (Revision 233182)
+++ gcc/fortran/invoke.texi (Arbeitskopie)
@@ -709,8 +709,10 @@ Check the code for syntax errors, but do not actua
 will generate module files for each module present in the code, but no
 other output file.
 
-@item -pedantic
+@item -Wpedantic
+@itemx -pedantic
 @opindex @code{pedantic}
+@opindex @code{Wpedantic}
 Issue warnings for uses of extensions to Fortran 95.
 @option{-pedantic} also applies to C-language constructs where they
 occur in GNU Fortran source files, such as use of @samp{\e} in a
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c   (Revision 233182)
+++ gcc/fortran/resolve.c   (Arbeitskopie)
@@ -2127,7 +2127,8 @@ resolve_elemental_actual (gfc_expr *expr, gfc_code
  && (set_by_optional || arg->expr->rank != rank)
  && !(isym && isym->id == GFC_ISYM_CONVERSION))
{
- gfc_warning (0, "%qs at %L is an array and OPTIONAL; IF IT IS "
+ gfc_warning (OPT_Wpedantic,
+  "%qs at %L is an array and OPTIONAL; IF IT IS "
   "MISSING, it cannot be the actual argument of an "
   "ELEMENTAL procedure unless there is a non-optional "
   "argument with the same rank (12.4.1.5)",
@@ -3685,7 +3686,8 @@ resolve_operator (gfc_expr *e)
  else
msg = "Inequality comparison for %s at %L";
 
- gfc_warning (0, msg, gfc_typename (>ts), >where);
+ gfc_warning (OPT_Wcompare_reals, msg,
+  gfc_typename (>ts), >where);
}
}
 
@@ -14890,12 +14892,13 @@ warn_unused_fortran_label (gfc_st_label *label)
   switch (label->referenced)
 {
 case ST_LABEL_UNKNOWN:

Re: [Patch, Fortran] PR 69495: unused-label warning does not tell which flag triggered it

[Manfred Schwarb]

Am 02.02.2016 um 21:26 schrieb Janus Weil:

Hi all,

here is a diagnostics patch, which makes sure that the responsible
flag is printed in several warning messages (for which this was still
missing).

The  only case that I'm not completely sure about is the hunk in
intrinsic.c. In particular I was not able to trigger this warning and
found no occurrence of it in the testsuite. Could someone check if the
flag that I'm using there is correct, please?

As a small extra the patch also mentions the -Wpedantic flag in the
gfortran documentation.

It regtests cleanly on x86_64-linux-gnu. Ok for trunk?

Cheers,
Janus



   if (source_size < result_size)
-gfc_warning (0, "Intrinsic TRANSFER at %L has partly undefined result: "
-"source size %ld < result size %ld", >where,
-(long) source_size, (long) result_size);
+gfc_warning (OPT_Wsurprising, "Intrinsic TRANSFER at %L has partly "
+"undefined result: source size %ld < result size %ld",
+>where, (long) source_size, (long) result_size);
 


Breaking apart of these strings will probably hamper translation.

Cheers,
Manfred

Re: [Patch, Fortran] PR 69495: unused-label warning does not tell which flag triggered it

[Manfred Schwarb]

Am 03.02.2016 um 19:18 schrieb Janus Weil:

Hi,

2016-02-03 10:21 GMT+01:00 Manfred Schwarb :

here is a diagnostics patch, which makes sure that the responsible
flag is printed in several warning messages (for which this was still
missing).



if (source_size < result_size)
-gfc_warning (0, "Intrinsic TRANSFER at %L has partly undefined result:
"
-"source size %ld < result size %ld", >where,
-(long) source_size, (long) result_size);
+gfc_warning (OPT_Wsurprising, "Intrinsic TRANSFER at %L has partly "
+"undefined result: source size %ld < result size %ld",
+>where, (long) source_size, (long) result_size);

Breaking apart of these strings will probably hamper translation.


thanks for the comment, I was not aware that this is a problem (in
fact I'm rather ignorant of the translation process as a whole). I was
just trying to comply with the GNU coding standards by avoiding
overlong lines.

So, I assume the problem is that the strings are being broken
*differently* than before, right? (Obviously the were broken already
...) I guess I will just move the start of the warning message to a
new line in order to avoid this.



There are 2 things with translation, and there is a third issue:
- As you noticed, breaking things differently means translation has to be
  done again.
- Normally, each string is translated independently, and depending on the
  language there may be lack of context (e.g. adjectives get different suffixes
  depending on the noun).
- grep'ability: you got such an error message, then you want to look for the
  corresponding code and do a grep for e.g. "partly undefined result".
  GOTCHA!

So IMHO strings should be left intact, irrespective of some arbitrary 80 char 
limits.
Other projects, e.g. the linux kernel, do deliberately violate the 80 char limit
if it is needed, and do not always break strings. I do not know how it is 
handled
in the GCC project, but I guess common sense is always a good recipe.

Of course it is no problem to split at natural boundaries, e.g. at ":", ";" or 
"."
characters.

Cheers,
Manfred



Btw, if anyone notices any further cases where the flag is missing in
the warning message, please let me know. (I haven't searched through
the whole gfortran code for more such cases and I'm not planning on
doing so, but I'll be happy to include further cases in the patch if
pointed out to me ...)

Also I guess I should mention Manuel and Dominique in the Changelog
(for their supportive comments in the PR).

Cheers,
Janus

Re: [Patch, Fortran] PR 69495: unused-label warning does not tell which flag triggered it

[Joseph Myers]

On Wed, 3 Feb 2016, Manfred Schwarb wrote:

> There are 2 things with translation, and there is a third issue:
> - As you noticed, breaking things differently means translation has to be
>   done again.
> - Normally, each string is translated independently, and depending on the
>   language there may be lack of context (e.g. adjectives get different
> suffixes
>   depending on the noun).

I believe gettext works fine with (compile-time) string constant 
concatenation - that is, extracts the whole concatenated string for 
translation, so these are non-issues.  What doesn't work includes:

* Runtime concatenation of strings or otherwise putting English fragments 
together at runtime.

* String constant concatenation where one of the concatenated pieces comes 
from a macro expansion.

* The argument for translation being a conditional expression:

  error (cond ? "message 1" : "message 2");

(in this case, only one of the messages may be extracted for translation, 
so you need to mark both of them up with appropriate macros such as G_).

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [Patch, Fortran] PR 69495: unused-label warning does not tell which flag triggered it

[Janus Weil]

Hi,

2016-02-03 10:21 GMT+01:00 Manfred Schwarb :
>> here is a diagnostics patch, which makes sure that the responsible
>> flag is printed in several warning messages (for which this was still
>> missing).
>>
>
>if (source_size < result_size)
> -gfc_warning (0, "Intrinsic TRANSFER at %L has partly undefined result:
> "
> -"source size %ld < result size %ld", >where,
> -(long) source_size, (long) result_size);
> +gfc_warning (OPT_Wsurprising, "Intrinsic TRANSFER at %L has partly "
> +"undefined result: source size %ld < result size %ld",
> +>where, (long) source_size, (long) result_size);
>
> Breaking apart of these strings will probably hamper translation.

thanks for the comment, I was not aware that this is a problem (in
fact I'm rather ignorant of the translation process as a whole). I was
just trying to comply with the GNU coding standards by avoiding
overlong lines.

So, I assume the problem is that the strings are being broken
*differently* than before, right? (Obviously the were broken already
...) I guess I will just move the start of the warning message to a
new line in order to avoid this.

Btw, if anyone notices any further cases where the flag is missing in
the warning message, please let me know. (I haven't searched through
the whole gfortran code for more such cases and I'm not planning on
doing so, but I'll be happy to include further cases in the patch if
pointed out to me ...)

Also I guess I should mention Manuel and Dominique in the Changelog
(for their supportive comments in the PR).

Cheers,
Janus

[Patch, Fortran] PR 69495: unused-label warning does not tell which flag triggered it

[Janus Weil]

Hi all,

here is a diagnostics patch, which makes sure that the responsible
flag is printed in several warning messages (for which this was still
missing).

The  only case that I'm not completely sure about is the hunk in
intrinsic.c. In particular I was not able to trigger this warning and
found no occurrence of it in the testsuite. Could someone check if the
flag that I'm using there is correct, please?

As a small extra the patch also mentions the -Wpedantic flag in the
gfortran documentation.

It regtests cleanly on x86_64-linux-gnu. Ok for trunk?

Cheers,
Janus


2016-02-01  Janus Weil  

PR fortran/69495
* invoke.texi: Mention -Wpedantic as an alias of -pedantic.
* check.c (gfc_check_transfer): Mention responsible flag in warning
message.
* frontend-passes.c (do_warn_function_elimination): Ditto.
* intrinsic.c (gfc_check_intrinsic_standard): Ditto.
* resolve.c (resolve_elemental_actual): Ditto.
(resolve_operator): Ditto.
(warn_unused_fortran_label): Ditto.
* trans-common.c (translate_common): Ditto.


2016-02-01  Janus Weil  

PR fortran/69495
* gfortran.dg/elemental_optional_args_6.f90: Use -Wpedantic flag.
Index: gcc/fortran/check.c
===
--- gcc/fortran/check.c (Revision 233091)
+++ gcc/fortran/check.c (Arbeitskopie)
@@ -5180,9 +5180,9 @@ gfc_check_transfer (gfc_expr *source, gfc_expr *mo
 return true;
 
   if (source_size < result_size)
-gfc_warning (0, "Intrinsic TRANSFER at %L has partly undefined result: "
-"source size %ld < result size %ld", >where,
-(long) source_size, (long) result_size);
+gfc_warning (OPT_Wsurprising, "Intrinsic TRANSFER at %L has partly "
+"undefined result: source size %ld < result size %ld",
+>where, (long) source_size, (long) result_size);
 
   return true;
 }
Index: gcc/fortran/frontend-passes.c
===
--- gcc/fortran/frontend-passes.c   (Revision 233091)
+++ gcc/fortran/frontend-passes.c   (Arbeitskopie)
@@ -715,11 +715,11 @@ do_warn_function_elimination (gfc_expr *e)
   if (e->expr_type != EXPR_FUNCTION)
 return;
   if (e->value.function.esym)
-gfc_warning (0, "Removing call to function %qs at %L",
-e->value.function.esym->name, &(e->where));
+gfc_warning (OPT_Wfunction_elimination, "Removing call to function %qs "
+"at %L", e->value.function.esym->name, &(e->where));
   else if (e->value.function.isym)
-gfc_warning (0, "Removing call to function %qs at %L",
-e->value.function.isym->name, &(e->where));
+gfc_warning (OPT_Wfunction_elimination, "Removing call to function %qs "
+"at %L", e->value.function.isym->name, &(e->where));
 }
 /* Callback function for the code walker for doing common function
elimination.  This builds up the list of functions in the expression
Index: gcc/fortran/intrinsic.c
===
--- gcc/fortran/intrinsic.c (Revision 233091)
+++ gcc/fortran/intrinsic.c (Arbeitskopie)
@@ -4369,7 +4369,7 @@ gfc_check_intrinsic_standard (const gfc_intrinsic_
 {
   /* Do only print a warning if not a GNU extension.  */
   if (!silent && isym->standard != GFC_STD_GNU)
-   gfc_warning (0, "Intrinsic %qs (is %s) is used at %L",
+   gfc_warning (OPT_Wintrinsics_std, "Intrinsic %qs (is %s) is used at %L",
 isym->name, _(symstd_msg), );
 
   return true;
Index: gcc/fortran/invoke.texi
===
--- gcc/fortran/invoke.texi (Revision 233091)
+++ gcc/fortran/invoke.texi (Arbeitskopie)
@@ -709,8 +709,10 @@ Check the code for syntax errors, but do not actua
 will generate module files for each module present in the code, but no
 other output file.
 
-@item -pedantic
+@item -Wpedantic
+@itemx -pedantic
 @opindex @code{pedantic}
+@opindex @code{Wpedantic}
 Issue warnings for uses of extensions to Fortran 95.
 @option{-pedantic} also applies to C-language constructs where they
 occur in GNU Fortran source files, such as use of @samp{\e} in a
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c   (Revision 233091)
+++ gcc/fortran/resolve.c   (Arbeitskopie)
@@ -2127,9 +2127,9 @@ resolve_elemental_actual (gfc_expr *expr, gfc_code
  && (set_by_optional || arg->expr->rank != rank)
  && !(isym && isym->id == GFC_ISYM_CONVERSION))
{
- gfc_warning (0, "%qs at %L is an array and OPTIONAL; IF IT IS "
-  "MISSING, it cannot be the actual argument of an "
-  "ELEMENTAL procedure unless there is a non-optional "
+ gfc_warning (OPT_Wpedantic, "%qs at %L is an array and OPTIONAL; "
+