Re: PING: Patch: PR rtl-optimization/45865

["H.J. Lu" <hjl dot tools at gmail dot com>]

On Fri, Oct 8, 2010 at 11:43 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Fri, Oct 8, 2010 at 4:50 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
>> On Tue, Oct 5, 2010 at 7:46 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
>>> On Tue, Oct 5, 2010 at 6:12 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
>>>> On Sun, Oct 3, 2010 at 4:34 AM, Bernd Schmidt <bernds@codesourcery.com> wrote:
>>>>> On 10/02/2010 03:07 PM, H.J. Lu wrote:
>>>>>> On Wed, Aug 4, 2010 at 6:35 AM, Bernd Schmidt <bernds@codesourcery.com> wrote:
>>>>>>> On 08/03/2010 07:12 PM, Jeff Law wrote:
>>>>>>>> OK. ?WRT the comment, we might want to just say that BB_MODIFIED is set
>>>>>>>> at the same time as a block is marked dirty, but is not cleared during a
>>>>>>>> df_analyze allowing a pass to update the DF information and still know
>>>>>>>> what blocks were modified.
>>>>>>>
>>>>>>> New patch below.
>>>>>>>
>>>>>>
>>>>>> This caused:
>>>>>>
>>>>>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45865
>>>>>
>>>>> This should fix it, refusing to move NOTE_EPILOGUE_BEGIN and anything
>>>>> beyond it.
>>>>>
>>>>> Bootstrapped and tested on i686-linux, ok?
>>>>>
>>>>
>>>> It still failed this testcase.
>>>>
>>>> --
>>>> H.J.
>>>> ---
>>>> [hjl@gnu-32 rrs]$ cat pr45865.c
>>>> typedef struct rtx_def *rtx;
>>>> enum machine_mode {
>>>> ?VOIDmode,
>>>> ?CCFPmode,
>>>> ?CCFPUmode,
>>>> ?MAX_MACHINE_MODE
>>>> };
>>>> enum mode_class {
>>>> ?MODE_CC,
>>>> ?MODE_FLOAT,
>>>> ?MODE_COMPLEX_FLOAT,
>>>> ?MODE_VECTOR_FLOAT
>>>> };
>>>> extern const enum mode_class mode_class[(int) MAX_MACHINE_MODE];
>>>> enum rtx_code {
>>>> ?UNKNOWN,
>>>> ?GEU,
>>>> ?ORDERED,
>>>> ?CONST_INT
>>>> };
>>>> struct rtx_def {
>>>> ?unsigned int code: 16;
>>>> ?unsigned int mode : 8;
>>>> };
>>>> extern enum rtx_code reverse_condition (enum rtx_code);
>>>> enum rtx_code
>>>> reversed_comparison_code_parts (enum rtx_code code, rtx insn, rtx arg0,
>>>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?rtx arg1)
>>>> {
>>>> ?enum machine_mode mode;
>>>> ?mode = (enum machine_mode) (arg0)->mode;
>>>> ?if (mode == VOIDmode)
>>>> ? ?mode = (enum machine_mode) (arg1)->mode;
>>>> ?if ((mode_class[(int) (mode)]) == MODE_CC)
>>>> ? ?return (mode != CCFPmode && mode != CCFPUmode
>>>> ? ? ? ? ? ?? reverse_condition (code)
>>>> ? ? ? ? ? ?: reverse_condition_maybe_unordered (code));
>>>> ?switch (code)
>>>> ? ?{
>>>> ? ?case GEU:
>>>> ? ? ?return reverse_condition (code);
>>>> ? ?case ORDERED:
>>>> ? ? ?return UNKNOWN;
>>>> ? ?}
>>>> ?if (((enum rtx_code) (arg0)->code) == CONST_INT
>>>> ? ? ?|| (((enum machine_mode) (arg0)->mode) != VOIDmode
>>>> ? ? ? ? ?&& ! ((mode_class[(int) (mode)]) == MODE_FLOAT
>>>> ? ? ? ? ? ? ? ?|| (mode_class[(int) (mode)]) == MODE_COMPLEX_FLOAT
>>>> ? ? ? ? ? ? ? ?|| (mode_class[(int) (mode)]) == MODE_VECTOR_FLOAT)))
>>>> ? ?return reverse_condition (code);
>>>> ?return UNKNOWN;
>>>> }
>>>> [hjl@gnu-32 rrs]$ /export/gnu/import/rrs/164914/usr/bin/gcc -O2 -S
>>>> -m32 pr45865.c
>>>> pr45865.c: In function \u2018reversed_comparison_code_parts\u2019:
>>>> pr45865.c:52:1: internal compiler error: in
>>>> dwarf2out_cfi_begin_epilogue, at dwarf2out.c:2930
>>>> Please submit a full bug report,
>>>> with preprocessed source if appropriate.
>>>> See <http://gcc.gnu.org/bugs.html> for instructions.
>>>> [hjl@gnu-32 rrs]$
>>>>
>>>
>>> One problem is:
>>>
>>> if (max_to == NULL_RTX || (fail && pmove_upto == NULL))
>>>
>>> When pmove_upto isn't NULL,*pmove_upto is initialized to NULL
>>> This patch works for me. ?OK for trunk?
>>>
>>> Thanks.
>>>
>>> --
>>> H.J.
>>> ---
>>> gcc/
>>>
>>> 2010-10-05 ?Bernd Schmidt ?<bernds@codesourcery.com>
>>> ? ? ? ? ? ?H.J. Lu ?<hongjiu.lu@intel.com>
>>>
>>> ? ? ? ? PR rtl-optimization/45865
>>> ? ? ? ? * df-problems.c (can_move_insns_across): Don't move
>>> ? ? ? ? NOTE_EPILOGUE_BEGIN and anything beyond it. ?Properly check
>>> ? ? ? ? pmove_upto.
>>>
>>> gcc/testsuite/
>>>
>>> 2010-10-05 ?H.J. Lu ?<hongjiu.lu@intel.com>
>>>
>>> ? ? ? ? PR rtl-optimization/45865
>>> ? ? ? ? * gcc.dg/torture/pr45865.c: New.
>>>
>
> On Linux/ia32, I got
>
> Bootstrap comparison failure!
> gcc/i386.o differs
> make[4]: *** [compare] Error 1
>
>

The difference is in ix86_get_builtin_type.


-- 
H.J.