--- Comment #1 from chrbr at gcc dot gnu dot org 2010-07-16 11:34 ---
done since http://gcc.gnu.org/ml/gcc-patches/2010-01/msg01147.html
needed ACCUMULATE_OUTGOING_ARG to fix unwinding (can go back to previous
behavior with -mno-accumulate-outgoing-args -fno-omit-frame-pointer
--- Comment #36 from chrbr at gcc dot gnu dot org 2010-02-10 12:02 ---
(In reply to comment #33)
Your fix of the middle end looks plausible but I think the target
shouldn't generate a CP at the eh landing pad anyway. I'll commit
the hunk below anyway after your patch for pic problem
--- Comment #34 from chrbr at gcc dot gnu dot org 2010-02-05 08:26 ---
(In reply to comment #33)
Your fix of the middle end looks plausible but I think the target
shouldn't generate a CP at the eh landing pad anyway. I'll commit
the hunk below anyway after your patch for pic problem
--- Comment #32 from chrbr at gcc dot gnu dot org 2010-02-05 07:05 ---
Looks smart and clean! One minor nit, I guess that the occurence of
gbr and GBR in ChangeLog and comments should be replaced with GOT to
avoid confusion with GBR register of SH CPU.
Thanks for catching up
--- Comment #28 from chrbr at gcc dot gnu dot org 2010-02-03 08:30 ---
Hello Kaj, thanks for your proposal
thanks for the proposal. but I'm wondering if preventing the scheduling of the
mov.l and mova instructions are not too much overkill ? (sh_reorg comes after
the scheduler
--- Comment #30 from chrbr at gcc dot gnu dot org 2010-02-03 13:12 ---
Created an attachment (id=19794)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19794action=view)
patch to fix GOT access load with constant pool
Patch under validation.
--
http://gcc.gnu.org/bugzilla
--- Comment #26 from chrbr at gcc dot gnu dot org 2010-02-01 16:30 ---
I'm afraid the unaligned access sigbug regression is another latent bug just
exhibited by the fix for the original PR :-(
what happens is the the GOT loading sequence is broken by a constant pool:
we end up to emit
--- Comment #25 from chrbr at gcc dot gnu dot org 2010-01-29 08:59 ---
by the way, FYI, trying to explain the differences between your results and
mine for sh4-linux. my build was is configured with --enable-target-optspace,
so all my runtime build tests are ran with -Os, not -O2 like
--- Comment #22 from chrbr at gcc dot gnu dot org 2010-01-28 13:09 ---
humm, looks like a latent bug. Accidentally the CP is inserted before a
compact_jump, which enable further redirect jump optimisation. I don't think it
is directly related to the fix, but lets work it a little bit
--- Comment #24 from chrbr at gcc dot gnu dot org 2010-01-29 07:46 ---
Created an attachment (id=19747)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19747action=view)
fixed removal of landing pad label rtx
The landing_pad label rtx was created and recorded in tree_inline
--- Comment #17 from chrbr at gcc dot gnu dot org 2010-01-27 12:50 ---
strange, I didn't see that, even the undefined symbol in the assembler.
OK I disable the fix until this is clarified.
Let me do a recheck on the silicium, will let you know.
-c
(In reply to comment #16)
I've
--- Comment #18 from chrbr at gcc dot gnu dot org 2010-01-27 13:24 ---
Subject: Bug 42841
Author: chrbr
Date: Wed Jan 27 13:24:40 2010
New Revision: 156282
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156282
Log:
temporarily revert fix for PR target/42841
Modified:
trunk
--- Comment #19 from chrbr at gcc dot gnu dot org 2010-01-27 13:40 ---
to make sure we are in the same testing/configuration environment could you
please send me the preprocessed file for
23_containers/deque/requirements/exception/propagation_consistent.cc as well as
the compilation
--- Comment #21 from chrbr at gcc dot gnu dot org 2010-01-27 18:13 ---
This one is marked as unsupported in my sh-superh-elf log, But I can reproduce
it now on sh4-linux. (despite that I have rebuilt a whole distrib without
seeing it :O).
Anyway I'm investigating. I'm reopening the bug
--- Comment #11 from chrbr at gcc dot gnu dot org 2010-01-26 07:20 ---
Subject: Bug 42841
Author: chrbr
Date: Tue Jan 26 07:20:27 2010
New Revision: 156229
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156229
Log:
fix PR target/42841
Modified:
trunk/gcc/ChangeLog
trunk
--- Comment #12 from chrbr at gcc dot gnu dot org 2010-01-26 07:22 ---
Subject: Bug 42841
Author: chrbr
Date: Tue Jan 26 07:21:57 2010
New Revision: 156230
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156230
Log:
fix PR target/42841
Modified:
branches/gcc-4_4-branch/gcc
--- Comment #13 from chrbr at gcc dot gnu dot org 2010-01-26 07:28 ---
Subject: Bug 42841
Author: chrbr
Date: Tue Jan 26 07:28:05 2010
New Revision: 156231
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156231
Log:
fix PR target/42841
Modified:
branches/gcc-4_3-branch/gcc
--- Comment #14 from chrbr at gcc dot gnu dot org 2010-01-26 07:29 ---
fixed in 4.5, 4.3 and 4.4
--
chrbr at gcc dot gnu dot org changed:
What|Removed |Added
unsigned as input and
output values.
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: trivial
Priority: P3
Component: treelang
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: chrbr
--- Comment #1 from chrbr at gcc dot gnu dot org 2009-10-09 07:12 ---
Created an attachment (id=18758)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18758action=view)
Fix synchronisation parameter/output signess
The attached patch gives the correct semantic. But should be checked
at gcc dot gnu dot org
ReportedBy: chrbr at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41486
--- Comment #1 from chrbr at gcc dot gnu dot org 2009-09-28 10:53 ---
Created an attachment (id=18665)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18665action=view)
case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41486
--- Comment #9 from chrbr at gcc dot gnu dot org 2009-03-12 15:04 ---
The attached patch improves the SH generation, but I noticed a small regression
with the ARM that could make use before of a shifted constant addressing mode,
so not using the extra register for the value.
A target
--- Comment #10 from chrbr at gcc dot gnu dot org 2009-03-12 15:10 ---
Created an attachment (id=17447)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17447action=view)
SH illustrative patch
for feedback only. win on SH. lost on ARM
2009-03-12 Christian Bruel christian.br
--- Comment #2 from chrbr at gcc dot gnu dot org 2009-03-11 08:46 ---
I observed some large performance regressions in 4.3 and upwards for many
benchmarks for the superh targets, There are many causes but the main one is
reduced to the indirect+offset access :
int
foo (int tab[], int
--
chrbr at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |chrbr at gcc dot gnu dot org
|dot org
--- Comment #4 from chrbr at gcc dot gnu dot org 2009-03-11 09:30 ---
(In reply to comment #3)
See http://gcc.gnu.org/ml/gcc-patches/2008-12/msg01134.html
Thanks, I tried your patch against a 4.3.3 base but it didn't fix the problem,
your patch canonicalizes while what I need
--- Comment #8 from chrbr at gcc dot gnu dot org 2009-03-11 14:07 ---
I have picky disabled the canonicalization in fold_plusminus_mult_expr for
identical constants that are power of 2, so my mov @(disp, rn) is back :-(. For
some reason your patch let the base+index computation
--
Summary: [
Product: gcc
Version: 4.3.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: chrbr at gcc dot gnu dot org
http
: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: chrbr at gcc dot gnu dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org
--- Comment #1 from chrbr at gcc dot gnu dot org 2009-03-06 14:05 ---
Created an attachment (id=17406)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17406action=view)
Example
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39391
--- Comment #4 from chrbr at gcc dot gnu dot org 2008-02-19 07:53 ---
fixed in mainline
--
chrbr at gcc dot gnu dot org changed:
What|Removed |Added
URL
--- Comment #11 from chrbr at gcc dot gnu dot org 2008-02-15 13:08 ---
If no one as started to do so, I'm resurecting this patch for the mainline, I
can test builtin-apply4.c on sh4.
btw, builtin-apply4.c doesn't currently fail with the testsuite because it is
restricted to { target
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: chrbr at gcc dot gnu dot org
GCC target triplet: sh4-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35178
--- Comment #1 from chrbr at gcc dot gnu dot org 2008-02-13 13:42 ---
Created an attachment (id=15138)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15138action=view)
gcc testsuite case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35178
--- Comment #2 from chrbr at gcc dot gnu dot org 2008-02-13 13:45 ---
Created an attachment (id=15139)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15139action=view)
Proposed patch
regression tested on sh-superh-elf and sh4-linux-gnu.
and bootstraped for i686-pc-linux-gnu
at gcc dot gnu dot org
ReportedBy: chrbr at gcc dot gnu dot org
GCC target triplet: sh-superh-elf,sh4-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34807
--- Comment #1 from chrbr at gcc dot gnu dot org 2008-01-16 08:47 ---
Created an attachment (id=14945)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14945action=view)
Test case
build with sh-superh-elf-gcc -O1 -fPIC test.c -S
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #2 from chrbr at gcc dot gnu dot org 2008-01-16 11:15 ---
Created an attachment (id=14946)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14946action=view)
fails with 4.2.2 and 4.3.0
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34807
--- Comment #7 from chrbr at gcc dot gnu dot org 2007-10-31 07:56 ---
Subject: Bug 19531
Author: chrbr
Date: Wed Oct 31 07:55:46 2007
New Revision: 129792
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=129792
Log:
fix PR c++/19531: NRV is performed on volatile temporary
Added
--- Comment #8 from chrbr at gcc dot gnu dot org 2007-10-31 08:01 ---
fixed check_return_expr
--
chrbr at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from chrbr at gcc dot gnu dot org 2007-10-09 08:36 ---
*** Bug 32684 has been marked as a duplicate of this bug. ***
--
chrbr at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from chrbr at gcc dot gnu dot org 2007-10-09 08:36 ---
I think this is a duplicate of #15473 (Sibcall optimization for libcalls).
*** This bug has been marked as a duplicate of 15473 ***
--
chrbr at gcc dot gnu dot org changed:
What|Removed
--- Comment #5 from chrbr at gcc dot gnu dot org 2007-10-09 13:12 ---
you are right, it's not a sibcall, my mistake.
But even at the tree level I still don't see the builtin marked as tailcall. On
a reduced case when entering find_tail_calls I have
D.1177_2 = __builtin_cos (phi_1(D
--- Comment #6 from chrbr at gcc dot gnu dot org 2007-10-09 13:15 ---
you are right, it's not a sibcall, my mistake.
typo, I meant libcall not sibcall
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32684
--- Comment #6 from chrbr at gcc dot gnu dot org 2007-10-08 11:02 ---
patch+testcase at http://gcc.gnu.org/ml/gcc-patches/2007-09/msg01902.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19531
--- Comment #4 from chrbr at gcc dot gnu dot org 2007-09-24 07:10 ---
Created an attachment (id=14248)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14248action=view)
volatile nrv patch
--
chrbr at gcc dot gnu dot org changed:
What|Removed
--- Comment #5 from chrbr at gcc dot gnu dot org 2007-09-24 07:14 ---
the attached patch was hanging in my sandbox. will submit it along with a
testsuite case.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19531
--- Comment #3 from chrbr at gcc dot gnu dot org 2007-09-03 13:24 ---
this report is quite old, but worth to pop :
We found similar problems with implicit memory block copying when using struct
copying by value. (frequent in C++ )
Softfloat architectures making a very extensive use
--- Comment #7 from chrbr at gcc dot gnu dot org 2007-06-08 07:58 ---
Subject: Bug 29953
Author: chrbr
Date: Fri Jun 8 07:58:41 2007
New Revision: 125564
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125564
Log:
PR target/29953
* config/sh/sh.md (doloop_end): New pattern
--- Comment #8 from chrbr at gcc dot gnu dot org 2007-06-08 08:18 ---
doloop_optimize does the iv inversion with the doloop_end insn support in the
machine description.
--
chrbr at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from chrbr at gcc dot gnu dot org 2007-05-15 10:30 ---
I dropped the 4.1 and implemented a -finvert-loops option on the trunk.
This option allows a basic induction variable to be decremented instead of
incremented to support exit testing against 0.
I'm validating
--- Comment #3 from chrbr at gcc dot gnu dot org 2007-04-23 07:59 ---
Hi Kaj,
The same problem seems to transpire from the movsf_ie pattern for the sh2a-fpu
that also have 32 bit memory instructions. So your fix also applies there.
Note that traditional sh memory move instructions can
: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: chrbr at gcc dot gnu dot org
GCC target triplet: sh-superh-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31640
--
chrbr at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |minor
Summary|cache align alignment is too|cache block
--- Comment #1 from chrbr at gcc dot gnu dot org 2007-04-20 14:13 ---
Created an attachment (id=13391)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13391action=view)
Illustrative patch to not align small basic blocks
I used this patch to reduce the number of basic blocks aligned
--- Comment #2 from chrbr at gcc dot gnu dot org 2007-04-20 15:51 ---
Created an attachment (id=13393)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13393action=view)
testcase for new instruction introduced by increased distance
In this example, the max distance between the jump
57 matches
Mail list logo
