[4.5 C] Fix types in fold_builtin_sincos

Joseph S. Myers joseph@codesourcery.com
Sat Jan 17 11:18:00 GMT 2009

On Sat, 17 Jan 2009, Richard Guenther wrote:

> On Sat, Jan 17, 2009 at 12:55 AM, Joseph S. Myers
> <joseph@codesourcery.com> wrote:
> > After my latest merge to c-4_5-branch from trunk some ICEs appeared
> > arising from fold_builtin_sincos building MODIFY_EXPRs in void_type_node
> > and then trying to use a COMPOUND_EXPR to convert to a non-void type.  (I
> > don't know why this didn't cause ICEs before; I don't think such trees,
> > where COMPOUND_EXPR involves a nontrivial conversion, are valid.)
> That's weird.  a MODIFY_EXPR doesn't have a type, so using void_type_node
> is exactly correct.  What is using the type of the MODIFY_EXPR?  It's better
> to fix that instead - if you grep for MODIFY_EXPR and void_type_node there
> are a lot more offenders otherwise.

A MODIFY_EXPR certainly does have a type and value in C, at least if its 
result is used - the type and value of the LHS after assignment.

But since sincos actually returns void, I think the actual problem here 
must be the type of the COMPOUND_EXPR, which should be void.  So I'm now 
testing this alternative patch - OK for 4.5 if it passes testing?

Index: builtins.c
--- builtins.c	(revision 143461)
+++ builtins.c	(working copy)
@@ -7930,7 +7930,7 @@
   call = build_call_expr (fn, 1, arg0);
   call = builtin_save_expr (call);
-  return build2 (COMPOUND_EXPR, type,
+  return build2 (COMPOUND_EXPR, void_type_node,
 		 build2 (MODIFY_EXPR, void_type_node,
 			 build_fold_indirect_ref (arg1),
 			 build1 (IMAGPART_EXPR, type, call)),
Index: ChangeLog.c45
--- ChangeLog.c45	(revision 143461)
+++ ChangeLog.c45	(working copy)
@@ -1,3 +1,8 @@
+2009-01-17  Joseph Myers  <joseph@codesourcery.com>
+	* builtins.c (fold_builtin_sincos): Build COMPOUND_EXPR in
+	void_type_node.
 2008-12-10  Joseph Myers  <joseph@codesourcery.com>
 	* c-typeck.c (c_fully_fold, c_fully_fold_internal,

Joseph S. Myers

More information about the Gcc-patches mailing list