Together with the combine.c patch posted (but remaining a WIP),
all coremark performance regressions are gone for CRIS, compared
to cc0. Unfortunately, I looked further, and found some issues
when running gcc.c-torture/execute/arith-rand.c and
arith-rand-ll.c, in those functions and the target-spe
Whoops. This little gem had the effect of making the output
operand (0) constraints disappear but not the input operand (1)
constraints for define_subst:ed patterns, probably because
there's another (match_dup 1) in the output template (not
investigated).
That went surprisingly unnoticed until I
Getting tired of:
make[1]: Entering directory 'x/gccobj/gcc'
Makefile:2682: warning: overriding recipe for target 'gt-cris.h'
xx/gcc/gcc/config/cris/t-cris:29: warning: ignoring old recipe for target
'gt-cris.h'
I'm just going to assume it is just stale cruft no longer (if
ever) needed since not
Comparing to the cc0 version of the CRIS port, I ran a few
microbenchmarks, for example gcc.c-torture/execute/arith-rand.c,
where there's sometimes an addition between an operation of
interest and the test on the result.
Unfortunately this patch doesn't remedy all the performance
regression for th
(All patches are committed.)
Delayed-branch-slot-filling a.k.a. reorg or dbr, often causes
opportunities for more compare-elimination than were visible for
the cmpelim pass. With cc0, these were caught by the
elimination pass run in "final", thus the missed opportunities
is a regression. A simpl
> From: Jeff Law
> Date: Tue, 5 May 2020 16:52:07 +0200
> On Mon, 2020-02-10 at 17:55 +0100, Hans-Peter Nilsson wrote:
> > * config/cris/cris.c (cris_reduce_compare): New function.
> > * config/cris/cris-protos.h (cris_reduce_compare): Add prototype.
> > * con
> From: Jeff Law via Gcc-patches
> Date: Tue, 5 May 2020 17:05:01 +0200
> On Wed, 2020-02-12 at 07:47 +0100, Hans-Peter Nilsson wrote:
> > I just rebased and updated the vendors/axis branch
> > axis/cris-decc0 with the following commits, which should bring
> > back com
Not that anyone would notice, except a few maintainers of
targets with delay-slots, and only if the first patch causes
fallout, as the others only touch stuff related to the CRIS target.
The 23 commits have been posted previously, around Jan-Feb. For
reference:
2c2d405 dbr: Filter-out TARGET_FLA
> From: Alexandre Oliva
> Date: Tue, 26 May 2020 15:52:57 +0200
> On May 26, 2020, Richard Biener wrote:
>
> > xgcc: error: unrecognized command-line option '-dumpbase'^M
>
> > xg++: error: unrecognized command-line option '-dA'; did you mean '-A'
>
> Here's a proper patch submission.
And he
> From: Alexandre Oliva
> Date: Wed, 27 May 2020 16:30:07 +0200
> On May 26, 2020, Hans-Peter Nilsson wrote:
>
> >> Here's a proper patch submission.
>
> > And here's an improper bug report.
>
> :-)
>
> Thanks, H-P,
>
> > xgcc: e
> From: Alexandre Oliva
> Date: Tue, 2 Jun 2020 13:29:03 +0200
> Hello, Anthony, H-P,
>
> On May 27, 2020, Anthony Green wrote:
>
> > Hans-Peter Nilsson via Gcc-patches writes:
> >> And here's an improper bug report.
> >>
> >> One of t
> From: Luis Machado via Gcc-patches
> Date: Mon, 11 Jan 2021 15:58:43 +0100
> This seems to have broken the builds on AArch64-Linux Ubuntu 18.04.
>
> make[2]: Entering directory 'binutils-gdb-master-bionic/libiberty'
> rm -f ./libiberty.a pic/./libiberty.a noasan/./libiberty.a
> ar --plugin /us
When cleaning out the multitude of patterns with unknown
coverage, this one went the way of the bathwater. It's use is
barely common enough to mark when diffing libgcc, and has a
minimal impact on performance-testsuites. Anyway, reinstated
with a couple of test-cases. It's suboptimal of gcc-core
The code in cris_select_cc_mode for selecting CC_NZmode was
partly inconsistent with the comment and partly seemed
ambiguous. I couldn't find a reason why I qualified selection
of CC_NZmode on the setting operation once a matching user was
spotted, so I just removed that. The cris.c update was du
Yet another misnumbering of operands: the asserted non-overlap
would be the only benign operands overlap. "Suddenly" exposed
by g++.dg/cpp0x/pr81325.C when testing unrelated changes
affecting register allocation.
To wit, operands 2 and 1 are the only ones that are safe for
overlap, it's only that
(The previous patch was also committed, FWIW, I just forgot to
mention it.)
Combine likes to change a zero-extension / and + shift as seen
in the test-case source to a logical shift followed by an and of
the shifted mask, like:
lsrq 1,r0
and.d 0x7f,r0
This was observed in the hot loop of corema
ot functions, and the swing between
different functions is larger than this difference; to be dealt
with separately.
Tested cris-elf, x86_64-linux, powerpc64le-linux, 2/3 through
aarch64-linux (unexpectedly slow).
Ok to commit?
2020-07-06 Hans-Peter Nilsson
PR target/93372
Most comments, including the second sentence in the head comment
of combine_validate_cost, the main decision-maker of the combine
pass, refer to the function as returning true if the new
insns(s) *cheaper* than the old insns, when in fact the function
returned true also if the cost was the same. R
> From: Richard Sandiford
> Date: Mon, 6 Jul 2020 11:48:25 +0200
> Out of interest, how do the results change if we still allow the
> combination for equal costs if the new sequence is shorter than
> the original? I think that still counts as "cheaper than",
> but maybe I'm too RISC-centric. ;-)
> From: Segher Boessenkool
> Date: Tue, 7 Jul 2020 01:42:47 +0200
TL;DR: recognize a parallel with a clobber of TARGET_FLAGS_REGNUM?
> Hi!
>
> On Mon, Jul 06, 2020 at 03:11:17AM +0200, Hans-Peter Nilsson wrote:
> > TL;DR: fixing a misdetection of what is a "simple
> From: Segher Boessenkool
> Date: Tue, 7 Jul 2020 01:42:47 +0200
(Regarding is_just_move in combine.c.)
> But it is *not* supposed to be the same as single_set.
>
> > I checked the original commit, c4c5ad1d6d1e1e a.k.a r263067 and
> > it seems parallels-as-sets were just overlooked and that th
The store to the whole of each volatile object was picked apart
like there had been an individual assignment to each of the
fields. Reads were added as part of that; see PR for details.
The reads from volatile memory were a clear bug; individual
stores questionable. A separate patch clarifies the
ething safe about aggregate
objects, but only for those that are the same size as a scalar
type.
There's an equal-sounding section (Volatiles) in extend.texi,
but this seems a more appropriate place, as specifying the
behavior of a standard qualifier.
gcc:
2020-12-02 Hans-Peter Nilsson
> From: Martin Sebor via Gcc-patches
> Date: Fri, 4 Dec 2020 01:49:51 +0100
> On 12/3/20 12:14 PM, Hans-Peter Nilsson via Gcc-patches wrote:
> > Belatedly, here's an updated version, using Martin Sebor's
> > suggested wording from
> > "https://gcc.gnu.
> From: Patrick Palka via Gcc-patches
> Date: Fri, 4 Nov 2022 16:05:25 +0100
> This patch moves the global object for constructing the standard streams
> out from and into the compiled library on targets that support
> the init_priority attribute. This means that no longer
> introduces a separ
How was r13-2619-g34b9a03353d3fd "gcov: Respect triplet when looking
for gcov" tested? I'm having a hard time believing it was tested with
a *cross-compiler* *in-build-tree*. I think it was only tested for
the special-case of an installed cross-compiler; not even with a
native build exercising th
Generated pdf inspected. Ok to commit?
Thoughts on fixing the IMHO wart to also expose all
replacements to all define_peephole2? Looks feasible
(famous last words), but then again I haven't checked the
history yet.
-- >8 --
I was a bit surprised when my define_peephole2 didn't match,
but it was
meant. Maybe you could add some words
> to say more explicitly which it is.
I'm referring to an example on the same pdf page.
But perhaps s/resumes at the last generated insn/resumes at
the last insn in the replacement sequence/ would help?
brgds, H-P
>
> paul
>
&g
> From: Hans-Peter Nilsson
> Date: Tue, 18 Apr 2023 20:44:12 +0200
>
> > From: Paul Koning
>
> > Date: Tue, 18 Apr 2023 14:32:07 -0400
> >
> > I'm not sure about the meaning of part of this.
> > "...resumes at the last generated insn."
> From: Hans-Peter Nilsson
> Date: Wed, 19 Apr 2023 05:15:27 +0200
> Approvers: pdf output reviewed. Ok to commit?
Patch retracted, at least temporarily. My "understanding"
may be clouded by looking at an actual bug. Sigh.
brgds, H-P
I'll commit this as obvious, so it doesn't trick anyone else
anymore.
-- >8 --
* recog.cc (peep2_attempt, peep2_update_life): Correct
head-comment description of parameter match_len.
---
gcc/recog.cc | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/gcc/recog.
> From: Hans-Peter Nilsson
> Date: Wed, 19 Apr 2023 06:06:27 +0200
>
> Patch retracted, at least temporarily. My "understanding"
> may be clouded by looking at an actual bug. Sigh.
Mea culpa. I was looking at the result of one
define_peephole2 and thinking it was
d out. Or
something else entirely unexpected. :)
> >Please also see below.
> >
> >On 19 April 2023 18:59:14 CEST, Hans-Peter Nilsson via Gcc-patches
> > wrote:
> >>Anyway, the missing-context problem I ran into remains: if
> >>you have an insn sequence {
> From: Hans-Peter Nilsson
> Date: Wed, 19 Apr 2023 18:59:14 +0200
[...]
> So again: Approvers: pdf output reviewed. Ok to commit?
> -- >8 --
> I was a bit surprised when my newly-added define_peephole2 didn't
> match, but it was because it was expected to partially ma
Not many targets define this besides msp430, pdp1, xtensa,
and arm compared to those that appear to unconditionally
have a hardware division instruction (also, pdp11 and
msp430 seem confused and should be empty instead of "1" and
"(! TARGET_HWMULT)" - and having hardware multiplication
doesn't hav
> From: Paul Koning
> Date: Wed, 26 Apr 2023 21:02:31 -0400
> > On Apr 26, 2023, at 8:05 PM, Hans-Peter Nilsson wrote:
> >
> > Not many targets define this besides msp430, pdp1, xtensa,
> > and arm compared to those that appear to unconditionally
> > have a
Ok to commit?
-- >8 --
I tried to make use of check-function-bodies for cris-elf and was a
bit surprised to see it failing. There's a deliberate empty line
after the filled delay slot of the return-function which was
mishandled. I thought "aha" and tried to add an empty line
(containing just a "*
> Date: Mon, 1 May 2023 07:21:59 -0600
> From: Jeff Law
> Spurred by Segher's RFC, I went ahead and tested several ports with LRA
> enabled. Not surprisingly, many failed, but a few built their full set
> of libraries successful and of those a few even ran their testsuites
> with no regressio
On previous occasions when a general LRA transition has been
discussed, IIRC, the argument was used, that everything is ready for
targets and their maintainers to make the transition. As I pointed
out then (though more than a year ago last time, people forget) that's
still not true: LRA documentat
Ping again.
> From: Hans-Peter Nilsson
> Date: Thu, 27 Apr 2023 01:55:24 +0200
>
> > From: Hans-Peter Nilsson
> > Date: Wed, 19 Apr 2023 18:59:14 +0200
> [...]
>
> > So again: Approvers: pdf output reviewed. Ok to commit?
> > -- >8 --
>
This has no effect on arith-rand-ll (which suffers badly from LRA) and
marginal effects (0.01% improvement) on coremark, but the size of
coremark shrinks by 0.2%. An earlier version was tested with a tree
around 2023-03 which showed (marginally) that ALL_REGS is preferable
to GENERAL_REGS.
This kind of transformation seems pretty generic and might be a
candidate for adding to the middle-end, perhaps as part of combine.
I noticed these happened more often for LRA, which is the reason I
went on this track of low-hanging-fruit-microoptimizations that are
such an itch when noticing them
Observed after opsplit1 with AND in libgcc floating-point
functions, like the first spottings of opsplit1/AND
opportunities. Two patterns are nominally needed, as the
peephole2 optimizer continues from the *first replacement*
insn, not from a minimum context for general matching; one
that includes
While moves of constants into registers are separately
optimizable, a combination of a move with a subsequent "and"
is slightly preferable even if the move can be generated
with the same number (and timing) of insns, as moves of
"just" registers are eliminated now and then in different
passes, loos
Unfortunately, doesn't cause a performance improvement for coremark,
but happens a few times in newlib, just enough to affect coremark
0.01% by size (or 4 bytes, and three cycles (__fwalk_sglue and
__vfiprintf_r each two bytes).
gcc:
* config/cris/cris.md (splitop): Add PLUS.
* con
Tested cris-elf and native x86_64-pc-linux-gnu.
Ok to commit?
-8< --
For targets where the ABI mandates structure layout that has
no padding, like cris-elf, this test started failing when
introduced as an add-on to the existing 1.cc, thereby
effectively causing a regression in testsuite r
> From: Jonathan Wakely
> Date: Wed, 1 Feb 2023 18:19:09 +0100
> On Wed, 1 Feb 2023 at 16:01, Jonathan Wakely wrote:
> >
> > On Wed, 1 Feb 2023 at 14:38, Hans-Peter Nilsson via Libstdc++
> > wrote:
> > >
> > > Tested cris-elf and native x86_64
Tested cris-elf, native x86_64-pc-linux-gnu.
Ok to commit?
--- 8< ---
These appear as regressions from a baseline before
r13-3761-ga239a63f868e29. See the PR trail.
Note that the warning for g++.dg/pr71488.C is for a *header*
file, thus we can't match the line number (sanely).
gcc/testsuite:
Tested cris-elf and native x86_64-pc-linux-gnu.
Ok to commit?
8<
The use of a "naked" int32_t (i.e. without a fitting #include:
stdint.h or cstdint or inttypes.h or an equivalent internal header),
in libstdc++-v3/include/pstl/unseq_backend_simd.h, caused an error for
cris-elf and apparen
(sort-of-ping:) Aldy, I missed CC:ing you on the similar
https://gcc.gnu.org/pipermail/gcc-patches/2023-February/611206.html
would you mind having a look?
Tested native x86_64-pc-linux-gnu (w/wo. -m32) and cris-elf.
Ok to commit?
8<
There was a commit r13-2082-gbf13a13c65bd06 "c++: remo
> From: Aldy Hernandez
> Date: Tue, 7 Feb 2023 17:52:02 +0100
> Up to the release managers, but I have no objections.
I take it that's for both patches. Thanks!
(Potential reviewers: these patches are local to the testsuite.)
brgds, H-P
>
> Aldy
>
> On 2/7/23
Tested native x86_64-pc-linux-gnu and cris-elf (non-LRA and
also hacked to switch to LRA).
Ok to commit?
--- 8< ---
The LRA target list is incomplete. Rather than syncing it with actual
LRA targets, better use existing infrastructure and look for a
LRA-specific pattern in the reload dump (which
> From: Richard Sandiford
> Date: Wed, 8 Feb 2023 17:54:15 +0100
> Hans-Peter Nilsson via Gcc-patches writes:
> > Tested native x86_64-pc-linux-gnu and cris-elf (non-LRA and
> > also hacked to switch to LRA).
>
> Since !LRA is hopefully not long for this world, I&#x
Sanity-checked for cris-elf with the
check_effective_target_lra correction in
https://gcc.gnu.org/pipermail/gcc-patches/2023-February/611531.html
Committed as obvious.
--- 8< ---
These tests spuriously lacked a "lra" limiter. Code using
"asm goto" with outputs gets a:
error: the target does not
> From: Vladimir Makarov via Gcc-patches
> Date: Thu, 9 Feb 2023 22:49:34 +0100
> The patch was successfully bootstrapped (--enable-languages=all) and
> tested on x86, x86-64, aarch64
Sorry, but this (also) caused test-suite regressions,
perhaps just for cris-elf. I've opened 108754 and will
a
When DWARF_FRAME_REGISTERS isn't defined, the default is
FIRST_PSEUDO_REGISTER which means that if you add faked
registers to the port, used for frame-context related
elimination, room is allocated for them in the register
context used for frame-unwinding, which is wasteful because
they're eliminat
Forgot to mention: no differences in cris-elf test-results at r11-7500.
Beware, tm.texi doesn't tell the whole story: a defined
HARD_FRAME_POINTER_REGNUM (different to FRAME_POINTER_REGNUM) is
supposed to make work easier for reload, being able to easily
tell actual frame-pointer-related addresses
See PR99212. Now, cris-elf isn't the only target for which this line
shows a failure; pru-unknown-elf and m68k-unknown-linux-gnu are two
others. I'll leave adjustments to the respective maintainers, but
trivially appending more triplets should work: no extra bracketing needed.
A specific effectiv
Unfortunately it appears that this PR is on nobody's radar.
Xfailing it to get an arguably artificial zero regression
state (since T0=2007-01-05) helps my autotester.
Caveat: the pass/fail state of this test, as long as stack
alignment isn't adjusted, is dependent on the alignment of
the stack at
> From: Richard Sandiford via Gcc-patches
> Date: Thu, 6 Jan 2022 15:48:01 +0100
> If an allocno A in an inner loop L spans a call, a parent allocno AP
> can choose to handle a call-clobbered/caller-saved hard register R
> in one of two ways:
>
> (1) save R before each call in L and restore R af
ck (error-prone) grep-and-eyeball in config/ shows this was the
only file missing the parenthesis. This lets cris-elf configured with
--enable-checking=yes,extra,rtl survive make all-gcc.
2022-01-11 Hans-Peter Nilsson
* config/cris/cris.c (cris_postdbr_cmpelim): Parenthesize
pa
hat I therefore agree that operators, identifiers and keywords
should have to be dressed up like this for internal error messages;
they were more readable without these garments, if only slightly so.
2022-01-11 Hans-Peter Nilsson
* config/cris/cris.c: Quote identifiers in parameters t
> From: Jeff Law via Gcc-patches
> Date: Wed, 12 Jan 2022 16:58:50 +0100
> On 1/12/2022 8:00 AM, Richard Biener wrote:
> > On Wed, Jan 12, 2022 at 3:26 PM Vladimir Makarov
> > wrote:
> >>
> >> On 2022-01-12 03:47, Richard Biener wrote:
> >>> On Tue, Jan 11, 2022 at 7:41 PM Vladimir Makarov via
> From: Jeff Law via Gcc-patches
> Date: Wed, 12 Jan 2022 16:58:50 +0100
> On 1/12/2022 8:00 AM, Richard Biener wrote:
> > On Wed, Jan 12, 2022 at 3:26 PM Vladimir Makarov
> > wrote:
> >>
> >> On 2022-01-12 03:47, Richard Biener wrote:
> >>> On Tue, Jan 11, 2022 at 7:41 PM Vladimir Makarov via
> From: Patrick Palka via Gcc-patches
> Date: Sun, 16 Jan 2022 19:06:48 +0100
> We're going to use the fast_float library in our (compiled-in)
> floating-point std::from_chars implementation for faster and more
> portable parsing of binary32/64 decimal strings.
>
> The single file fast_float.h
Pinging this patch.
> From: Hans-Peter Nilsson
> Date: Thu, 9 Mar 2023 19:56:16 +0100
>
> It's not obvious to me whether considered best to include or
> exclude these tests that depend on structure layout details.
> If excluding, the obvious alternative to this patch is
> From: David Malcolm
> Date: Thu, 16 Mar 2023 13:55:48 -0400
> On Thu, 2023-03-09 at 19:56 +0100, Hans-Peter Nilsson wrote:
> > It's not obvious to me whether considered best to include or
> > exclude these tests that depend on structure layout details.
> > If ex
> From: Hans-Peter Nilsson
> Date: Thu, 16 Mar 2023 19:25:05 +0100
> That doesn't seem like a good idea. At a glance the
> *testcode* will be simpler, but the patch will be slightly
> larger
Bah, s/but the patch will be slightly larger/and the patch
will certainly be small
> From: David Malcolm
> Date: Thu, 16 Mar 2023 14:42:58 -0400
> I think I prefer the top one-liner dg-skip-if approach you mentioned in
> your original email; it seems simplest.
Ok then. There's also a choice between adding a
target-specifier (i.e. "{ target { ! default_packed } }") to
the dg-c
> From: Hans-Peter Nilsson
> CC: ,
> Date: Tue, 14 Mar 2023 17:04:43 +0100
Ping on contents (formatting is approved):
> I needed to check what was allowed in a define_split, but
> had problems understanding what was meant by "Splitting of
> jump instruction into sequen
(CC to respectively author and committer of pr100359.c.)
Tested cris-elf and native x86_64-linux: the two
scan-tree-dumps pass and x86_64-linux still links. Ok to
commit?
-- >8 --
The test gcc.dg/tree-ssa/pr100359.c fails the "test for
excess errors" for at least m68k-linux, pru-elf, and
cris-el
Tested native x86_64-linux and cris-elf. The "recent patch
to gcc.dg/tree-ssa/pr100359.c" refers to r13-6838.
Committed as obvious after that commit.
-- >8 --
The test gcc.dg/tree-ssa/ssa-fre-100.c fails the
scan-tree-dump-not fre1 "baz" for at least m68k-linux,
pru-elf, and cris-elf according to
gcc:
* config/cris/constraints.md ("R"): Remove unused constraint.
---
gcc/config/cris/constraints.md | 10 --
1 file changed, 10 deletions(-)
diff --git a/gcc/config/cris/constraints.md b/gcc/config/cris/constraints.md
index 05a1d24ef5a1..5efb61364f46 100644
--- a/gcc/config/cris
This patch affects a post-reload define_split for CRIS that transforms
a condition-code-clobbering addition into a non-clobbering addition.
(A "two-operand" addition between registers is the only insn that has
both a condition-code-clobbering and a non-clobbering variant for
CRIS.) Many more "add.
The test-case gcc.target/cris/rld-legit1.c is a reduced
test-case that required defining LEGITIMIZE_RELOAD_ADDRESS
to stop the address from being decomposed into several insns
by reload. Valid but suboptimal code was generated.
(Before implementing that hook for CRIS, the same test-case
also expo
This patch has no effect on builds using reload of libgcc, newlib libc, my
own at-a-glance-testsuite and coremark. That somewhat surprisingly
also goes for LRA builds, even with all CRIS reload_in_progress
augmented to include lra_in_progress. I just noticed it when checking
because another port
> From: Hans-Peter Nilsson
> Date: Tue, 14 Mar 2023 17:04:43 +0100
Ping #2 on contents (formatting is approved):
> -- >8 --
> I needed to check what was allowed in a define_split, but
> had problems understanding what was meant by "Splitting of
> jump instruction
Stepping through a gdb session inspecting costs that cause
gcc.dg/tree-ssa/slsr-13.c to fail, exposed that before this
patch, cris_rtx_costs told that a shift of 1 of a register
costs 5, while adding two registers costs 4.
Making the cost of a quick-immediate constant equal to using
a register (de
> Attached. I also removed the bogus warning in Walloc-13.c that no longer
> happens
> Add recursive GORI recompuations with a depth limit.
>
> PR tree-optimization/109154
> gcc/
> * gimple-range-gori.cc (gori_compute::may_recompute_p): Add depth
> li
> Date: Fri, 31 Mar 2023 15:48:22 -0400
> From: Andrew MacLeod via Gcc-patches
> Reply-To: Andrew MacLeod
> commit 55bf4f0d443e5adbacfcdbbebf4b2e0c74d1dcc8
> Author: Andrew MacLeod
> Date: Fri Mar 31 15:42:43 2023 -0400
>
> Adjust testcases to not produce errors..
>
> tr
Committed as obvious. See also the previous discussion
regarding my define_split doc patch.
-- >8 --
The line-break in the example looked odd, even more so with
a page-break in the middle of it, due to recently added text
in preceding pages.
* doc/md.texi (Including Patterns): Fix page br
> Date: Tue, 18 Apr 2023 07:43:41 -0600
> From: Jeff Law
> On 2/15/23 08:34, Hans-Peter Nilsson via Gcc-patches wrote:
> > Regtested cris-elf with its LEGITIMIZE_RELOAD_ADDRESS
> > disabled, where it regresses gcc.target/cris/rld-legit1.c;
> > as expected, beca
)[0xac6c]
/lib/libc.so.6( __libc_start_main +0x120)[0x4c86d104]
./bt[0xa510]
The CodeSourcery toolchain contains a "fix" like the following,
please consider for adding it.
Best regards
Peter Wächtler
--- eh_personality.cc.orig 2012-02-28 16:35:20.0 +0100
+++ eh_pers
(int*, int, int) +0xf0)[0xa8e0]
./bt( main +0x230)[0xac6c]
/lib/libc.so.6( __libc_start_main +0x120)[0x4c86d104]
./bt[0xa510]
The CodeSourcery toolchain contains a "fix" like the following,
please consider for adding it.
Best regards
Peter Wächtler
--- eh_personality.cc.orig
> On Mon, Mar 19, 2012 at 12:12 PM, Andrew Stubbs
> wrote:
> > On 16/03/12 13:29, EXTERNAL Waechtler Peter (Fa. TCP,
> CM-AI/PJ-CF31) wrote:
> >>
> >> The CodeSourcery toolchain contains a "fix" like the following,
> >> please consider for a
> -Ursprüngliche Nachricht-
> Von: Andrew Stubbs [mailto:a...@codesourcery.com]
> Gesendet: Montag, 19. März 2012 17:12
> An: EXTERNAL Waechtler Peter (Fa. TCP, CM-AI/PJ-CF31)
> Cc: gcc-patches@gcc.gnu.org; libstd...@gcc.gnu.org;
> p...@codesourcery.com; pwaecht...@mac.c
2301 - 2386 of 2386 matches
Mail list logo
