[Bug tree-optimization/33389] [4.3 Regression] Revision 128239 causes libgomp failure
--- Comment #2 from jh at suse dot cz 2007-09-12 12:01 --- Subject: Re: [4.3 Regression] Revision 128239 causes libgomp failure Hi, I´ve just tested ia64-linux and x86_64-linux on our testers and both are clean WRT libgomp: === libgomp Summary === # of expected passes496 it might be some sort of race condition (I sometimes see libgomp failures appear and go such as: libgomp.fortran/omp_parse3.f90 -O0 execution test One obvious difference is that we now consider functions produced by OMP lowering inlinable. This can be avoided by: Index: omp-low.c === *** omp-low.c (revision 128412) --- omp-low.c (working copy) *** expand_omp_parallel (struct omp_region * *** 2589,2594 --- 2589,2595 /* Inform the callgraph about the new function. */ DECL_STRUCT_FUNCTION (child_fn)->curr_properties = cfun->curr_properties; + DECL_UNINLINABLE (child_fn) = true; cgraph_add_new_function (child_fn, true); /* Fix the callgraph edges for child_cfun. Those for cfun will be I am not sure if the functions was uninlinable by decision or just because someone forgot to play with DECL_INLINE, but can you test this if it makes any difference? I can not think of any other difference this patch sould cause especially with -finline-functions. Jakub, is libgomp safe wrt inlining? Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33389
[Bug tree-optimization/33389] [4.3 Regression] Revision 128239 causes libgomp failure
--- Comment #4 from jh at suse dot cz 2007-09-12 14:16 --- Subject: Re: [4.3 Regression] Revision 128239 causes libgomp failure > > Have you compared the times to take for "make check" on libgomp between > revision 128238 and HEAD? With C libgomp tests only, revision 128238 takes > less than 15 seconds on a 1.5GHz ia64 machine. Revision 128239 takes more > than 20 minutes plus random failures. Interesting. At the moment I can't access any ia64 machine directly, just test via our mail based interface that won't let me time the test. Are those failures an timeouts? It might be some sort of deadlocking... Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33389
[Bug tree-optimization/33383] [4.3 Regression] Revision 128092 miscompiles 400.perlbench
--- Comment #14 from jh at suse dot cz 2007-10-15 11:39 ---
Subject: Re: [4.3 Regression] Revision 128092 miscompiles 400.perlbench
>
> when sv.c is compiled with -O2 -fstrict-aliasing, then the
> *(IV**)xiv = PL_xiv_root; write isn't considered aliased with the
> iv = ((XPVIV*) (sv)->sv_any)->xiv_iv;, because the former accesses the object
Duh, thanks and congratulations for finding this!
>
> It seems perl is aware of this, but doesn't care to fix it - Configure has
> instead:
It also might be that perl developers figured out by experimentation
that -fno-strict-aliasing helps, we probably could try to let them know.
> case "$gccversion" in
> 1*) ;;
> 2.[0-8]*) ;;
> ?*) echo " "
> echo "Checking if your compiler accepts -fno-strict-aliasing"
> 2
> >&1
> echo 'int main(void) { return 0; }' > gcctest.c
> if $cc -O2 -fno-strict-aliasing -o gcctest gcctest.c; then
> echo "Yes, it does." 2>&1
> case "$ccflags" in
> *strict-aliasing*)
> echo "Leaving current flags $ccflags alone."
> 2>
> &1
> ;;
> *) dflt="$dflt -fno-strict-aliasing" ;;
> esac
> else
> echo "Nope, it doesn't, but that's ok." 2>&1
> fi
> ;;
> esac
>
> Not sure what is the best way forward with CPU2006 and GCC though (and what
> are
> other compilers doing to pass 400.perlbench). Is it acceptable to add
> -fno-strict-aliasing just for this test?
This should not be that dificult to fix. Ideally we can convince SPEC to
produce official patch as they did with similar problems with CPU2000?
Honza
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33383
[Bug middle-end/20635] [4.0 Regression] ICE in cgraph_mark_reachable_node
--- Additional Comments From jh at suse dot cz 2005-03-29 23:48 --- Subject: Re: [4.0 Regression] ICE in cgraph_mark_reachable_node > > --- Additional Comments From gschafer at zip dot com dot au 2005-03-29 > 23:41 --- > (In reply to comment #6) > > I'll apply the patch and report back later if it fixes the problem. Would be > > nice to get this applied on the 4.0 branch. Thanks. > > It did indeed fix the problem. Thanks. I didn't hat time to look closer into the patch yet, but won't we run into symmetric problem with aliased functions too? Thanks for fixing the problem! Honza > > -- > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20635 > > --- You are receiving this mail because: --- > You are the assignee for the bug, or are watching the assignee. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20635
[Bug target/20717] [4.1 Regression] Many C++ testsuite failures on ia64-hpux
--- Additional Comments From jh at suse dot cz 2005-04-02 19:26 --- Subject: Re: [4.1 Regression] Many C++ testsuite failures on ia64-hpux > > --- Additional Comments From schwab at suse dot de 2005-04-02 19:03 > --- > The bootstrap failure on ia64-linux was introduced by the latter change, so > it > is most likely the same issue. The cgraph change concerning unit-at-a-time and C++ should be noop now, but it should not affect anything. I did bootstrapped ia-64 at a time of applying the branch and I saw failure on clean branch already, so it looks like something broke earlier. I will try to investigate after returning from trip at wenesday. Honza > > -- >What|Removed |Added > > CC||schwab at suse dot de > GCC target triplet|ia64-*-hpux11.* |ia64-*-* > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20717 > > --- You are receiving this mail because: --- > You are on the CC list for the bug, or are watching someone who is. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20717
[Bug target/20717] [4.1 Regression] Many C++ testsuite failures on ia64-hpux
--- Additional Comments From jh at suse dot cz 2005-04-05 09:46 --- Subject: Re: [4.1 Regression] Many C++ testsuite failures on ia64-hpux > > --- Additional Comments From wilson at gcc dot gnu dot org 2005-04-05 > 04:04 --- > The patch seems to have been incompletely checked in. The ChangeLog entry > claims to be removing code from final.c, but the code is still there. > > I laboriously tracked down the problem to the fact that cgraphunit handles > ADDR_EXPR but not FDESC_ADDR. Hence, only targets that use function > descriptors > are affected. Like IA-64. This sounds like reason for the failure. What precisely is the behaviour of FDESC_ADDR? (ie should I behave same way as if I see ADDR_EXPR - assume that address of the function has been taken and thus it is neccesary?). Honza > > > -- >What|Removed |Added > > Status|UNCONFIRMED |NEW > Ever Confirmed||1 >Last reconfirmed|-00-00 00:00:00 |2005-04-05 04:04:14 >date|| > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20717 > > --- You are receiving this mail because: --- > You are on the CC list for the bug, or are watching someone who is. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20717
[Bug target/37048] [4.4 Regression] Revision 138835 breaks bootstrap
--- Comment #4 from jh at suse dot cz 2008-08-07 14:30 ---
Subject: Re: [4.4 Regression] Revision 138835 breaks bootstrap
Hi,
thanks for testcase, for some reason it does not reproduce on our
testing setup, probably due to ancient glibc that still has
memcpy/memset inlines.
This patch should fix it, I am testing it right now but I am not sure I
will be able to commit before tomorro wunforutnately.
The problem is that we now use single stringops on optimize_size
regions, but the patterns are disabled. It is not problem to enable
them; we never produce them directly, only via the stringop expanders.
(at least I am convinced combine won't produce this)
Honza
* i386.md (single stringop patterns): Enable unconditionally.
Index: config/i386/i386.md
===
*** config/i386/i386.md (revision 138835)
--- config/i386/i386.md (working copy)
***
*** 18652,18658
(set (match_operand:DI 1 "register_operand" "=S")
(plus:DI (match_dup 3)
(const_int 8)))]
! "TARGET_64BIT && TARGET_SINGLE_STRINGOP"
"movsq"
[(set_attr "type" "str")
(set_attr "mode" "DI")
--- 18652,18658
(set (match_operand:DI 1 "register_operand" "=S")
(plus:DI (match_dup 3)
(const_int 8)))]
! "TARGET_64BIT"
"movsq"
[(set_attr "type" "str")
(set_attr "mode" "DI")
***
*** 18667,18673
(set (match_operand:SI 1 "register_operand" "=S")
(plus:SI (match_dup 3)
(const_int 4)))]
! "!TARGET_64BIT && TARGET_SINGLE_STRINGOP"
"movs{l|d}"
[(set_attr "type" "str")
(set_attr "mode" "SI")
--- 18667,18673
(set (match_operand:SI 1 "register_operand" "=S")
(plus:SI (match_dup 3)
(const_int 4)))]
! "!TARGET_64BIT"
"movs{l|d}"
[(set_attr "type" "str")
(set_attr "mode" "SI")
***
*** 18682,18688
(set (match_operand:DI 1 "register_operand" "=S")
(plus:DI (match_dup 3)
(const_int 4)))]
! "TARGET_64BIT && TARGET_SINGLE_STRINGOP"
"movs{l|d}"
[(set_attr "type" "str")
(set_attr "mode" "SI")
--- 18682,18688
(set (match_operand:DI 1 "register_operand" "=S")
(plus:DI (match_dup 3)
(const_int 4)))]
! "TARGET_64BIT"
"movs{l|d}"
[(set_attr "type" "str")
(set_attr "mode" "SI")
***
*** 18697,18703
(set (match_operand:SI 1 "register_operand" "=S")
(plus:SI (match_dup 3)
(const_int 2)))]
! "!TARGET_64BIT && TARGET_SINGLE_STRINGOP"
"movsw"
[(set_attr "type" "str")
(set_attr "memory" "both")
--- 18697,18703
(set (match_operand:SI 1 "register_operand" "=S")
(plus:SI (match_dup 3)
(const_int 2)))]
! "!TARGET_64BIT"
"movsw"
[(set_attr "type" "str")
(set_attr "memory" "both")
***
*** 18712,18718
(set (match_operand:DI 1 "register_operand" "=S")
(plus:DI (match_dup 3)
(const_int 2)))]
! "TARGET_64BIT && TARGET_SINGLE_STRINGOP"
"movsw"
[(set_attr "type" "str")
(set_attr "memory" "both")
--- 18712,18718
(set (match_operand:DI 1 "register_operand" "=S")
(plus:DI (match_dup 3)
(const_int 2)))]
! "TARGET_64BIT"
"movsw"
[(set_attr "type" "str")
(set_attr "memory" "both")
***
*** 18727,18733
(set (match_operand:SI 1 "register_operand" "=S")
(plus:SI (match_dup 3)
(const_int 1)))]
! "!TARGET_64BIT && TARGET_SINGLE_STRINGOP"
"movsb"
[(set_attr "type" "str")
(set_attr "memory" "both")
--- 18727,18733
(set (match_operand:SI 1 "register_operand" "=S")
(plus:SI (match_dup 3)
(const_int 1)))]
! "!TARGET_64BIT"
"movsb"
[(set_attr "type" "str")
(set_attr "memory"
[Bug target/37055] [4.4 Regression] Revision 138835 breaks -msse2 -mfpmath=sse -Os
--- Comment #2 from jh at suse dot cz 2008-08-08 10:47 ---
Subject: Re: internal compiler error: in emit_unop_insn, at optabs.c:3806
Hi,
this is patch I am testing.
Index: optabs.c
===
*** optabs.c(revision 138862)
--- optabs.c(working copy)
*** maybe_emit_unop_insn (int icode, rtx tar
*** 3769,3774
--- 3769,3775
rtx temp;
enum machine_mode mode0 = insn_data[icode].operand[1].mode;
rtx pat;
+ rtx last = get_last_insn ();
temp = target;
*** maybe_emit_unop_insn (int icode, rtx tar
*** 3782,3788
pat = GEN_FCN (icode) (temp, op0);
if (!pat)
! return false;
if (INSN_P (pat) && NEXT_INSN (pat) != NULL_RTX && code != UNKNOWN)
add_equal_note (pat, temp, code, op0, NULL_RTX);
--- 3783,3792
pat = GEN_FCN (icode) (temp, op0);
if (!pat)
! {
! delete_insns_since (last);
! return false;
! }
if (INSN_P (pat) && NEXT_INSN (pat) != NULL_RTX && code != UNKNOWN)
add_equal_note (pat, temp, code, op0, NULL_RTX);
*** expand_fix (rtx to, rtx from, int unsign
*** 5157,5162
--- 5161,5167
if (icode != CODE_FOR_nothing)
{
+ rtx last = get_last_insn ();
if (fmode != GET_MODE (from))
from = convert_to_mode (fmode, from, 0);
*** expand_fix (rtx to, rtx from, int unsign
*** 5170,5180
if (imode != GET_MODE (to))
target = gen_reg_rtx (imode);
! emit_unop_insn (icode, target, from,
! doing_unsigned ? UNSIGNED_FIX : FIX);
! if (target != to)
! convert_move (to, target, unsignedp);
! return;
}
}
--- 5175,5188
if (imode != GET_MODE (to))
target = gen_reg_rtx (imode);
! if (maybe_emit_unop_insn (icode, target, from,
! doing_unsigned ? UNSIGNED_FIX : FIX))
! {
! if (target != to)
! convert_move (to, target, unsignedp);
! return;
! }
! delete_insns_since (last);
}
}
*** expand_sfix_optab (rtx to, rtx from, con
*** 5382,5387
--- 5390,5396
icode = convert_optab_handler (tab, imode, fmode)->insn_code;
if (icode != CODE_FOR_nothing)
{
+ rtx last = get_last_insn ();
if (fmode != GET_MODE (from))
from = convert_to_mode (fmode, from, 0);
*** expand_sfix_optab (rtx to, rtx from, con
*** 5389,5395
target = gen_reg_rtx (imode);
if (!maybe_emit_unop_insn (icode, target, from, UNKNOWN))
! return false;
if (target != to)
convert_move (to, target, 0);
return true;
--- 5398,5407
target = gen_reg_rtx (imode);
if (!maybe_emit_unop_insn (icode, target, from, UNKNOWN))
! {
! delete_insns_since (last);
! continue;
! }
if (target != to)
convert_move (to, target, 0);
return true;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37055
[Bug middle-end/37218] [4.4 Regression] Revision 139525 caused many SLP regressions
--- Comment #3 from jh at suse dot cz 2008-08-24 11:37 --- Subject: Re: [4.4 Regression] Revision 139525 caused many SLP regressions > > or should I open another PR? I've reverted the accidental commit as well as fixed this problem, so I hope it is all OK. Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37218
[Bug middle-end/37227] [4.4 Regression] gcc.dg/ipa/ipa-?.c
--- Comment #2 from jh at suse dot cz 2008-08-25 10:41 ---
Subject: Re: [4.4 Regression] gcc.dg/ipa/ipa-?.c
Sorry, apparently I tested the new cost model only with IPCP enabled by
default. Until this is done, we need -fipa-cp-clone for those
testcases.
I am testing the following.
Index: ipa/ipacost-2.c
===
*** ipa/ipacost-2.c (revision 139544)
--- ipa/ipacost-2.c (working copy)
***
*** 1,5
/* { dg-do compile } */
! /* { dg-options "-O3 -fipa-cp -fdump-ipa-cp -fno-early-inlining
-fdump-tree-optimized" } */
int array[100];
--- 1,5
/* { dg-do compile } */
! /* { dg-options "-O3 -fipa-cp -fipa-cp-clone -fdump-ipa-cp
-fno-early-inlining -fdump-tree-optimized" } */
int array[100];
Index: ipa/ipa-1.c
===
*** ipa/ipa-1.c (revision 139544)
--- ipa/ipa-1.c (working copy)
***
*** 1,5
/* { dg-do compile } */
! /* { dg-options "-O3 -fipa-cp -fdump-ipa-cp -fno-early-inlining" } */
/* { dg-skip-if "PR 25442" { "*-*-*" } { "-fpic" "-fPIC" } { "" } } */
#include
--- 1,5
/* { dg-do compile } */
! /* { dg-options "-O3 -fipa-cp -fipa-cp-clone -fdump-ipa-cp
-fno-early-inlining" } */
/* { dg-skip-if "PR 25442" { "*-*-*" } { "-fpic" "-fPIC" } { "" } } */
#include
Index: ipa/ipa-2.c
===
*** ipa/ipa-2.c (revision 139544)
--- ipa/ipa-2.c (working copy)
***
*** 1,5
/* { dg-do compile } */
! /* { dg-options "-O3 -fipa-cp -fdump-ipa-cp -fno-early-inlining" } */
/* { dg-skip-if "PR 25442" { "*-*-*" } { "-fpic" "-fPIC" } { "" } } */
#include
--- 1,5
/* { dg-do compile } */
! /* { dg-options "-O3 -fipa-cp -fipa-cp-clone -fdump-ipa-cp
-fno-early-inlining" } */
/* { dg-skip-if "PR 25442" { "*-*-*" } { "-fpic" "-fPIC" } { "" } } */
#include
Index: ipa/ipa-3.c
===
*** ipa/ipa-3.c (revision 139544)
--- ipa/ipa-3.c (working copy)
***
*** 1,5
/* { dg-do compile } */
! /* { dg-options "-O3 -fipa-cp -fdump-ipa-cp -fno-early-inlining" } */
/* { dg-skip-if "PR 25442" { "*-*-*" } { "-fpic" "-fPIC" } { "" } } */
--- 1,5
/* { dg-do compile } */
! /* { dg-options "-O3 -fipa-cp -fipa-cp-clone -fdump-ipa-cp
-fno-early-inlining" } */
/* { dg-skip-if "PR 25442" { "*-*-*" } { "-fpic" "-fPIC" } { "" } } */
Index: ipa/ipa-4.c
===
*** ipa/ipa-4.c (revision 139544)
--- ipa/ipa-4.c (working copy)
***
*** 1,5
/* { dg-do compile } */
! /* { dg-options "-O3 -fipa-cp -fdump-ipa-cp" } */
/* { dg-skip-if "PR 25442" { "*-*-*" } { "-fpic" "-fPIC" } { "" } } */
#include
--- 1,5
/* { dg-do compile } */
! /* { dg-options "-O3 -fipa-cp -fipa-cp-clone -fdump-ipa-cp" } */
/* { dg-skip-if "PR 25442" { "*-*-*" } { "-fpic" "-fPIC" } { "" } } */
#include
Index: ipa/ipa-5.c
===
*** ipa/ipa-5.c (revision 139544)
--- ipa/ipa-5.c (working copy)
***
*** 1,5
/* { dg-do compile } */
! /* { dg-options "-O3 -fipa-cp -fdump-ipa-cp -fno-early-inlining" } */
/* { dg-skip-if "PR 25442" { "*-*-*" } { "-fpic" "-fPIC" } { "" } } */
/* Float & short constants. */
--- 1,5
/* { dg-do compile } */
! /* { dg-options "-O3 -fipa-cp -fipa-cp-clone -fdump-ipa-cp
-fno-early-inlining" } */
/* { dg-skip-if "PR 25442" { "*-*-*" } { "-fpic" "-fPIC" } { "" } } */
/* Float & short constants. */
Index: ipa/ipa-7.c
===
*** ipa/ipa-7.c (revision 139544)
--- ipa/ipa-7.c (working copy)
***
*** 1,5
/* { dg-do compile } */
! /* { dg-options "-O3 -fipa-cp -fdump-ipa-cp -fno-early-inlining" } */
/* { dg-skip-if "PR 25442" { "*-*-*" } { "-fpic" "-fPIC" } { "" } } */
#include
--- 1,5
/* { dg-do compile } */
! /* { dg-options "-O3 -fipa-cp -fipa-cp-clone -fdump-ipa-cp
-fno-early-inlining" } */
/* { dg-skip-if "PR 25442" { "*-*-*" } { "-fpic" "-fPIC" } { "" } } */
#include
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37227
[Bug middle-end/37293] [4.4 Regression] r139762 breaks libstdc++ build on darwin
--- Comment #11 from jh at suse dot cz 2008-08-31 09:38 --- Subject: Re: [4.4 Regression] r139762 breaks libstdc++ build on darwin > > I will see what I can do about this issue. Mostly we need to look at > where we change from weak to non weak and then fix up those call > statements. Honza, does that seem correct? I guess so, we need to update the call statement either during redirection or during fixup_cfg. Thank you for looking into that! Btw we should do ipcp clonning first but still inline the function, as code does not grow. I need to look into that too. Honza > > Thanks, > Andrew Pinski > > > > > > > /bin/sh ../libtool --tag CXX --mode=compile > > /sw/src/fink.build/gcc44-4.3.999-20080830/darwin_objdir/./gcc/xgcc > > -shared-libgcc -B/sw/src/fink.build/gcc44-4.3.999-20080830/ > > darwin_objdir/./gcc > > -nostdinc++ > > -L/sw/src/fink.build/gcc44-4.3.999-20080830/darwin_objdir/i686-apple- > > darwin9/libstdc++-v3/src > > -L/sw/src/fink.build/gcc44-4.3.999-20080830/darwin_objdir/i686-apple- > > darwin9/libstdc++-v3/src/.libs > > -B/sw/lib/gcc4.4/i686-apple-darwin9/bin/ > > -B/sw/lib/gcc4.4/i686-apple-darwin9/lib/ -isystem > > /sw/lib/gcc4.4/i686-apple-darwin9/include -isystem > > /sw/lib/gcc4.4/i686-apple-darwin9/sys-include > > -I/sw/src/fink.build/gcc44-4.3.999-20080830/darwin_objdir/i686-apple- > > darwin9/libstdc++-v3/include/i686-apple-darwin9 > > -I/sw/src/fink.build/gcc44-4.3.999-20080830/darwin_objdir/i686-apple- > > darwin9/libstdc++-v3/include > > -I/sw/src/fink.build/gcc44-4.3.999-20080830/gcc-4.4-20080830/libstdc+ > > +-v3/libsupc++ > > -I/sw/include -fno-implicit-templates -Wall -Wextra -Wwrite-strings - > > Wcast-qual > > -fdiagnostics-show-location=once -fvisibility-inlines-hidden > > -ffunction-sections -fdata-sections -g -O2-c -o > > bitmap_allocator.lo > > ../../../../gcc-4.4-20080830/libstdc++-v3/src/bitmap_allocator.cc > > libtool: compile: > > /sw/src/fink.build/gcc44-4.3.999-20080830/darwin_objdir/./gcc/xgcc > > -shared-libgcc -B/sw/src/fink.build/gcc44-4.3.999-20080830/ > > darwin_objdir/./gcc > > -nostdinc++ > > -L/sw/src/fink.build/gcc44-4.3.999-20080830/darwin_objdir/i686-apple- > > darwin9/libstdc++-v3/src > > -L/sw/src/fink.build/gcc44-4.3.999-20080830/darwin_objdir/i686-apple- > > darwin9/libstdc++-v3/src/.libs > > -B/sw/lib/gcc4.4/i686-apple-darwin9/bin/ > > -B/sw/lib/gcc4.4/i686-apple-darwin9/lib/ -isystem > > /sw/lib/gcc4.4/i686-apple-darwin9/include -isystem > > /sw/lib/gcc4.4/i686-apple-darwin9/sys-include > > -I/sw/src/fink.build/gcc44-4.3.999-20080830/darwin_objdir/i686-apple- > > darwin9/libstdc++-v3/include/i686-apple-darwin9 > > -I/sw/src/fink.build/gcc44-4.3.999-20080830/darwin_objdir/i686-apple- > > darwin9/libstdc++-v3/include > > -I/sw/src/fink.build/gcc44-4.3.999-20080830/gcc-4.4-20080830/libstdc+ > > +-v3/libsupc++ > > -I/sw/include -fno-implicit-templates -Wall -Wextra -Wwrite-strings - > > Wcast-qual > > -fdiagnostics-show-location=once -fvisibility-inlines-hidden > > -ffunction-sections -fdata-sections -g -O2 -c > > ../../../../gcc-4.4-20080830/libstdc++-v3/src/bitmap_allocator.cc - > > fno-common > > -DPIC -o .libs/bitmap_allocator.o > > ../../../../gcc-4.4-20080830/libstdc++-v3/src/bitmap_allocator.cc: > > In member > > function 'void > > __gnu_cxx::bitmap_allocator<_Tp>::_M_deallocate_single_object(_Tp*) > > [with _Tp = > > wchar_t]': > > ../../../../gcc-4.4-20080830/libstdc++-v3/src/bitmap_allocator.cc: > > 126: error: > > statement marked for throw, but doesn't > > T.292 (__diff_74); > > > > ../../../../gcc-4.4-20080830/libstdc++-v3/src/bitmap_allocator.cc: > > 126: internal > > compiler error: verify_stmts failed > > Please submit a full bug report, > > with preprocessed source if appropriate. > > See <http://gcc.gnu.org/bugs.html> for instructions. > > > > > > -- > > > > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37293 > > > > > -- > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37293 > > --- You are receiving this mail because: --- > You are on the CC list for the bug, or are watching someone who is. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37293
[Bug middle-end/37378] [4.4 Regression] Divide_X
--- Comment #6 from jh at suse dot cz 2008-09-05 12:39 --- Subject: Re: [4.4 Regression] Divide_X > All failures have > > -2147483648 > -2147483648 > 0 > 0 > 0 > java.lang.ArithmeticException: / by zero > java.lang.ArithmeticException: / by zero I've caused bug in expand_divmod that temporarily prevented divmod from expanding into unwound sequence. I fixed it day before yesterday and it should not cause wrong code problems, just code quality issues. And it matters only for constant divisors. Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37378
[Bug target/37378] [4.4 Regression] Revision 139827 causes Divide_X
--- Comment #13 from jh at suse dot cz 2008-09-06 23:18 --- Subject: Re: [4.4 Regression] Revision 139827 causes Divide_X > This looks like a target issue anyways. The patch had effect of turning code paths leading to trap or noreturn etc. to be optimized for size... Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37378
[Bug target/35271] Stack not aligned at mod 16 byte boundary in x86_64 code
--- Comment #20 from jh at suse dot cz 2008-02-24 20:49 ---
Subject: Re: Stack not aligned at mod 16 byte boundary in x86_64 code
Hi,
what about this patch. There seems to be availablity check missing
earlier in code. This way GCC will always align calls to functions that
might be overwritten (thus resolved by dynamic linker) with exception of
the recursive calls..
I still wonder how this problem can hit us so late: if we was
misaligning commonly stack on PIC calls and dynamic linker was crashing
on it, I would expect darwin to be unable to boot at all...
Honza
Index: calls.c
===
--- calls.c (revision 132575)
+++ calls.c (working copy)
@@ -2102,7 +2102,9 @@ expand_call (tree exp, rtx target, int i
if (fndecl)
{
struct cgraph_rtl_info *i = cgraph_rtl_info (fndecl);
- if (i && i->preferred_incoming_stack_boundary)
+ if (i && i->preferred_incoming_stack_boundary
+ && (cgraph_function_body_availability (cgraph_node (fndecl))
+ >= AVAIL_AVAILABLE))
preferred_stack_boundary = i->preferred_incoming_stack_boundary;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35271
[Bug target/35271] Stack not aligned at mod 16 byte boundary in x86_64 code
--- Comment #24 from jh at suse dot cz 2008-02-26 09:43 --- Subject: Re: Stack not aligned at mod 16 byte boundary in x86_64 code > I guess we need > 1) Get the patch to check overwritability of body to mainline and branch, > since > it is quite wrong to optimize based on knowledge of body that might be > replaced > 2) Figure out how to get Apple's linker in sync with Darwin backend in GCC. > If > the symbols are locally bound I guess the backend should just output the > direct > call, not via PLT table. If the objects are not locally bound we need to > change > the predicate. > I am not terribly familiar with MACHOPIC, what is the case? (ie does MACHOPIC > allow overwritting -fpic symbols like ELF?) So in short both fixes are at GCC rather than linker side, assuming that linker will link direct call to externally visible symbol at link time, rather than dynamic load time that would be case of ELF? Can someone check this? Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35271
[Bug tree-optimization/39259] [4.4 Regression] internal compiler error: in initialize_cfun, at tree-inline.c:1749
--- Comment #6 from jh at suse dot cz 2009-02-23 15:05 --- Subject: Re: [4.4 Regression] internal compiler error: in initialize_cfun, at tree-inline.c:1749 Hi, the assert seems confused. We can clone setjmp/alloca, just can't inline it. (well, in fact we even can inline alloca if we are cureful) just replace src_cfun by cfun and add notice_special_calls into processing of new statements. Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39259
[Bug lto/57602] Runfails for several C/C++ benchmarks from spec2000 for i686 with -flto after r199422
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57602 --- Comment #5 from Jan Hubicka --- As described in patch the change is intentional. finalized/analyzed flags come from pre unit at a time. ipa code should not care about analyzed bit. i will look what broke. Honza Cituji izamyatin at gmail dot com : > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57602 > > Igor Zamyatin changed: > >What|Removed |Added > > CC||hubicka at ucw dot cz > > --- Comment #3 from Igor Zamyatin --- > I believe the problem happens because cleanup that was made in > http://gcc.gnu.org/ml/gcc-patches/2013-05/msg01644.html > sometimes changes field 'analyzed' to 'symbol.definition' but at the > same time > in other places to 'symbol.analyzed'. > It looks like 'symbol.definition' corresponds to the former 'finalized' field > not 'analyzed' and 'symbol.definition' are not always the same as > 'symbol.analyzed'. > > I'm attaching the patch (no bootstrap and make check testing though) which > fixes this (but not in all places across the compiler, sort of minimum > intrusion) and runfails disappeared with these changes. > > Jan, could you please take a close look since now many x86 32-bit apps built > with lto are broken. > > -- > You are receiving this mail because: > You are on the CC list for the bug. >
[Bug c++/22592] -fvisibility-inlines-hidden broken differently
--- Additional Comments From jh at suse dot cz 2005-09-03 10:51 ---
Subject: Re: -fvisibility-inlines-hidden broken differently
>
> --- Additional Comments From mmitchel at gcc dot gnu dot org 2005-09-03
> 01:03 ---
> Frankly, I think -fvisibility-inlines-hidden is a bad idea. I don't feel that
> way about -fvisibility, but giving inline functions special linkage in this
> way
> is a very fragile concept, and awards something with minimal C++ semantics
> ("inline") substantial observable semantics.
>
> The documentation for -fv-i-h is not clear about this case. All it really
> says
> is that any inlines emitted will be hidden. The compiler's meeting that
> requirement, trivially, because it's not emitting any inlines.
Is that even correct that we don't emit any inline? (ie see bellow)
>
> I don't think that we should do anything different in *this* source file
> because
> -fv-i-h is present. The thing we actually want to know is how the file
> containing the vtable is going to be compiled, and we can't know that here.
> Therefore, it seems to me that the mistake in Michael's chain of events is:
>
> 4) the call is emitted such that it expects a local (hidden) definition
>of the function in the DSO (i.e. not over PLT but direct call)
>
> Nothing in the semantics of -fv-i-h says that all inline functions in the
> program will be in this DSO. If we were to try to believe that, other things
> (like "extern template") would probably break too. Instead, the linker should
> have the responsibility of binding the relocation within the DSO at DSO
> link-time, if there happens to be a satisfying symbol at link time.
>
> Jan, I don't think your patch is correct, as I don't think anything about the
> optimization of this program should change based on -fv-i-h.
Hmm, OK, there are two problems I see.
One problem is that this testcase breaks. We can declare it invalid or
one other possibility I run across is to teach locally_bound predicate
in varasm to not believe that this hidden inline function is going to be
linked locally. This is very similar to way -fvisibility works - ie
function is hidden only if defined in current unit and would result in
DSO to build and even link if the other DSO will export the inline
function (that won't happen with -fv-i-h on the other DSO, right?)
This is not quite trivial, becuase -fv-i-h is hanled in the frontend and
backend already don't see whether the particular inline was actually
declared hidden (where user should provide it in within same DSO) or
whether the hidden implied this way, but I guess we can simply be
conservative here and when flag is active, thread this way all comdats
with inline flag and hidden visibility.
But the more general problem however is that I think it is quite
incorrect to call comdat linkonce function directly without actually
outputting it into current compilation unit, at least from the
definition of comdat flag:
/* Used in a DECL to indicate that, even if it TREE_PUBLIC, it need
not be put out unless it is needed in this translation unit.
Entities like this are shared across translation units (like weak
entities), but are guaranteed to be generated by any translation
unit that needs them, and therefore need not be put out anywhere
where they are not needed. DECL_COMDAT is just a hint to the
back-end; it is up to front-ends which set this flag to ensure
that there will never be any harm, other than bloat, in putting out
something which is DECL_COMDAT. */
Making direct call the function probably makes function "needed in this
translation unit" even tought it wasn't originally. This can happen
with and without the patch in this special case (COMDAT functio being
originally referenced by vtable not going to be output here). Is there
something behind scenes making this safe? (like is the argument that
the function will be provided by unit defining vtable anyway safe and if
so, why is not frontend emitting it as extern inline in all other units
saving object file sizes?)
If not, we probably should prevent the folding...
Honza
>
> --
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22592
>
> --- You are receiving this mail because: ---
> You are on the CC list for the bug, or are watching someone who is.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22592
[Bug target/24419] [3.4/4.0/4.1 Regression]: ix86 prologue puts values beyond stack
--- Comment #6 from jh at suse dot cz 2005-10-18 17:22 --- Subject: Re: [3.4/4.0/4.1 Regression]: ix86 prologue puts values beyond stack > > > --- Comment #5 from hjl at lucon dot org 2005-10-18 04:37 --- > >From bar.i.26.flow2: > > (insn/f 51 11 52 0 (set (mem:DI (plus:DI (reg/f:DI 7 sp) > (const_int -16 [0xfff0])) [0 S8 A8]) > (reg:DI 3 bx)) -1 (nil) > (expr_list:REG_DEAD (reg:DI 3 bx) > (nil))) > > (insn/f 52 51 53 0 (set (mem:DI (plus:DI (reg/f:DI 7 sp) > (const_int -8 [0xfff8])) [0 S8 A8]) > (reg:DI 6 bp)) -1 (nil) > (expr_list:REG_DEAD (reg:DI 6 bp) > (nil))) > > (insn/f 53 52 54 0 (parallel [ > (set (reg/f:DI 7 sp) > (plus:DI (reg/f:DI 7 sp) > (const_int -16 [0xfff0]))) > (clobber (reg:CC 17 flags)) > (clobber (mem:BLK (scratch) [0 A8])) > ]) -1 (nil) > (expr_list:REG_UNUSED (reg:CC 17 flags) > (nil))) > > Gcc doesn't tell the truth here since memory isn't/shouldn't be clobber > when adjusting SP. The transformation to push is probably valid only on x86 where any data on opposite side of stack pointer is implicitly clobbered (for signal handers stacks or whatever), so conversion of sub to push is safe. This is not very well modelled by RTL and ineed was problem few times in past (where scheduler overactively moved the stuff resulting in kernel crashes if I remember right) On x86-64 we probably should conditionalize this and use only for functions not using red zone or avoid the red zone usage for argument area when we are going to produce push instead of sub (the reason for that optimization is to reduce dependency chain that is more important that push conversion for Athlon, not sure what is the case for Nocona) Honza > > > -- > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24419 > > --- You are receiving this mail because: --- > You are on the CC list for the bug, or are watching someone who is. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24419
[Bug target/24419] ix86 prologue clobbers memory when it shouldn't
--- Comment #8 from jh at suse dot cz 2005-10-18 17:41 --- Subject: Re: ix86 prologue clobbers memory when it shouldn't > > > --- Comment #7 from hjl at lucon dot org 2005-10-18 17:33 --- > We are working on ix86 optimization and run into this problem. The patch quoted on begining of thread should affect compilation with -mred-zone enabled only and that one is off for ix86. Can I see 32bit testcase? In general it is wrong on x86 to put data on unallocated stack at first place... Honza > > > -- > > hjl at lucon dot org changed: > >What|Removed |Added > > Summary|[3.4/4.0/4.1 Regression]: |ix86 prologue clobbers >|ix86 prologue puts values |memory when it shouldn't >|beyond stack| > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24419 > > --- You are receiving this mail because: --- > You are on the CC list for the bug, or are watching someone who is. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24419
[Bug target/24419] ix86 prologue clobbers memory when it shouldn't
--- Comment #10 from jh at suse dot cz 2005-10-18 18:17 --- Subject: Re: ix86 prologue clobbers memory when it shouldn't > > > --- Comment #9 from hjl at lucon dot org 2005-10-18 17:50 --- > We only run into the problem with red zone enabled, which is x86-64. We have > 2 issues: > > 1. When prologue uses mov, memory shouldn't be clobbered. But > ix86_expand_prologue calls pro_epilogue_adjust_stack which clobbers > memory. > 2. We convert stack pointer subtractions to push even when memory isn't > clobbered with patterns like > > ;; Convert esp subtractions to push. > (define_peephole2 > [(match_scratch:SI 0 "r") >(parallel [(set (reg:SI SP_REG) (plus:SI (reg:SI SP_REG) (const_int > -4))) > (clobber (reg:CC FLAGS_REG))])] > "optimize_size || !TARGET_SUB_ESP_4" > [(clobber (match_dup 0)) >(set (mem:SI (pre_dec:SI (reg:SI SP_REG))) (match_dup 0))]) > > I don't think we can do that since push will clobber memory. Without red zone this is safe, but I see we do the conversion on 64bit too that definitly is unsafe. What about this patch? Index: i386.md === RCS file: /cvs/gcc/gcc/gcc/config/i386/i386.md,v retrieving revision 1.655 diff -c -3 -p -r1.655 i386.md *** i386.md 24 Sep 2005 15:47:57 - 1.655 --- i386.md 18 Oct 2005 18:16:00 - *** *** 19306,19316 (clobber (mem:BLK (scratch)))])]) ;; Convert esp subtractions to push. (define_peephole2 [(match_scratch:SI 0 "r") (parallel [(set (reg:SI SP_REG) (plus:SI (reg:SI SP_REG) (const_int -4))) (clobber (reg:CC FLAGS_REG))])] ! "optimize_size || !TARGET_SUB_ESP_4" [(clobber (match_dup 0)) (set (mem:SI (pre_dec:SI (reg:SI SP_REG))) (match_dup 0))]) --- 19306,19320 (clobber (mem:BLK (scratch)))])]) ;; Convert esp subtractions to push. + ;; This conversion is safe only under assumption that unallocated stack is + ;; implicitly clobbered as specified by 32bit ABI (for signal handlers and such). + ;; This is not valid with red zone, but we can work harder and enable the + ;; optimization for functions that are not using it. (define_peephole2 [(match_scratch:SI 0 "r") (parallel [(set (reg:SI SP_REG) (plus:SI (reg:SI SP_REG) (const_int -4))) (clobber (reg:CC FLAGS_REG))])] ! "(optimize_size || !TARGET_SUB_ESP_4) && !TARGET_RED_ZONE" [(clobber (match_dup 0)) (set (mem:SI (pre_dec:SI (reg:SI SP_REG))) (match_dup 0))]) *** *** 19318,19324 [(match_scratch:SI 0 "r") (parallel [(set (reg:SI SP_REG) (plus:SI (reg:SI SP_REG) (const_int -8))) (clobber (reg:CC FLAGS_REG))])] ! "optimize_size || !TARGET_SUB_ESP_8" [(clobber (match_dup 0)) (set (mem:SI (pre_dec:SI (reg:SI SP_REG))) (match_dup 0)) (set (mem:SI (pre_dec:SI (reg:SI SP_REG))) (match_dup 0))]) --- 19322,19328 [(match_scratch:SI 0 "r") (parallel [(set (reg:SI SP_REG) (plus:SI (reg:SI SP_REG) (const_int -8))) (clobber (reg:CC FLAGS_REG))])] ! "(optimize_size || !TARGET_SUB_ESP_8) && !TARGET_RED_ZONE" [(clobber (match_dup 0)) (set (mem:SI (pre_dec:SI (reg:SI SP_REG))) (match_dup 0)) (set (mem:SI (pre_dec:SI (reg:SI SP_REG))) (match_dup 0))]) *** *** 19438,19448 (clobber (mem:BLK (scratch)))])]) ;; Convert esp subtractions to push. (define_peephole2 [(match_scratch:DI 0 "r") (parallel [(set (reg:DI SP_REG) (plus:DI (reg:DI SP_REG) (const_int -8))) (clobber (reg:CC FLAGS_REG))])] ! "optimize_size || !TARGET_SUB_ESP_4" [(clobber (match_dup 0)) (set (mem:DI (pre_dec:DI (reg:DI SP_REG))) (match_dup 0))]) --- 19442,19456 (clobber (mem:BLK (scratch)))])]) ;; Convert esp subtractions to push. + ;; This conversion is safe only under assumption that unallocated stack is + ;; implicitly clobbered as specified by 32bit ABI (for signal handlers and such). + ;; This is not valid with red zone, but we can work harder and enable the + ;; optimization for functions that are not using it. (define_peephole2 [(match_scratch:DI 0 "r") (parallel [(set (reg:DI SP_REG) (plus:DI (reg:DI SP_REG) (const_int -8))) (clobber (reg:CC FLAGS_REG))])] ! "(optimize_size || !TARGET_SUB_ESP_4) && !TARGET_RED_ZONE" [(clobber (match_dup 0)) (set (mem:DI (pre_dec:DI (reg:DI SP_REG))) (match_dup 0))]) *** *** 19450,19456 [(match_scratch:DI 0 "r") (parallel [(set (reg:DI SP_REG) (plus:DI (reg:DI SP_REG) (const_int -16))) (clobber (reg:CC FLAGS_REG))])] ! "optimize_si
[Bug target/24419] ix86 prologue clobbers memory when it shouldn't
--- Comment #13 from jh at suse dot cz 2005-10-18 18:29 --- Subject: Re: ix86 prologue clobbers memory when it shouldn't > > > --- Comment #12 from hjl at lucon dot org 2005-10-18 18:26 --- > There is another issue when converting stack additions to pop: > > (define_peephole2 > [(match_scratch:SI 0 "r") >(parallel [(set (reg:SI SP_REG) (plus:SI (reg:SI SP_REG) (const_int 4))) > > (clobber (reg:CC FLAGS_REG))])] > "" > [(parallel [(set (match_dup 0) (mem:SI (reg:SI SP_REG))) > (set (reg:SI SP_REG) (plus:SI (reg:SI SP_REG) (const_int 4)))])] > "") > > Is that 100% safe with red zone? In theory, compiler can adjust stack, but not > clobber memory since there is a red zone. It is reading memory here, not writting so it should be safe... Honza > > > -- > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24419 > > --- You are receiving this mail because: --- > You are on the CC list for the bug, or are watching someone who is. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24419
[Bug middle-end/17667] Const/pure function detection during tree-based profiling
--- Additional Comments From jh at suse dot cz 2005-07-05 00:54 --- Subject: Re: Const/pure function detection during tree-based profiling > > --- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-04 > 21:35 --- > Isn't this fixed now or does this need to be submitted still? This is fixed by Kenny's aliasing series that AFAIK wasn't reviewed yet. Honza > > -- > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17667 > > --- You are receiving this mail because: --- > You are the assignee for the bug, or are watching the assignee. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17667
[Bug tree-optimization/22216] [4.1 regression] ICE during GC
--- Additional Comments From jh at suse dot cz 2005-07-09 17:50 --- Subject: Re: [4.1 regression] ICE during GC > > --- Additional Comments From schwab at suse dot de 2005-07-09 17:15 > --- > I can't reproduce it any more. Whether it's gone dormant again or fixed for > real I don't know. I've bootstrapped with gcac from tree about a week old and it went fluently, so hopefully it is fixed somehow. Honza > > -- > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22216 > > --- You are receiving this mail because: --- > You are on the CC list for the bug, or are watching someone who is. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22216
[Bug target/16961] Poor x86-64 performance with 128bit ints
--- Additional Comments From jh at suse dot cz 2005-07-18 12:45 ---
Subject: Re: Poor x86-64 performance with 128bit ints
>
> --- Additional Comments From steven at gcc dot gnu dot org 2005-07-18
> 07:47 ---
> The 128 bits arithmetic has improved now:
>
> typedef unsigned long mp_word __attribute__ ((mode(TI)));
> mp_word a, b;
> void test(void) { a += b; }
>
> test:
> movqa(%rip), %rax
> addqb(%rip), %rax
> movqa+8(%rip), %rdx
> adcqb+8(%rip), %rdx
> movq%rax, a(%rip)
> movq%rdx, a+8(%rip)
> ret
I think the PR should be closed now when Jan added the 128bit arithmetic
patterns I originally skipped in the x86-64 port as it was killing my
32bit cross compiler at that time :)
At lest we should now perofrm no worse than i386 on 64bit math (that
sucks of course ;)
Honza
>
>
> --
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16961
>
> --- You are receiving this mail because: ---
> You are on the CC list for the bug, or are watching someone who is.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16961
[Bug middle-end/35970] except.c:3382: error: 'struct eh_status' has no member named 'call
--- Comment #1 from jh at suse dot cz 2008-04-18 05:40 --- Subject: Re: except.c:3382: error: 'struct eh_status' has no member named 'call Hi, I've comitted the fix this morning, hope it is OK now. Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35970
[Bug target/36851] [4.4 regression] cc1plus SEGV compiling strstream.cc on Tru64 UNIX
--- Comment #6 from jh at suse dot cz 2008-08-02 10:49 --- Subject: Re: [4.4 regression] cc1plus SEGV compiling strstream.cc on Tru64 UNIX > > If you provide a preprocessed testcase maybe he can. Otherwise patches > > welcome > > I guess. > > Done. Unfortunately, I won't be available for testing until September 1st. > > If this cannot be resolved, I'll certainly need quite some guidance to fix > it myself. I was also at conference till 1st. I will try to look at it now. Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36851
[Bug target/36851] [4.4 regression] cc1plus SEGV compiling strstream.cc on Tru64 UNIX
--- Comment #7 from jh at suse dot cz 2008-08-02 11:31 --- Subject: Re: [4.4 regression] cc1plus SEGV compiling strstream.cc on Tru64 UNIX Looks like Aplha is not tuplified yet? ../../gcc/config/alpha/alpha.c: In function 'va_list_skip_additions': ../../gcc/config/alpha/alpha.c:5815: warning: assignment from incompatible pointer type ../../gcc/config/alpha/alpha.c:5817: error: 'PHI_NODE' undeclared (first use in this function) ../../gcc/config/alpha/alpha.c:5817: error: (Each undeclared identifier is reported only once ../../gcc/config/alpha/alpha.c:5817: error: for each function it appears in.) Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36851
[Bug tree-optimization/18463] [4.0/4.1 Regression] suboptimal use of fancy x86 addressing modes
--- Additional Comments From jh at suse dot cz 2005-06-13 13:40 --- Subject: Re: [4.0/4.1 Regression] suboptimal use of fancy x86 addressing modes > > --- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-13 > 12:46 --- > On the mainline we get now: > .L4: > movl(%ebp,%edx,4), %eax > movl%eax, (%ebx,%edx,4) > movl(%esi,%edx,4), %eax > movl%eax, (%ecx,%edx,4) > incl%edx > cmpl%edx, %edi > jne .L4 > > Which is better but the two loads/stores are not scheduled. -frename-registers? But hardware will do that for you anyway. Honza > > -- > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18463 > > --- You are receiving this mail because: --- > You are on the CC list for the bug, or are watching someone who is. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18463
[Bug target/18019] [4.0 Regression] -march=pentium4 generates word fetch instead of byte fetch
--- Additional Comments From jh at suse dot cz 2004-12-19 16:16 --- Subject: Re: [4.0 Regression] -march=pentium4 generates word fetch instead of byte fetch > > --- Additional Comments From steven at gcc dot gnu dot org 2004-12-18 > 22:49 --- > Honza, > > PING I am still backlogged but I will look into it now. What about cleaning up tree-inline.c and other mess? That thing is hell to merge... Honza > > > > -- > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18019 > > --- You are receiving this mail because: --- > You are on the CC list for the bug, or are watching someone who is. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18019
[Bug c/19031] [4.0 Regression] #pragma weak handling changes in 4.0.0
--- Additional Comments From jh at suse dot cz 2005-01-01 23:27 --- Subject: Re: [4.0 Regression] #pragma weak handling changes in 4.0.0 > > --- Additional Comments From rth at gcc dot gnu dot org 2004-12-31 23:30 > --- > I think that this sort of thing *ought* to work. How, exactly, to teach > cgraph to make it happen is perhaps tricky... OK, if I understand it right the main trickyness of this is the fact that we no longer can get cgraph node from the identifier, right? One possibility is to set TREE_SYMBOL_REFERENCED and teach cgraphunit to walk all the nodes once after finalization and put them into the queue, but it is particularly ugly and clash with Zack's plans on killing TREE_SYMBOL_REFERENCED (in that case we can probably use just the hash of string instead). If no one sees better sollution, I will implement it... Honza > > -- >What|Removed |Added > > AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org >|dot org | > Status|UNCONFIRMED |ASSIGNED > Ever Confirmed||1 >Last reconfirmed|-00-00 00:00:00 |2004-12-31 23:30:52 >date|| > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19031 > > --- You are receiving this mail because: --- > You are on the CC list for the bug, or are watching someone who is. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19031
[Bug target/18910] [4.0 Regression] unrecognisable insn in regclass on x86/amd64
--- Additional Comments From jh at suse dot cz 2005-01-01 23:52 ---
Subject: Re: [4.0 Regression] unrecognisable insn in regclass on x86/amd64
>
> --- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-01
> 22:33 ---
> (In reply to comment #21)
> > This is the original thread which leads to this regession:
> >
> > http://gcc.gnu.org/ml/gcc/2004-11/threads.html#00839
>
> If you notice this works on all other targets other than x86/x86_64 which
> means that it is a latent bug
> in the x86 back-end.
the problem seems to be loop optimizer taking the
(const:SI (plus:SI (symbol_ref:SI ("foo") [flags 0x58] ) (const_int 8 [0x8]))
construct from REG_EQUAL note and throwing it into emit_move_insn
without any care.
I don't think emit_move_insn is required to deal with arbitary constant
operand like this, so it seems to me that correct (and safe) way is to
prevent loop from this idea... I am testing attached patch. But we
might also teach move expander to decompose the CONST and legitimize it
as we do for usual variable references...
Honza
Index: loop.c
===
RCS file: /cvs/gcc/gcc/gcc/loop.c,v
retrieving revision 1.518
diff -c -3 -p -r1.518 loop.c
*** loop.c 18 Dec 2004 07:55:35 - 1.518
--- loop.c 1 Jan 2005 23:47:22 -
*** scan_loop (struct loop *loop, int flags)
*** 1149,1160
Otherwise, only use the REG_EQUAL contents if a REG_RETVAL
note is present. */
temp = find_reg_note (p, REG_EQUIV, NULL_RTX);
! if (temp)
src = XEXP (temp, 0), move_insn = 1;
else
{
temp = find_reg_note (p, REG_EQUAL, NULL_RTX);
! if (temp && CONSTANT_P (XEXP (temp, 0)))
src = XEXP (temp, 0), move_insn = 1;
if (temp && find_reg_note (p, REG_RETVAL, NULL_RTX))
{
--- 1149,1161
Otherwise, only use the REG_EQUAL contents if a REG_RETVAL
note is present. */
temp = find_reg_note (p, REG_EQUIV, NULL_RTX);
! if (temp && general_operand (XEXP (temp, 0), VOIDmode))
src = XEXP (temp, 0), move_insn = 1;
else
{
temp = find_reg_note (p, REG_EQUAL, NULL_RTX);
! if (temp && CONSTANT_P (XEXP (temp, 0))
! && LEGITIMATE_CONSTANT_P (XEXP (temp, 0)))
src = XEXP (temp, 0), move_insn = 1;
if (temp && find_reg_note (p, REG_RETVAL, NULL_RTX))
{
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18910
[Bug target/18910] [4.0 Regression] unrecognisable insn in regclass on x86/amd64
--- Additional Comments From jh at suse dot cz 2005-01-02 00:14 ---
Subject: Re: [4.0 Regression] unrecognisable insn in regclass on x86/amd64
>
> --- Additional Comments From jh at suse dot cz 2005-01-01 23:52 ---
> Subject: Re: [4.0 Regression] unrecognisable insn in regclass on x86/amd64
>
> >
> > --- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-01
> > 22:33 ---
> > (In reply to comment #21)
> > > This is the original thread which leads to this regession:
> > >
> > > http://gcc.gnu.org/ml/gcc/2004-11/threads.html#00839
> >
> > If you notice this works on all other targets other than x86/x86_64 which
> > means that it is a latent bug
> > in the x86 back-end.
> the problem seems to be loop optimizer taking the
> (const:SI (plus:SI (symbol_ref:SI ("foo") [flags 0x58] 0xb7d5e828 foo>) (const_int 8 [0x8]))
> construct from REG_EQUAL note and throwing it into emit_move_insn
> without any care.
>
> I don't think emit_move_insn is required to deal with arbitary constant
> operand like this, so it seems to me that correct (and safe) way is to
> prevent loop from this idea... I am testing attached patch. But we
> might also teach move expander to decompose the CONST and legitimize it
> as we do for usual variable references...
Hmm, actually I now recall that last time we went across similar problem
(cse constructing crazy CONST expression later used by loop same sick
way) we decided to restrict cse to construct sane CONSTs and producing
offsetted reference to TLS seems to be quite sane, so perhaps fixing it
other way around is better. Here is the patch I am testing ;)
Index: config/i386/i386.c
===
RCS file: /cvs/gcc/gcc/gcc/config/i386/i386.c,v
retrieving revision 1.766
diff -c -3 -p -r1.766 i386.c
*** config/i386/i386.c 28 Dec 2004 05:26:23 - 1.766
--- config/i386/i386.c 2 Jan 2005 00:11:53 -
*** ix86_expand_move (enum machine_mode mode
*** 7472,7478
op0 = operands[0];
op1 = operands[1];
! model = GET_CODE (op1) == SYMBOL_REF ? SYMBOL_REF_TLS_MODEL (op1) : 0;
if (model)
{
op1 = legitimize_tls_address (op1, model, true);
--- 7472,7484
op0 = operands[0];
op1 = operands[1];
! if (GET_CODE (op1) == CONST && GET_CODE (XEXP (op1, 0)) == PLUS
! && GET_CODE (XEXP (XEXP (op1, 0), 0)) == SYMBOL_REF)
! model = SYMBOL_REF_TLS_MODEL (XEXP (XEXP (op1, 0), 0));
! else if (GET_CODE (op1) == SYMBOL_REF)
! model = SYMBOL_REF_TLS_MODEL (op1);
! else
! model = 0;
if (model)
{
op1 = legitimize_tls_address (op1, model, true);
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18910
[Bug middle-end/18499] [4.0 Regression] quadratic behavior in cfgexpand
--- Additional Comments From jh at suse dot cz 2004-11-15 10:37 ---
Subject: Re: New: [4.0 Regression] quadratic behavior in cfgexpand
> The test case for 17340 exposes quadratic behavior caused by
> abnormal edges in the CFG:
>
>
> % cumulative self self total
> time seconds secondscalls s/call s/call name
> 13.83 36.6037.60 272892 0.00 0.00 remove_edge
> 4.90 50.9213.32 17634463 0.00 0.00 replace_goto_queue_1
> 2.18 56.84 5.92 443335 0.00 0.00 find_reloads
> 1.93 62.08 5.24 1110938 0.00 0.00
> gt_ggc_mx_lang_tree_node
> 1.76 66.87 4.79 375356 0.00 0.00 record_reg_classes
> 1.39 70.65 3.78 13455581 0.00 0.00 ggc_set_mark
> 1.37 74.37 3.72 8683135 0.00 0.00 ggc_alloc_stat
> 1.26 77.81 3.44 3448355 0.00 0.00 comptypes
> 1.21 81.09 3.28 1336950 0.00 0.00 walk_tree
>
> ---
> 0.110.00 919/272892 purge_dead_edges [270]
> 0.370.003133/272892 delete_basic_block [160]
> 1.080.009094/272892
> remove_phi_nodes_and_edges_for_unreachable_block [234]
> 1.100.009303/272892 remove_fake_predecessors
> [229]
> 2.060.01 17341/272892 merge_blocks [139]
> 2.610.01 21999/272892 find_bb_boundaries [100]
> 3.840.02 32405/272892 connect_post_landing_pads
> [78]
> 9.660.04 81428/272892 finish_eh_generation [31]
>16.770.00 97270/272892 expand_gimple_basic_block
> [17]
> [30]13.9 37.600.08 272892 remove_edge [30]
> 0.080.00 272892/523547 ggc_free [613]
> 0.000.00 272892/341925 free_edge [2842]
> ---
>
> This comes from this loop:
>
> for (ei = ei_start (bb->succs); (e = ei_safe_edge (ei)); )
> {
> /* Clear EDGE_EXECUTABLE. This flag is never used in the backend. */
> e->flags &= ~EDGE_EXECUTABLE;
>
> /* At the moment not all abnormal edges match the RTL representation.
> It is safe to remove them here as find_sub_basic_blocks will
> rediscover them. In the future we should get this fixed properly.
> */
> if (e->flags & EDGE_ABNORMAL)
> remove_edge (ei);
> else
> ei_next (&ei);
> }
>
> We walk all edges here, and we walk all of them again for remove_edge.
Hmm, this was introduced by the edge vectors change. What is the
canonical way to walk the edges and remove some?
Honza
>
> --
>Summary: [4.0 Regression] quadratic behavior in cfgexpand
>Product: gcc
>Version: 4.0.0
> Status: UNCONFIRMED
> Keywords: compile-time-hog
> Severity: normal
> Priority: P2
> Component: middle-end
> AssignedTo: unassigned at gcc dot gnu dot org
> ReportedBy: steven at gcc dot gnu dot org
> CC: gcc-bugs at gcc dot gnu dot org,jh at suse dot cz
> BugsThisDependsOn: 17340
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18499
>
> --- You are receiving this mail because: ---
> You are on the CC list for the bug, or are watching someone who is.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18499
[Bug target/18019] [4.0 Regression] -march=pentium4 generates word fetch instead of byte fetch
--- Additional Comments From jh at suse dot cz 2004-12-02 09:02 --- Subject: Re: [4.0 Regression] -march=pentium4 generates word fetch instead of byte fetch > > --- Additional Comments From neroden at gcc dot gnu dot org 2004-12-02 > 03:35 --- > Jan's message quoted in the previous comment seems to be orthogonal to the > main problem in this bug. The problem is that a word fetch is being > generated > which *reads out of bounds memory*. > > If the last byte in a page is being fetched, you must not extend that to > fetch > the next byte; if the first byte in a page is being fetched, you must not > extend that to fetch the previous byte. Those are the key failure situations > which must be prevented, regardless of whether this is -Os, -O2, or -O0. > > It doesn't appear to me that the changes proposed in Jan's message actually > address that, since none of them seem to feature a alignment or other type of > correctness check before converting a QImode move into a (possibly illegal) > SImode move. We don't need to check that since the code always use zero extension conversion (unless it hit the buggy -Os conditional) and zero extension still reads byte, just writes whole register. It is not good idea to use full sized read even for aligned sources since we will get partial memory stalls. We use full sized moves only for register to register moves where it is safe. I will prepare the patch later today. Honza > > In particular, this statement looks like it's wrong: > >while for > >TARGET_PARTIAL_REG_STALL/TARGET_PARTIAL_REG_DEPENDENCY we can still use > >the full moves as long as they don't encode longer. > > I believe a check is required that the full moves don't cause a segmentation > violation. An alignment check would be sufficient (it would prohibit more > cases than strictly necessary, but this is a correctness issue, and I haven't > thought of a better check). > > > -- > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18019 > > --- You are receiving this mail because: --- > You are on the CC list for the bug, or are watching someone who is. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18019
[Bug middle-end/30017] [4.3 Regression] ICE in cp_expr_size, at cp/cp-objcp-common.c:101
--- Comment #14 from jh at suse dot cz 2006-11-30 18:54 --- Subject: Re: [4.3 Regression] ICE in cp_expr_size, at cp/cp-objcp-common.c:101 > > The code has not undefined behavior, but I think removing the check is ok > > (it's > > certainly not supposed to trigger _inside_ the assignment operator or the > > copy constructor). > > Actually I don't think removing that check is ok. Allows us to find problems > with the gimplifier, when it is trying to create a temprorary variable when it > should not. Well, actually we probably need to decide on one thing - ie if we want to allow such a moves later at gimple form. I would say that we want to as we want to make gimple language indepdendent in longer form and thus classes are just aggregates as of any kind and assigning them is safe. If we don't want to, we need to come with check prohibiting builtins.c to construct the assignment. If we want to, we need to find way to either relax or elliminate the check or move it to better place. I still wonder why do we need expr_size hook that late in compilation? (ie using TYPE_UNIT_SIZE instead would solve the problem too) Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30017
[Bug rtl-optimization/29841] [4.2/4.3 regression] ICE with scheduling and __builtin_trap
--- Comment #8 from jh at suse dot cz 2006-12-19 13:39 --- Subject: Re: [4.2/4.3 regression] ICE with scheduling and __builtin_trap Hi, barrier in the middle of basic block is invalid and should be noticed by verify_flow_info and ICE. What part of my patch you quote is supposed to fix the problem? Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29841
[Bug rtl-optimization/29841] [4.2/4.3 regression] ICE with scheduling and __builtin_trap
--- Comment #10 from jh at suse dot cz 2006-12-19 14:12 --- Subject: Re: [4.2/4.3 regression] ICE with scheduling and __builtin_trap > > cfgrtl.c: rtl_verify_flow_info () makes the same statement as > control_flow_insn_p (): > /* We may have a barrier inside a basic block before dead code >elimination. There is no BLOCK_FOR_INSN field in a barrier. */ Duh, I would consider HP's patch adding the hunk to verify_flow_info in 2004 as incorrect even if it was commited as obvious. Clearly we don't want to have barriers within basic blocks, dead code ellimination done or not, especially not at the scheduling time! (frankly, we don't want to have barriers at first place) I would suggest put that hunk in (it was probably just merge omision from my side) and try to remove the verify_flow_info bit and see if everything works. I can do it tonight or tomorrow unless you beat me. Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29841
