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 -
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: "Ric
> > 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:/
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
> 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 ru
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../.
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
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 po
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 paramete
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
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 in
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
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.f
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.
>
> Wha
> 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 in
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../
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
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 t
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,
> 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
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() su
> > 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 tes
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
avoi
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
Ru
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 "__attrib
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 fing
$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 v
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 m
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++,tre
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
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 invocati
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
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
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 `conv
> (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.
> 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 (us
>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
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 dele
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.
>
>
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 (st
> 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_
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 l
> 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 we
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 big
> 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
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
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
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 +
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
functi
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
> 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 t
> 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
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
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
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 d
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-j
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
> ===
> ---
57 matches
Mail list logo
