gcc 4.4.0 error at postreload.c:396

gcc 4.4.0 error at postreload.c:396

[Bernd Roesch]

Hi,

I search gcc ML and find this.

http://gcc.gnu.org/ml/gcc/2009-05/msg00413.html

but here i have source with no 64 bit CPU.
is the fix now in and should i test current gcc4.4 ?

I also like to know if there is possible to build a gcc with better error
messages ?
It show as error place last bracket of the function.

Get a report of GCC 4.4.0 internal compiler error.happen on the last
bracket of the function.see --> mark
he report that GCC 4.3.2 work ok with same source.

the source is in ffmpeg package and gcc4.4.0 (release)run on cygwin.
A preprocessed source i do not have, hope this can help and somebody can
tell me what problem can be or how get more precise info about problem.

Here is output:

$ make_68k_v4
/bin/ffmpeg8/version.sh "/bin/ffmpeg8" version.h
/usr/local/amiga/bin/m68k-amigaos-gcc-4.4.0.exe -V 4.4.0 
-DHAVE_AV_CONFIG_H -I.
-I"/bin/ffmpeg8" -mnobitfield -m68060 -std=c99  
-Wdeclaration-after-statement -W
disabled-optimization -fno-math-errno -D_ISOC99_SOURCE 
-D_POSIX_C_SOURCE=200112
-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -fno-common 
-fomit-frame-pointer -Wal
l -Wno-switch -Wpointer-arith -Wredundant-decls -Wcast-qual 
-Wwrite-strings -Wun
def -O3          -c -o libavcodec/mpegvideo.o libavcodec/mpegvideo.c
libavcodec/mpegvideo.c: In function 'init_rl':
libavcodec/mpegvideo.c:760: warning: pointer targets in assignment 
differ in sig
nedness
libavcodec/mpegvideo.c:765: warning: pointer targets in assignment 
differ in sig
nedness
libavcodec/mpegvideo.c: In function 'MPV_motion_lowres':
libavcodec/mpegvideo.c:1707: error: insn does not satisfy its constraints:
(insn 937 3765 3766 59 libavcodec/mpegvideo.c:1488 (set (reg:SI 0 d0 
[931])
        (plus:SI (mem/f:SI (reg:SI 9 a1) [7 S4 A16])
            (reg:SI 0 d0 [931]))) 131 {*addsi3_internal} (nil))
libavcodec/mpegvideo.c:1707: internal compiler error: in 
reload_cse_simplify_ope
rands, at postreload.c:396
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

GCC 4.3.2 don't have this error - compiles "mpegvideo.c" file without 
problems.

Regards

static inline void MPV_motion_lowres(MpegEncContext *s,
                              uint8_t *dest_y, uint8_t *dest_cb, uint8_t
*dest_cr,
                              int dir, uint8_t **ref_picture,
                              h264_chroma_mc_func *pix_op)
{
    int mx, my;
    int mb_x, mb_y, i;
    const int lowres= s->avctx->lowres;
    const int block_s= 8>>lowres;

    mb_x = s->mb_x;
    mb_y = s->mb_y;

    switch(s->mv_type) {
    case MV_TYPE_16X16:
        mpeg_motion_lowres(s, dest_y, dest_cb, dest_cr,
                    0, 0, 0,
                    ref_picture, pix_op,
                    s->mv[dir][0][0], s->mv[dir][0][1], 2*block_s);
        break;
    case MV_TYPE_8X8:
        mx = 0;
        my = 0;
            for(i=0;i<4;i++) {
                hpel_motion_lowres(s, dest_y + ((i & 1) + (i >> 1) *
s->linesize)*block_s,
                            ref_picture[0], 0, 0,
                            (2*mb_x + (i & 1))*block_s, (2*mb_y + (i
>>1))*block_s,
                            s->width, s->height, s->linesize,
                            s->h_edge_pos >> lowres, s->v_edge_pos >>
lowres,
                            block_s, block_s, pix_op,
                            s->mv[dir][i][0], s->mv[dir][i][1]);

                mx += s->mv[dir][i][0];
                my += s->mv[dir][i][1];
            }

        if(!CONFIG_GRAY || !(s->flags&CODEC_FLAG_GRAY))
            chroma_4mv_motion_lowres(s, dest_cb, dest_cr, ref_picture,
pix_op, mx, my);
        break;
    case MV_TYPE_FIELD:
        if (s->picture_structure == PICT_FRAME) {
            /* top field */
            mpeg_motion_lowres(s, dest_y, dest_cb, dest_cr,
                        1, 0, s->field_select[dir][0],
                        ref_picture, pix_op,
                        s->mv[dir][0][0], s->mv[dir][0][1], block_s);
            /* bottom field */
            mpeg_motion_lowres(s, dest_y, dest_cb, dest_cr,
                        1, 1, s->field_select[dir][1],
                        ref_picture, pix_op,
                        s->mv[dir][1][0], s->mv[dir][1][1], block_s);
        } else {
            if(s->picture_structure != s->field_select[dir][0] + 1 &&
s->pict_type != FF_B_TYPE && !s->first_field){
                ref_picture= s->current_picture_ptr->data;
            }

            mpeg_motion_lowres(s, dest_y, dest_cb, dest_cr,
                        0, 0, s->field_select[dir][0],
                        ref_picture, pix_op,
                        s->mv[dir][0][0], s->mv[dir][0][1], 2*block_s);
        }
        break;
    case MV_TYPE_16X8:
        for(i=0; i<2; i++){
            uint8_t ** ref2picture;

            if(s->picture_structure == s->field_select[dir][i] + 1 ||
s->pict_type == FF_B_TYPE || s->first_field){
                ref2picture= ref_picture;
            }else{
                ref2picture= s->current_picture_ptr->data;
            }

            mpeg_motion_lowres(s, dest_y, dest_cb, dest_cr,
                        0, 0, s->field_select[dir][i],
                        ref2picture, pix_op,
                        s->mv[dir][i][0], s->mv[dir][i][1] + 2*block_s*i,
block_s);

            dest_y += 2*block_s*s->linesize;
            dest_cb+= (2*block_s>>s->chroma_y_shift)*s->uvlinesize;
            dest_cr+= (2*block_s>>s->chroma_y_shift)*s->uvlinesize;
        }
        break;
    case MV_TYPE_DMV:
        if(s->picture_structure == PICT_FRAME){
            for(i=0; i<2; i++){
                int j;
                for(j=0; j<2; j++){
                    mpeg_motion_lowres(s, dest_y, dest_cb, dest_cr,
                                1, j, j^i,
                                ref_picture, pix_op,
                                s->mv[dir][2*i + j][0], s->mv[dir][2*i +
j][1], block_s);
                }
                pix_op = s->dsp.avg_h264_chroma_pixels_tab;
            }
        }else{
            for(i=0; i<2; i++){
                mpeg_motion_lowres(s, dest_y, dest_cb, dest_cr,
                            0, 0, s->picture_structure != i+1,
                            ref_picture, pix_op,
                           
s->mv[dir][2*i][0],s->mv[dir][2*i][1],2*block_s);

                // after put we make avg of the same block
                pix_op = s->dsp.avg_h264_chroma_pixels_tab;

                //opposite parity is always in the same frame if this is
second field
                if(!s->first_field){
                    ref_picture = s->current_picture_ptr->data;
                }
            }
        }
    break;
    default: assert(0);
    }
-->}


-------------------------------


----------------------------------------------------
19 Miêdzynarodowy Festiwal Teatralny MALTA, Poznañ 23-27/06. 
W programie m.in. 
Nine Inch Nails i Jane's Addiction z Peaches. 
Szczegó³y na
http://klik.wp.pl/?adr=http%3A%2F%2Fcorto.www.wp.pl%2Fas%2Fnin.html&sid=753


*** End of forwarded message ***

Bye

Re: gcc 4.4.0 error at postreload.c:396

[Paolo Bonzini]

Bernd Roesch wrote:
> Hi,
> 
> I search gcc ML and find this.
> 
> http://gcc.gnu.org/ml/gcc/2009-05/msg00413.html
> 
> but here i have source with no 64 bit CPU.
> is the fix now in and should i test current gcc4.4 ?

The fix is machine-dependent (the message you quoted referred to the 
poster's proprietary port), so likely not.  Please create a bugzilla 
entry and CC me.  You will need a preprocessed file but it is easy to 
create one: just add --save-temps to the command line and you'll find 
that GCC now generates a mpegvideo.i file with the preprocessed sources.

> I also like to know if there is possible to build a gcc with better error
> messages ?
> It show as error place last bracket of the function.

Yes, it is not optimal.  For front-end errors, gcc 4.5.0 will have 
better positions.  For this kind of back-end error it is difficult to 
find a position because anyway the error depends on all the 
optimizations done so far, and it is only remotely connected to the 
source code.

Paolo

-funswitch-loops slowdown.is it possible to change settings in backend ?

[Bernd Roesch]

Hello 

The -funswitch-loops Option seem work on gcc 4.3.0 and above not good for
speed.Test on m68k gcc.

It generate much larger code(wma123) and code is slower in many case (try
out ffmpeg H264 decode)i get report from a Athlon 2600+ with single channel
ram
running amiga 68k emulator.

But on my System use a AMD64 3000+ and Dual Channel ram running amiga
emulator
-funswitch-loops cause only large files but no slowdown.

but i guess on a real 68k/coldfire CPU without 2. level cache,
-funswitch-loops is more
not optimal.
gcc 3.4.0 have too this option set on -O3 or i am wrong ?
and here the speed is better and code is smaller

Is there a way to tweak some values on backend for specific CPU so
-funswitch-loops works 3.4.0(maybe unroll not so much loops ?

for now best solution for speed (H264 decode work on the system with single
Channel ram same ot little faster as 3.4.0 build.) is let disable
-funswitch-loops disable as far i get speedvalue reports. 

here are some values that show too slowdown on compilers 4.2.4 and 4.3.0 but
on
X86

http://multimedia.cx/eggs/compiler-performance-profiling-with-ffmpeg/

Regards

-funswitch-loops slowdown.is it possible to change settings in backend ?

[Bernd Roesch]

Hello 

The -funswitch-loops Option seem work on gcc 4.3.0 and above not good for
speed.Test on m68k gcc.

It generate much larger code(wma123) and code is slower in many case (try
out ffmpeg H264 decode)i get report from a Athlon 2600+ with single channel
ram
running amiga 68k emulator.

But on my System use a AMD64 3000+ and Dual Channel ram running amiga
emulator
-funswitch-loops cause only large files but no slowdown.

but i guess on a real 68k/coldfire CPU without 2. level cache,
-funswitch-loops is more
not optimal.
gcc 3.4.0 have too this option set on -O3 or i am wrong ?
and here the speed is better and code is smaller

Is there a way to tweak some values on backend for specific CPU so
-funswitch-loops works 3.4.0(maybe unroll not so much loops ?

for now best solution for speed (H264 decode work on the system with single
Channel ram same ot little faster as 3.4.0 build.) is let disable
-funswitch-loops disable as far i get speedvalue reports. 

here are some values that show too slowdown on compilers 4.2.4 and 4.3.0 but
on
X86

http://multimedia.cx/eggs/compiler-performance-profiling-with-ffmpeg/

Regards