--- Comment #1 from simartin at gcc dot gnu dot org 2007-05-07 07:23
---
Hello.
I've had a look at the code, and the PRE dump apparently directly calls
print_generic_expr (not via default_tree_printer) with TDF_DIAGNOSTIC in the
dump flags. I'm not sure how those flags are setup...
I
--- Comment #2 from ghazi at gcc dot gnu dot org 2007-05-07 07:35 ---
I'll be doing the reentrant lgamma_r/gamma_r versions as well. (They're
actually easier because I get the signgam identifer as a pointer parameter
rather than having to find it at global scope.)
--
--- 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
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 #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]
*
--- 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
--- 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 constant
--- 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
--- 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 #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 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 @@
--- 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
script
--- 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 #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
It would be nice to have a builtin for memchr too, for many reasons. For
example, on the C++ library side, char_traitschar::find could be better
optimized; we could avoid including cstring anywhere in the headers
(__builtin_memcpy, memmove, memset, memcmp are already available!)...
--
--- 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
--- 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 #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 pointers
--
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
--
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 #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
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=
--- 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
--
--- 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
--- 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).
--
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
--- 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
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::RT) [with T = hpc::B]:
main.cpp:11: instantiated from here
func.h:14:
--- 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
30 matches
Mail list logo
