--- Comment #11 from rakdver at gcc dot gnu dot org 2007-05-07 14:25
---
(In reply to comment #10)
> So this comes down to the orders of passes? At least that is what is being
> said as far as I can tell (though maybe flow is just too stupid to pull back
> the increment and have it as
With or without "using boo::work" in func.h, it doesn't pick the template
function in the namespace. However, changing "work(a)" to "work(10)" in func.h
compiles.
g++ error report:
func.h: In function void boo::rfunc(const boo::R&) [with T = hpc::B]:
main.cpp:11: instantiated from here
func.h:
--- Comment #2 from dberlin at gcc dot gnu dot org 2007-05-07 14:02 ---
Subject: Re: [4.3 Regression] Printing to dump file broken
On 7 May 2007 06:23:40 -, simartin at gcc dot gnu dot org
<[EMAIL PROTECTED]> wrote:
>
>
> --- Comment #1 from simartin at gcc dot gnu dot org 200
This testcase ICEs with current mainline:
--cut here--
_Decimal128 d128;
long double tf;
void foo (void)
{
d128 = tf;
}
--cut here--
gcc -O -std=gnu99
074.c: In function âfooâ:
074.c:6: internal compiler error: in cgraph_local_info, at cgraph.c:618
Please submit a full bug report,
with prepro
--- Comment #10 from pinskia at gcc dot gnu dot org 2007-05-07 13:57
---
So this comes down to the orders of passes? At least that is what is being
said as far as I can tell (though maybe flow is just too stupid to pull back
the increment and have it as being free).
--
http://gcc.
--- Comment #9 from rearnsha at gcc dot gnu dot org 2007-05-07 13:50
---
(In reply to comment #8)
>
> actually, this should save one addition (only the index is incremented, the
> additions of index to bases are done in the addressing mode).
When a machine has a post-increment instru
--- Comment #17 from patchapp at dberlin dot org 2007-05-07 13:45 ---
Subject: Bug number preprocessor/14331
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-05/msg00399.html
--
http://gcc.gnu.org
I get the following while bootstrapping gcc on a Tru64 alpha:
/bin/ksh ./libtool --mode=compile
/freeware/gcc/build/4.1.2/gcc-alpha-build/gcc/gcj
-B/freeware/gcc/build/4.1.2/gcc-alpha-build/alpha-dec-osf5.1/libjava/
-B/freeware/gcc/build/4.1.2/gcc-alpha-build/gcc/ -mieee -fclasspath=
-fbootclasspa
--- Comment #10 from rleigh at debian dot org 2007-05-07 13:04 ---
Also fails with GCC 4.1.3.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14258
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot
|dot org
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-05-07 12:04 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot
|dot org
--- Comment #8 from rakdver at gcc dot gnu dot org 2007-05-07 11:22 ---
(In reply to comment #7)
> Here's another example of code that is now significantly worse (~20% larger).
> Rather than incrementing the base pointers on each iteration of the loop, we
> now maintain both base pointe
--- Comment #21 from ubizjak at gmail dot com 2007-05-07 11:11 ---
Patch at http://gcc.gnu.org/ml/gcc-patches/2007-05/msg00390.html
--
ubizjak at gmail dot com changed:
What|Removed |Added
---
--- Comment #14 from ebotcazou at gcc dot gnu dot org 2007-05-07 10:58
---
> Should -finline-functions be excluded from the default -O3 options?
> (until mended. If it can't be trusted building the comopiler, can it be
> trusted for anything else?)
-finline-functions is very likely not
It would be nice to have a builtin for memchr too, for many reasons. For
example, on the C++ library side, char_traits::find could be better
optimized; we could avoid including anywhere in the headers
(__builtin_memcpy, memmove, memset, memcmp are already available!)...
--
Summary: M
--- Comment #7 from rearnsha at gcc dot gnu dot org 2007-05-07 10:43
---
Here's another example of code that is now significantly worse (~20% larger).
Rather than incrementing the base pointers on each iteration of the loop, we
now maintain both base pointers and and offset. This cost
--- Comment #13 from anirkko at insel dot ch 2007-05-07 10:33 ---
(In addition to comment #12)
PS: The above was done on sparcv9 (UltraSparc-III)
with Solaris 8. Thus, the bug is confirmed on
several machines with several versions of Solaris
and several versions of binutils
--- Comment #12 from anirkko at insel dot ch 2007-05-07 10:29 ---
(In reply to comment #10)
...
> Yes, I'm going to reopen it, but I'm not sure someone will tackle it.
>
The culprit is -finline-functions:
The gcc man page says -O3 adds only 3 additional options. My bootstrapping
scrip
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-05-07 09:59
---
Tentative patch:
Index: intrinsics/system.c
===
--- intrinsics/system.c (revision 124460)
+++ intrinsics/system.c (working copy)
@@ -49,6 +49,9 @@ s
--- Comment #6 from stevenb dot gcc at gmail dot com 2007-05-07 09:46
---
Subject: Re: [4.2/4.3 Regression] Code size regression caused by fix to PR
31360
Constant / copy simplifications should be done in at least CSE,
fwprop, and the gcse CPROP passes (we run CPROP three times!).
-
--- Comment #3 from pault at gcc dot gnu dot org 2007-05-07 09:45 ---
This will be fixed at the same time as PR29786. This, in its turn, is awaiting
the fix for PR18769, where Brooks is wading through the necessary gcc
modifications.
Paul
--
pault at gcc dot gnu dot org changed:
--- Comment #5 from rakdver at kam dot mff dot cuni dot cz 2007-05-07
09:38 ---
Subject: Re: [4.2/4.3 Regression] Code size regression caused by fix to PR
31360
> (In reply to comment #2)
> > > 1) Hoists a register containing 0 out of the loop
> > The correct thing to do.
> >
> Not ne
--- Comment #4 from rearnsha at gcc dot gnu dot org 2007-05-07 09:34
---
(In reply to comment #2)
> > 1) Hoists a register containing 0 out of the loop
> The correct thing to do.
>
Not necessarily. Hoisting literal constants means that opportunities to simply
insns based on that consta
--- Comment #5 from pault at gcc dot gnu dot org 2007-05-07 08:59 ---
(In reply to comment #4)
FX,
integer,parameter :: i(1,1) = reshape ((/0/),(/1,1/))
! integer,parameter :: i(1,1) = 1
integer :: j(1)
j = lbound(any(i==1,2))
print *, j
end
works correctly, so it is the in
--- Comment #20 from ubizjak at gmail dot com 2007-05-07 08:51 ---
Following one-liner fixes the failure. Note that this is for i386 only, as we
also need to skip other autoinc/autodec references.
This is now a generic RTL problem.
2007-05-07 Uros Bizjak <[EMAIL PROTECTED]>
Suppose, you have the following C-File (input.c), empty.h is just an empty
file:
#include "empty.h"
void dummy(void) {
}
Issue the command:
gcc -c input.c -MD -MT foo.o -o input.o
The content of input.d is:
foo.o input.o: input.c empty.h
but I would expect:
foo.o: input.c empty.h
which also is
--- Comment #19 from ubizjak at gmail dot com 2007-05-07 08:19 ---
Here is the problem:
Compilation enteres emit_move_via_integer() with:
x = (mem/i:SD (pre_dec:SI (reg/f:SI 7 sp)) [0 S4 A32])
y = (reg/v:SD 59 [ arg ])
emit_move_change_mode() generates invalid insn from x because it fo
28 matches
Mail list logo
