[RFC] missing return warnings

[Jan Hubicka]

Hi,
I am looking into what parts of frontend stil depends on frontend inline
decision (ie DECL_INLINE now ignored by middle end).  All these uses
strike wrong, given that inlining decisions are independent on it.
These divergences for example requires us to enable expensive
-finline-functions for --profile-generate even though we really want it
only for --profile-use (where it is a lot cheaper given that profile
blocks unnecesary inlining).

For C++ there are number of cases I need to go through dealing with
attempts to not instantiate non-inline methods that won't be needed.
My plan is to make instantiation unconditional and measure effect on our
C++ benchmarks.
For C it seems to be single case for return warning:
/* PR c++/4872 */
/* { dg-do compile } */
/* { dg-options "-Wreturn-type" } */

static inline int f() {} /* { dg-warning "return" "missing return" } */

In this case we produce missing return warning from frontend. 
This however is not truly consistent - if I make the function used, we
actually get two warnings - one from frontend, one from middle end
(that is CFG aware and does not merely check for presence of return
statement in  function).  If I remove the inline keyword, we lose the
warning since C frontend does not expect that we can now optimize out
static functions for a while.

The code in question is:

Index: c-decl.c
===
*** c-decl.c(revision 128161)
--- c-decl.c(working copy)
*** finish_function (void)
*** 6752,6776 
  
finish_fname_decls ();
  
-   /* Complain if there's just no return statement.  */
-   if (warn_return_type
-   && TREE_CODE (TREE_TYPE (TREE_TYPE (fndecl))) != VOID_TYPE
-   && !current_function_returns_value && !current_function_returns_null
-   /* Don't complain if we are no-return.  */
-   && !current_function_returns_abnormally
-   /* Don't warn for main().  */
-   && !MAIN_NAME_P (DECL_NAME (fndecl))
-   /* Or if they didn't actually specify a return type.  */
-   && !C_FUNCTION_IMPLICIT_INT (fndecl)
-   /* Normally, with -Wreturn-type, flow will complain.  Unless we're an
-inline function, as we might never be compiled separately.  */
-   && DECL_INLINE (fndecl))
- {
-   warning (OPT_Wreturn_type,
-  "no return statement in function returning non-void");
-   TREE_NO_WARNING (fndecl) = 1;
- }
- 
/* Store the end of the function, so that we get good line number
   info for the epilogue.  */
cfun->function_end_locus = input_location;
--- 6725,6730 

I wonder what we want to do here - I guess we can either make the
warning unconditional and declare it as two indpendent things or we can
just drop the feature since user will get properly warned on every
function he actually uses.

What would be preferred solution here?

Similarly there is equivalent C++ frotned code.

Honza

Re: GCC "make" errors

[mandeep singh bhambra]

I have installed the latest binutils (2.9.1) available from the GNU ftp site so 
I cannot understand why this is occuring. Are there some sort of parameter 
options I need to enter or do I need to reinstall the binutils with parameter 
options?

Regards,

> - Original Message -
> From: "Richard Guenther" <[EMAIL PROTECTED]>
> To: "mandeep singh bhambra" <[EMAIL PROTECTED]>
> Subject: Re: GCC "make" errors
> Date: Wed, 5 Sep 2007 13:57:29 +0200
> 
> 
> On 9/5/07, mandeep singh bhambra <[EMAIL PROTECTED]> wrote:
> >
> > Hi,
> >
> > In response to the march options, I tried to use both
> > "-march=athlon-xp -g -O2" and "-march=i686 -g -O2" but it does not
> > like it. It still gives the error message about the 386 commands.
> >
> > When i use the ./configure command the march option is accepted as
> > part of using gcc as it displays the following:
> >
> > checking for gcc... (cached) gcc
> > checking whether the C compiler (gcc -march=athlon-xp -g -O2 ) works... yes
> > checking whether the C compiler (gcc -march=athlon-xp -g -O2 ) is a
> > cross-compiler... no
> > checking whether we are using GNU C... (cached) yes
> > checking whether gcc accepts -g... (cached) yes
> >
> > checking for gcc... (cached) gcc
> > checking whether the C compiler (gcc -march=i686 -g -O2 ) works... yes
> > checking whether the C compiler (gcc -march=i686 -g -O2 ) is a
> > cross-compiler... no
> > checking whether we are using GNU C... (cached) yes
> > checking whether gcc accepts -g... (cached) yes
> >
> > Can you please outline what I can do to eliminate the error message
> > or which version of binutils i can install.
> >
> > Thanks,
> >
> > Mani
> >
> > > > - Original Message -
> > > > From: "Tim Prince" <[EMAIL PROTECTED]>
> > > > To: [EMAIL PROTECTED]
> > > > Subject: Re: GCC "make" errors
> > > > Date: Fri, 10 Aug 2007 02:07:44 -0700
> > > >
> > > >
> > > > [EMAIL PROTECTED] wrote:
> > > > Hi,
> > > >
> > > > I wanted update my GCC compiler to 4.2.1 to install an updated
> > > > version of C libraries (glibc) and it is giving me errors while
> > > > it is making the build. I type ./configure which works fine but
> > > > when I type "make" it runs fine until it starts to give errors
> > > > which are as follows:
> > > >
> > > > /tmp/ccacyMlE.s: Assembler messages:
> > > > /tmp/ccacyMlE.s:72: Error: no such 386 instruction: `stmxcsr'
> > > > /tmp/ccacyMlE.s:90: Error: no such 386 instruction: `ldmxcsr'
> > > > /tmp/ccacyMlE.s:119: Error: no such 386 instruction: `fxsave'
> 
> Your binutils version is obviously too old.
> 
> Richard.

>


-- 
We've Got Your Name @ www.mail.com!!!
Get a FREE E-mail Account Today - Choose From 100+ Domains

Re: Someone has caused regressions in gfortran

[Jan Hubicka]

> > Sadly, the testsuite regressions don't seems to be fixed.  I will try to
> > figure out tomorrow why the function is still being inlined.
> 
> The test case gfortran.dg/do_3.F90 pass with -fno-strict-overflow
> (see http://gcc.gnu.org/ml/fortran/2007-09/msg00116.html).
> I have posted at http://gcc.gnu.org/ml/fortran/2007-09/msg00107.html
> a reduced test case without inlining issues showing a similar
> breakage.  If someone can show that before the recent failure
> the functions were not inlined, I think the failure would
> be fully explained. Otherwise it will require further investigation.

The testcase was indeed previously not inlined at all.  Shall we add
-fno-strict-overflow to the testcase then?

Honza
> 
> As far as I can tell without -fno-strict-overflow the executable
> reduces to a call abort at the level of 
> 
> if (i /= final) call abort
> 
> as if final = huge(to)+1_1 giving an overflow, the comparison is
> assuming to always fail.  I remember a lot of traffic on the gcc mailing
> list a couple months ago about this kind of optimization and the
> reasons behind -fno-strict-overflow, but I dont have the time right
> now to look deeper.
> 
> Dominique

Bootstrap failure under Irix

[Philippe Schaffnit]

Hi!

I am seeing the folowing bootstrap failure under SGI Irix:

bash /USER/philippe/Irix/Gcc_Sources/gcc/../move-if-change tmp-codes.h
insn-codes.h
echo timestamp > s-codes
gcc -c   -g -fkeep-inline-functions -DIN_GCC   -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition
-Wmissing-format-attribute -pedantic -Wno-long-long
-Wno-variadic-macros
-Wno-overlength-strings -fno-common   -DHAVE_CONFIG_H -I. -I.
-I/USER/philippe/Irix/Gcc_Sources/gcc
-I/USER/philippe/Irix/Gcc_Sources/gcc/.
-I/USER/philippe/Irix/Gcc_Sources/gcc/../include -I./../intl
-I/USER/philippe/Irix/Gcc_Sources/gcc/../libcpp/include
-I/USER/philippe/Irix/Gmp/include -I/USER/philippe/Irix/Mpfr/include
-I/USER/philippe/Irix/Gcc_Sources/gcc/../libdecnumber
-I/USER/philippe/Irix/Gcc_Sources/gcc/../libdecnumber/dpd
-I../libdecnumberinsn-emit.c -o insn-emit.o
/USER/philippe/Irix/Gcc_Sources/gcc/config/mips/mips.md: In function
'gen_fixuns_truncdfsi2':
/USER/philippe/Irix/Gcc_Sources/gcc/config/mips/mips.md:2808: error: too
few arguments to function 'real_2expN'
/USER/philippe/Irix/Gcc_Sources/gcc/config/mips/mips.md: In function
'gen_fixuns_truncdfdi2':
/USER/philippe/Irix/Gcc_Sources/gcc/config/mips/mips.md:2853: error: too
few arguments to function 'real_2expN'
/USER/philippe/Irix/Gcc_Sources/gcc/config/mips/mips.md: In function
'gen_fixuns_truncsfsi2':
/USER/philippe/Irix/Gcc_Sources/gcc/config/mips/mips.md:2895: error: too
few arguments to function 'real_2expN'
/USER/philippe/Irix/Gcc_Sources/gcc/config/mips/mips.md: In function
'gen_fixuns_truncsfdi2':
/USER/philippe/Irix/Gcc_Sources/gcc/config/mips/mips.md:2937: error: too
few arguments to function 'real_2expN'
make[3]: *** [insn-emit.o] Error 1
make[3]: Leaving directory `/USER/philippe/Irix/Compilation/Gcc/gcc'
make[2]: *** [all-stage1-gcc] Error 2
make[2]: Leaving directory `/USER/philippe/Irix/Compilation/Gcc'
make[1]: *** [stage1-bubble] Error 2
make[1]: Leaving directory `/USER/philippe/Irix/Compilation/Gcc'
make: *** [bootstrap] Error 2

My last attempt at wa succesful with : '4.3.0 20070823 (experimental)
[trunk revision 127728]' (I haven't tried in between). Can anyone
suggest anything?

Thanks!

Philippe

Re: Someone has caused regressions in gfortran

[Dominique Dhumieres]

> The testcase was indeed previously not inlined at all.  Shall we add
> -fno-strict-overflow to the testcase then?

This what I would do, but I am not qualified to make the call.
In addition my working setup is totally broken right now 
(at stage1). Could you do the addition to the testcase
and run the gfortran testsuite? From the result it would
be easier to reach a conclusion.

TIA

Dominique

Bootstrap broken: ../../gcc/gcc/ada/trans.c:5896: error: too few arguments to function `real_2expN'

[Christian Joensson]

Using checkout Thu Sep  6 05:56:16 UTC 2007 (revision 128174), I get a
bootstrap failure:

gcc -c   -g -fkeep-inline-functions -DIN_GCC   -W -Wall
-Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-DHAVE_CONFIG_H -I. -Iada -I../../gcc/gcc -I../../gcc/gcc/ada
-I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include
-I../../gcc/gcc/../libdecnumber -I../../gcc/gcc/../libdecnumber/dpd
-I../libdecnumber../../gcc/gcc/ada/trans.c -o ada/trans.o
../../gcc/gcc/ada/trans.c: In function `convert_with_check':
../../gcc/gcc/ada/trans.c:5896: error: too few arguments to function
`real_2expN'
make[3]: *** [ada/trans.o] Error 1
make[3]: Leaving directory `/usr/local/src/trunk/objdir/gcc'
make[2]: *** [all-stage1-gcc] Error 2
make[2]: Leaving directory `/usr/local/src/trunk/objdir'
make[1]: *** [stage1-bubble] Error 2
make[1]: Leaving directory `/usr/local/src/trunk/objdir'
make: *** [all] Error 2

-- 
Cheers,

/ChJ

Bootstrap failure under Linux

[Philippe Schaffnit]

Hi!

I am getting the following bootstrap failure under Linux (Linux pinguin7
2.6.5-7.104-bigsmp #1 SMP Wed Jul 28 16:42:13 UTC 2004 i686 i686 i386
GNU/Linux).

make[2]: Leaving directory `/usr1/MICRESS/Philippe/Compilation/Gcc'
make "DESTDIR=" "RPATH_ENVVAR=LD_LIBRARY_PATH"
"TARGET_SUBDIR=i686-pc-linux-gnu"
"bindir=/usr1/MICRESS/Philippe/Tools/Gcc/bin"
"datadir=/usr1/MICRESS/Philippe/Tools/Gcc/share"
"exec_prefix=/usr1/MICRESS/Philippe/Tools/Gcc"
"includedir=/usr1/MICRESS/Philippe/Tools/Gcc/include"
"datarootdir=/usr1/MICRESS/Philippe/Tools/Gcc/share"
"docdir=/usr1/MICRESS/Philippe/Tools/Gcc/share/doc"
"infodir=/usr1/MICRESS/Philippe/Tools/Gcc/info"
"pdfdir=/usr1/MICRESS/Philippe/Tools/Gcc/share/doc"
"htmldir=/usr1/MICRESS/Philippe/Tools/Gcc/yes"
"libdir=/usr1/MICRESS/Philippe/Tools/Gcc/lib"
"libexecdir=/usr1/MICRESS/Philippe/Tools/Gcc/libexec" "lispdir="
"localstatedir=/usr1/MICRESS/Philippe/Tools/Gcc/var"
"mandir=/usr1/MICRESS/Philippe/Tools/Gcc/man"
"oldincludedir=/usr/include" "prefix=/usr1/MICRESS/Philippe/Tools/Gcc"
"sbindir=/usr1/MICRESS/Philippe/Tools/Gcc/sbin"
"sharedstatedir=/usr1/MICRESS/Philippe/Tools/Gcc/com"
"sysconfdir=/usr1/MICRESS/Philippe/Tools/Gcc/etc"
"tooldir=/usr1/MICRESS/Philippe/Tools/Gcc/i686-pc-linux-gnu"
"build_tooldir=/usr1/MICRESS/Philippe/Tools/Gcc/i686-pc-linux-gnu"
"target_alias=i686-pc-linux-gnu" "BISON=bison" "CC_FOR_BUILD=gcc"
"CFLAGS_FOR_BUILD=-g -O2" "CXX_FOR_BUILD=g++" "EXPECT=expect"
"FLEX=flex" "INSTALL=/usr/bin/install -c" "INSTALL_DATA=/usr/bin/install
-c -m 644" "INSTALL_PROGRAM=/usr/bin/install -c"
"INSTALL_SCRIPT=/usr/bin/install -c" "LEX=flex" "M4=m4" "MAKE=make"
"RUNTEST=runtest" "RUNTESTFLAGS=" "SHELL=/bin/sh" "YACC=bison -y" "`echo
'ADAFLAGS=' | sed -e s'/[^=][^=]*=$/XFOO=/'`" "AR_FLAGS=rc" "`echo
'BOOT_ADAFLAGS=' | sed -e s'/[^=][^=]*=$/XFOO=/'`" "BOOT_CFLAGS=-g -O2
-fomit-frame-pointer" "BOOT_LDFLAGS=" "CFLAGS=-g -O2" "CXXFLAGS=-g -O2"
"LDFLAGS=" "LIBCFLAGS=-g -O2" "LIBCXXFLAGS=-g -O2
-fno-implicit-templates" "STAGE1_CFLAGS=-g -fkeep-inline-functions"
"STAGE1_CHECKING=--enable-checking=yes,types" "STAGE1_LANGUAGES=c"
"STAGE2_CFLAGS=-g -O2 -fomit-frame-pointer" "STAGE3_CFLAGS=-g -O2
-fomit-frame-pointer" "STAGE4_CFLAGS=-g -O2 -fomit-frame-pointer"
"GNATBIND=no" "GNATMAKE=no" "AR_FOR_TARGET=ar" "AS_FOR_TARGET=as"
"CC_FOR_TARGET=/usr1/MICRESS/Philippe/Compilation/Gcc/./gcc/xgcc
-B/usr1/MICRESS/Philippe/Compilation/Gcc/./gcc/
-B/usr1/MICRESS/Philippe/Tools/Gcc/i686-pc-linux-gnu/bin/
-B/usr1/MICRESS/Philippe/Tools/Gcc/i686-pc-linux-gnu/lib/ -isystem
/usr1/MICRESS/Philippe/Tools/Gcc/i686-pc-linux-gnu/include -isystem
/usr1/MICRESS/Philippe/Tools/Gcc/i686-pc-linux-gnu/sys-include"
"CFLAGS_FOR_TARGET=-O2 -g -O2  " "CPPFLAGS_FOR_TARGET="
"CXX_FOR_TARGET=g++
-B/usr1/MICRESS/Philippe/Tools/Gcc/i686-pc-linux-gnu/bin/
-B/usr1/MICRESS/Philippe/Tools/Gcc/i686-pc-linux-gnu/lib/ -isystem
/usr1/MICRESS/Philippe/Tools/Gcc/i686-pc-linux-gnu/include -isystem
/usr1/MICRESS/Philippe/Tools/Gcc/i686-pc-linux-gnu/sys-include"
"CXXFLAGS_FOR_TARGET=-g -O2   -D_GNU_SOURCE"
"DLLTOOL_FOR_TARGET=dlltool"
"GCJ_FOR_TARGET=-B/usr1/MICRESS/Philippe/Tools/Gcc/i686-pc-linux-gnu/bin/
-B/usr1/MICRESS/Philippe/Tools/Gcc/i686-pc-linux-gnu/lib/ -isystem
/usr1/MICRESS/Philippe/Tools/Gcc/i686-pc-linux-gnu/include -isystem
/usr1/MICRESS/Philippe/Tools/Gcc/i686-pc-linux-gnu/sys-include"
"GFORTRAN_FOR_TARGET=/usr1/MICRESS/Philippe/Compilation/Gcc/./gcc/gfortran
-B/usr1/MICRESS/Philippe/Compilation/Gcc/./gcc/
-B/usr1/MICRESS/Philippe/Tools/Gcc/i686-pc-linux-gnu/bin/
-B/usr1/MICRESS/Philippe/Tools/Gcc/i686-pc-linux-gnu/lib/ -isystem
/usr1/MICRESS/Philippe/Tools/Gcc/i686-pc-linux-gnu/include -isystem
/usr1/MICRESS/Philippe/Tools/Gcc/i686-pc-linux-gnu/sys-include"
"LD_FOR_TARGET=ld" "LIPO_FOR_TARGET=lipo" "LDFLAGS_FOR_TARGET="
"LIBCFLAGS_FOR_TARGET=-O2 -g -O2  " "LIBCXXFLAGS_FOR_TARGET=-g -O2  
-D_GNU_SOURCE -fno-implicit-templates" "NM_FOR_TARGET=nm"
"OBJDUMP_FOR_TARGET=objdump" "RANLIB_FOR_TARGET=ranlib"
"STRIP_FOR_TARGET=strip" "WINDRES_FOR_TARGET=windres"
"WINDMC_FOR_TARGET=windmc" "`echo 'LANGUAGES=' | sed -e
s'/[^=][^=]*=$/XFOO=/'`" "LEAN=false" "CONFIG_SHELL=/bin/sh"
"MAKEINFO=/WORK/BLUE1_USER/philippe/Irix/Gcc_Sources/missing makeinfo
--split-size=500 --split-size=500"  compare
make[2]: Entering directory `/usr1/MICRESS/Philippe/Compilation/Gcc'
make[3]: Entering directory `/usr1/MICRESS/Philippe/Compilation/Gcc'
rm -f stage_current
make[3]: Leaving directory `/usr1/MICRESS/Philippe/Compilation/Gcc'
Comparing stages 2 and 3
warning: ./cc1-checksum.o differs
Bootstrap comparison failure!
./cfgloopmanip.o differs
make[2]: *** [compare] Error 1
make[2]: Leaving directory `/usr1/MICRESS/Philippe/Compilation/Gcc'
make[1]: *** [stage3-bubble] Error 2
make[1]: Leaving directory `/usr1/MICRESS/Philippe/Compilation/Gcc'
make: *** [bootstrap] Error 2

Is anyone else seeing that?

Thanks!

Philippe

Re: GCC 4.3.0 Status Report (2007-09-04)

[Richard Guenther]

On 9/5/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> Summary
> ===
>
> We are closing in on Stage 3, previously announced for September 10th.
> At this point, I'm not aware of any reason to delay that date.  Are
> there any Stage 2 patches that people don't think will be submitted by
> that point?
>
> Are there Stage 1 or Stage 2 patches in need of review?  I'll do my best
> to either (a) convince someone to review them, or (b) review them myself.

There is

http://gcc.gnu.org/ml/gcc-patches/2007-08/msg01978.html

for example, which is not suitable for stage3.

Richard.

Re: GCC "make" errors

[Richard Guenther]

On 9/6/07, mandeep singh bhambra <[EMAIL PROTECTED]> wrote:
> I have installed the latest binutils (2.9.1) available from the GNU ftp site 
> so I cannot understand why this is occuring. Are there some sort of parameter 
> options I need to enter or do I need to reinstall the binutils with parameter 
> options?

2.9.1 is from the stone-age, 2.18 is current.

Richard.

Re: GCC 4.3.0 Status Report (2007-09-04)

[Paolo Bonzini]

There is

http://gcc.gnu.org/ml/gcc-patches/2007-08/msg01978.html

for example, which is not suitable for stage3.


As much as I like the idea, wasn't get_non_trapping considered unsafe?

Paolo

Re: GCC 4.3.0 Status Report (2007-09-04)

[Richard Guenther]

On 9/6/07, Paolo Bonzini <[EMAIL PROTECTED]> wrote:
>
> > There is
> >
> > http://gcc.gnu.org/ml/gcc-patches/2007-08/msg01978.html
> >
> > for example, which is not suitable for stage3.
>
> As much as I like the idea, wasn't get_non_trapping considered unsafe?

Only if you tried to preserve this information across passes.  This updated
patch computes this information just for the local transformation.

Richard.

Re: GCC 4.3.0 Status Report (2007-09-04)

[Manuel López-Ibáñez]

On 05/09/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> Summary
> ===
>
> We are closing in on Stage 3, previously announced for September 10th.
> At this point, I'm not aware of any reason to delay that date.  Are
> there any Stage 2 patches that people don't think will be submitted by
> that point?
>
> Are there Stage 1 or Stage 2 patches in need of review?  I'll do my best
> to either (a) convince someone to review them, or (b) review them myself.
>

The patches to make the new -Wconversion work with decimal float types
are still pending review.
http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01356.html

Unfortunately, even if I could skip sleep for one night to get some
extra time, I won't have the means needed to test them, update them to
current trunk or commit them before Sep 10th. Perhaps in two or three
weeks I could...

By the way, have the patches for FixedPointArithmetic added
Wconversion support? I guess that will make the patches above to not
apply cleanly anymore.

Cheers,

Manuel.

Re: Someone has caused regressions in gfortran (c_char_tests_red.f03)

[Dominique Dhumieres]

I have done some investigation about the recent failure of
gfortran.dg/c_char_tests.f03. First the failure disappears
with -fno-inline or -fno-inline-functions:

[karma] f90/bug% gfc c_char_tests_db.f03 -O3 -fno-inline c_char_driver_db.c
[karma] f90/bug% a.out
[karma] f90/bug% gfc c_char_tests_db.f03 -O3 -fno-inline-functions 
c_char_driver_db.c
[karma] f90/bug% a.out

Second, if I remove the line   sub0();
in c_char_driver.c, the test succeeds, so the C driver can be reduced to:

[karma] f90/bug% cat c_char_driver_red.c
void sub0(void);

int main(int argc, char **argv)
{
  char my_char = 'y';
  
  sub0();
  
  return 0;
}

with the same behavior. Now the stange part: if I try the following reduced 
code:

! { dg-do run }
! { dg-additional-sources c_char_driver.c }
! Verify that character dummy arguments for bind(c) procedures can work both 
! by-value and by-reference when called by either C or Fortran.
! PR fortran/32732
module c_char_tests
  use, intrinsic :: iso_c_binding, only: c_char
  implicit none
contains
  subroutine param_test(my_char) bind(c)
character(c_char), value :: my_char

call sub1(my_char)
  end subroutine param_test

  subroutine sub0() bind(c)
call param_test('y')
  end subroutine sub0

  subroutine sub1(my_char_ref) bind(c)
character(c_char) :: my_char_ref
if(my_char_ref /= c_char_'y') call abort()
  end subroutine sub1
end module c_char_tests

! { dg-final { cleanup-modules "c_char_tests" } }

I get:

[karma] f90/bug% gfc c_char_tests_red.f03 -O3 -fno-inline-functions 
c_char_driver_red.c
[karma] f90/bug% a.out
Abort
[karma] f90/bug% gfc c_char_tests_red.f03 -O3 -fno-inline-functions -fno-inline 
c_char_driver_red.c
[karma] f90/bug% a.out

Wierd, isn't it?

So if one wants an immediate clean test suite, add -fno-inline-functions.
Now clearly the new version of GCC inlines more than the previous one,
with two failing cases. The first one (do_3) is a very borderline one,
testing folding after integer overflows and I think the addition of
-fno-strict-overflow is enough. In my opinion, the second case requires
further investigation, but I don't think it would be a good idea to
try to prevent the new inlining (unless we discover that it open
another Pandora box).

Cheers

Dominique

Re: [RFC] missing return warnings

[Manuel López-Ibáñez]

On 06/09/07, Jan Hubicka <[EMAIL PROTECTED]> wrote:
> I wonder what we want to do here - I guess we can either make the
> warning unconditional and declare it as two indpendent things or we can
> just drop the feature since user will get properly warned on every
> function he actually uses.
>
> What would be preferred solution here?

My preferred solution would be that TREE_NO_WARNING did actually
prevent to emit a duplicate warning.

tree-cfg.c (execute_warn_function_return)
--
 /* If we see "return;" in some basic block, then we do reach the end
 without returning a value.  */
  else if (warn_return_type
   && !TREE_NO_WARNING (cfun->decl)
   && EDGE_COUNT (EXIT_BLOCK_PTR->preds) > 0
   && !VOID_TYPE_P (TREE_TYPE (TREE_TYPE (cfun->decl
{
  FOR_EACH_EDGE (e, ei, EXIT_BLOCK_PTR->preds)
{
  tree last = last_stmt (e->src);
  if (TREE_CODE (last) == RETURN_EXPR
  && TREE_OPERAND (last, 0) == NULL
  && !TREE_NO_WARNING (last))
{
#ifdef USE_MAPPED_LOCATION
  location = EXPR_LOCATION (last);
  if (location == UNKNOWN_LOCATION)
  location = cfun->function_end_locus;
  warning (0, "%Hcontrol reaches end of non-void function", 
&location);
#else
  locus = EXPR_LOCUS (last);
  if (!locus)
locus = &cfun->function_end_locus;
  warning (0, "%Hcontrol reaches end of non-void function", locus);
#endif
  TREE_NO_WARNING (cfun->decl) = 1;
  break;
}
}
}

Why is that not so? That would also prevent the whole loop  from being
executed at all. Do cfun->decl and fndecl point to different things?

If that is difficult then not getting a warning about a function that
is not used does not seem so tragic as long as the middle-end warns
for every case that the front-end would warn (assuming the function is
used). The warning in the middle-end does not depend on optimization
being enabled, does it?

Cheers,

Manuel.

Re: GCC 4.3.0 Status Report (2007-09-04)

[Jan Hubicka]

> Summary
> ===
> 
> We are closing in on Stage 3, previously announced for September 10th.
> At this point, I'm not aware of any reason to delay that date.  Are
> there any Stage 2 patches that people don't think will be submitted by
> that point?

I am still planning to do some retuning of inliner (our inline limits
wasn't revisited for inclusion of SSA optimizers).  I am now waiting on
Diego to decide on
http://gcc.gnu.org/ml/gcc-patches/2007-02/msg00318.html
that makes the metrics looks quite significandly different.  Then I will
run few tests on our C++/SPEC tester in hope that we can now
significandly cut some of the limits previously pushed up by the tests
with large abstraction (DLV/Tramp3d) and speedup compilation/reduce
binaries.  It will probably take more than 2 days, but I hope it is
acceptable for early stage3. I will be on conference from 10th to 16th,
but I expect to be able to do the benchmarking needed.

Honza

Re: Bootstrap broken: ../../gcc/gcc/ada/trans.c:5896: error: too few arguments to function `real_2expN'

[Sandra Loosemore]

Christian Joensson wrote:

Using checkout Thu Sep  6 05:56:16 UTC 2007 (revision 128174), I get a
bootstrap failure:

gcc -c   -g -fkeep-inline-functions -DIN_GCC   -W -Wall
-Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-DHAVE_CONFIG_H -I. -Iada -I../../gcc/gcc -I../../gcc/gcc/ada
-I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include
-I../../gcc/gcc/../libdecnumber -I../../gcc/gcc/../libdecnumber/dpd
-I../libdecnumber../../gcc/gcc/ada/trans.c -o ada/trans.o
../../gcc/gcc/ada/trans.c: In function `convert_with_check':
../../gcc/gcc/ada/trans.c:5896: error: too few arguments to function
`real_2expN'
make[3]: *** [ada/trans.o] Error 1
make[3]: Leaving directory `/usr/local/src/trunk/objdir/gcc'
make[2]: *** [all-stage1-gcc] Error 2
make[2]: Leaving directory `/usr/local/src/trunk/objdir'
make[1]: *** [stage1-bubble] Error 2
make[1]: Leaving directory `/usr/local/src/trunk/objdir'
make: *** [all] Error 2



It looks like this is due to this change, not my modification to trans.c:

2007-09-05  Janis Johnson  <[EMAIL PROTECTED]>

* optabs.c (expand_float): Convert unsigned integer as signed only
if it provides sufficient accuracy; add mode argument to 
real_2expN.

(expand_fix): Fix comment typos; extend binary float into mode
wider than destination for converion to unsigned integer; add mode
argument to real_2expN.
* real.c (real_2expN): Add mode argument to special-case decimal
float values.
* real.h (real_2expN): Ditto.
* fixed-value.c (check_real_for_fixed_mode): Add mode argument to
real_2expN.
(fixed_from_string): Ditto.
(fixed_to_decimal): Ditto.
(fixed_convert_from_real): Ditto.
(real_convert_from_fixed): Ditto.
* config/rs6000/rs6000.md (FP): Include DD and TD modes.
* config/rs6000/dfp.md (extendddtd2, a3, addtd3, subdd3, 
subtd3,

muldd3, multd3, divdd3, divtd3, cmpdd_internal1, cmptd_internal1,
floatditd2, ftruncdd2, fixdddi2, ftrunctd2, fixddi2): New.

-Sandra

Re: Bootstrap broken: ../../gcc/gcc/ada/trans.c:5896: error: too few arguments to function `real_2expN'

[Christian Joensson]

2007/9/6, Sandra Loosemore <[EMAIL PROTECTED]>:
> Christian Joensson wrote:
> > Using checkout Thu Sep  6 05:56:16 UTC 2007 (revision 128174), I get a
> > bootstrap failure:
> >
> > gcc -c   -g -fkeep-inline-functions -DIN_GCC   -W -Wall
> > -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
> > -DHAVE_CONFIG_H -I. -Iada -I../../gcc/gcc -I../../gcc/gcc/ada
> > -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include
> > -I../../gcc/gcc/../libdecnumber -I../../gcc/gcc/../libdecnumber/dpd
> > -I../libdecnumber../../gcc/gcc/ada/trans.c -o ada/trans.o
> > ../../gcc/gcc/ada/trans.c: In function `convert_with_check':
> > ../../gcc/gcc/ada/trans.c:5896: error: too few arguments to function
> > `real_2expN'
> > make[3]: *** [ada/trans.o] Error 1
> > make[3]: Leaving directory `/usr/local/src/trunk/objdir/gcc'
> > make[2]: *** [all-stage1-gcc] Error 2
> > make[2]: Leaving directory `/usr/local/src/trunk/objdir'
> > make[1]: *** [stage1-bubble] Error 2
> > make[1]: Leaving directory `/usr/local/src/trunk/objdir'
> > make: *** [all] Error 2
> >
>
> It looks like this is due to this change, not my modification to trans.c:
>
> 2007-09-05  Janis Johnson  <[EMAIL PROTECTED]>
>
>  * optabs.c (expand_float): Convert unsigned integer as signed only
>  if it provides sufficient accuracy; add mode argument to
> real_2expN.
>  (expand_fix): Fix comment typos; extend binary float into mode
>  wider than destination for converion to unsigned integer; add mode
>  argument to real_2expN.
>  * real.c (real_2expN): Add mode argument to special-case decimal
>  float values.
>  * real.h (real_2expN): Ditto.
>  * fixed-value.c (check_real_for_fixed_mode): Add mode argument to
>  real_2expN.
>  (fixed_from_string): Ditto.
>  (fixed_to_decimal): Ditto.
>  (fixed_convert_from_real): Ditto.
>  (real_convert_from_fixed): Ditto.
>  * config/rs6000/rs6000.md (FP): Include DD and TD modes.
>  * config/rs6000/dfp.md (extendddtd2, a3, addtd3, subdd3,
> subtd3,
>  muldd3, multd3, divdd3, divtd3, cmpdd_internal1, cmptd_internal1,
>  floatditd2, ftruncdd2, fixdddi2, ftrunctd2, fixddi2): New.
>
sorry, I didn't look (at all) what was in your commit, I simply looked
at it and saw that you were the last one on it...

btw, still fails at Thu Sep  6 13:05:57 UTC 2007 (revision 128182).

this is on

Windows XP Pro/SP2 cygwin Pentium M processor 2.13GHz system with packages:

binutils 20060817-1 2.17.50 20060817
bison2.3-1  2.3
cygwin   1.5.24-2   (rev. 1.46 of newlib's stdio.h)
dejagnu  20021217-2 1.4.2.x
expect   20030128-1 5.26
gcc  3.4.4-3
gcc-ada  3.4.4-3
gcc-g++  3.4.4-3
gmp  4.2.1-1
make 3.81-1
mpfr 2.2.1-1
tcltk20060202-1 8.4
w32api   3.10-1


-- 
Cheers,

/ChJ

Re: GCC 4.3.0 Status Report (2007-09-04)

[Sebastian Pop]

On 9/4/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> We are closing in on Stage 3, previously announced for September 10th.
> At this point, I'm not aware of any reason to delay that date.  Are
> there any Stage 2 patches that people don't think will be submitted by
> that point?
>

I still plan to submit the loop distribution pass.

Sebastian

Re: GCC "make" errors

[Tim Prince]

mandeep singh bhambra wrote:
> I have installed the latest binutils (2.9.1) available from the GNU ftp site 
> so I cannot understand why this is occuring. Are there some sort of parameter 
> options I need to enter or do I need to reinstall the binutils with parameter 
> options?
> 

On my laptop, with absolutely no attention to updating binutils, I get
[EMAIL PROTECTED]:~> ld --version
GNU ld (GNU Binutils) 2.17.50.20070726-4 (SUSE Linux)

If you keep both an old and a new binutils installed in separate
directories, it's difficult to assure use of the new one, unless you
reconfigure your gcc --with-ld  so that gcc's implicit use of ld will
take the new one.

Re: Register allocation issues

[David Edelsohn]

> Matt Lee writes:

Matt> The problem is, that though the loads can be optimized by pipelining
Matt> them. The register allocator has created a dependency by using only r3
Matt> and r4, instead of using the other volatiles.

GCC's register allocator currently is designed to minimize the
number of hard registers.  As Ian mentioned, -frename-registers tries to
perform register renaming with available registers after register
allocation.  As they say, "Your Mileage May Vary".

David

RE: Register allocation issues

[Dave Korn]

On 05 September 2007 23:47, Matt Lee wrote:

> Registers r3 to r12 are volatiles. However, for the C code below,
> 
> struct foo {
> int a[4];
> } ;
> 
> struct foo p, q;
> 
> void func ()
> {
> memcpy (&p, &q, sizeof (struct foo));
> }
> 
> I am getting a instruction sequence for func() such as,
> 
> load r3, q + 0
> load r4, q + 4
> store r3, p + 0
> store r4, p + 4
> load r3, q + 4
> load r4, q + 8
> store r3, p + 4
> store r4, p + 8
> 
> The problem is, that though the loads can be optimized by pipelining
> them. The register allocator has created a dependency by using only r3
> and r4, instead of using the other volatiles.

  Does your backend define a movdi pattern?


cheers,
  DaveK
-- 
Can't think of a witty .sigline today

Re: Someone has caused regressions in gfortran

[Jan Hubicka]

> > The testcase was indeed previously not inlined at all.  Shall we add
> > -fno-strict-overflow to the testcase then?
> 
> This what I would do, but I am not qualified to make the call.
> In addition my working setup is totally broken right now 
> (at stage1). Could you do the addition to the testcase
> and run the gfortran testsuite? From the result it would
> be easier to reach a conclusion.

Yep, it does fix the problem.

Honza
> 
> TIA
> 
> Dominique

warnings in GCC source?

[Basile STARYNKEVITCH]

Hello All,

In most of GCC source code, it is perfectly normal to expect that no 
warnings should appear, even if the sources are compiled with -Wall or 
more. Actually the GCC bootstrap process seems to require this.


However, I see some occasions where warnings might be quite difficult to 
avoid:


1: DLSYM: This probably should concern the plugin branch (or 
experiment): the POSIX way of getting a routine inside a plug-in is 
dlsym (or which happens to return a pointer, which has to be cast to a 
function pointer somewhere. This cast will get a warning at a certain 
level, like
   warning: ISO C forbids conversion of object pointer to function 
pointer type
This warning cannot be easily avoided. IIRC, some future POSIX standard 
is expected to provide a dlfsym variant to dlsym.


2. generated code: when some C files are generated, it may be hard to 
avoid some warnings, typically a generated C function might have unused 
arguments (which might be not very easy to detect at generation stage).


So is there an easy way to have some acceptable warnings in GCC?

Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***

ARM miscompilation of __moddi3 on trunk

[Andrew Haley]

This simple test case:

#include 

int ten = 10;

int main()
{
  printf ("%lld\n", 92233720368547758LL % ten);
  return 0;
}

returns

0

because (afaics) __moddi3 is miscompiled.

Breakpoint 4, __moddi3 (u=92233720368547758, v=10)
at /home/aph/gcc/trunk/libgcc/../gcc/libgcc2.c:923
(gdb) fin
Run till exit from #0  __moddi3 (u=, v=92233718306963466)
at /home/aph/gcc/trunk/libgcc/../gcc/libgcc2.c:919
0x8474 in main () at ppp.c:7
Value returned is $3 = 0

Recompiling libgcc with -O0 fixes the problem:

(gdb) 
(gdb) fin
Run till exit from #0  __moddi3 (u=92233720368547758, v=10)
at /home/aph/gcc/trunk/libgcc/../gcc/libgcc2.c:879
0x84a4 in main () at ppp.c:7
Value returned is $4 = 8

And recompiling just _moddi3.o fixes it again.


Target: arm-linux-gnueabi
Configured with: /home/aph/gcc/trunk/configure --with-system-zlib 
--enable-threads=posix --enable-nls --enable-__cxa_atexit --enable-clocale=gnu 
--enable-libstdcxx-debug --enable-mpfr --enable-checking=release 
--disable-multilib --disable-static arm-linux-gnueabi --disable-bootstrap 
--disable-sjlj-exceptions --prefix=/home/aph/gcc/install 
build_alias=arm-linux-gnueabi host_alias=arm-linux-gnueabi 
target_alias=arm-linux-gnueabi --enable-languages=c,c++,java --no-create 
--no-recursion


Andrew.

RE: warnings in GCC source?

[Dave Korn]

On 06 September 2007 16:55, Basile STARYNKEVITCH wrote:

> 2. generated code: when some C files are generated, it may be hard to
> avoid some warnings, typically a generated C function might have unused
> arguments (which might be not very easy to detect at generation stage).


  Generate "__attribute__ ((unused))" on all parameters/variables, regardless.


cheers,
  DaveK
-- 
Can't think of a witty .sigline today

Re: warnings in GCC source?

[Andreas Schwab]

Basile STARYNKEVITCH <[EMAIL PROTECTED]> writes:

> So is there an easy way to have some acceptable warnings in GCC?

See gcc/Makefile.in, look for -Wno-error.

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Is stmt_ann()->references_memory equal to !ZERO_SSA_OPERANDS (stmt, (SSA_OP_VUSE | SSA_OP_VIRTUAL_DEFS)?

[Richard Guenther]

$subject?  During early optimization the !ZERO_SSA_OPERANDS check doesn't
say the truth (well it does, but only in some sense) while the
references_memory flag seems to be updated ok.

There is one case, for calls, where we set references_memory
unconditionally even if we later might not add any virtual operands at 
all.

So, is it ok to replace those checks by checking the variable annotation
instead?

Thanks,
Richard.

Re: Is stmt_ann()->references_memory equal to !ZERO_SSA_OPERANDS (stmt, (SSA_OP_VUSE | SSA_OP_VIRTUAL_DEFS)?

[Diego Novillo]

On 9/6/07, Richard Guenther <[EMAIL PROTECTED]> wrote:

> $subject?

It is not.  You can have a statement that references memory and have
no virtual operands at all (volatile or totally pruned VOPs for
instance).

Also, the very first alias analysis pass will find statements with no
VOPs but with memory references.  stmt_references_memory_p() must work
regardless.

> So, is it ok to replace those checks by checking the variable annotation
> instead?

What variable annotation?  This is a statement annotation.

can't reinterpret_cast to/from the same type

[Peter A. Felvegi]

hello,

i don't know if it's a bug, please clarify:

rc.cpp:
--8<--
void f()
{
int x = 0;
int y = reinterpret_cast(x);
}
--8<--
gcc -v:
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu
--enable-libstdcxx-debug --enable-mpfr --with-tune=i686
--enable-checking=release i486-linux-gnu
Thread model: posix
gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)

gcc -c rc.cpp:
rc.cpp: In function ‘void f()’:
rc.cpp:4: error: invalid cast from type ‘int’ to type ‘int’

i suspected that one could cast from int to int.

google hasn't found any relevant pages for 'gcc reinterpret cast bug'

regards, peter

[lto] project: adding --with-libelf to configure

[Nathan Froyd]

The LTO driver requires libelf and currently grovels around in the
system directories looking for it, which may not always be the right
place to find it.  (This bit me when building LTO on our new Linux
machines, which do not have libelf installed.)  The Right Thing would be
to add a --with-libelf flag to configure so we wouldn't have to assume
it's always installed in one particular place.  A small LTO project
would be for someone to add a --with-libelf to configure.

I'm not an expert at configury; would somebody else like to take a whack
at this?

-Nathan

Re: RTL sharing bootstrap failure on sparc-sun-solaris2.10

[Andreas Tobler]

Kaveh R. GHAZI wrote:

(Sorry, first one bounced from gcc@ because it was over 400k)

Hi Jan,

On sparc-sun-solaris2.10, I'm getting new bootstrap failures in stage2
complaining several times about rtl sharing.  I've included four .i files
for modules that ICEed during stage2, and the cc1 invocations below.

Would you please take a look?


Jan proposed the below patch.
I successfully tested it and I'm testing now.

Regards,
Andreas

Index: reorg.c
===
--- reorg.c (revision 128181)
+++ reorg.c (working copy)
@@ -3991,6 +3991,9 @@
  if (GET_CODE (pat) == SEQUENCE)
insn = XVECEXP (pat, 0, 0);
}
+   if (INSN_P (insn) && GET_CODE (PATTERN (insn)) == USE
+ && INSN_P (XEXP (PATTERN (insn), 0)))
+   delete_insn (insn);
   if (!JUMP_P (insn))
continue;

RE: GCC 4.3.0 Status Report (2007-09-04)

[Fu, Chao-Ying]

Manuel López-Ibáñez wrote:
> 
> On 05/09/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> > Summary
> > ===
> >
> > We are closing in on Stage 3, previously announced for 
> September 10th.
> > At this point, I'm not aware of any reason to delay that date.  Are
> > there any Stage 2 patches that people don't think will be 
> submitted by
> > that point?
> >
> > Are there Stage 1 or Stage 2 patches in need of review?  
> I'll do my best
> > to either (a) convince someone to review them, or (b) 
> review them myself.
> >
> 
> The patches to make the new -Wconversion work with decimal float types
> are still pending review.
> http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01356.html
> 
> Unfortunately, even if I could skip sleep for one night to get some
> extra time, I won't have the means needed to test them, update them to
> current trunk or commit them before Sep 10th. Perhaps in two or three
> weeks I could...
> 
> By the way, have the patches for FixedPointArithmetic added
> Wconversion support? I guess that will make the patches above to not
> apply cleanly anymore.

  Not yet.  After I get the remaining patches (7, 8, 9, 10) checked in,
I will see how much work is needed to support Wconversion 
for fixed-point types.  Thanks!

Regards,
Chao-ying

Re: Bootstrap failure under Irix

[Janis Johnson]

On Thu, 2007-09-06 at 09:47 +0200, Philippe Schaffnit wrote:
> Hi!
> 
> I am seeing the folowing bootstrap failure under SGI Irix:

> /USER/philippe/Irix/Gcc_Sources/gcc/config/mips/mips.md: In function
> 'gen_fixuns_truncdfsi2':
> /USER/philippe/Irix/Gcc_Sources/gcc/config/mips/mips.md:2808: error: too
> few arguments to function 'real_2expN'

> My last attempt at wa succesful with : '4.3.0 20070823 (experimental)
> [trunk revision 127728]' (I haven't tried in between). Can anyone
> suggest anything?

I broke this, and reverted the patch (and two other patches that cleaned
up after it) in r128193.

Janis

Re: Bootstrap broken: ../../gcc/gcc/ada/trans.c:5896: error: too few arguments to function `real_2expN'

[Janis Johnson]

On Thu, 2007-09-06 at 15:32 +0200, Christian Joensson wrote:
> 2007/9/6, Sandra Loosemore <[EMAIL PROTECTED]>:
> > Christian Joensson wrote:
> > > Using checkout Thu Sep  6 05:56:16 UTC 2007 (revision 128174), I get a
> > > bootstrap failure:
> > >
> > > ../../gcc/gcc/ada/trans.c: In function `convert_with_check':
> > > ../../gcc/gcc/ada/trans.c:5896: error: too few arguments to function
> > > `real_2expN'

> >
> > It looks like this is due to this change, not my modification to trans.c:
> >
> > 2007-09-05  Janis Johnson  <[EMAIL PROTECTED]>

I've reverted this patch, and two cleanup patches, in r128193.

Janis

Re: RTL sharing bootstrap failure on sparc-sun-solaris2.10

[Jan Hubicka]

> (Sorry, first one bounced from gcc@ because it was over 400k)
> 
> Hi Jan,
> 
> On sparc-sun-solaris2.10, I'm getting new bootstrap failures in stage2
> complaining several times about rtl sharing.  I've included four .i files
> for modules that ICEed during stage2, and the cc1 invocations below.
> 
> Would you please take a look?

Hi,
I already have fix for this just waiting for Andreas Tobler to verify
that it does what expected.  If you could give it a try, it would be
nice.

The problem is 

/* Called when INSN is being moved from a location near the target of a jump.
   We leave a marker of the form (use (INSN)) immediately in front
   of WHERE for mark_target_live_regs.  These markers will be deleted when
   reorg finishes.

   We used to try to update the live status of registers if WHERE is at
   the start of a basic block, but that can't work since we may remove a
   BARRIER in relax_delay_slots.  */

static void
update_block (rtx insn, rtx where)
{
  /* Ignore if this was in a delay slot and it came from the target of
 a branch.  */
  if (INSN_FROM_TARGET_P (insn))
return;

  emit_insn_before (gen_rtx_USE (VOIDmode, insn), where);

  /* INSN might be making a value live in a block where it didn't use to
 be.  So recompute liveness information for this block.  */

  incr_ticks_for_insn (insn);
}

Producing USE expressions embedding whole INSN.  The comment promise
that those will be removed before reorg ends, but they are not.  This
patch just adds simple code to remove them in very last dbr_schedule
pass. 

Honza

Index: reorg.c
===
--- reorg.c (revision 128145)
+++ reorg.c (working copy)
@@ -3991,6 +3991,9 @@ dbr_schedule (rtx first)
  if (GET_CODE (pat) == SEQUENCE)
insn = XVECEXP (pat, 0, 0);
}
+  if (INSN_P (insn) && GET_CODE (PATTERN (insn)) == USE
+ && INSN_P (XEXP (PATTERN (insn), 0)))
+   delete_insn (insn);
   if (!JUMP_P (insn))
continue;
 

Re: RTL sharing bootstrap failure on sparc-sun-solaris2.10

[Jan Hubicka]

> Hi,
> I already have fix for this just waiting for Andreas Tobler to verify
> that it does what expected.  If you could give it a try, it would be
> nice.
> 
> The problem is 
> 
> /* Called when INSN is being moved from a location near the target of a jump.
>We leave a marker of the form (use (INSN)) immediately in front
>of WHERE for mark_target_live_regs.  These markers will be deleted when
>reorg finishes.
> 
>We used to try to update the live status of registers if WHERE is at
>the start of a basic block, but that can't work since we may remove a
>BARRIER in relax_delay_slots.  */
> 
> static void
> update_block (rtx insn, rtx where)
> {
>   /* Ignore if this was in a delay slot and it came from the target of
>  a branch.  */
>   if (INSN_FROM_TARGET_P (insn))
> return;
> 
>   emit_insn_before (gen_rtx_USE (VOIDmode, insn), where);
> 
>   /* INSN might be making a value live in a block where it didn't use to
>  be.  So recompute liveness information for this block.  */
> 
>   incr_ticks_for_insn (insn);
> }
> 
> Producing USE expressions embedding whole INSN.  The comment promise
> that those will be removed before reorg ends, but they are not.  This
> patch just adds simple code to remove them in very last dbr_schedule
> pass. 
> 
> Honza

Since patch seems to work for Andreas, would it be OK?
* recog.c (dbr_schedule): Remove placeholder USE insns
previously inserted by update_block.
> 
> Index: reorg.c
> ===
> --- reorg.c   (revision 128145)
> +++ reorg.c   (working copy)
> @@ -3991,6 +3991,9 @@ dbr_schedule (rtx first)
> if (GET_CODE (pat) == SEQUENCE)
>   insn = XVECEXP (pat, 0, 0);
>   }
> +  if (INSN_P (insn) && GET_CODE (PATTERN (insn)) == USE
> +   && INSN_P (XEXP (PATTERN (insn), 0)))
> + delete_insn (insn);
>if (!JUMP_P (insn))
>   continue;
>  

RE: GCC 4.3.0 Status Report (2007-09-04)

[Jagasia, Harsha]

>On 9/4/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
>> We are closing in on Stage 3, previously announced for September
10th.
>> At this point, I'm not aware of any reason to delay that date.  Are
>> there any Stage 2 patches that people don't think will be submitted
by
>> that point?
>>

I still plan to submit a patch for the x86 target cost model tuning. 

Harsha

Re: RTL sharing bootstrap failure on sparc-sun-solaris2.10

[Ian Lance Taylor]

Jan Hubicka <[EMAIL PROTECTED]> writes:

> Producing USE expressions embedding whole INSN.  The comment promise
> that those will be removed before reorg ends, but they are not.  This
> patch just adds simple code to remove them in very last dbr_schedule
> pass. 

I see code in dbr_schedule to delete them:

  /* Delete any USE insns made by update_block; subsequent passes don't need
 them or know how to deal with them.  */
  for (insn = first; insn; insn = next)
{
  next = NEXT_INSN (insn);

  if (NONJUMP_INSN_P (insn) && GET_CODE (PATTERN (insn)) == USE
  && INSN_P (XEXP (PATTERN (insn), 0)))
next = delete_related_insns (insn);
}

Why is that not working?

Ian

Re: Register allocation issues

[Matt Lee]

On 9/6/07, David Edelsohn <[EMAIL PROTECTED]> wrote:
> > Matt Lee writes:
>
> Matt> The problem is, that though the loads can be optimized by pipelining
> Matt> them. The register allocator has created a dependency by using only r3
> Matt> and r4, instead of using the other volatiles.
>
> GCC's register allocator currently is designed to minimize the
> number of hard registers.  As Ian mentioned, -frename-registers tries to
> perform register renaming with available registers after register
> allocation.  As they say, "Your Mileage May Vary".
>

There is no point trying to minimize usage of volatile hard registers,
is there? They are precisely there to be used up as much as needed.
The function is a leaf procedure as well, so there are no other
considerations. Lastly, architectures like PPC do make use of more
registers (without -frename-registers), so there has to be something
in the PPC back-end that allows for the liberal use or in mine that
prevents such.

-- 
thanks,
Matt

Re: Register allocation issues

[Matt Lee]

On 9/6/07, Dave Korn <[EMAIL PROTECTED]> wrote:
> On 05 September 2007 23:47, Matt Lee wrote:
>
> > Registers r3 to r12 are volatiles. However, for the C code below,
> >
> > struct foo {
> > int a[4];
> > } ;
> >
> > struct foo p, q;
> >
> > void func ()
> > {
> > memcpy (&p, &q, sizeof (struct foo));
> > }
> >
> > I am getting a instruction sequence for func() such as,
> >
> > load r3, q + 0
> > load r4, q + 4
> > store r3, p + 0
> > store r4, p + 4
> > load r3, q + 4
> > load r4, q + 8
> > store r3, p + 4
> > store r4, p + 8
> >
> > The problem is, that though the loads can be optimized by pipelining
> > them. The register allocator has created a dependency by using only r3
> > and r4, instead of using the other volatiles.
>
>   Does your backend define a movdi pattern?
>
>

Yes it does. But in this case, these are word-by-word moves from
memory to memory and make use of only movsi.
-- 
thanks,
Matt

Re: RTL sharing bootstrap failure on sparc-sun-solaris2.10

[Jan Hubicka]

> Jan Hubicka <[EMAIL PROTECTED]> writes:
> 
> > Producing USE expressions embedding whole INSN.  The comment promise
> > that those will be removed before reorg ends, but they are not.  This
> > patch just adds simple code to remove them in very last dbr_schedule
> > pass. 
> 
> I see code in dbr_schedule to delete them:
> 
>   /* Delete any USE insns made by update_block; subsequent passes don't need
>  them or know how to deal with them.  */
>   for (insn = first; insn; insn = next)
> {
>   next = NEXT_INSN (insn);
> 
>   if (NONJUMP_INSN_P (insn) && GET_CODE (PATTERN (insn)) == USE
> && INSN_P (XEXP (PATTERN (insn), 0)))
>   next = delete_related_insns (insn);
> }
> 
> Why is that not working?

Hmm, good catch. I didn't noticed that code.
The problem is that update_block is still called after this loop is
done, at least moving that loop down past the loop just bellow it solves
the ICE too.

I must admit I have no idea what those placeholders are good for...

Honza
> 
> Ian

Re: RTL sharing bootstrap failure on sparc-sun-solaris2.10

[Ian Lance Taylor]

Jan Hubicka <[EMAIL PROTECTED]> writes:

> > Jan Hubicka <[EMAIL PROTECTED]> writes:
> > 
> > > Producing USE expressions embedding whole INSN.  The comment promise
> > > that those will be removed before reorg ends, but they are not.  This
> > > patch just adds simple code to remove them in very last dbr_schedule
> > > pass. 
> > 
> > I see code in dbr_schedule to delete them:
> > 
> >   /* Delete any USE insns made by update_block; subsequent passes don't need
> >  them or know how to deal with them.  */
> >   for (insn = first; insn; insn = next)
> > {
> >   next = NEXT_INSN (insn);
> > 
> >   if (NONJUMP_INSN_P (insn) && GET_CODE (PATTERN (insn)) == USE
> >   && INSN_P (XEXP (PATTERN (insn), 0)))
> > next = delete_related_insns (insn);
> > }
> > 
> > Why is that not working?
> 
> Hmm, good catch. I didn't noticed that code.
> The problem is that update_block is still called after this loop is
> done, at least moving that loop down past the loop just bellow it solves
> the ICE too.

Ah, it's from the calls to fill_simple_delay_slots in
make_return_insns.  The "Delete any USE insns" loop needs to move
below that.

> I must admit I have no idea what those placeholders are good for...

They tell mark_target_live_regs that the registers used by the insn
which was moved are live.

Ian

Re: Register allocation issues

[dje]

> Matt Lee writes: 
Date: Thu, 06 Sep 2007 15:02:52 -0400
From: David Edelsohn <[EMAIL PROTECTED]>

Matt> There is no point trying to minimize usage of volatile hard registers,
Matt> is there? They are precisely there to be used up as much as needed.
Matt> The function is a leaf procedure as well, so there are no other
Matt> considerations. Lastly, architectures like PPC do make use of more
Matt> registers (without -frename-registers), so there has to be something
Matt> in the PPC back-end that allows for the liberal use or in mine that
Matt> prevents such.

GCC RA mostly is tuned for IA-32 with very few registers.

The rs6000 port defines the movmemsi pattern calling
expand_block_move() which generates many intermediate pseudos.

David

Re: Register allocation issues

[Segher Boessenkool]

load r3, q + 0
load r4, q + 4
store r3, p + 0
store r4, p + 4
load r3, q + 4
load r4, q + 8
store r3, p + 4
store r4, p + 8


These last four lines should be

load r3, q + 8
load r4, q + 12
store r3, p + 8
store r4, p + 12


Did you just typo it or do you have a bigger problem?  The
problems might even be connected, who knows :-)


Segher

Re: RTL sharing bootstrap failure on sparc-sun-solaris2.10

[Jan Hubicka]

> Jan Hubicka <[EMAIL PROTECTED]> writes:
> 
> > > Jan Hubicka <[EMAIL PROTECTED]> writes:
> > > 
> > > > Producing USE expressions embedding whole INSN.  The comment promise
> > > > that those will be removed before reorg ends, but they are not.  This
> > > > patch just adds simple code to remove them in very last dbr_schedule
> > > > pass. 
> > > 
> > > I see code in dbr_schedule to delete them:
> > > 
> > >   /* Delete any USE insns made by update_block; subsequent passes don't 
> > > need
> > >  them or know how to deal with them.  */
> > >   for (insn = first; insn; insn = next)
> > > {
> > >   next = NEXT_INSN (insn);
> > > 
> > >   if (NONJUMP_INSN_P (insn) && GET_CODE (PATTERN (insn)) == USE
> > > && INSN_P (XEXP (PATTERN (insn), 0)))
> > >   next = delete_related_insns (insn);
> > > }
> > > 
> > > Why is that not working?
> > 
> > Hmm, good catch. I didn't noticed that code.
> > The problem is that update_block is still called after this loop is
> > done, at least moving that loop down past the loop just bellow it solves
> > the ICE too.
> 
> Ah, it's from the calls to fill_simple_delay_slots in
> make_return_insns.  The "Delete any USE insns" loop needs to move
> below that.
> 
> > I must admit I have no idea what those placeholders are good for...
> 
> They tell mark_target_live_regs that the registers used by the insn
> which was moved are live.

Ah, I see.
The attached patch seems to work on my testcase too.

Honza

Index: reorg.c
===
--- reorg.c (revision 128145)
+++ reorg.c (working copy)
@@ -3863,17 +3863,6 @@ dbr_schedule (rtx first)
   relax_delay_slots (first);
 }
 
-  /* Delete any USE insns made by update_block; subsequent passes don't need
- them or know how to deal with them.  */
-  for (insn = first; insn; insn = next)
-{
-  next = NEXT_INSN (insn);
-
-  if (NONJUMP_INSN_P (insn) && GET_CODE (PATTERN (insn)) == USE
- && INSN_P (XEXP (PATTERN (insn), 0)))
-   next = delete_related_insns (insn);
-}
-
   /* If we made an end of function label, indicate that it is now
  safe to delete it by undoing our prior adjustment to LABEL_NUSES.
  If it is now unused, delete it.  */
@@ -3885,6 +3874,17 @@ dbr_schedule (rtx first)
 make_return_insns (first);
 #endif
 
+  /* Delete any USE insns made by update_block; subsequent passes don't need
+ them or know how to deal with them.  */
+  for (insn = first; insn; insn = next)
+{
+  next = NEXT_INSN (insn);
+
+  if (NONJUMP_INSN_P (insn) && GET_CODE (PATTERN (insn)) == USE
+ && INSN_P (XEXP (PATTERN (insn), 0)))
+   next = delete_related_insns (insn);
+}
+
   obstack_free (&unfilled_slots_obstack, unfilled_firstobj);
 
   /* It is not clear why the line below is needed, but it does seem to be.  */

Re: RTL sharing bootstrap failure on sparc-sun-solaris2.10

[Ian Lance Taylor]

Jan Hubicka <[EMAIL PROTECTED]> writes:

> The attached patch seems to work on my testcase too.

This patch is OK if it passes testing and gets a ChangeLog entry.

Thanks.

Ian

Re: Register allocation issues

[Matt Lee]

On 9/6/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > Matt Lee writes:
> Date: Thu, 06 Sep 2007 15:02:52 -0400
> From: David Edelsohn <[EMAIL PROTECTED]>
>
> Matt> There is no point trying to minimize usage of volatile hard registers,
> Matt> is there? They are precisely there to be used up as much as needed.
> Matt> The function is a leaf procedure as well, so there are no other
> Matt> considerations. Lastly, architectures like PPC do make use of more
> Matt> registers (without -frename-registers), so there has to be something
> Matt> in the PPC back-end that allows for the liberal use or in mine that
> Matt> prevents such.
>
> GCC RA mostly is tuned for IA-32 with very few registers.
>
> The rs6000 port defines the movmemsi pattern calling
> expand_block_move() which generates many intermediate pseudos.
>

So does mine. My generated RTL has all the right looking RTL with a
unique pseudo for each load/store pair. If you see the dump in the
original email from the .lreg files, the problem is that these pseudos
get bound to only 2 out of 10 candidate volatile registers.

-- 
thanks,
Matt

Re: Register allocation issues

[Matt Lee]

On 9/6/07, Segher Boessenkool <[EMAIL PROTECTED]> wrote:
> > load r3, q + 0
> > load r4, q + 4
> > store r3, p + 0
> > store r4, p + 4
> > load r3, q + 4
> > load r4, q + 8
> > store r3, p + 4
> > store r4, p + 8
>
> These last four lines should be
>
> load r3, q + 8
> load r4, q + 12
> store r3, p + 8
> store r4, p + 12
>
>
> Did you just typo it or do you have a bigger problem?  The
> problems might even be connected, who knows :-)
>

Sorry, that was a typo.

Re: [RFC] missing return warnings

[Mark Mitchell]

Jan Hubicka wrote:

> For C++ there are number of cases I need to go through dealing with
> attempts to not instantiate non-inline methods that won't be needed.

I'm not sure exactly what cases you're referring to, but please be
careful.  For example, changing if/when we instantiate template
functions, or if/when we generate bodies for implicitly defined
constructors, destructors, or assignment operators would be a semantic
change, and contrary to the standard.

> For C it seems to be single case for return warning:
> /* PR c++/4872 */
> /* { dg-do compile } */
> /* { dg-options "-Wreturn-type" } */
> 
> static inline int f() {} /* { dg-warning "return" "missing return" } */
> 
> In this case we produce missing return warning from frontend. 
> This however is not truly consistent - if I make the function used, we
> actually get two warnings - one from frontend, one from middle end
> (that is CFG aware and does not merely check for presence of return
> statement in  function). 

As you know, I don't like the middle end issuing warnings at all.  So,
you'll not be surprised that I think we should warn about this function
independent of optimization.  People want these warnings to tell them
about possible bugs in their software, not just the ones that affect
them in their current configuration, depending on how much optimization
applies, etc.  If we want the middle end to warn about this kind of
case, we should make sure that it does so for all functions, used or not.

-- 
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713

Re: [RFC] missing return warnings

[Mark Mitchell]

Jan Hubicka wrote:

> I am basically trying to avoid need for DECL_INLINE (while keeping
> DECL_DECLARED_INLINE and DECL_UNINLINABLE for frontend use) - inliner is
> now doing all the job himself to figure out what is or isn't needed.

That certainly makes sense to me.

> With the noreturn warning made unconditional:

...

> With the noreturn warning disabled completely:

...

> So it seems to be all about those warnings now.

OK, that sounds pretty encouraging.

Thansk,

-- 
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713

Re: [RFC] missing return warnings

[Jan Hubicka]

> Jan Hubicka wrote:
> 
> > For C++ there are number of cases I need to go through dealing with
> > attempts to not instantiate non-inline methods that won't be needed.
> 
> I'm not sure exactly what cases you're referring to, but please be
> careful.  For example, changing if/when we instantiate template
> functions, or if/when we generate bodies for implicitly defined
> constructors, destructors, or assignment operators would be a semantic
> change, and contrary to the standard.

I am basically trying to avoid need for DECL_INLINE (while keeping
DECL_DECLARED_INLINE and DECL_UNINLINABLE for frontend use) - inliner is
now doing all the job himself to figure out what is or isn't needed.
There seems to be whole a lot of legacy code that is now wrong and/or
unnecesary (such as code preventing optimization of stack assignments on
inlinable functions to aid inliner or a lot of code assuming that only
inlinable functions are deferred).

We still should care about DECL_DECLARED_INLINE, if it affects semantics
of standard, but I would hope the output from frontends to actually not
depend on -finline-functions flag if possible.  I am experimenting with
the attached patch, it adds few failures:

With the noreturn warning made unconditional:
g++.dg/warn/pr23075.C (test for excess errors)  

g++.old-deja/g++.brendan/crash52.C (test for excess errors) 

g++.old-deja/g++.jason/report.C (test for excess errors)

gcc.dg/20040206-1.c  (test for warnings, line 10)   

gcc.dg/20040206-1.c (test for excess errors)

gcc.dg/pr23075.c  (test for warnings, line 14)  

gcc.dg/pr23075.c (test for excess errors)   

gcc.dg/return-type-1.c (test for excess errors) 

gcc.dg/return-type-1.c warning for falling off end of non-void function
(test for warnings, line 9) 

gcc.dg/return-type-3.c (test for excess errors) 

gcc.dg/return-type-3.c warning for falling off end of non-void function
(test for warnings, line 14)  

With the noreturn warning disabled completely:

g++.dg/warn/noreturn-2.C  (test for warnings, line 4)   

g++.old-deja/g++.bugs/900205_03.C  (test for errors, line 29)   

g++.old-deja/g++.bugs/900205_03.C  (test for errors, line 32)   

g++.old-deja/g++.law/operators17.C  (test for warnings, line 11)

gcc.dg/Wreturn-type.c (test for excess errors)  

gcc.dg/Wreturn-type.c missing return (test for warnings, line 5) 

So it seems to be all about those warnings now.

> 
> > For C it seems to be single case for return warning:
> > /* PR c++/4872 */
> > /* { dg-do compile } */
> > /* { dg-options "-Wreturn-type" } */
> > 
> > static inline int f() {} /* { dg-warning "return" "missing return" } */
> > 
> > In this case we produce missing return warning from frontend. 
> > This however is not truly consistent - if I make the function used, we
> > actually get two warnings - one from frontend, one from middle end
> > (that is CFG aware and does not merely check for presence of return
> > statement in  function). 
> 
> As you know, I don't like the middle end issuing warnings at all.  So,
> you'll not be surprised that I think we should warn about this function
> independent of optimization.  People want these warnings to tell them
> about possible bugs in their software, not just the ones that affect
> them in their current configuration, depending on how much optimization
> applies, etc.  If we want the middle end to warn about this kind of
> case, we should make sure that it does so for all functions, used or not.

Yep, I agree that the warnings should g

Re: [RFC] missing return warnings

[Jan Hubicka]

> Jan Hubicka wrote:
> 
> > I am basically trying to avoid need for DECL_INLINE (while keeping
> > DECL_DECLARED_INLINE and DECL_UNINLINABLE for frontend use) - inliner is
> > now doing all the job himself to figure out what is or isn't needed.
> 
> That certainly makes sense to me.
> 
> > With the noreturn warning made unconditional:
> 
> ...
> 
> > With the noreturn warning disabled completely:
> 
> ...
> 
> > So it seems to be all about those warnings now.
> 
> OK, that sounds pretty encouraging.

One problem that I am concerned about is that C++ frontend is actually
trying to avoid instantiating some stuff that it knows will not be
needed if not inlined.  I would kill this logic, but I hope this is the
case where the feature is not worth the maintenance cost.

I've applied the patch for C++ nightly testing, for tramp3d, the
difference seems to be in wash.  I will do some proofreading tomorrow
and send updated patch.

Honza
> 
> Thansk,
> 
> -- 
> Mark Mitchell
> CodeSourcery
> [EMAIL PROTECTED]
> (650) 331-3385 x713

Re: [RFC] missing return warnings

[Mark Mitchell]

Jan Hubicka wrote:

> One problem that I am concerned about is that C++ frontend is actually
> trying to avoid instantiating some stuff that it knows will not be
> needed if not inlined.  I would kill this logic, but I hope this is the
> case where the feature is not worth the maintenance cost.

We need to be careful about terms.  "Instantiating" means "substituting
actual arguments into a template definition to get an actual
definition".  There's also generating definitions for
implicitly-declared class member functions; that doesn't have a great
term in the standard, but we can call it "defining implicit functions".
 Which one of these situations are you concerned about?

I guess, in a way, it doesn't matter which one.  In both cases, the
standard says when you must do it.  So, we can't change that.

I suspect that the code that you're looking at may have just been a
front-end optimization.  For example, at least at one point, it made GCC
a lot slower to have very long instantiation chains: f needs g,
g needs h, etc.  It was better to instantiate things one at a
time than to have a deep stack.  But, if h was inline, then we
needed to make sure its body was available when g was being
instantiated so that we could inline it.  Now, that's probably no longer
true.  We can probably always avoid the deep stack, and just let cgraph
handle it.

-- 
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713

GC work status, any comments?

[Laurynas Biveinis]

Hello,

I've spent last two months at Google quietly working on the boehm-gc
branch from my last year's SoC project -
http://gcc.gnu.org/wiki/Garbage_collection_tuning . To recap, I've
integrated Boehm's GC into GCC proper, adjusted gengtype and GGC
support files to generate typed GC allocators for every GTY type, and
added type tag to every GC allocated object.

However, as I was trying to make Boehm's GC use exact type layout
information, I was running into increasingly difficult issues with
every type converted. So then I stopped and scavenged the branch for
immediately useful stuff, almost all of which I have submitted to the
mainline by now.

So my question is, what do you want to see done next? It seems that
continuing working with Boehm's GC will be not that productive. I'm
thinking about bringing over to the mainline the typed GC allocator
infrastructure, so that every ggc_alloc becomes, e.g.
ggc_alloc_rtx_def, ggc_alloc_cleared_tree_node and so on for every
GTY'ed type. In the first step they would be simple wrappers around
ggc_alloc - I would not add the type tag byte to the allocated objects
and that would wait until explicit marker stack, the first user of
them. Immediate benefits of this change would be somewhat better type
safety and protection from GC misuses with non-GTY types (use pool or
obstack instead). Alternatives are bringing over type tag overhead to
the mainline as well, or starting working on explicit marker stack on
the top of ggc-page.

Any comments?

-- 
Laurynas

Re: RTL sharing bootstrap failure on sparc-sun-solaris2.10

[Christian Joensson]

2007/9/6, Kaveh R. GHAZI <[EMAIL PROTECTED]>:
> (Sorry, first one bounced from gcc@ because it was over 400k)
>
> Hi Jan,
>
> On sparc-sun-solaris2.10, I'm getting new bootstrap failures in stage2
> complaining several times about rtl sharing.  I've included four .i files
> for modules that ICEed during stage2, and the cc1 invocations below.
>
> Would you please take a look?
>
> Thanks,
> --Kaveh

FWIW, I get a similar problem on sparc/sparc64 linux.

-- 
Cheers,

/ChJ

Bootstrap broke today on mipsel-linux.

[David Daney]

With revision 128207

Configured: ../trunk/configure 
--prefix=/home/ddaney/gccsvn/trunk-install --target=mipsel-linux 
--build=mipsel-linux --host=mipsel-linux --with-gmp=/home/ddaney/mp 
--with-mpfr=/home/ddaney/mp --with-arch=sb1 --disable-java-awt 
--without-x --enable-__cxa_atexit --disable-jvmpi


I used to work:

http://gcc.gnu.org/ml/gcc-testresults/2007-09/msg00234.html


/home/ddaney/gccsvn/trunk-build/./gcc/xgcc -shared-libgcc 
-B/home/ddaney/gccsvn/trunk-build/./gcc -nostdinc++ 
-L/home/ddaney/gccsvn/trunk-build/mipsel-linux/libstdc++-v3/src 
-L/home/ddaney/gccsvn/trunk-build/mipsel-linux/libstdc++-v3/src/.libs 
-B/home/ddaney/gccsvn/trunk-install/mipsel-linux/bin/ 
-B/home/ddaney/gccsvn/trunk-install/mipsel-linux/lib/ -isystem 
/home/ddaney/gccsvn/trunk-install/mipsel-linux/include -isystem 
/home/ddaney/gccsvn/trunk-install/mipsel-linux/sys-include -Winvalid-pch 
-Wno-deprecated -x c++-header -g -O2   -D_GNU_SOURCE 
-I/home/ddaney/gccsvn/trunk-build/mipsel-linux/libstdc++-v3/include/mipsel-linux 
-I/home/ddaney/gccsvn/trunk-build/mipsel-linux/libstdc++-v3/include 
-I/home/ddaney/gccsvn/trunk/libstdc++-v3/libsupc++ -O2 -g 
/home/ddaney/gccsvn/trunk/libstdc++-v3/include/precompiled/extc++.h -o 
mipsel-linux/bits/extc++.h.gch/O2g.gch
In file included from 
/home/ddaney/gccsvn/trunk-build/mipsel-linux/libstdc++-v3/include/ext/pb_ds/detail/binary_heap_/binary_heap_.hpp:344,
from 
/home/ddaney/gccsvn/trunk-build/mipsel-linux/libstdc++-v3/include/ext/pb_ds/detail/priority_queue_base_dispatch.hpp:53,
from 
/home/ddaney/gccsvn/trunk-build/mipsel-linux/libstdc++-v3/include/ext/pb_ds/priority_queue.hpp:51,
from 
/home/ddaney/gccsvn/trunk/libstdc++-v3/include/precompiled/extc++.h:63:
/home/ddaney/gccsvn/trunk-build/mipsel-linux/libstdc++-v3/include/ext/pb_ds/detail/binary_heap_/insert_fn_imps.hpp: 
In member function 'void pb_ds::detail::binary_heap_Allocator>::insert_entry(typename 
__gnu_cxx::__conditional_typeCmp_Fn, Allocator>::simple_value, Value_Type, typename 
Allocator::rebind::other::pointer>::__type)':
/home/ddaney/gccsvn/trunk-build/mipsel-linux/libstdc++-v3/include/ext/pb_ds/detail/binary_heap_/insert_fn_imps.hpp:94: 
internal compiler error: tree check: expected integer_cst, have 
scope_ref in tree_int_cst_sgn, at tree.c:4974

Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Re: RTL sharing bootstrap failure on sparc-sun-solaris2.10

[Kaveh R. GHAZI]

On Thu, 6 Sep 2007, Jan Hubicka wrote:

> Hi,
> I already have fix for this just waiting for Andreas Tobler to verify
> that it does what expected.  If you could give it a try, it would be
> nice.
> Honza
>
> Index: reorg.c
> ===
> --- reorg.c   (revision 128145)
> +++ reorg.c   (working copy)
> @@ -3991,6 +3991,9 @@ dbr_schedule (rtx first)
> if (GET_CODE (pat) == SEQUENCE)
>   insn = XVECEXP (pat, 0, 0);
>   }
> +  if (INSN_P (insn) && GET_CODE (PATTERN (insn)) == USE
> +   && INSN_P (XEXP (PATTERN (insn), 0)))
> + delete_insn (insn);
>if (!JUMP_P (insn))
>   continue;

FWIW, this patch fixes the problem.  Test results here:
http://gcc.gnu.org/ml/gcc-testresults/2007-09/msg00313.html

I'll try again with your updated version tonight.

--Kaveh
--
Kaveh R. Ghazi  [EMAIL PROTECTED]