--- 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
--- 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, re
--- 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
> i
--- 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'
--- 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 i
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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 t
--- 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
--- 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...
Ho
--- 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
--- 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
--- 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 a
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 d
--- 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-hid
--- 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
--- 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.
Th
--- 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 x8
--- 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
--- 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 doe
--- 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 dorm
--- 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:
>
>
--- 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
--- 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. U
--- 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/al
--- 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 ge
--- 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,
>
&g
--- 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* t
--- 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)
>
--- 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] unrecognisabl
--- 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
--- 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 mess
--- 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
--- 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
--- 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
38 matches
Mail list logo
