On Thu, 30 Nov 2023 at 17:53, Jeff Law wrote:
> > * ext-dce.c: Fixes for carry handling.
> >
> > * ext-dce.c (safe_for_live_propagation): Handle MINUS.
> >(ext_dce_process_uses): Break out carry handling into ..
> >(carry_backpropagate): This new function.
> >
I originally computed mmask in carry_backpropagate from XEXP (x, 0),
but abandoned that when I realized we also get called for RTX_OBJ
things. I forgot to adjust the SIGN_EXTEND code, though. Fixed
in the attached revised patch. Also made sure to not make inputs
of LSHIFTRT / ASHIFTRT live if
On Wed, 29 Nov 2023 at 20:05, Joern Rennecke
wrote:
> > I suspect it'd be more useful to add handling of LSHIFTRT and ASHIFTRT
> > . Some ports do
> > a lot of static shifting.
>
> > +case SS_ASHIFT:
> > +case US_ASHIFT:
> > +
On Wed, 29 Nov 2023 at 19:57, Joern Rennecke
wrote:
>
> Attached is what I have for carry_backpropagate .
>
> The utility of special handling for SS_ASHIFT / US_ASHIFT seems
> somewhat marginal.
>
> I suspect it'd be more useful to add handling of LSHIFTRT and ASHIFTRT
>
Author: Joern Rennecke
Date: Wed Nov 29 18:46:06 2023 +
* ext-dce.c: Fixes for carry handling.
* ext-dce.c (safe_for_live_propagation): Handle MINUS.
(ext_dce_process_uses): Break out carry handling into ..
(carry_backpropagate): This new function.
Better
Why did you leave out MINUS from safe_for_live_propagation ?
On Tue, 28 Nov 2023 at 13:36, Joern Rennecke
wrote:
> For the saturating truncation operations, we have the high-to-low
propagation,
> but no low-to-high propagation, so that would be something separate to model.
P.S.:
For unsigned saturating truncation, the propagation from higher to
On Mon, 27 Nov 2023 at 20:18, Jeff Law wrote:
>
>
>
> On 11/27/23 13:03, Richard Sandiford wrote:
> > Joern Rennecke writes:
> >> On 11/20/23 11:26, Richard Sandiford wrote:
> >>>> + /* ?!? What is the point of this adjustment to DST_MASK?
On Mon, 27 Nov 2023 at 20:03, Richard Sandiford
wrote:
>
> Joern Rennecke writes:
> > On 11/20/23 11:26, Richard Sandiford wrote:
> >>> + /* ?!? What is the point of this adjustment to DST_MASK? */
> >>> + if (code == PLUS || code == MINUS
> &
You are applying PATTERN to an INSN_LIST.
diff --git a/gcc/ext-dce.cc b/gcc/ext-dce.cc
index 52032b50951..4523654538c 100644
--- a/gcc/ext-dce.cc
+++ b/gcc/ext-dce.cc
@@ -122,10 +122,9 @@ safe_for_live_propagation (rtx_code code)
optimziation phase during use handling will be. */
static
On 11/20/23 11:26, Richard Sandiford wrote:
>> + /* ?!? What is the point of this adjustment to DST_MASK? */
>> + if (code == PLUS || code == MINUS
>> + || code == MULT || code == ASHIFT)
>> + dst_mask
>> + = dst_mask ? ((2ULL << floor_log2 (dst_mask)) - 1) : 0;
>
> Yeah, sympathise
On 11/20/23 11:26, Richard Sandiford wrote:
>> +
>> + mask = GET_MODE_MASK (GET_MODE (SUBREG_REG (x))) << bit;
>> + if (!mask)
>> + mask = -0x1ULL;
>
> Not sure I follow this. What does the -0x1ULL constant indicate?
> Also, isn't it the mask of the outer register that
support for XCVhwlp extension in CV32E40P
2023-11-18 Joern Rennecke
gcc/
* common/config/riscv/riscv-common.cc (riscv_ext_version_table):
Add xcvhwlp.
(riscv_ext_flag_table): Likewise.
* config.gcc (riscv*): Add corev.o to extra_objs.
* config/riscv
aram=riscv-autovec-preference=scalable
riscv-sim/-march=rv64imac/-mabi=lp64
2023-11-08 Joern Rennecke
gcc/testsuite/
* lib/scanasm.exp (scan-assembler-times): Disregard LTO sections.
(scan-assembler-dem, scan-assembler-dem-not): Likewise.
(dg-scan): Likewise, if nam
On Wed, 11 Oct 2023 at 05:48, Joern Rennecke
wrote:
> So I propose we look at the first character of the regexp, and if it's neither
> ^ nor \ (neither caret nor backslash), we consider the regexp un-anchored,
> and prepend ^[^"]* , so it won't allow a match after a double q
On Sat, 30 Sept 2023 at 22:12, Joern Rennecke
wrote:
> Also, we might have different directives for not scanning in LTO sections -
> or just ignoring .ascii . Or maybe the other way round - you have to do
> something special if you want to scan inside strings, and by default we
>
.
2023-10-05 Joern Rennecke
gcc/
* doc/md.texi (doloop_end): Document oprional operand 2.
* loop-doloop.cc (doloop_optimize): Provide 3rd operand to
gen_doloop_end.
* target-insns.def (doloop_end): Add optional 3rd operand.
diff --git a/gcc
On Wed, 4 Oct 2023 at 18:38, Patrick O'Neill wrote:
>
> Hi Joern,
>
> I'm seeing new failures introduced by this patch
> (9464e72bcc9123b619215af8cfef491772a3ebd9).
>
> On rv64gcv:
> FAIL: gcc.dg/pr90263.c scan-assembler memcpy
My testing didn't flag this because I used elf targets. The
hed is the committed version.
commit 9464e72bcc9123b619215af8cfef491772a3ebd9
Author: Joern Rennecke
Date: Mon Oct 2 03:16:09 2023 +0100
cpymem for RISC-V with v extension
gcc/
* config/riscv/riscv-protos.h (riscv_vector::expand_block_move):
Declare.
* config/riscv/riscv-v
Committed as obvious (RE doesn't compile without patch, and I know
what I meant when I wrote it).
commit 5f3da480e7541a9c29d655dccb2463fc5f3cf2c4
Author: Joern Rennecke
Date: Sun Oct 1 22:46:43 2023 +0100
Fix typo in add_options_for_riscv_v, add_options_for_riscv_zfh
On Fri, 29 Sept 2023 at 14:54, Jeff Law wrote:
> So I recommend we go forward with Joern's approach (so consider that an
> ACK for the trunk). Joern can you post a follow-up manual twiddle so
> that other ports can follow your example and avoid this problem?
The manual... so not in the
st for using scalars values
spanning multiple
addressable units.
Make riscv_vector::legitimize_move adjust SRC in the caller.
2023-09-29 Joern Rennecke
Juzhe-Zhong
PR target/111566
gcc/
* config/riscv/riscv-protos.h (riscv_vector::legitimize_move):
Chan
On Wed, 27 Sept 2023 at 18:22, Jeff Law wrote:
> It would help to describe how these patterns were under specified so
> that folks don't continue to make the same mistake as new tests get added.
dg-final scan-assembler, scan-assembler-not, and scan-assembler-times
use a tcl regular expression
as obvious.
commit d326bb6d7588425d013791299272f913fb23e56d
Author: Joern Rennecke
Date: Wed Sep 27 10:05:13 2023 +0100
Harden scan patterns with a bit of scripting:
$ egrep -r 'scan-assembler(|-not|-times) "[[:alnum:].]{1,7}"' riscv
$ egrep -rl 'scan-assembler(|-
On Tue, 26 Sept 2023 at 14:18, Jeff Law wrote:
> But the Coremark code is what it is. This isn't a whole lot
> different than the work in the 90s which rewrote loops and compromised
> some of the spec benchmarks, or the eqntott hack to simplify that one
> key loop in eqntott.
I think the
On Sun, 24 Sept 2023 at 12:41, Alexander Monakov wrote:
>
>
> On Sun, 24 Sep 2023, Joern Rennecke wrote:
>
> > It is a stated goal of coremark to test performance for CRC.
>
> I would expect a good CRC benchmark to print CRC throughput in
> bytes per cycle or megabytes
Mariam Harutyunyan:
+++ b/gcc/ChangeLog
@@ -1,3 +1,45 @@
+2023-08-03 Mariam Arutunian
+
It is common courtesy to include all authors in the list of authors
for the ChangeLog; also,
this may help people in the future understand the history of the code better.
While must of your patch is new, it
In the patch call we talked about sign extsnsion elimination, so I dug
up this patch set that I did a while ago. It is still lacking some
documentation and testing in a more recent base version;
I only adjusted the common.opt part context for the patch to apply.
Author: Joern Rennecke
Date
rength reduction of the opaque pattern version for -O3,
though. Would people also like to see that expanded into RTL? Or
should I just drop in the opaque pattern for that? Or not at all,
because everyone uses Superscalar Out-Of-Order execution?
commit 1f4b7a8e6798acab1f79de38e85d9d080a76eb4a
Autho
On Fri, 4 Aug 2023 at 21:52, Jeff Law wrote:
> > diff --git a/gcc/config/riscv/riscv-v.cc b/gcc/config/riscv/riscv-v.cc
> > index b4884a30872..e61110fa3ad 100644
> > --- a/gcc/config/riscv/riscv-v.cc
> > +++ b/gcc/config/riscv/riscv-v.cc
> > @@ -49,6 +49,7 @@
> > #include "tm-constrs.h"
> >
ting with -march as a pathname or similar, but I suppose
you'd deserve whatever you get then. I don't see a bobby tables scenario
here.)
I also found one comment pasto.
I have attached the amended patch - not tested yet. I hope to get some opinions
today on the patch call regarding the t
> Making operand 0 read/write in define_insn_and_split prevents the web pass
> from creating a new pseudo
> for the clobber, avoiding the whole problem.
That is the right solution. If you clobber a match_dup of an input
operand, that makes it and input-and-output operand, so you should
mark it
I think it would make sense to leave the exact vector layout, like
vlen and lmul, to the caller.
Attached is an attempt to implement sin and cos vectorized so it
allows lmul values of m1 and m2, while using no more than a quarter of
the vector registers.
The function could live in libgcc and be
check_effective_target_riscv_v_ok to
check if that's ok, and then
add_options_for_riscv_v to add the appropriate -march option.
Examples how this can be used can be found
athttps://github.com/embecosm/rvv-gcc/tree/rvv-12/gcc/testsuite
2023-04-17 Joern Rennecke
gcc/testsuite/
* lib/target-supports.exp
-march=rv64imafdcv_zicsr_zifencei_zfh_zba_zbb_zbs_zve32f_zve32x_zve64d_zve64f_zve64x_zvl128b_zvl32b_zvl64b/-mabi=lp64d
riscv-sim/-march=rv64imafdcv_zicsr_zifencei_zfh_zve32f_zve32x_zve64d_zve64f_zve64x_zvl128b_zvl32b_zvl64b/-mabi=lp64d
2023-07-12 Ju-Zhe Zhong
Joern Re
Committed as obvious.
commit 6bab2772dbc42ce7a1b29b03ae84e6e434e23c4e
Author: Joern Rennecke
Date: Tue Jul 18 04:28:55 2023 +0100
Tighten regexps in gcc.target/riscv/_Float16-zhinx-1.c .
The original "mv" regexp would match
.ascii "\254\254\375\002e2N6\013\
I haven't worked with these targets in years and can't really do sensible
maintenance or reviews of patches for them.
I am currently working on optimizations for other ports like RISC-V.
ARC has still an active maintainer in Claudiu Zissulescu, so is basically
unaffected.
I am not aware of any
On Thu, 18 May 2023 at 16:37, Joern Rennecke wrote
in https://gcc.gnu.org/pipermail/gcc-patches/2023-May/618928.html :
>
> This breaks building libstdc++-v3 for
> -march=rv32imafdcv_zicsr_zifencei_zba_zbb_zbc_zbs_zve32f_zve32x_zve64d_zve64f_zve64x_zvl128b_zvl32b_zvl64b
> -mabi=ilp32f
On Wed, Jun 1, 2022 at 02:28:45 GMT 2022, zhongjuzhe
wrote:
> gcc/testsuite/ChangeLog:
>
>* gcc.target/riscv/rvv/intrinsic/vlex_2.c: New test.
These intrinsic test cases look like they have been machine generated. And if
they aren't, they probably should (have) be(en). I've been
> and there needs to be code to actually expand the builtin using optabs.
> And something needs to be done to make match.pd work on the output.
Never mind that bit, that was just due to a function argument type mismatch
on the last argument of the crc built-in functions.
On Wed, 16 Mar 2022 at 08:15, Richard Biener wrote:
> The canonical place to transform loops into builtins would be loop
> distribution.
> Another place would be final value replacement since you basically replace
> the reduction result with a call to the builtin, but I think
>
On 15/03/2022, Richard Biener wrote:
> Why's this a new pass? Every walk over all insns costs time. The pass
> lacks any comments as to what CFG / stmt structure is matched. From
> a quick look it seems like it first(?) statically matches a stmt sequence
> without considering intermediate
On 15/03/2022, Richard Biener wrote:
> Why's this a new pass? Every walk over all insns costs time.
If should typically scan considerably less than all the insns.
> The pass
> lacks any comments as to what CFG / stmt structure is matched.
I've put a file in:
config/riscv/tree-crc-doc.txt
This misses some documentation and testing, but it appears to work
well with 64 bit RISC-V.
-fext-dce is best used with aggressive unrolling and/or inlining. It deletes
zero/sign extensiions where the part of the register that the
zero/sign extension
pertains to is dead.
This is not about
On Tue, 15 Mar 2022 at 02:17, Oleg Endo wrote:
> > In my own CRC library I've got ~30 'commonly used' CRC types, based on
> the following generic definition:
> > This being a library makes it relatively easy to tune and customize for
> various systems.
...
> How would that work together with
Oops, that was meant to go to the list too.
On Tue, 15 Mar 2022 at 01:04, Andrew Pinski wrote:
>
> On Mon, Mar 14, 2022 at 5:33 PM Joern Rennecke
> wrote:
> >
> > Most microprocessors have efficient ways to perform CRC operations, be
> > that with lookup table
, we'll get more
contributions of suitable named patterns for various ports.
bootstrapped on x86_64-pc-linux-gnu .
2022-03-14 Jon Beniston
Joern Rennecke
* Makefile.in (OBJS): Add tree-crc.o .
* builtin-types.def (BT_FN_UINT16_UINT16_UINT8_CONST_SIZE): Define
didn't actually
return early (doing
things with an array of N elements where N might be zero... but it
isn't for the actual data).
Does someone have a benchmark / computing load where the early return
is beneficial? Or conversely, harmful?
2022-03-14 Joern Rennecke
* common.opt (fearly
I find that when compiling some files, lra goes into an infinite loop
reloading constant
addresses. This patch allows them to just be recognized as matching addresses
immediately, which also saves a bit of space for a few other files.
Bootstrapped and regression tested on x86_64-pc-linux-gnu.
On Mon, 17 May 2021 at 11:59, Richard Biener wrote:
> The plan for reload is to axe it similar to CC0 support. Sooner than later,
> but
> give it's still used exclusively by a lot of target means it might
> take some time.
> So for you it's always just -fretry-compilation -m[no-]lra? Given
On Mon, 17 May 2021 at 08:36, Richard Biener wrote:
>
> On Sun, May 16, 2021 at 8:53 PM Joern Rennecke
> wrote:
> >
> > For architectures with likely spilled register classes, neither
> > register allocator is guaranteed
> > to succeed when using optimizati
of the number
of alternatives of operand 0.
So I propose the attached patch now.
Bootstrapped on x86_64-pc-linux-gnu.
2021-05-17 Joern Rennecke
Make "wrong number of alternatives" message more specific, and
remove assumption on where the problem is.
diff --g
-linux-gnu.
FWIW, we also have patches for cpplib / lexer / parser char and string
handling to make 8 -> 16 bit char cross-compiling work, but they can't
be ported forward easily because the parser has changed since gcc9.
2021-04-16 Joern Rennecke
* c-family/c-commo
retry, which is
implemented in the compiler driver.
Bootstrapped on x86_64-pc-linux-gnu.
2021-05-16 Joern Rennecke
* common.opt: New option -fretry-compilation=.
* gcc.c (execute): Implement -fretry-compilation.
* doc/invoke.texi: Document -fretry-compilation.
diff --git
Bootstrapped regtested and on x86_64-pc-linux-gnu.
2021-02-22 Joern Rennecke
lra fix to reduce fatal spill failures.
* lra-constraints.c (split_reg): No longer static.
* lra-int.h (split_reg): Declare.
* lra-assigns.c (lra_split_hard_reg_for): Add strategy
for MATCH_SCRATCH in alter_predicate_for_insn.
This makes most sense together with the previous patch for MATCH_DUP support,
although the latter can also be used stand-alone, so have posted and
tested these
patches separately.
Bootstrapped on x86_64-pc-linux-gnu.
2020-12-12 Joern Rennecke
Fix
not only wrong, but can also
be impossible when the pattern should apply to multiple patterns with
different operand numbers.
The attached patch fixes this.
Bootstrapped on x86_64-pc-linux-gnu.
2020-12-12 Joern Rennecke
Fix match_dup bug of define_cond_exec.
* gensupport.c
patch fixes this.
Bootstrapped on x86_64-pc-linux-gnu.
2020-12-12 Joern Rennecke
Fix match_dup bug of define_cond_exec.
* gensupport.c (alter_predicate_for_insn): Handle MATCH_DUP.
diff --git a/gcc/gensupport.c b/gcc/gensupport.c
index e1ca06dbc1e..92275358078 100644
--- a/gcc
. By making genoutput tell you what the
argument counts are, this gets a little bit easier.
Bootstrapped on x86_64-pc-linux-gnu.
2021-01-13 Joern Rennecke
Make "wrong number of alternatives" message a bit more specific.
diff --git a/gcc/genoutput.c b/gcc/genoutput.c
index 8
Bootstrapped on x86_64-pc-linux-gnu.
2020-12-10 Joern Rennecke
Fix bug in the define_subst handling that made match_scratch unusable for
multi-alternative patterns.
diff --git a/gcc/gensupport.c b/gcc/gensupport.c
index e1ca06dbc1e..4022c661adb 100644
--- a/gcc/gensupport.c
+++ b/gcc
On Fri, 5 Apr 2019 at 11:07, Richard Sandiford
wrote:
> > 2019-04-04 Joern Rennecke
> >
> > * sched-deps.c (sched_macro_fuse_insns): Check return value of
> > targetm.fixed_condition_code_regs.
>
> OK, thanks.
Thanks for the review.
Is that OK
, if TARGET_FIXED_CONDITION_CODE_REGS
has the default value as defined in target.def (hook_bool_uintp_uintp_false).
The attached patch fixes this by checking the return value of
targetm.fixed_condition_code_regs. Bootstrapped & regtested on
x86_64-pc-linux-gnu .
2019-04-04 Joern Rennecke
* sched-de
On 2 February 2015 at 21:54, Paul Shortis pshor...@dataworx.com.au wrote:
I could have avoided the expander and used a single instruction pattern for
a)b)c) if if could have found a way to have alternative dependent clobbers
in an instruction pattern. I investigated attributes but couldn't see
On 23 January 2015 at 13:46, Andrew Stubbs a...@codesourcery.com wrote:
How does reload ensure that an SImode value (re)loaded into an FP register
has a valid stack index?
You could use CANNOT_CHANGE_MODE_CLASS, or request secondary reload.
For the latter, you can look at the memory/pseudo to
On 14 January 2015 at 18:03, vgol...@innovasic.de vgol...@innovasic.de wrote:
Hello out there,
I am looking of some support maintaining the m68k target toolchain (incl GDB)
for the fido1100 (basically a CPU32, the real changes are in GDB). Some
experience with the m68k target would be
On 26 November 2014 at 16:48, Mathias Roslund mathias.rosl...@amidog.se wrote:
Since then I've added more instructions and gotten to the point where most
stuff seems to be working. My current issue is that signed divide and all
shift operations insists on sign/zero extending the operands,
On 24 November 2014 at 10:58, Martin Jambor mjam...@suse.cz wrote:
On Sun, Nov 23, 2014 at 06:48:53PM -0500, Lawrence Velázquez wrote:
Hi,
I recently contributed some fixes against GCC trunk, gcc-4_9-branch, and
gcc-4_8-branch for which I need the requisite legal paperwork.
However, I'd
On 11 November 2014 16:22, Joey Ye joey.ye...@gmail.com wrote:
Markus,
-mmcu probably will not work for ARM architectured MCUs. Reason are
* Confusion. -mcpu is encouraged and already widely used for ARM
architectures. Introducing -mmcu will be very confusing.
It' just a matter of bundling
On 9 November 2014 23:13, Sandra Loosemore san...@codesourcery.com wrote:
Forgive me if this has been raised before -- I tried searching the archives
but couldn't think of good keywords that would weed out unrelated posts
I was checking the testing requirements for a C front end patch
.
By setting CPLUSPLUS_CPP_SPEC to %(cpp), we let the cc1plus
preprocessor look up the actual value of the preprocessor specs.
OK to apply?
2014-11-09 Joern Rennecke joern.renne...@embecosm.com
* /config/avr/avr.h (CPLUSPLUS_CPP_SPEC): Define.
diff --git a/gcc/config/avr/avr.h b/gcc/config/avr
I forgot the 'x' number base specifier in r216034.
Committed as obvious.
2014-11-09 Joern Rennecke joern.renne...@embecosm.com
* config/avr/predicates.md (low_io_address_operand): Fix typo.
Index: config/avr/predicates.md
On 31 October 2014 15:10, James Greenhalgh james.greenha...@arm.com wrote:
While I am there, arc defines a macro CAN_MOVE_BY_PIECES, which is
unused, so clean that up too.
That's not a clean-up. This pertains to PR 39350.
Which, incidentally, this hookization completely ignores, entrenching
On 4 November 2014 14:24, James Greenhalgh james.greenha...@arm.com wrote:
On Tue, Nov 04, 2014 at 12:07:56PM +, Joern Rennecke wrote:
On 31 October 2014 15:10, James Greenhalgh james.greenha...@arm.com wrote:
While I am there, arc defines a macro CAN_MOVE_BY_PIECES, which is
unused, so
On 3 November 2014 21:51, David Kang dk...@isi.edu wrote:
Thank you for the tips.
I tried the following condition for split.
reload_completed FP_REG_P (operands[0])
But, the registers are still changed.
How can I specify after register allocation in the split condition?
Are you sure
On 3 November 2014 14:33, Sivanupandi, Pitchumani
pitchumani.sivanupa...@atmel.com wrote:
Hi,
Unrecognized option error is issued by avr-gcc for devices with AVR_ISA_RMW.
This is because of an incorrect spec string device spec generation.
Below patch corrects the incorrect spec string in
On 24 October 2014 09:06, Thomas Preud'homme thomas.preudho...@arm.com wrote:
From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On
Behalf Of Joseph S. Myers
I'm not clear if you're proposing such a patch for review, but note:
Yep but not yet for inclusion as I'm waiting to see if
On 25 October 2014 10:54, Richard Sandiford rdsandif...@googlemail.com wrote:
This is part of a series to remove uses of for_each_rtx from the ports.
Tested by making sure there were no code changes for gcc.dg, gcc.c-torture
and g++.dg for arc-elf. OK to install?
OK.
On 25 October 2014 10:53, Richard Sandiford rdsandif...@googlemail.com wrote:
...
Tested by making sure there were no code changes for gcc.dg, gcc.c-torture
and g++.dg for arc-elf. OK to install?
Thanks,
Richard
gcc/
* config/arc/arc.c: Include rtl-iter.h.
On 25 October 2014 10:56, Richard Sandiford rdsandif...@googlemail.com wrote:
This is part of a series to remove uses of for_each_rtx from the ports.
Tested by making sure there were no code changes for gcc.dg, gcc.c-torture
and g++.dg for arc-elf. OK to install?
Thanks,
Richard
gcc/
On 25 October 2014 10:58, Richard Sandiford rdsandif...@googlemail.com wrote:
This is part of a series to remove uses of for_each_rtx from the ports.
Tested by making sure there were no code changes for gcc.dg, gcc.c-torture
and g++.dg for arc-elf. OK to install?
Thanks,
Richard
gcc/
In __do_global_dtors, I ended up changing the order of execution
in order to get back to the forwards/backwards order as found in
crtstuff.c
The patch I attached to target/63223 is actually an extract from this patch.
gcc:
2014-08-29 Joern Rennecke joern.renne...@embecosm.com
Vidya
Make can't 'build' check-c++ without rules for check-target-libgomp-c++ /
check-target-libitm-c++
This patch makes sure that there's at least a dummy rule available.
On 21 October 2014 16:35, Joern Rennecke joern.renne...@embecosm.com wrote:
Make can't 'build' check-c++ without rules for check-target-libgomp-c++ /
check-target-libitm-c++
This patch makes sure that there's at least a dummy rule available.
Sorry - forgot to attach the patch - here
gcc:
2014-09-23 Joern Rennecke joern.renne...@embecosm.com
* config/avr/avr.h (LIBSTDCXX): Don't define.
* config/avr/avr.c (TARGET_UNWIND_WORD_MODE): Define.
(avr_unwind_word_mode): New function.
* config/avr/avr.c (avr_asm_function_rodata_section
libstdc++-v3:
2013-06-14 Joern Rennecke joern.renne...@embecosm.com
* configure.ac [avr-*-*]: Don't use AC_LIBTOOL_DLOPEN.
* crossconfig.m4: Add avr-*-* settings.
* configure: Regenerate.
Index: configure.ac
libstdc++-v3:
2013-06-14 Joern Rennecke joern.renne...@embecosm.com
* include/bits/locale_facets_nonio.h (__tm_small_int): typedef/define.
(_M_extract_num): Templatize base type of __member argument.
(_M_extract_name): Change type of __member argument to __tm_small_int
The gdb version check ends up trying to invoke gdb on the target -
not so nice if your target is too small to accomodate gdb in the first place.
I've added a check similar to the one in gdb-test to punt on non-native
targets.
libstdc++-v3:
2013-09-17 Joern Rennecke joern.renne...@embecosm.com
We got a couple of tests that assume -frtti; this is the default for
most targets, but not for avr.
libstdc++-v3:
2013-09-24 Joern Rennecke joern.renne...@embecosm.com
* testsuite/18_support/type_info/hash_code.cc (dg-options): Add -frtti.
* testsuite/20_util/shared_ptr/cons
A couple of tests fail because an unqualified size_t is used.
2014-09-15 Joern Rennecke joern.renne...@embecosm.com
* libstdc++-v3/testsuite/util/io/prog_bar.cc: Qualify size_t.
* libstdc++-v3/testsuite/util/io/prog_bar.hpp: Likewise.
* libstdc++-v3/testsuite/util/io
On 21 October 2014 17:29, Jonathan Wakely jwak...@redhat.com wrote:
+typedef typeof (((tm*)0)-tm_sec) __tm_small_int;
I think this should probably use __typeof__ to work with
-Wpedantic-errors
Ok, makes sense, and it's a straightforward change.
+#else /* For 100% mangling compatibility,
On 13 October 2014 20:43, Jeff Law l...@redhat.com wrote:
...
I think you want smode in the mode_for_size call rather than mode, right
(both instances)?
No, nregs is the number of hard registers of regno in mode. Hence
we must use the
size of mode.
How to choose the mode class is not so
think of arguments for or against, but got no
concrete examples for either.
2014-10-11 Joern Rennecke joern.renne...@embecosm.com
Jeff Law l...@redhat.com
* caller-save.c (replace_reg_with_saved_mem): If saved_mode covers
multiple hard registers, use word_mode.
diff
Trying to build avr2 strftime of avr-libc ICEs as we are trying to
convert a PSImode address to HImode. There is no reason to
do this conversion in the first place - it is a case of failing to recognize
the proper address space.
The attached patch fixes this.
Bootstrapped on i686-pc-linux-gnu.
On 8 October 2014 12:02, Richard Biener richard.guent...@gmail.com wrote:
...
- if (POINTER_TYPE_P (TREE_TYPE (exp)))
- as = TYPE_ADDR_SPACE (TREE_TYPE (TREE_TYPE (exp)));
- else
- as = ADDR_SPACE_GENERIC;
-
+ as = TYPE_ADDR_SPACE (TREE_TYPE (TREE_TYPE
-patches/2014-10/msg00420.html ,
as avr-libc won't build otherwise.
2014-10-08 Joern Rennecke joern.renne...@embecosm.com
* config/avr/avr.opt (mmcu=): Change to have a string value.
(mn-flash=, mskip-bug, march=, mrmw): New options.
(HeaderInclude): New.
(mmcu
On 18 August 2014 11:35, Joey Ye joey.ye...@gmail.com wrote:
Joern, there is https://sourceware.org/ml/newlib/2014/msg00166.html,
which is already in newlib mainline. I think it solves the same issue
in a slight different approach.
Does it work for you?
No, this is completely besides the
On 7 October 2014 18:38, Jeff Law l...@redhat.com wrote:
On 10/06/14 20:57, Joern Rennecke wrote:
On 6 October 2014 19:58, Jeff Law l...@redhat.com wrote:
What makes word_mode special here? ie, why is special casing for
word_mode
the right thing to do?
The patch does not special-case
Investigating an ICE while trying to compile libgcc2.c:__udivmoddi4 for
a new avr variant with different register set/allocation order, I found
replace_reg_with_saved_mem falling over its own nonsense. The instruction:
(debug_insn 97 96 98 2 (var_location:SI __x2 (mult:SI (lshiftrt:SI
(reg/v:SI
On 6 October 2014 19:58, Jeff Law l...@redhat.com wrote:
What makes word_mode special here? ie, why is special casing for word_mode
the right thing to do?
The patch does not special-case word mode. The if condition tests if
smode would
cover multiple hard registers.
If that would be the case,
On 2 September 2014 16:28, Joseph S. Myers jos...@codesourcery.com wrote:
On Tue, 2 Sep 2014, Joey Ye wrote:
Apparently newlib is not following this specification very well, as
there are symbols like _abc_r defined every where in current newlib. I
am not implying the spec should not be
1 - 100 of 875 matches
Mail list logo
