[parisc-linux] g++ (3.3): ...Error: Field out of range

[parisc-linux] g++ (3.3): ...Error: Field out of range

[Joel Soete]

Hi Dave,

Some month ago we already spook about a similar pb (<http://lists.parisc-linux.org/pipermail/parisc-linux/2003-January/018938.html>)
but that was an ld pb and now it is an "Assembler" pb:

 g3.3 -DHAVE_CONFIG_H -I. -I/CAD/OpenCascade/src/OCC/OCC/src/TKFillet -I../..
-I/CAD/OpenCascade/src/OCC/OCC/inc -I/CAD/OpenCascade/src/OCC/OCC/drv/ChFiDS
-I/CAD/OpenCascade/src/OCC/OCC/drv/ChFi2d -I/CAD/OpenCascade/src/OCC/OCC/drv/ChFi3d
-I/CAD/OpenCascade/src/OCC/OCC/drv/ChFiKPart -I/CAD/OpenCascade/src/OCC/OCC/drv/Blend
-I/CAD/OpenCascade/src/OCC/OCC/drv/BRepBlend -I/CAD/OpenCascade/src/OCC/OCC/drv/BlendFunc
-I/CAD/OpenCascade/src/OCC/OCC/drv/BRepFilletAPI -I/CAD/OpenCascade/src/OCC/OCC/drv/FilletSurf
-g -O2 -DCSFDB -MT ChFi3d_Builder_CnCrn.lo -MD -MP -MF .deps/ChFi3d_Builder_CnCrn.Tpo
-c /CAD/OpenCascade/src/OCC/OCC/src/ChFi3d/ChFi3d_Builder_CnCrn.cxx  -fPIC
-DPIC -o .libs/ChFi3d_Builder_CnCrn.o
/tmp/ccQuyyIf.s: Assembler messages:
/tmp/ccQuyyIf.s:146240: Error: Field out of range [-262144..262143] (-290528).
make[3]: *** [ChFi3d_Builder_CnCrn.lo] Error 1
make[3]: Leaving directory `/CAD/OpenCascade/build-40/src/TKFillet'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/CAD/OpenCascade/build-40/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/CAD/OpenCascade/build-40'
make: *** [all] Error 2

palx2000:/CAD/OpenCascade/build-40# dpkg -l g3.3
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ Name                    Version                 Description
=======================-=======================-==============================================================
ii  g3.3                 3.3-3                   The GNU C compiler

This occurs as well with binutils 2.13.90.0.18-1.7 as with 2.14.90.0.4-0.1.

OTC according gcc br 10274 (<http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10274>)
which I filled in because of a ICE (in its time), binutils 2.13.2.1 would
solved this pb (but unfortunately not debian available). What should I do
more to help to fix this?

Thanks in advance,
    Joel

---------------------------------
Découvrez les 6 clés et gagnez le Club Med à Vie avec Tiscali
http://www.tiscali.be/nl/subs/tiscali4life/default.asp?lang=fr

[parisc-linux] Re: g++ (3.3): ...Error: Field out of range

[John David Anglin]

Hi Joel,

>  g3.3 -DHAVE_CONFIG_H -I. -I/CAD/OpenCascade/src/OCC/OCC/src/TKFillet -I../..
> -I/CAD/OpenCascade/src/OCC/OCC/inc -I/CAD/OpenCascade/src/OCC/OCC/drv/ChFiDS
> -I/CAD/OpenCascade/src/OCC/OCC/drv/ChFi2d -I/CAD/OpenCascade/src/OCC/OCC/drv/ChFi3d
> -I/CAD/OpenCascade/src/OCC/OCC/drv/ChFiKPart -I/CAD/OpenCascade/src/OCC/OCC/drv/Blend
> -I/CAD/OpenCascade/src/OCC/OCC/drv/BRepBlend -I/CAD/OpenCascade/src/OCC/OCC/drv/BlendFunc
> -I/CAD/OpenCascade/src/OCC/OCC/drv/BRepFilletAPI -I/CAD/OpenCascade/src/OCC/OCC/drv/FilletSurf
> -g -O2 -DCSFDB -MT ChFi3d_Builder_CnCrn.lo -MD -MP -MF .deps/ChFi3d_Builder_CnCrn.Tpo
> -c /CAD/OpenCascade/src/OCC/OCC/src/ChFi3d/ChFi3d_Builder_CnCrn.cxx  -fPIC
> -DPIC -o .libs/ChFi3d_Builder_CnCrn.o
> /tmp/ccQuyyIf.s: Assembler messages:
> /tmp/ccQuyyIf.s:146240: Error: Field out of range [-262144..262143] (-290528).
> make[3]: *** [ChFi3d_Builder_CnCrn.lo] Error 1
> make[3]: Leaving directory `/CAD/OpenCascade/build-40/src/TKFillet'
> make[2]: *** [all-recursive] Error 1
> make[2]: Leaving directory `/CAD/OpenCascade/build-40/src'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory `/CAD/OpenCascade/build-40'
> make: *** [all] Error 2
> 
> palx2000:/CAD/OpenCascade/build-40# dpkg -l g3.3
> Desired=Unknown/Install/Remove/Purge/Hold
> | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
> |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
> ||/ Name                    Version                 Description
> =======================-=======================-==============================================================
> ii  g3.3                 3.3-3                   The GNU C compiler
> 
> This occurs as well with binutils 2.13.90.0.18-1.7 as with 2.14.90.0.4-0.1.
> 
> OTC according gcc br 10274 (<http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10274>)
> which I filled in because of a ICE (in its time), binutils 2.13.2.1 would
> solved this pb (but unfortunately not debian available). What should I do
> more to help to fix this?

You could try assembling with the current cvs version of binutils.  You
can generate an assembler file by changing `-c' to `-S' and the output
file name in the above command.  This will allow you to look at the
assembler line in question and see whether this is a problem with stubs
or not (i.e., something other than a branch to a function).  As this is
C++ code, there might be a huge number of small functions causing overflow
of the stub table.

The stub table fix was done quite sometime ago and I would have thought
that recent debian versions of binutils would have it.

If this is not a stub table overflow problem, please file a gcc PR
including the preprocessed source from the above command.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

[parisc-linux] Re: g++ (3.3): ...Error: Field out of range

[Joel Soete]

Hi Dave,

Shame on me: I forgot to test with different compression option.

I just do it and the problem doesn't occure any more without -O2 or with
-O1?


> You could try assembling with the current cvs version of binutils.  You
> can generate an assembler file by changing `-c' to `-S' and the output
> file name in the above command.  This will allow you to look at the
> assembler line in question and see whether this is a problem with stubs
> or not (i.e., something other than a branch to a function).  As this is
> C++ code, there might be a huge number of small functions causing overflow
> of the stub table.
> 
> The stub table fix was done quite sometime ago and I would have thought
> that recent debian versions of binutils would have it.
> 
> If this is not a stub table overflow problem, please file a gcc PR
> including the preprocessed source from the above command.

Never the less I will try to rebuild cvs binutils then check if the pb continue.

See you later,
    Joel


---------------------------------
Tiscali ADSL: 19,50 euros/mois...abonnez-vous sur www.tiscali.be

Re: [parisc-linux] Re: g++ (3.3): ...Error: Field out of range

[John David Anglin]

> Shame on me: I forgot to test with different compression option.
> 
> I just do it and the problem doesn't occure any more without -O2 or with
> -O1?

The optimization level affects inlining and as a result the size of
functions.  There has been a lot of discussion on the gcc lists related
to problems with inlining with the new tree inliner in 3.3, particularly
in C++ code.  So, the problem should be looked at even if there is a
work around.  The first step is to determine whether this is a gcc or
binutils problem (i.e., we need to know if the size of the stub table
has overflowed or if gcc has miscalculated an offset).

It would be a big help if you would generate the preprocessed source
code using the exact command that fails except for changing `-c' to `-E',
and then submit it in a gcc bug report describing the failure.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Re: [parisc-linux] Re: g++ (3.3): ...Error: Field out of range

[Joel Soete]

Hi Dave,

Sorry for delay (even with my speedy b2k, it takes some time for optimizing
this stuff :-) ).

> The optimization level affects inlining and as a result the size of
> functions.  There has been a lot of discussion on the gcc lists related
> to problems with inlining with the new tree inliner in 3.3, particularly
> in C++ code.  So, the problem should be looked at even if there is a
> work around.  The first step is to determine whether this is gcc or
> binutils problem (i.e., we need to know if the size of the stub table
> has overflowed or if gcc has miscalculated an offset).

Finaly, here we are:

a) The same bad result with -O2 and today cvs binutils :-(
# as --version

GNU assembler 2.14.90 20030618
Copyright 2002 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License.  This program has absolutely no warranty.
This assembler was configured for a target of `hppa-linux'.

# as -o t.o ChFi3d_Builder_CnCrn.s-O2
ChFi3d_Builder_CnCrn.s-O2: Assembler messages:
ChFi3d_Builder_CnCrn.s-O2:146240: Error: Field out of range [-262144..262143]
(-290528).

b) the pre-asm around line 146240:
[...]
 146234 .LBB15456:   
 146235         copy %r4,%r19
 146236         ldo 7216(%r22),%r22
 146237         addl %r22,%r30,%r22
 146238 .LBE15456:
 146239         ftest
 146240         b .L6999
 146241         stw %r23,0(%r22)
 146242         stw %r0,0(%r22)
 146243         stw %r1,-12(%r30)
 146244         bl .+8,%r1
 146245         addil L'.L6999-$PIC_pcrel$0+4,%r1  
 146246         ldo R'.L6999-$PIC_pcrel$0+8(%r1),%r1
 146247         bv %r0(%r1)
 146248         ldw -12(%r30),%r1
 146249 .L7131:

[...]

(iirc b .L6999 means branch _b_ack to label .L6999 
if yes here is also text around this location:
[...]

  29378 .L6999:
  29379         .loc 1 1000 0   
  29380         ldil L'-16384,%r20
  29381         .loc 1 1001 0
  29382         ldil L'-16384,%r22
  29383         .loc 1 1000 0
  29384         ldo 7208(%r20),%r20
  29385         .loc 1 1001 0
  29386         ldil L'-16384,%r23
  29387         .loc 1 1000 0
  29388         addl %r20,%r30,%r20
  29389         .loc 1 1001 0
  29390         ldo 6308(%r22),%r22
  29391         .loc 1 1000 0
  29392         ldw 0(%r20),%r20
  29393 .LBE4386:
[...])

It is well a stub table pb?

If not I will procede next step tomorrow :-)

Thanks again for your attention and patience,
    Joel


---------------------------------
Tiscali ADSL: 19,50 euros/mois...abonnez-vous sur www.tiscali.be

Re: [parisc-linux] Re: g++ (3.3): ...Error: Field out of range

[John David Anglin]

> It is well a stub table pb?

No, this is a gcc pb.  Please proceed with a PR.  I can see the
problem.  There isn't support for long floating-point branches
in the machine definition :(

I would suggest that the code being generated for this
function isn't going to be very good.  Whenever at function
exceeds 240KB in size, then GCC needs to generate long branches
for function calls and some internal branches.  These sequences
are much longer and less efficient.  You can tweak the parameters
of the GCC's inlining model and probably reduce the size of
the generated code.  The parameters are settable from the
command line and are documented in the manual, etc.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Re: [parisc-linux] Re: g++ (3.3): ...Error: Field out of range

[Joel Soete]

Hi Dave,
>
>> It is well a stub table pb?

> No, this is a gcc pb.  Please proceed with a PR.  I can see the
> problem.  There isn't support for long floating-point branches
> in the machine definition :(
>

I am on going to prepare (btw would that I make you or p-l ml list in CC
of the PR?)

> I would suggest that the code being generated for this fuction
> isn't going to be very good.  Whenever at function
> exceeds 240KB in size, then GCC needs to generate long branches
> for function calls and some internal branches.  These sequences
> are much longer and less efficient.  You can tweak the parameter
> of the GCC's inlining model and probably reduce the size of
> the generated code.  The parameters are settable from the
> command line and are documented in the manual, etc.

hmm I found well severall cmd line parameter concerning inline stuff and
I was first tempted to test
-finline-limit=225000 (doesn't help)
-finline-limit=120000 (doesn't help more)
too bad :-(

and no more help with -fno-implicit-templates and/or -fno-implicit-inline-templates.

The only help is -fno-default-inline (i suppose that -fno-inline also) but
seems to me a bit like -O1.

Thanks again,
    Joel


---------------------------------
Tiscali ADSL: 19,50 euros/mois...abonnez-vous sur www.tiscali.be

Re: [parisc-linux] Re: g++ (3.3): ...Error: Field out of range

[John David Anglin]

Hi Joel,

Putting me on the CC list of the PR would be appreciated.

> > I would suggest that the code being generated for this fuction
> > isn't going to be very good.  Whenever at function
> > exceeds 240KB in size, then GCC needs to generate long branches
> > for function calls and some internal branches.  These sequences
> > are much longer and less efficient.  You can tweak the parameter
> > of the GCC's inlining model and probably reduce the size of
> > the generated code.  The parameters are settable from the
> > command line and are documented in the manual, etc.
> 
> hmm I found well severall cmd line parameter concerning inline stuff and
> I was first tempted to test
> -finline-limit=225000 (doesn't help)
> -finline-limit=120000 (doesn't help more)
> too bad :-(

These are the options that provide detailed control for inlining:

  --param max-inline-insns-rtl=<value> The maximum number of instructions for the RTL inliner
  --param min-inline-insns=<value>     The number of instructions in a single functions still eligible to inlining after a lot recursive inlining
  --param max-inline-slope=<value>     The slope of the linear function throttling inlining after the recursive inlining limit has been reached is given by the negative reciprocal value of this parameter
  --param max-inline-insns=<value>     The maximum number of instructions by repeated inlining before gcc starts to throttle inlining
  --param max-inline-insns-auto=<value> The maximum number of instructions when automatically inlining
  --param max-inline-insns-single=<value> The maximum number of instructions in a single function eligible for inlining

The RTL is not used by C or C++ anymore.  Look in the GCC file params.def
for the defaults and discussion.  I think reducing PARAM_MAX_INLINE_INSNS
from its default of 600 to something in the range of 200-300, or less will
help.  You might also make the slope more aggressive.  I know that changes
are needed to build LyX (see <http://gcc.gnu.org/PR?10160>).

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Re: [parisc-linux] Re: g++ (3.3): ...Error: Field out of range

[Joel Soete]

Hey Dave,

> Putting me on the CC list of the PR would be appreciated.

May be have you already recieved this:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11254


[...]
> These are the options that provide detailed control for inlining:
>
>   --param max-inline-insns-rtl=<value> The maximum number of instructions
for
> the RTL inliner
>   --param min-inline-insns=<value>     The number of instructions in a
single
> functions still eligible to inlining after a lot recursive inlining
>   --param max-inline-slope=<value>     The slope of the linear function

> throttling inlining after the recursive inlining limit has been reached
is 
> given by the negative reciprocal value of this parameter
>   --param max-inline-insns=<value>     The maximum number of instructions
by
>  repeated inlining before gcc starts to throttle inlining
>   --param max-inline-insns-auto=<value> The maximum number of instructions
>  when automatically inlining
>   --param max-inline-insns-single=<value> The maximum number of instructions
>  in a single function eligible for inlining

> The RTL is not used by C or C++ anymore.  Look in the GCC file params.def
> for the defaults and discussion.  I think reducing PARAM_MAX_INLINE_INSNS
> from its default of 600 to something in the range of 200-300, or less will
> help.  You might also make the slope more aggressive.  I know that changes
> are needed to build LyX (see <http://gcc/gnu.org/PR?10160>).

Ah, in fact I well read it also but do not figure out because of man comment:
"max-inline-insns
    If an function contains more than this many instructions, it
    will not be inlined.  This option is precisely equivalent to
    -finline-limit.
"

Anyway, I try 300, 200, 100 and stop at 50 without any more success :-(
(I can still try lower?)

Thanks again for all,
    Joel


---------------------------------
Tiscali ADSL: 19,50 euros/mois...abonnez-vous sur www.tiscali.be

Re: [parisc-linux] Re: g++ (3.3): ...Error: Field out of range

[John David Anglin]

> Ah, in fact I well read it also but do not figure out because of man comment:
> "max-inline-insns
>     If an function contains more than this many instructions, it
>     will not be inlined.  This option is precisely equivalent to
>     -finline-limit.
> "
> 
> Anyway, I try 300, 200, 100 and stop at 50 without any more success :-(
> (I can still try lower?)

Actually, I see that the `val' from -finline-limit sets the parameters
as follows in 3.4:

      set_param_value ("max-inline-insns", val);
      set_param_value ("max-inline-insns-single", val/2);
      set_param_value ("max-inline-insns-auto", val/2);
      set_param_value ("max-inline-insns-rtl", val);
      if (val/4 < MIN_INLINE_INSNS)
	{
	  if (val/4 > 10)
	    set_param_value ("min-inline-insns", val/4);
	  else
	    set_param_value ("min-inline-insns", 10);
	}

You might also try -fno-default-inline and -fno-inline, but it's
looking as if inlining isn't the driving factor in the size of
the routine.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Re: [parisc-linux] Re: g++ (3.3): ...Error: Field out of range

[Joel Soete]

Hello Dave,

> > Ah, in fact I well read it also but do not figure out because of man
comment:
> > "max-inline-insns
> >    If an function contains more than this many instructions, it
> >    will not be inlined.  This option is precisely equivalent to
> >    -finline limit.
> > "
> >
> > Anyway, I try 300, 200, 100 and stop at 50 without any more success :-(
> > (I can still try lower?)
>

Could it be different in 3.3? I try with 5 and no success but...

> Actually, I see that the `val' from -finline-limit sets the parameters
> as follows in 3.4:
>
>       set_param_value ("max-inline-insns", val);
>       set_param_value ("max-inline-insns-single", val/2);
>       set_param_value ("max-inline-insns-auto", val/2);
>       set_param_value ("max-inline-insns-rtl", val);
>       if (val/4 < MIN_INLINE_INSNS)
>	{
> 	  if (val/4 > 10)
>	    set param_value ("min-inline-insns", val/4);
> 	  else
> 	    set_param_value ("min-inline-insns", 10);
> 	}
>
> You might also try -fno-default-inline and -fno-inline, but it's
> looking as if inlining isn't the driving factor in the size of
> the routine.

Yes the inlining is one factor:

The first works (see <http://lists.parisc-linux.org/pipermail/parisc-linux/2003-June/020202.html>
;) and certainly the second too;

but also a better news:
(I definitely need to clean my glasses: in man default -finline-limit=600)

and it so works with -finline-limit= something between 350 (works) and 400
(failled). Now I am curious to see the differences between --param and this
-finline-limit (if i have some time)?

Thanks for all,
    Joel

ps: sorry to report so late but my wife was angry because test was too long

---------------------------------
Tiscali ADSL: 19,50 euros/mois...abonnez-vous sur www.tiscali.be

Re: [parisc-linux] Re: g++ (3.3): ...Error: Field out of range

[Joel Soete]

Hello again Dave,

> > Ah, in fact I well read it also but do not figure out because of man
comment:
> > "max-inline-insns
> >    If an function contains more than this many instructions, it
> >    will not be inlined.  This option is precisely equival
>nt to
> >    -finline limit.
> > "
> >
> > Anyway, I try 300, 200, 100 and stop at 50 without any more success :-(
> > (I can still try lower?)
>

Could it be different in 3.3? I try with 5 and no success but...

> Actually, I see that the `v
>l' from -finline-limit sets the parameters
> as follows in 3.4:
>
>       set_param_value ("max-inline-insns", val);
>       set_param_value ("max-inline-insns-single", val/2);
>       set_param_value ("max-inline-insns-auto", val/2);
>       set
>param_value ("max-inline-insns-rtl", val);
>       if (val/4 < MIN_INLINE_INSNS)
>	{
> 	  if (val/4 > 10)
>	    set param_value ("min-inline-insns", val/4);
> 	  else
> 	    set_param_value ("min-inline-insns", 10);
> 	}
>
> You might also try
>-fno-default-inline and -fno-inline, but it's
> looking as if inlining isn't the driving factor in the size of
> the routine.

Yes the inlining is one factor:

The first works (see <http://lists.parisc-linux.org/pipermail/parisc-linux/2003-June/0
>0202.html>
;) and certainly the second too;

but also a better news:
(I definitely need to clean my glasses: in man default -finline-limit=600)

and it so works with -finline-limit= something between 350 (works) and 400
(failled). Now I am curio
>s to see the differences between --param and this
-finline-limit (if i have some time)?

===

Sorry to reply to myself but I continue my test and reading again gcc man
(well all gcc-3.0, -3.2 and -3.3 are installed on this box and I would also
have to prefer to read man -l /usr/share/man/man1/gcc-3.3.1.gz).

And also re-reading <http://gcc.gnu.org/PR?10160> 

--param max-inline-insns=180 ... 5 # :( it fails
but otc
--param max-inline-insns-single=180 # ;) it works also (even if compile time
is
long versus -finline-limit=300) 

So looks like very much PR=10160 excepted that here it is not only a performance
pb but also a failure of compilation.


Thanks for you understand,
    Joel

ps: sorry also for bad quoting (pb with isp webmail)


---------------------------------
Tiscali ADSL: 19,50 euros/mois...abonnez-vous sur www.tiscali.be