[Bug tree-optimization/36258] New: remove useless edge split in copy_loop_headers
The function copy_loop_headers after duplicate the region for a loop, 237 /* Ensure that the latch and the preheader is simple (we know that they 238 are not now, since there was the loop exit condition. */ 239 split_edge (loop_preheader_edge (loop)); 240 split_edge (loop_latch_edge (loop)); 241 } In fact, the statements in line 239 and 240 are useless because there will be no code motion optimizing (for example loop invariant movement) related to that splitting in this pass, and the edges created by above statements are removed by cfg cleanup in execute_todo that follows. I have comment out the statements of line 239 and 240, and bootstraped and tested on Linux i686 i686 i686 GNU/Linux. I also compared the output asm files on about 2000 C files under gcc.c-torture, there is no difference when compiled using the compilers before commenting out above statements and after commenting out the statements. Thanks alot Zhouyi Zhou -- Summary: remove useless edge split in copy_loop_headers Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: zhouyi04 at ios dot cn GCC build triplet: Linux i686 i686 i686 GNU/Linux GCC host triplet: Linux i686 i686 i686 GNU/Linux GCC target triplet: Linux i686 i686 i686 GNU/Linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36258
[Bug fortran/36257] SPREAD gives wrong results with CHARACTER variables
--- Comment #1 from pault at gcc dot gnu dot org 2008-05-18 10:03 --- Confirmed. This is quite revealing... implicit none character(len=5), dimension(3,3), parameter :: & p = reshape(["a", "b", "c", "d", "e", "f", "g", "h", "i"], [3,3]) character(len=5), dimension(3,3) :: m1 m1 = p print *, shape (spread (p, 1, 2)) print *, spread (p, 1, 2) print *, spread (p, 1, 2)//"z" ! print *, spread (p, 1, 2) /= spread (m1, 1, 2) ! if (any (spread (p, 1, 2) /= spread (m1, 1, 2))) call abort end The first two prints are OK but the third is completely screwed up. The front-end is not providing the right shape, to judge by the array descriptors provided for the temporaries. BTW characters are treated separately in the library - they all go to spread_internal. Thanks for that one! Maybe Thomas can pinpoint the problem right away? Cheers Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-05-18 10:03:00 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36257
[Bug fortran/36257] SPREAD gives wrong results with array CHARACTER parameters
--- Comment #2 from tkoenig at gcc dot gnu dot org 2008-05-18 10:42 ---
The problem is with the array parameter.
$ cat spread.f90
implicit none
character(len=5), dimension(3,3), parameter :: &
p = reshape(["a", "b", "c", "d", "e", "f", "g", "h", "i"], [3,3])
character(len=5), dimension(3,3) :: m1
m1 = p
print '(18A)', spread (p, 1, 2)//"z"
print '(18A)', spread (m1, 1, 2)//"z"
end
$ gfortran -fdump-tree-original -g spread.f90
$ gdb ./a.out
Breakpoint 1 (_gfortran_spread_char) pending.
(gdb) r
Starting program: /tmp/a.out
Breakpoint 2 at 0xb7f69f13: file
../../../../gcc/trunk/libgfortran/intrinsics/spread_generic.c, line 421.
Pending breakpoint "_gfortran_spread_char" resolved
Breakpoint 2, *_gfortran_spread_char (ret=0xbfe7d7b8, ret_length=5,
source=0xbfe7d80c,
along=0x8048dd4, pncopies=0x8048dd0, source_length=5)
at ../../../../gcc/trunk/libgfortran/intrinsics/spread_generic.c:422
422 spread_internal (ret, source, along, pncopies, source_length);
(gdb) p *source
$1 = {data = 0xbfe7d827 "abcç¿\001", offset = 0, dtype = 369, dim =
{{
stride = 1, lbound = 0, ubound = 2}, {stride = 1627389952, lbound =
538976288,
ubound = 538976354}, {stride = 538993440, lbound = -1075372000, ubound =
1}, {
stride = 0, lbound = -1075324808, ubound = -1208419248}, {stride =
-1075324752,
lbound = -1209229152, ubound = -1075317768}, {stride = -1075324652,
lbound = -1075324808, ubound = 134515769}, {stride = 1, lbound =
-1075324652,
ubound = -1075324792}}}
This is seriously flawed. The data pointer is wrong, as is the dtype.
Using m1 is ok:
(gdb) c
Continuing.
azazbzbzczcz
Breakpoint 2, *_gfortran_spread_char (ret=0xbfe7d758, ret_length=5,
source=0xbfe7d7b8,
along=0x8048dd4, pncopies=0x8048dd0, source_length=5)
at ../../../../gcc/trunk/libgfortran/intrinsics/spread_generic.c:422
422 spread_internal (ret, source, along, pncopies, source_length);
(gdb) p *source
$2 = {data = 0xbfe7d78b "abcdefghi
\213×ç¿üÿÿÿr\001",
offset = 4294967292, dtype = 370, dim = {{stride = 1, lbound = 1, ubound =
3}, {
stride = 3, lbound = 1, ubound = 3}, {stride = -1208504320, lbound =
543414304,
ubound = 2048925728}, {stride = -1075324928, lbound = 0, ubound = 0},
{stride = 1,
lbound = 0, ubound = 2}, {stride = 134516032, lbound = 134516037,
ubound = 134516042}, {stride = -1075324889, lbound = 0, ubound = 369}}}
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
Summary|SPREAD gives wrong results |SPREAD gives wrong results
|with CHARACTER variables|with array CHARACTER
||parameters
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36257
[Bug fortran/36251] PUBLIC and PRIVATE abuse
--- Comment #6 from burnus at gcc dot gnu dot org 2008-05-18 11:10 --- Subject: Bug 36251 Author: burnus Date: Sun May 18 11:10:11 2008 New Revision: 135495 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=135495 Log: 2008-05-18 Steven G. Kargl <[EMAIL PROTECTED]> PR fortran/36251 * symbol.c (check_conflict): Issue errors for abuse of PUBLIC, * PRIVATE, and BIND(C). * resolve.c (gfc_verify_binding_labels): Fix NULL pointer * dereference. 2008-05-18 Steven G. Kargl <[EMAIL PROTECTED]> PR fortran/36251 gfortran.dg/public_private_module.f90: new test. gfortran.dg/bind_c_module.f90: new test. Added: trunk/gcc/testsuite/gfortran.dg/bind_c_module.f90 trunk/gcc/testsuite/gfortran.dg/public_private_module.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/fortran/symbol.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36251
[Bug fortran/36251] PUBLIC and PRIVATE abuse
--- Comment #7 from burnus at gcc dot gnu dot org 2008-05-18 11:11 --- Fixed on the trunk (4.4.0). Thanks for the patch. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36251
[Bug ada/36250] --enable-threads=gnat stops build
--- Comment #1 from charlet at gcc dot gnu dot org 2008-05-18 11:15 --- --enable-threads=gnat is obsolete and will be removed as soon as someone submits a patch to that effect. Your report simply shows that nobody is using it these days (and use the default instead). Arno -- charlet at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36250
[Bug fortran/36257] SPREAD gives wrong results with array CHARACTER parameters
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2008-05-18 14:55
---
I have some more information, but it still doesn't make sense. I'm comparing
the codepaths taken in the front-end by:
implicit none
character(len=5), dimension(3,3), parameter :: &
p = reshape(["a", "b", "c", "d", "e", "f", "g", "h", "i"], [3,3])
character(len=5), dimension(3,3) :: m1
m1 = p
print '(18A)', spread (m1, 1, 2)//"z"
end
and:
implicit none
character(len=5), dimension(3,3), parameter :: &
p = reshape(["a", "b", "c", "d", "e", "f", "g", "h", "i"], [3,3])
print '(18A)', spread (p, 1, 2)//"z"
end
In both cases, we end up twice in gfc_resolve_spread, but while for a
non-parameter array, we always give the return type its correct rank (f->rank =
3), for the paramater array, we give it a rank of 2 the second time. That's
because in check_charlen_present(), the source->rank gets modified from 2 to
1). I don't understand why we do this (someone assumed that we can only have
array parameters with rank 1?)
So, commenting that piece of code there:
Index: iresolve.c
===
--- iresolve.c (revision 135395)
+++ iresolve.c (working copy)
@@ -78,7 +78,7 @@ check_charlen_present (gfc_expr *source)
{
source->ts.cl->length =
gfc_int_expr (source->value.constructor->expr->value.character.length);
- source->rank = 1;
+ /*source->rank = 1;*/
}
}
make that testcase work, but I wonder what else it breaks :)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36257
[Bug target/36259] New: libdecnumber/decNumber.c:711: internal compiler error: in reload_cse_simplify_operands, at postreload.c:395
In stage2,
source='../../gcc/libdecnumber/decNumber.c' object='decNumber.o' libtool=no
/Users/dave/gnu/gcc/objdir/./prev-gcc/xgcc
-B/Users/dave/gnu/gcc/objdir/./prev-gcc/
-B/opt/gnu/gcc/gcc-4.4.0/i686-apple-darwin9/bin/ -I../../gcc/libdecnumber -I.
-g -O2 -fomit-frame-pointer -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute
-Wcast-qual -pedantic -Wno-long-long -Werror -I../../gcc/libdecnumber -I. -c
../../gcc/libdecnumber/decNumber.c
../../gcc/libdecnumber/decNumber.c: In function 'decNumberFromString':
../../gcc/libdecnumber/decNumber.c:711: error: insn does not satisfy its
constraints:
(insn 739 337 338 69 ../../gcc/libdecnumber/decNumber.c:599 (set (mem/c:QI
(plus:SI (reg/f:SI 7 sp)
(const_int 31 [0x1f])) [316 prephitmp.4485+0 S1 A8])
(reg:QI 4 si)) 62 {*movqi_1} (nil))
../../gcc/libdecnumber/decNumber.c:711: internal compiler error: in
reload_cse_simplify_operands, at postreload.c:395
[EMAIL PROTECTED]:~/gnu/gcc/objdir/prev-gcc$ ./xgcc -B./ -v
Reading specs from ./specs
Target: i686-apple-darwin9
Configured with: ../gcc/configure --build=i686-apple-darwin9
--host=i686-apple-darwin9 --target=i686-apple-darwin9 --with-gnu-as
--with-tune=generic --prefix=/opt/gnu/gcc/gcc-4.4.0 --enable-debug=no
--disable-nls --enable-languages=c,c++,objc,fortran,ada,obj-c++,java
Thread model: posix
gcc version 4.4.0 20080518 (experimental) [trunk revision 135503] (GCC)
--
Summary: libdecnumber/decNumber.c:711: internal compiler error:
in reload_cse_simplify_operands, at postreload.c:395
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: danglin at gcc dot gnu dot org
GCC build triplet: i686-apple-darwin9
GCC host triplet: i686-apple-darwin9
GCC target triplet: i686-apple-darwin9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36259
[Bug fortran/35824] Overloading problems with derived type with allocatable array
--- Comment #3 from pault at gcc dot gnu dot org 2008-05-18 15:37 ---
> I have to admit, I did not quickly see in the dump (-fdump-tree-original) why
> it is failing; at a glance, both calling "neg_at" in MAIN__ and the assignment
> in "neg_at" itself look ok; and "t2 = -t1" also works.
The reason is that the lhs is deallocated and nulled before the assignment:
if (t1.b.data != 0B)
{
__builtin_free (t1.b.data);
}
t1.b.data = 0B;
D.722 = neg_at (&t1);
at_from_at (&t1, &D.722);
if (D.722.b.data != 0B)
{
__builtin_free (D.722.b.data);
}
D.722.b.data = 0B;
}
Thus a data null is passed to the neg_at.
If the operator assignment is deleted, so that we rely on the intrinsic
assignment for derived types with allocatable components, the correct result is
obtained:
D.719 = t2;
t2 = neg_at (&t1);
if (D.719.b.data != 0B)
{
__builtin_free (D.719.b.data);
}
D.719.b.data = 0B;
I'll have to see how that can be emulated.
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35824
[Bug middle-end/35509] [4.3/4.4 Regression] builtin isinf() mismatch to compile-time substitution
--- Comment #13 from ghazi at gcc dot gnu dot org 2008-05-18 15:51 --- Patch to implement a separate builtin isinf_sign posted here: http://gcc.gnu.org/ml/gcc-patches/2008-05/msg01067.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35509
[Bug target/36222] x86 fails to optimize out __v4si -> __m128i move
--- Comment #8 from uweigand at gcc dot gnu dot org 2008-05-18 15:58
---
That special case in find_reloads is really about a different situation.
We do not have a simple move here.
The problem also is not really related to vector instruction in particular;
reload doesn't at all care what the instructions actually do ...
There are two problems involved in this particular case, each of which
suffices to prevent optimal register allocation.
Before reload, we have
(insn:HI 10 27 11 2 d.c:7 (set (reg:V2SI 66)
(vec_concat:V2SI (mem/c/i:SI (reg/f:SI 16 argp) [2 x1+0 S4 A32])
(reg/v:SI 60 [ x2 ]))) 1338 {*vec_concatv2si_sse2}
(expr_list:REG_DEAD (reg/v:SI 60 [ x2 ])
(nil)))
where local register allocation has already selected hard registers
for *both* operands 0 and 2:
;; Register 60 in 21.
;; Register 66 in 21.
Now, the insn pattern offers those alternatives:
(define_insn "*vec_concatv2si_sse2"
[(set (match_operand:V2SI 0 "register_operand" "=x,x ,*y,*y")
(vec_concat:V2SI
(match_operand:SI 1 "nonimmediate_operand" " 0,rm, 0,rm")
(match_operand:SI 2 "reg_or_0_operand" " x,C ,*y, C")))]
As operand 2 is not zero ("C" constraint), reload must choose
the first alternative, which has a matching constraint between
operands 0 and 1.
This means that the choices selected by local-alloc (both operand
0 and 2 in the same register) *force* a reload of operand 0 here.
Why does local-alloc choose the same register for the two operands?
This happens because in general, there is no conflict between a
register that is used and set in the same insn, because usually the
same hard register *can* be used for both.
In this case this is not true, but local-alloc does not recognize
this. There is indeed code in block_alloc that tries to handle
matching constraints, but this only recognizes the more typical
scenario where *every* alternative requires a match.
Here, we seemingly have alternatives that do not require a match
-- of course, that doesn't help because in these alternatives
operand 2 is extremely constrained ("C" will only accept a constant
zero) and so they aren't actually usable ...
Even assuming local-alloc had made better choices, reload would still
generate an output reload. This second problem really comes down to
use of matching constraints between operands of different modes / sizes.
Once operand 0 was assigned to a hard register by local-alloc, reload
would generally attempt to also assign operand 1 to the same register,
in order to fulfill the matching constraint without requiring an
output reload.
This is done by the routine find_dummy_reload. However, in this
particular case, that routine immediately fails due to:
/* If operands exceed a word, we can't use either of them
unless they have the same size. */
if (GET_MODE_SIZE (outmode) != GET_MODE_SIZE (inmode)
&& (GET_MODE_SIZE (outmode) > UNITS_PER_WORD
|| GET_MODE_SIZE (inmode) > UNITS_PER_WORD))
return 0;
because operand 0 is two words in size, while operand 1 is just
a single word in size. I'm not completely sure this check (which
has been in SVN forever) is still required today ...
In any case, the simplest work-around might be to write that pattern
in a way that is easier to handle by local-alloc / reload: the two
cases x <- 0, x and x <- rm, C are nearly completely unrelated; why
not split them into two different insn patterns?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36222
[Bug fortran/35824] Overloading problems with derived type with allocatable array
--- Comment #4 from pault at gcc dot gnu dot org 2008-05-18 16:00 --- (In reply to comment #3) The patch that I have been working on, which is held up by memory leak problems, actually cures this fellow too. I am active again on all the allocatable component bugs. Watch this space. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2008-04-04 14:14:38 |2008-05-18 16:00:55 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35824
[Bug target/36222] x86 fails to optimize out __v4si -> __m128i move
--- Comment #9 from rguenth at gcc dot gnu dot org 2008-05-18 16:58 --- Did you investigate whether IRA fixes this issue? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36222
[Bug tree-optimization/36258] remove useless edge split in copy_loop_headers
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-05-18 16:59 --- Zdenek probably remembers why this was done. In any case, posting a patch to gcc-patches would be appropriate. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org, rakdver at gcc dot gnu ||dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36258
[Bug target/36259] libdecnumber/decNumber.c:711: internal compiler error: in reload_cse_simplify_operands, at postreload.c:395
--- Comment #1 from ubizjak at gmail dot com 2008-05-18 17:02 --- Hm, I have reverted my TARGET_SECONDARY_RELOAD patch while this issue is being investigated. For some reason, copying %esi to Q_REGS class doesn't happen... Fixed by reverting the problematic patch for now. -- ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36259
[Bug target/36259] libdecnumber/decNumber.c:711: internal compiler error: in reload_cse_simplify_operands, at postreload.c:395
--- Comment #2 from dominiq at lps dot ens dot fr 2008-05-18 17:51 ---
I got similar errors for an incremental update:
...
/opt/gcc/i686-darwin/./prev-gcc/xgcc -B/opt/gcc/i686-darwin/./prev-gcc/
-B/opt/gcc/gcc4.4w/i686-apple-darwin9/bin/ -c -g -O2 -fomit-frame-pointer
-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 -Werror -fno-common -DHAVE_CONFIG_H -I. -I.
-I../../gcc-4.4-work/gcc -I../../gcc-4.4-work/gcc/.
-I../../gcc-4.4-work/gcc/../include -I./../intl
-I../../gcc-4.4-work/gcc/../libcpp/include -I/sw/include
-I../../gcc-4.4-work/gcc/../libdecnumber
-I../../gcc-4.4-work/gcc/../libdecnumber/dpd -I../libdecnumber
../../gcc-4.4-work/gcc/tree.c -o tree.o
../../gcc-4.4-work/gcc/tree-vrp.c: In function 'find_case_label_range':
../../gcc-4.4-work/gcc/tree-vrp.c:5593: error: insn does not satisfy its
constraints:
(insn 692 79 80 6 ../../gcc-4.4-work/gcc/tree-vrp.c:5564 (set (mem/c:QI
(plus:SI (reg/f:SI 7 sp)
(const_int 35 [0x23])) [278 take_default+0 S1 A8])
(reg:QI 4 si)) 62 {*movqi_1} (nil))
../../gcc-4.4-work/gcc/tree-vrp.c:5593: internal compiler error: in
reload_cse_simplify_operands, at postreload.c:395
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
make[3]: *** [tree-vrp.o] Error 1
make[3]: *** Waiting for unfinished jobs
../../gcc-4.4-work/gcc/tree.c: In function 'build2_stat':
../../gcc-4.4-work/gcc/tree.c:3214: error: insn does not satisfy its
constraints:
(insn 698 299 699 51 ../../gcc-4.4-work/gcc/tree.c:3201 (set (mem/c:QI (plus:SI
(reg/f:SI 7 sp)
(const_int 64 [0x40])) [621 side_effects+0 S1 A8])
(reg:QI 4 si)) 62 {*movqi_1} (nil))
../../gcc-4.4-work/gcc/tree.c:3214: internal compiler error: in
reload_cse_simplify_operands, at postreload.c:395
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
make[3]: *** [tree.o] Error 1
make[2]: *** [all-stage2-gcc] Error 2
make[1]: *** [stage2-bubble] Error 2
make: *** [all] Error 2
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36259
[Bug middle-end/36037] [4.4 regression] segfault in gt_ggc_mx_dw_loc_descr_struct
--- Comment #3 from jv244 at cam dot ac dot uk 2008-05-18 17:52 --- I think this bug is back. Current gfortran fails again with: (gdb) run all.f90 -march=k8-sse3 -mcx16 -msahf --param l1-cache-size=64 --param l1-cache-line-size=64 --param l2-cache-size=1024 -mtune=k8 -quiet -dumpbase all.f90 -auxbase all -O3 -version -ffast-math -ftree-vectorize -fintrinsic-modules-path /data03/vondele/gcc_trunk/build/lib/gcc/x86_64-unknown-linux-gnu/4.4.0/finclude -o /tmp/ccJOx9ry.s Starting program: /data03/vondele/gcc_trunk/build/libexec/gcc/x86_64-unknown-linux-gnu/4.4.0/f951 all.f90 -march=k8-sse3 -mcx16 -msahf --param l1-cache-size=64 --param l1-cache-line-size=64 --param l2-cache-size=1024 -mtune=k8 -quiet -dumpbase all.f90 -auxbase all -O3 -version -ffast-math -ftree-vectorize -fintrinsic-modules-path /data03/vondele/gcc_trunk/build/lib/gcc/x86_64-unknown-linux-gnu/4.4.0/finclude -o /tmp/ccJOx9ry.s GNU Fortran (GCC) version 4.4.0 20080518 (experimental) [trunk revision 135494] (x86_64-unknown-linux-gnu) compiled by GNU C version 4.4.0 20080518 (experimental) [trunk revision 135494], GMP version 4.2.1, MPFR version 2.2.1. GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Program received signal SIGSEGV, Segmentation fault. ggc_set_mark (p=0x2) at /data03/vondele/gcc_trunk/gcc/gcc/ggc-page.c:584 584 while (table->high_bits != high_bits) (gdb) bt #0 ggc_set_mark (p=0x2) at /data03/vondele/gcc_trunk/gcc/gcc/ggc-page.c:584 #1 0x00485568 in gt_ggc_mx_lang_tree_node (x_p=) at ./gt-fortran-f95-lang.h:49 #2 0x0048667f in gt_ggc_mx_lang_type (x_p=) at ./gtype-fortran.h:64 #3 0x00485b24 in gt_ggc_mx_lang_tree_node (x_p=) at ./gt-fortran-f95-lang.h:338 #4 0x00485acb in gt_ggc_mx_lang_tree_node (x_p=) at ./gt-fortran-f95-lang.h:333 #5 0x00485acb in gt_ggc_mx_lang_tree_node (x_p=) at ./gt-fortran-f95-lang.h:333 #6 0x00485acb in gt_ggc_mx_lang_tree_node (x_p=) at ./gt-fortran-f95-lang.h:333 #7 0x00485acb in gt_ggc_mx_lang_tree_node (x_p=) at ./gt-fortran-f95-lang.h:333 #8 0x00485acb in gt_ggc_mx_lang_tree_node (x_p=) at ./gt-fortran-f95-lang.h:333 #9 0x00485acb in gt_ggc_mx_lang_tree_node (x_p=) at ./gt-fortran-f95-lang.h:333 #10 0x00485acb in gt_ggc_mx_lang_tree_node (x_p=) at ./gt-fortran-f95-lang.h:333 #11 0x00485acb in gt_ggc_mx_lang_tree_node (x_p=) at ./gt-fortran-f95-lang.h:333 #12 0x00485acb in gt_ggc_mx_lang_tree_node (x_p=) at ./gt-fortran-f95-lang.h:333 #13 0x00485acb in gt_ggc_mx_lang_tree_node (x_p=) at ./gt-fortran-f95-lang.h:333 #14 0x00485acb in gt_ggc_mx_lang_tree_node (x_p=) at ./gt-fortran-f95-lang.h:333 #15 0x00485acb in gt_ggc_mx_lang_tree_node (x_p=) at ./gt-fortran-f95-lang.h:333 #16 0x00485acb in gt_ggc_mx_lang_tree_node (x_p=) at ./gt-fortran-f95-lang.h:333 #17 0x00485acb in gt_ggc_mx_lang_tree_node (x_p=) at ./gt-fortran-f95-lang.h:333 #18 0x00485acb in gt_ggc_mx_lang_tree_node (x_p=) at ./gt-fortran-f95-lang.h:333 #19 0x00485acb in gt_ggc_mx_lang_tree_node (x_p=) at ./gt-fortran-f95-lang.h:333 #20 0x00485acb in gt_ggc_mx_lang_tree_node (x_p=) at ./gt-fortran-f95-lang.h:333 #21 0x00485acb in gt_ggc_mx_lang_tree_node (x_p=) at ./gt-fortran-f95-lang.h:333 #22 0x00485acb in gt_ggc_mx_lang_tree_node (x_p=) at ./gt-fortran-f95-lang.h:333 #23 0x00485acb in gt_ggc_mx_lang_tree_node (x_p=) at ./gt-fortran-f95-lang.h:333 #24 0x00485acb in gt_ggc_mx_lang_tree_node (x_p=) at ./gt-fortran-f95-lang.h:333 #25 0x00485acb in gt_ggc_mx_lang_tree_node (x_p=) at ./gt-fortran-f95-lang.h:333 #26 0x00485acb in gt_ggc_mx_lang_tree_node (x_p=) at ./gt-fortran-f95-lang.h:333 #27 0x00485acb in gt_ggc_mx_lang_tree_node (x_p=) at ./gt-fortran-f95-lang.h:333 #28 0x00485acb in gt_ggc_mx_lang_tree_node (x_p=) at ./gt-fortran-f95-lang.h:333 #29 0x00485acb in gt_ggc_mx_lang_tree_node (x_p=) at ./gt-fortran-f95-lang.h:333 #30 0x00485acb in gt_ggc_mx_lang_tree_node (x_p=) at ./gt-fortran-f95-lang.h:333 #31 0x00485acb in gt_ggc_mx_lang_tree_node (x_p=) at ./gt-fortran-f95-lang.h:333 #32 0x00485acb in gt_ggc_mx_lang_tree_node (x_p=) at ./gt-fortran-f95-lang.h:333 #33 0x00485acb in gt_ggc_mx_lang_tree_node (x_p=) at ./gt-fortran-f95-lang.h:333 #34 0x00485acb in gt_ggc_mx_lang_tree_node (x_p=) at ./gt-fortran-f95-lang.h:333 #35 0x00485acb in gt_ggc_mx_lang_tree_node (x_p=) at ./gt-fortran-f95-lang.h:333 #36 0x00485acb in gt_ggc_mx_lang_tree_node (x_p=) at ./gt-fortran-f95-lang.h:333 #37 0x00485acb in gt_ggc_mx_lang_tree_node (x_p=) at ./gt-fortran-f95-lang.h:333 #38 0x00485acb in gt_ggc_mx_lang_tree_node (x_p=) at ./gt-fortran-f95-lang.h:333 #39 0x00485acb in gt_ggc_mx_lang_tree_node (x_p=) at ./gt-fortran-f95-lang.h:333 #40 0x00485acb
[Bug middle-end/36037] [4.4 regression] segfault in gt_ggc_mx_dw_loc_descr_struct
--- Comment #4 from jv244 at cam dot ac dot uk 2008-05-18 17:59 --- the end of the backtrace (notice the depth) might be useful as well: #78681 0x00486421 in gt_ggc_mx_lang_tree_node (x_p=) at ./gt-fortran-f95-lang.h:290 #78682 0x00632f85 in gt_ggc_mx_cgraph_node (x_p=) at gtype-desc.c:161 #78683 0x00633236 in gt_ggc_m_P11cgraph_node4htab (x_p=) at gtype-desc.c:1852 #78684 0x0061203f in ggc_mark_roots () at /data03/vondele/gcc_trunk/gcc/gcc/ggc-common.c:104 #78685 0x004d0279 in ggc_collect () at /data03/vondele/gcc_trunk/gcc/gcc/ggc-page.c:1895 #78686 0x0067a235 in execute_todo (flags=34871) at /data03/vondele/gcc_trunk/gcc/gcc/passes.c:1051 #78687 0x0067a4c4 in execute_one_pass (pass=0xf16380) at /data03/vondele/gcc_trunk/gcc/gcc/passes.c:1307 #78688 0x0067a6a5 in execute_pass_list (pass=0xf16380) at /data03/vondele/gcc_trunk/gcc/gcc/passes.c:1335 #78689 0x0067a6bd in execute_pass_list (pass=0xf15ea0) at /data03/vondele/gcc_trunk/gcc/gcc/passes.c:1336 #78690 0x0067a99e in execute_ipa_pass_list (pass=0xf15e40) at /data03/vondele/gcc_trunk/gcc/gcc/passes.c:892 #78691 0x0091a76d in cgraph_optimize () at /data03/vondele/gcc_trunk/gcc/gcc/cgraphunit.c:1336 #78692 0x00484e65 in gfc_be_parse_file (set_yydebug=) at /data03/vondele/gcc_trunk/gcc/gcc/fortran/f95-lang.c:262 #78693 0x006ffa68 in toplev_main (argc=, argv=) at /data03/vondele/gcc_trunk/gcc/gcc/toplev.c:963 #78694 0x2b0d19a7c154 in __libc_start_main () from /lib64/libc.so.6 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36037
rshift problem
cat rshift.c
#include
#include
int main(void)
{
unsigned j = ~0 >> 8;
unsigned i = ~0;
i >>= 8;
printf("i = %x\n", i);
printf("j = %x\n", j);
exit(0);
}
gcc -o rshift rshift.c -Wall -g
[EMAIL PROTECTED]:~/b1systems/ckurs> ./rshift
i = ff
j =
[EMAIL PROTECTED]:~/b1systems/ckurs> gcc --version
gcc (GCC) 4.2.1 (SUSE Linux)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Am I just doing something wrong? Why aren't i and j equal?
Re: rshift problem
On Sun, May 18, 2008 at 11:24 AM, John Kacur <[EMAIL PROTECTED]> wrote:
> int main(void)
> {
> unsigned j = ~0 >> 8;
The above is signed right shift which will keep the sign bit and replicate it.
> unsigned i = ~0;
> i >>= 8;
While this is an unsigned right shift.
-- Pinski
[Bug target/36090] [4.3/4.4 Regression] ppc64 cacoshl miscompilation
--- Comment #41 from jakub at gcc dot gnu dot org 2008-05-18 18:31 --- The bug is fixed there (though with the safer rs6000 specific fix), just the testcase hasn't been committed. I'll do that later tonight. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36090
[Bug fortran/36260] New: Audit intrinsic.texi and check whether keyword= names match
See http://gcc.gnu.org/ml/fortran/2008-05/msg00207.html
Currently, the keywords used in intrinsic.texi don't match intrinsic.c.
(So far for all non-vendor extensions, intrinsic.c was correct.)
TODO:
- FSTAT: Fix intrinsic.{texi,c} argument-name mismatch
- FREE: Fix intrinsic.{texi,c} argument-name mismatch
- Everything after LINK needs to be audited
and the problems mentioned at c.l.f. need to be fixed*
- LINK needs to be fixed. Currently there is a mismatch of the keywords between
the subroutine and function version (in intrinsic.c) and neither of them
matches intrinsic.texi.
*
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/07bc8e6635971853
- MOVE_ALLOC(SRC, DEST) should be MOVE_ALLOC(FROM, TO)
- loc(ARRAY), nint(A), write(*,*) real(A), sizeof(I)
--
Summary: Audit intrinsic.texi and check whether keyword= names
match
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: documentation
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36260
[Bug target/36090] [4.3/4.4 Regression] ppc64 cacoshl miscompilation
--- Comment #42 from jakub at gcc dot gnu dot org 2008-05-18 20:19 --- Subject: Bug 36090 Author: jakub Date: Sun May 18 20:19:03 2008 New Revision: 135508 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=135508 Log: PR target/36090 * gcc.c-torture/execute/20080502-1.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/execute/20080502-1.c Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36090
[Bug target/36090] [4.3/4.4 Regression] ppc64 cacoshl miscompilation
--- Comment #43 from jakub at gcc dot gnu dot org 2008-05-18 20:20 --- Subject: Bug 36090 Author: jakub Date: Sun May 18 20:19:55 2008 New Revision: 135509 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=135509 Log: PR target/36090 * gcc.c-torture/execute/20080502-1.c: New test. Added: branches/gcc-4_3-branch/gcc/testsuite/gcc.c-torture/execute/20080502-1.c Modified: branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36090
[Bug target/36090] [4.3/4.4 Regression] ppc64 cacoshl miscompilation
--- Comment #44 from jakub at gcc dot gnu dot org 2008-05-18 20:24 --- The bug I've reported is fixed both on the trunk and on the branch, although with different patches. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36090
[Bug fortran/36167] ICE in gfc_conv_descriptor_dimension, at fortran/trans-array.c:242
--- Comment #3 from pault at gcc dot gnu dot org 2008-05-18 21:02 --- Frank, I am downgrading this to 'normal' severity - 'major' is reserved for fairly cataclysmic bugs for the whole of gcc. 'ice-on-valid-code' will catch the attention of gfortran developers. I'll try to come back to it when I have sorted the allocatable component memory leaks. Thanks Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Severity|major |normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36167
[Bug c++/35025] [4.3 regression] ICE with invalid specialization of variadic template
--- Comment #2 from reichelt at gcc dot gnu dot org 2008-05-18 21:57 --- Fixed on mainline - probably by the patch for PR 35331. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.3/4.4 regression] ICE|[4.3 regression] ICE with |with invalid specialization |invalid specialization of |of variadic template|variadic template http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35025
[Bug c++/36261] New: Static const member data not found when used in a template
This small program cannot be compiled. It failes with an "undefined reference
to `A::N'" error. Replacing the main function line with:
std::cout << "Number: " << std::min(1, (int)A::N) << "\n";
results in a successful compilation.
This is the small program to reproduce the bug:
#include
#include
struct A {
static const int N = 2;
};
int main ()
{
std::cout << "Number: " << std::min(1, A::N) << "\n";
}
--
Summary: Static const member data not found when used in a
template
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Bernd dot Donner at gmx dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36261
[Bug c++/36261] Static const member data not found when used in a template
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-05-18 22:52 --- std::min(1, A::N) std::min takes a reference to a const type which means you need the defintion of A::N including the definition. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36261
[Bug c++/36261] Static const member data not found when used in a template
--- Comment #2 from paolo dot carlini at oracle dot com 2008-05-18 22:58 --- In other terms, just add, after the declaration of struct A: const int A::N; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36261
[Bug c/36262] New: Extreme memory usage compared to older versions
While compiling the NES emulator FCE Ultra for my new Fedora 9 system (x86-64), I noticed that gcc 4.3.0 (or at least Fedora's version of it) used so much memory on some of the files that my system almost crashed. The preprocessed source code that trigger this bug is attached here. This seems to be a regression, as I have not been able to reproduce it on Fedora's gcc 3.4.6 (compat-gcc-34-3.4.6-9.x86_64), nor on gcc 4.1.2 on my old system (Slackware 12). I search for other memory related bugs in gcc 4.3, and found a couple that mention similar problems, so it's possible (or even probable) that this is a duplicate. I'm not sure, though, so I've created this bug report just so you can take a quick look at the problem and dismiss it if there's nothing new here. Sorry about the length of the code that reproduces the bug, by the way. It's a 20 thousand line file with, what looks like, machine-generated C code. -- Summary: Extreme memory usage compared to older versions Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hakonrk at fys dot uio dot no http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36262
[Bug c/36262] Extreme memory usage compared to older versions
--- Comment #1 from hakonrk at fys dot uio dot no 2008-05-18 23:07 --- Created an attachment (id=15653) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15653&action=view) Uses gigabytes of memory when compiled with optimizations on 4.3.0 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36262
[Bug fortran/36176] TRANSFER of constant substrings
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2008-05-18 23:07 --- Fixed on 4.4 and 4.3. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Summary|[4.3] TRANSFER of constant |TRANSFER of constant |substrings |substrings Target Milestone|--- |4.3.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36176
[Bug middle-end/35509] [4.3/4.4 Regression] builtin isinf() mismatch to compile-time substitution
--- Comment #14 from ghazi at gcc dot gnu dot org 2008-05-18 23:20 --- Subject: Bug 35509 Author: ghazi Date: Sun May 18 23:19:38 2008 New Revision: 135517 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=135517 Log: PR middle-end/35509 * builtins.c (mathfn_built_in_1): Renamed from mathfn_built_in. Add `implicit' parameter. Handle BUILT_IN_SIGNBIT. (mathfn_built_in): Rewrite in terms of mathfn_built_in_1. (fold_builtin_classify): Handle BUILT_IN_ISINF_SIGN. (fold_builtin_1): Likewise. * builtins.def (BUILT_IN_ISINF_SIGN): New. c-common.c (check_builtin_function_arguments): Handle BUILT_IN_ISINF_SIGN. * doc/extend.texi: Document __builtin_isinf_sign. * fold-const.c (operand_equal_p): Handle COND_EXPR. testsuite: * gcc.dg/builtins-error.c: Test __builtin_isinf_sign. * gcc.dg/tg-tests.h: Likewise. Mark variables volatile. * gcc.dg/torture/builtin-isinf_sign-1.c: New test. Modified: trunk/gcc/ChangeLog trunk/gcc/builtins.c trunk/gcc/builtins.def trunk/gcc/c-common.c trunk/gcc/doc/extend.texi trunk/gcc/fold-const.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/builtins-error.c trunk/gcc/testsuite/gcc.dg/tg-tests.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35509
[Bug c++/36261] Static const member data not found when used in a template
--- Comment #3 from Bernd dot Donner at gmx dot net 2008-05-19 00:00
---
(In reply to comment #2)
> In other terms, just add, after the declaration of struct A:
>
> const int A::N;
>
According to the C++ standard "static const" member variables can be declarend
_and_ defined immediately inside the declaration of the class. It should not be
neccessary to declare A::N outside the class again. Other compilers "microsoft
express 2005" by the way do accept this code. The definition of A::N is
present. Otherwise, why does this code compile and link fine?
This program is accepted by gcc:
#include
#include
struct A {
static const int N = 2;
};
int main ()
{
std::cout << "Number: " << A::N << "\n";
}
This program is _not_ accepted by gcc:
#include
#include
struct A {
static const int N = 2;
};
int main ()
{
std::cout << "Number: " << std::min(1, A::N) << "\n";
}
Static const member variables may be defined and declared the way I have
proposed. According to the standard it is no more neccessary to provide a
declaration outside the class, I know that this was once neccessary. The web is
full of examples that shows that my declaration and definition of A::N is legal
in C++. Sorry, for insisting to look at this problem once again.
--
Bernd dot Donner at gmx dot net changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36261
[Bug c++/36261] Static const member data not found when used in a template
--- Comment #4 from paolo dot carlini at oracle dot com 2008-05-19 00:10 --- *** This bug has been marked as a duplicate of 30745 *** -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36261
[Bug c++/30745] Undefined static const
--- Comment #6 from paolo dot carlini at oracle dot com 2008-05-19 00:10 --- *** Bug 36261 has been marked as a duplicate of this bug. *** -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||Bernd dot Donner at gmx dot ||net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30745
[Bug c++/36261] Static const member data not found when used in a template
--- Comment #5 from paolo dot carlini at oracle dot com 2008-05-19 00:16 --- And you are certainly wrong that the Standard allows to omit the definition, in this case. This is 9.4.2/4 oc C++03, note the last sentence: If a static data member is of const integral or const enumeration type, its declaration in the class definition can specify aconstant-initializer which shall be an integral constant expression (5.19). In that case, the member can appear in integral constant expressions. The member shall still be defined in a name-space scope if it is used in the program and the namespace scope definition shall not contain aninitializer. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36261
[Bug c++/36261] Static const member data not found when used in a template
--- Comment #6 from Bernd dot Donner at gmx dot net 2008-05-19 00:18 --- Sorry, this is my fault your comments are correct. -- Bernd dot Donner at gmx dot net changed: What|Removed |Added Resolution|DUPLICATE |INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36261
[Bug tree-optimization/26854] Inordinate compile times on large routines
--- Comment #66 from vmakarov at redhat dot com 2008-05-19 02:00 --- The problem with IRA was in too many allocnos to be chosen for spilling. The most tome was spent in choosing the best allocno for spilling. The patch solving the problem is coming. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
[Bug tree-optimization/26854] Inordinate compile times on large routines
--- Comment #67 from vmakarov at gcc dot gnu dot org 2008-05-19 02:03 --- Subject: Bug 26854 Author: vmakarov Date: Mon May 19 02:02:52 2008 New Revision: 135523 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=135523 Log: 2008-05-18 Vladimir Makarov <[EMAIL PROTECTED]> PR tree-optimization/26854 * timevar.def (TV_RELOAD): New timer. * ira.c (ira): Use TV_IRA and TV_RELOAD. (pass_ira): Remove TV_IRA. * Makefile.in (ira-color.o): Add SPLAY_TREE_H. * ira-conflicts.c (DEF_VEC_P, DEF_ALLOCC_P): Move to ira-int.h. * ira-int.h (DEF_VEC_P, DEF_ALLOCC_P): Move from ira-conflicts.c and ira-color.c. (struct allocno): New bitfield splay_removed_p. (ALLOCNO_MAY_BE_SPILLED_P): New macro. * ira-color.c (splay-tree.h): Add the header. (allocno_spill_priority_compare, splay_tree_allocate, splay_tree_free): New functions. (DEF_VEC_P, DEF_ALLOCC_P): Move to ira-int.h. (sorted_allocnos_for_spilling): Rename to allocnos_for_spilling. (splay_tree_node_pool, removed_splay_allocno_vec, uncolorable_allocnos_num, uncolorable_allocnos_splay_tree): New global variables. (add_allocno_to_bucket, add_allocno_to_ordered_bucket, delete_allocno_from_bucket): Update uncolorable_allocnos_num. (USE_SPLAY_P): New macro. (push_allocno_to_stack): Remove allocno from the splay tree. (push_allocnos_to_stack): Use the splay trees. (do_coloring): Create and finish splay_tree_node_pool. Move allocation/deallocation of allocnos_for_spilling to here... (initiate_ira_assign, finish_ira_assign): Move allocnos_for_spilling from here... (ira_color): Allocate/deallocate removed_splay_allocno_vec. * ira-build.c (DEF_VEC_P, DEF_ALLOCC_P): Move to ira-int.h. (create_allocno): Initiate ALLOCNO_SPLAY_REMOVED_P. Modified: branches/ira/gcc/ChangeLog branches/ira/gcc/Makefile.in branches/ira/gcc/ira-build.c branches/ira/gcc/ira-color.c branches/ira/gcc/ira-conflicts.c branches/ira/gcc/ira-int.h branches/ira/gcc/ira.c branches/ira/gcc/timevar.def -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
[Bug tree-optimization/26854] Inordinate compile times on large routines
--- Comment #68 from vmakarov at redhat dot com 2008-05-19 02:08 --- The patch solving IRA problem is described in http://gcc.gnu.org/ml/gcc-patches/2008-05/msg01093.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
[Bug middle-end/35509] [4.3/4.4 Regression] builtin isinf() mismatch to compile-time substitution
--- Comment #15 from ghazi at gcc dot gnu dot org 2008-05-19 06:16 --- Addressed this by adding __builtin_isinf_sign() -- ghazi at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35509
[Bug middle-end/35509] [4.3/4.4 Regression] builtin isinf() mismatch to compile-time substitution
-- ghazi at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ghazi at gcc dot gnu dot org |dot org | Status|REOPENED|ASSIGNED Last reconfirmed|2008-04-13 16:27:57 |2008-05-19 06:16:49 date|| Target Milestone|4.3.1 |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35509
[Bug middle-end/35509] [4.3/4.4 Regression] builtin isinf() mismatch to compile-time substitution
--- Comment #16 from ghazi at gcc dot gnu dot org 2008-05-19 06:19 --- Fixed in 4.4.0 by adding a new builtin for systems that care about the sign of isinf's return value. E.g. do this: #define isinf(x) __builtin_isinf_sign(x) -- ghazi at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||4.4.0 Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35509
