@@ -11683,50 +11683,60 @@ jsrsearch(int ilix)
1168311683int
1168411684alt_qjsr (int ilix )
1168511685{
11686+ int altx , j , noprs ;
11687+ ILI_OP opc ;
11688+
1168611689 if (ILI_ALT (ilix )) {
11687- if (IL_TYPE (ILI_OPC (ILI_ALT (ilix ))) == ILTY_DEFINE )
11690+ altx = ILI_ALT (ilix );
11691+ opc = ILI_OPC (altx );
11692+ if (IL_TYPE (opc ) == ILTY_DEFINE )
1168811693 return 1 ;
11689- {
11690- /*
11691- * A bug (asrt) occurred with the 32-bit cg where the BIH_QJSR
11692- * flag was not set, but the block contained a QJSR -- alt_qjsr(),
11693- * when called from flow(, is supposed to detect qjsrs alt ili.
11694- * There are just a few cases where the ALT ILI does not
11695- * immediately reference a QJSR, but it's an ILI whose operand
11696- * is a QJSR; an example of this is a 64-bit relational fo
11697- * something like
11698- * if ( i8 .gt. 0 )
11699- * 49 QJSR 342~<__mth_i_kcmpz> 48^
11700- * 50 DFRIR 49^ ir( 1)
11701- * 51 ICMPZ 50^ gt
11702- * 52 KCMPZ 47^ gt 51^-alt
11703- * ...
11704- * The solution for now is to check just one level below the
11705- * ALT -- this isn't general at all, so the next time the bug
11706- * occurs, may have to implement a complete fix (i.e., just
11707- * call the 'new' routine, qjsr_in(), above);
11708- */
11709- int altx ;
11710- ILI_OP opc ;
11711- int noprs , j ;
11712- altx = ILI_ALT (ilix );
11713- opc = ILI_OPC (altx );
11714- noprs = IL_OPRS (opc );
11715- for (j = 1 ; j <= noprs ; ++ j ) {
11716- if (IL_ISLINK (opc , j )) {
11717- if (IL_TYPE (ILI_OPC (ILI_OPND (altx , j ))) == ILTY_DEFINE )
11718- return 1 ;
11719- }
11694+
11695+ /* In a few cases a QJSR's result ILI (namely a 'define' ILI such
11696+ * as IL_DFRDP, etc) is not 'altx' itself but rather an operand of
11697+ * 'altx'. For example, if the C99 ABI is used on x86 then a
11698+ * complex*16 function result is returned in a pair of registers,
11699+ * %xmm0 and %xmm1, and the ILI 'altx' is
11700+ * IL_DPDP2DCMPLX( IL_DFRDP(...), IL_DFRDP(...) ). Also on x86-32
11701+ * a 64-bit condition such as:
11702+ *
11703+ * if (i8 .gt. 0)
11704+ *
11705+ * gives rise to ILIs such as:
11706+ *
11707+ * 49 QJSR 342~<__mth_i_kcmpz> 48^
11708+ * 50 DFRIR 49^ ir( 1)
11709+ * 51 ICMPZ 50^ gt
11710+ * 52 KCMPZ 47^ gt 51^-alt
11711+ *
11712+ * The solution for now is to check whether any operand of 'altx'
11713+ * is a define ILI.
11714+ *
11715+ * This deals with the cases that we're currently aware of, but if
11716+ * a situation arises in which the define ILI is more deeply
11717+ * nested in 'altx's ILI tree then we'll have to implement a
11718+ * complete fix, e.g. by calling 'qjsr_in()'. Note, if this
11719+ * function fails to detect a QJSR ILI that is present in 'altx's
11720+ * ILI tree then the x86 native CG may indicate this by generating
11721+ * the warning ICE "gen_lilis: BIH_QJSR needs to be set for bih
11722+ * <bih_number>".
11723+ */
11724+ noprs = IL_OPRS (opc );
11725+ for (j = 1 ; j <= noprs ; ++ j ) {
11726+ if (IL_ISLINK (opc , j ) &&
11727+ IL_TYPE (ILI_OPC (ILI_OPND (altx , j ))) == ILTY_DEFINE ) {
11728+ return 1 ;
1172011729 }
1172111730 }
1172211731 }
11732+
1172311733 switch (ILI_OPC (ilix )) {
1172411734 case IL_FSINCOS :
1172511735 case IL_DSINCOS :
1172611736 return 1 ;
1172711737 }
1172811738 return 0 ;
11729- }
11739+ } /* end alt_qjsr(int ilix) */
1173011740
1173111741/** \brief Look for 'QJSR' in this tree
1173211742 */
0 commit comments