diff mbox

[fortran] PR 59599 ICE on intrinsic ichar

Message ID 52FE8FD2.10807@sfr.fr
State New
Headers show

Commit Message

Mikael Morin Feb. 14, 2014, 9:51 p.m. UTC
Hello,

this bug is not a regression, but the patch shouldn't wreck the compiler
too much on the other hand.
The problem is a wrong number of arguments while generating code for the
ichar intrinsic.  The correct number is 2 without the kind argument and
3 with it.
The attached patch uses the gfc_intrinsic_argument_list_length function
like it's done for other intrinsics.

Regression tested on x86_64-unknown-linux-gnu. OK for trunk/4.8/4.7?

Mikael
2014-02-14  Mikael Morin  <mikael@gcc.gnu.org>

	PR fortran/59599
	* trans-intrinsic.c (gfc_conv_intrinsic_ichar): Calculate the
	number of arguments.

2014-02-14  Mikael Morin  <mikael@gcc.gnu.org>

	PR fortran/59599
	* gfortran.dg/ichar_3.f90: New test.

Comments

Steve Kargl Feb. 14, 2014, 11:45 p.m. UTC | #1
On Fri, Feb 14, 2014 at 10:51:14PM +0100, Mikael Morin wrote:
> Hello,
> 
> this bug is not a regression, but the patch shouldn't wreck the compiler
> too much on the other hand.
> The problem is a wrong number of arguments while generating code for the
> ichar intrinsic.  The correct number is 2 without the kind argument and
> 3 with it.
> The attached patch uses the gfc_intrinsic_argument_list_length function
> like it's done for other intrinsics.
> 

Once the problem is identified, the patch is almost trivial.
From the Fortran standpoint, it's OK.  Need RM approval.
Richard Biener Feb. 15, 2014, 10:04 a.m. UTC | #2
On Fri, 14 Feb 2014, Mikael Morin wrote:

> Hello,
> 
> this bug is not a regression, but the patch shouldn't wreck the compiler
> too much on the other hand.
> The problem is a wrong number of arguments while generating code for the
> ichar intrinsic.  The correct number is 2 without the kind argument and
> 3 with it.
> The attached patch uses the gfc_intrinsic_argument_list_length function
> like it's done for other intrinsics.
> 
> Regression tested on x86_64-unknown-linux-gnu. OK for trunk/4.8/4.7?

Generally wrong-code non-regression fixes for Fortran are fine
if Fortran maintainers think so.

Richard.
Mikael Morin Feb. 15, 2014, 11:19 a.m. UTC | #3
Le 15/02/2014 11:04, Richard Biener a écrit :
> On Fri, 14 Feb 2014, Mikael Morin wrote:
> 
>> Hello,
>>
>> this bug is not a regression, but the patch shouldn't wreck the compiler
>> too much on the other hand.
>> The problem is a wrong number of arguments while generating code for the
>> ichar intrinsic.  The correct number is 2 without the kind argument and
>> 3 with it.
>> The attached patch uses the gfc_intrinsic_argument_list_length function
>> like it's done for other intrinsics.
>>
>> Regression tested on x86_64-unknown-linux-gnu. OK for trunk/4.8/4.7?
> 
> Generally wrong-code non-regression fixes for Fortran are fine
> if Fortran maintainers think so.
> 
Technically it's an ICE, not a wrong-code; but I bet it would be a
wrong-code if the scalarizer didn't notice a problem.
I'll proceed with the committal. Thanks for the review(s).

Mikael
diff mbox

Patch

diff --git a/gcc/fortran/trans-intrinsic.c b/gcc/fortran/trans-intrinsic.c
index 1eb9490..cff8e89 100644
--- a/gcc/fortran/trans-intrinsic.c
+++ b/gcc/fortran/trans-intrinsic.c
@@ -4689,8 +4689,10 @@  static void
 gfc_conv_intrinsic_ichar (gfc_se * se, gfc_expr * expr)
 {
   tree args[2], type, pchartype;
+  int nargs;
 
-  gfc_conv_intrinsic_function_args (se, expr, args, 2);
+  nargs = gfc_intrinsic_argument_list_length (expr);
+  gfc_conv_intrinsic_function_args (se, expr, args, nargs);
   gcc_assert (POINTER_TYPE_P (TREE_TYPE (args[1])));
   pchartype = gfc_get_pchar_type (expr->value.function.actual->expr->ts.kind);
   args[1] = fold_build1_loc (input_location, NOP_EXPR, pchartype, args[1]);