Re: [PATCH] Fix DJGPP LTO with debug

Richard Biener writes: > DJ, did you ever run the testsuite with a configuration that has LTO > enabled? I don't see any djgpp results posted to gcc-testresults. > Quick googling doesn't yield anything useful with regarding on how to > do actual testing with a cross so I only built a

Stepping down, mostly...

iq2000 portNick Clifton lm32 port Sebastien Bourdeauducq -m32c port DJ Delorie m32r port Nick Clifton m68k port (?) Jeff Law m68k port Andreas Schwab m68k

Re: [PATCH] [MSP430] Fix device name symbol defined for MSP430i series of devices

That's fine too, I was thinking of checking mcu_name[i] against NUL. Any of those solutions would work :-)

Re: [PATCH] [MSP430] Fix device name symbol defined for MSP430i series of devices

Jozef Lawrynowicz writes: > - for (i = start_upper; i < strlen (mcu_name); i++) > + for (i = start_upper; i < strlen (mcu_name) - 2; i++) Might be faster to test mcu_name[i] instead of calling strlen repeatedly too, but this only runs once per invocation ;-)

Re: [PATCH] [MSP430] Fix device name symbol defined for MSP430i series of devices

> + snprintf (mcu_name, sizeof (mcu_name) - 1, "__%s__", target_mcu); > + start_upper = 0; Can optimize this to 2 :-) Otherwise OK.

Re: [PATCH] [MSP430] Fix device name symbol defined for MSP430i series of devices

Jozef Lawrynowicz writes: > Word from TI is that the lowercase i is an exception, the rule is to have all > uppercase letters. No further msp430i devices are planned so the rules for > generating device names in this patch shouldn't need any future changes. So a future-proof patch would

Re: [PATCH] [MSP430] Fix device name symbol defined for MSP430i series of devices

Jozef Lawrynowicz writes: > For the currently released msp430i* devices, only digits follow the i, so no > upper or lower case conversion is needed. Thinking of the future... do we expect any new devices with letters? Should we plan for them? Or better to wait, in case there are more

Re: [PATCH] [MSP430] Fix device name symbol defined for MSP430i series of devices

Jozef Lawrynowicz writes: > + if (strncmp (target_mcu, "msp430i", 7) == 0) > + snprintf (mcu_name, sizeof (mcu_name) - 1, "__MSP430i%s__", > + target_mcu + 7); > + else Do you need to TOUPPER the parts of target_mcu after char 7 ?

Re: [PATCH] [MSP430] Allow interrupt handers to be static and fix __interrupt__ attribute causing an ICE

Jozef Lawrynowicz writes: > If an argument is passed to the interrupt attribute, GCC will create a section > for the interrupt vector when outputting the assembly. This, combined with the > code to ensure the interrupt function doesn't get optimized out, ensures the > symbol for the interrupt

Re: [PATCH] [MSP430] Allow interrupt handers to be static and fix __interrupt__ attribute causing an ICE

The reason I required interrupt handlers to be non-static is because the linker builds the interrupt handler table using weak references. If the handler is static, it won't be added to the table, and never called. So you'd need a test to ensure that the handler was properly entered into the

Re: [PATCH 1/2] gcc_qsort: source code changes

Alexander Monakov writes: > I'm not sure. It has a weaker contract compared to qsort, and I believe > functions in libiberty are understood to provide stronger/better replacements. The original intent of libiberty was to provide a stronger *portability* contract, i.e. to

Re: ping [PATCH] Fix trunk failing to build for msp430-elf

The testsuite parts are OK with me, but the tree.c change needs separate approval...

Re: [PATCH] Use dlsym to check if libdl is needed for plugin

"H.J. Lu" writes: > config/ > > * plugins.m4 (AC_PLUGINS): Use dlsym to check if libdl is needed. This is OK.

Re: [PATCH] RL78 one_cmplhi2 improvement

"Sebastian Perta" writes: > Is this similar to what you had in mind? Yes. Did it affect code size in any of the larger tests? I was hoping that it wouldn't force too much into 8-bit registers and cause more moves to be needed elsewhere. (and even if it didn't, I

Re: [PATCH] RL78 one_cmplhi2 improvement

Const type promotion is the bane of embedded developers... One thing to try is to use (subreg:QI in a define_expand, so that there's a one_cmplhi2 pattern that expands to two QImode insns that operate on HImode input/outputs via SUBREGs. I don't have high hopes of gcc optimizing this properly

Re: {PATCH] RL78 movdf define expand

This is OK. In the future, please include the Changelog entry as a separate text, not part of the patch, as it will rarely apply cleanly. "Sebastian Perta" writes: > > * config/rl78/rl78.md (movdf): New define expand.

Re: [PATCH] RL78 new "vector" function attribute

"Sebastian Perta" writes: >>>Looks OK to me, but wait a day or two for a docs person to comment on... > 6 days no comments so far, can I check in now? Yup, go ahead. >>>if the new line is too long > There are many other lines which have the same length or are even

Re: [PING] [PATCH] [MSP430] PR79242: Implement Complex Partial Integers

The msp43-specific parts look OK to me, but obviously they're kinda useless without the core changes :-)

Re: [PATCH] RL78 new "vector" function attribute

Sebastian Perta writes: > I've updated the patch (extend.texi) as you suggested. > Please let me know if this is OK to check-in, thank you! Looks OK to me, but wait a day or two for a docs person to comment on... > -On RX targets, you may specify one or more vector

Re: [PATCH] RL78 new "vector" function attribute

If the RX and RL78 now share interrupt/vector semantics, can we combine the docs? I.e. instead of a new section for RL78, can we change the RX section to say something like "For RX and RL78..." ?

Re: [PATCH] RL78 addsi3 improvement

This is OK. I wonder if these types of optimizations should be added to the assembler too? At least, if relaxation is enabled...

Re: [PATCH] rl78 anddi3 improvement

Jeff Law writes: > So I think you're ultimately far better off determining why GCC does not > generate efficient code for 64bit logicals on the rl78 target. In thinking about this more, one possible reason is that rl78 has an 8-bit WORD_MODE. Which means DImode operations are

Re: FW: [PATCH] rl78 umaxdi3 improvement

"Sebastian Perta" writes: > * config/rl78/rl78.md: New define_expand "umaxdi3". > * config/rl78/rl78.md: New define_expand "smaxdi3". > * config/rl78/rl78.md: New define_expand "smindi3". > * config/rl78/rl78.md: New define_expand "umindi3". >

Re: [PATCH] RL78 UNUSED note setting bug fix in rl78_note_reg_set

Sebastian Perta writes: > * config/rl78/rl78.c (rl78_note_reg_set): fixed dead reg check > for non-QImode registers This is OK. Thanks! Note: in the future; ChangeLog entries should be provided separate from the patch; they rarely apply cleanly anyway. > Index:

Re: Compilation warning in simple-object-xcoff.c

Eli Zaretskii writes: > DJ, would the following semi-kludgey workaround be acceptable? It would be no worse than what we have now, if the only purpose is to avoid a warning. Ideally, we would check to see if we're discarding non-zero values from that offset, and not call the

Re: Compilation warning in simple-object-xcoff.c

Well, it should all work fine as long as the xcoff64 file is less than 4 Gb. And it's not the host's bit size that counts; there are usually ways to get 64-bit file operations on 32-bit hosts.

Re: Compilation warning in simple-object-xcoff.c

I think that warning is valid - the host has a 32-bit limit to file sizes (off_t) but it's trying to read a 64-bit offset (in that clause). It's warning you that you won't be able to handle files as large as the field implies. Can we hide the warning? Probably. Should we? Debatable, as long

Re: [PATCH] RL78 UNUSED note setting bug fix in rl78_note_reg_set

"Sebastian Perta" writes: > Please let me know if this is OK. Thank you! Do you have checkin privs yet? This is ok aside from.. > + /* 'dead' keeps track of the QImode registers if r is of different size > + we need to check the other subparts as well */

Re: [PATCH] RL78 movdi improvement

I saw one regression with this patch: PASS-FAIL: gcc.dg/torture/vshuf-v8qi.c -O2 execution test Could you confirm this? Note: I'm testing with your other (pre-2018 at least) patches applied at the same time (smax etc, anddi, bswaphi) so it might be an interaction, but the code looks like a

Re: [PATCH] rl78 anddi3 improvement

Right, when doing 64-bit operations on an 8-bit mcu with limited registers, a hand-written assembler routine that you call as needed will beat anything gcc spits out - for size-per-call. And I had a lot of trouble getting gcc to deal with the rl78's limited register set and addressing modes -

Re: [RFTesting] New POINTER_DIFF_EXPR

Richard Biener writes: > The question is what ptrdiff_t is for a specific address space. Or > rather if that type may be dependent on the address space or if we can > always use that of the default address space. Some targets have a "far" address space that's bigger

Re: [PATCH] rl78 subdi3 improvement

Committed. Thanks! Note: your diff program isn't producing valid diffs... * it's dropping leading tabs * it's not putting a space after file names in the headers I have to manually fix these to apply the patch; if you could fix it on your end that would be appreciated :-)

Re: [PATCH] PR target/82624 msp430-elf target must allow for NULL pointer dereferences

Thanks for your patch; I applied it with some minor changes. Please note that you don't need to submit patches to generated files (*.1 and *.info), that patches are customarily made against the development tree not a released tarball (which is probably why you thought you had to patch the

Re: [PATCH] rl78 adddi3 improvement

Sebastian Perta writes: > Please let me know if this is OK, Thank you! Sorry for the delay, it's OK and I committed it for you with a few minor changes to make it work with today's tree. Thanks!

Re: [PATCH] [MSP430] [PR80993] Prevent lto removing interrupt handlers

Richard Biener writes: > Humm... don't you have to register interrupt handlers somehow? MSP430 uses an "if they're present, they're registered" approach, so it's driven by the user tagging functions as interrupts - the linker notices that they're present and links

Re: [PATCH] [MSP430] Read mcu data from file instead of hardcoded data

Back when we first designed this, I asked about including devices.csv in the gcc sources, and... no. It's not GPL. So please make sure to thoroughly test the "no devices.csv found" case. It's fine to use it to override the internal data, but not fine to rely on it. > *

Re: [PATCH,AIX] Enable libiberty to read AIX XCOFF

"REIX, Tony" writes: > It appears that XNEWVEC() calls xmalloc which prints a message and > calls xexit if malloc fails. Objection removed then ;-) > So, yes, we check if (strtab == NULL) though there is no way that > XDELETEVEC(NULL) breaks something. However, it is a

Re: [PATCH,AIX] Enable libiberty to read AIX XCOFF

David Edelsohn writes: > This patch generally looks good to me -- it clearly is an incremental > improvement. One of the libiberty maintainers, such as Ian, needs to > approve the patch. As AIX maintainer, I think you have the authority to approve patches like this, which

Re: MinGW compilation warnings in libiberty's xstrndup.c

Eli Zaretskii writes: > Seems to work fine, thanks. Checked into gcc trunk then :-)

Re: MinGW compilation warnings in libiberty's xstrndup.c

Please try this patch: Index: config.in === --- config.in (revision 248482) +++ config.in (working copy) @@ -76,12 +76,16 @@ #undef HAVE_DECL_SBRK /* Define to 1 if you have the declaration of `snprintf', and to 0 if you

Re: MinGW compilation warnings in libiberty's waitpid.c

Joel Brobecker writes: > Normally, I'd expect someone pushing to GCC's libibert to also > update our repo accordingly. Note that I used to auto-sync libiberty from gcc to binutils/gdb, but when binutils/gdb switched to git, that script broke, and as I don't like using

Re: MinGW compilation warnings in libiberty's waitpid.c

Thanks. Committed!

Re: MinGW compilation warnings in libiberty's waitpid.c

Eli Zaretskii writes: >> What about mingw64? > > It will be covered as well, because it defines __MINGW32__, Ah, OK. > Is there anything else I need to do about this part to get it solved > in the upstream repository? A ChangeLog entry would be nice, so I don't have to write one

Re: MinGW compilation warnings in libiberty's waitpid.c

Eli Zaretskii writes: > Instead of making waitpid an always-failing stub on MinGW, wouldn't it > be better to make it work on MinGW? Like this: That's up to you, if it's target-specific. What about mingw64? > --- libiberty/waitpid.c~0 2016-08-01 18:50:21.0 +0300 >

Re: MinGW compilation warnings in libiberty's waitpid.c

Eli Zaretskii writes: > Hmm... no, this doesn't solve the problem. The expansion of AC_LIBOBJ > for waitpid is gone from the configure script, but the value of > LIBOBJS in libiberty/Makefile still includes waitpid.o. What else is > related to this? After re-reading the sources

Re: MinGW compilation warnings in libiberty's include/environ.h

Eli Zaretskii writes: > My problem is, I don't have a GCC repository, so doing the above means In this case, a gdb repo would have sufficed. > IOW, not everyone who reports a problem can necessarily provide a > patch. The fact that you know too much about my abilities in other >

Re: MinGW compilation warnings in libiberty's waitpid.c

Please try this patch, since my mingw environment is old: Index: libiberty/ChangeLog === --- libiberty/ChangeLog (revision 248307) +++ libiberty/ChangeLog (working copy) @@ -1,3 +1,7 @@ +2017-05-19 Eli Zaretskii + +

Re: MinGW compilation warnings in libiberty's include/environ.h

Pedro Alves writes: > That sounds to me like the root issue that should be fixed, > so that these fallback definitions don't come into into play at all. > I.e., why isn't HAVE_ENVIRON_DECL defined on mingw when > setenv.o is built? Sounds like a decl check is missing > in

Re: MinGW compilation warnings in libiberty's include/environ.h

Fix committed. As Pedro noted, the correct way to request a change is to make the change in your local checked out repo, and run "svn diff" (or "git diff"). That makes sure that the fix is what you intended, and that you don't have other unexpected changes (especially in regenerated files, like

Re: MinGW compilation warnings in libiberty's xstrndup.c

Pedro Alves writes: > Ah, yeah. AFAICS, all the declaration checks in libiberty.h are > HAVE_DECL checks. This suggests to me that this declaration guard > should be HAVE_DECL too [1]. Except the ones in the $funcs list, which includes strnlen. I think in the old days,

Re: MinGW compilation warnings in libiberty's xstrndup.c

Right, I meant, libiberty's configure, gcc's configure, binutils' configure, and gdb's configure, all need to agree on whether strnlen is a HAVE or a HAVE_DECL type symbol. If they don't, the header can't provide "one" working solution.

Re: MinGW compilation warnings in libiberty's xstrndup.c

Eli Zaretskii writes: > It should use HAVE_STRNLEN instead, because that's the only > strnlen-related macro defined in config.g when strnlen is probed by > the configure script. Ah, but gcc's configure defines HAVE_DECL_STRNLEN. Header guards need to be coordinated across all the

Re: transaction_safe exceptions prevent libstdc++ building for some targets

Joe Seymour writes: >> the msp430 -mlarge multilib failing to build with... >>> configure: error: Unknown underlying type for size_t >>> make[1]: *** [configure-target-libstdc++-v3] Error 1 > > This is still reproducible. FYI the underlying type is uint20_t I think I've

Re: [PATCH 2/2] [msp430] Remove mpy.o from libgcc

Committed. Thanks!

Re: [PATCH 1/2] [msp430] Remove source files from libmul archives

Committed. Thanks!

Re: [PATCH] [msp430] Sync msp430_mcu_data with devices.csv

Committed for you, thanks!

[patch] libiberty/78584

While the root solution for the bug is "don't do that", we should at least try to detect the obviously wrong case more gracefully. Committed. * argv.c (expandargv): Check for directories passed as @-files. Index: argv.c ===

Re: [PATCH] Implement new hook for max_align_t_align

Jason Merrill writes: > If PA malloc doesn't actually provide 16-byte alignment, this change > seems problematic; it will mean any type that wants 16-byte alignment > will silently get 8-byte alignment instead. Should such cases be calling memalign (or posix_memalign) instead

Re: Change license of filenames.h to LGPL

Florian Weimer writes: > Sorry, I don't understand. Surely anything released under the LGPL by > the FSF can be upgraded to the current GPLv3? First upgrade to the > latest LGPL, then switch over to the GPLv3? > > (I assume that the FSF releases their works under the “any

Re: Change license of filenames.h to LGPL

Ozkan Sezer writes: > I am not using filename_cmp.c, nor do I include hashtab.h. The version > I took was an old one with macros only and I added some more macros and > inlines to it. (I replied to these, but I forgot including the CC list, > here:

Re: Change license of filenames.h to LGPL

Eli Zaretskii writes: >> But then the implementation would need relicensing as well, wouldn't >> it? > > Which implementation? of Ozkan's library? libiberty's filename_cmp.c is GPL and implements two of the functions in filenames.h; if those are why he's using it, then it's still

Re: Change license of filenames.h to LGPL

Eli Zaretskii writes: > Because Ozkan wants to use it in an otherwise LGPL package. Ok, but that doesn't say why it's different. That reason could apply to any header in there. Do we need to convert all headers there to LGPL? Is this "otherwise LGPL package" in one of our repos,

Re: Change license of filenames.h to LGPL

Most of the files in include/ are GPL, not LGPL. Why is this one different?

Re: [PATCH][Libiberty] Support empty arguments in pex-win32

This is OK. Thanks!

Re: [PATCH][msp430] Don't output __interrupt_vector sections for weak functions

Approved and committed. Thanks! Sorry for the delay, I was away for the holiday weekend and it slipped through the cracks when I returned.

Re: [Bug target/77570] New: [msp430-elf] Wrong assembly in delay_cycles_32x insn declaration

Patch applied as per bug report... 2016-09-12 Orlando Arias PR target/77570 * config/msp430/msp430.md (delay_cycles_32x): Fix pushm/popm. Index: config/msp430/msp430.md === ---

Re: [PATCH][msp430] Don't output __interrupt_vector sections for weak functions

Which results in a more user-obvious case, ignoring the interrupt attribute or ignoring the weak attribute? I would think that we never want to compile and link successfully if we can't do what the user wants, and omitting an interrupt handler is... bad. I think this should either be a hard

Re: Ping^2: [PATCH build/doc] Replacing libiberty with gnulib

ayush goel writes: > This patch https://gcc.gnu.org/ml/gcc-patches/2016-07/msg01302.html > is still pending review. The build portions are OK, assuming a global maintainer has approved of adding gnulib in general.

Re: [PATCH 1/4][Ada,DJGPP] Ada support for DJGPP

> Frankly at this stage, I do not think it makes sense to maintain an > Ada port for DJGPP and in particular maintain all these extra > special cases and #ifdefs. I don't think this is a reasonable attitude to take with people who are willing to do the work to do it. Frankly, I'd like to take

[target/71338]: enable mulu for RL78/G10

Reverts https://gcc.gnu.org/ml/gcc-patches/2014-08/msg01538.html - G10 supports MULU but not other multiplication methods. Committed. PR target/71338 * config/rl78/rl78-expand.c (umulqihi3): Enable for G10. * config/rl78/rl78-virtual.c (umulhi3_shift_virt): Likewise.

Re: [PATCH] rl78.c: fix warning

David Malcolm writes: > gcc/ChangeLog: > * config/rl78/rl78.c (rl78_expand_prologue): Convert local > from int to unsigned. Ok. I'm going to note that the corresponding loop in the epilogue also uses signed, but in that case, it must.

Re: libiberty: Don't needlessly clear xmemdup allocated memory

Ok then. Thanks!

Re: libiberty: Don't needlessly clear xmemdup allocated memory

Alan Modra writes: > * xmemdup.c (xmemdup): Use xmalloc rather than xcalloc. In glibc at least, calloc can be faster than memset if the kernel is pre-zero-ing pages. Thus, in those cases, your change makes the code slower by adding an unneeded memset. Have you

Re: [PATCH: RL78] Optimize libgcc routines using clrw and clrb

Kaushik Phatak writes: > 2016-04-06 Kaushik Phatak > > * config/rl78/bit-count.S: Use clrw/clrb where possible. > * config/rl78/cmpsi2.S: Likewise. > * config/rl78/divmodhi.S Likewise. > * config/rl78/divmodsi.S

Re: [PATCH] Fix compiling large files

> At this point we usually have a PR to go with all stage4 > changes. But a meaningful PR is difficult to create, since > the attachment would be too large. Perhaps a generator could > be created, but since it wouldn't go in the testsuite it seems > like a waste of time. > > Thoughts? CPP

Re: RFA: MEP: Add newlib-stdint.h to tm_file.

> Looks good to me. Obviously you'll need appropriate ChangeLogs. OK > with the ChangeLogs added. Done.

Re: RFA: MEP: Add newlib-stdint.h to tm_file.

> Write a patch to deprecate it in config.gcc (search for openbsd2 to help > you find the right spot) and an update to the gcc6 webpage. How's this? Index: htdocs/gcc-6/changes.html === RCS file:

Re: RFA: MEP: Add newlib-stdint.h to tm_file.

> Can we make that official? 64402, 49401 & 24998 go away when MEP is > deprecated. We can, what's the next step? I announced intent in Dec, nobody commented or stepped up to take it.

Re: RFA: MEP: Add newlib-stdint.h to tm_file.

Note, though, that I'm in the process of deprecating mep...

Re: RFA: MEP: Add newlib-stdint.h to tm_file.

Ok.

msp430: fix function type declarations

Minor bug, fixed, committed. * config/msp430/msp430.c (msp430_start_function): Add function type. 2016-02-04 Uros Bizjak Index: config/msp430/msp430.c === --- config/msp430/msp430.c (revision

Re: [PING][PATCH 5/6] [DJGPP] gcc/config/i386: update DJGPP configuration related files

> I posted last version of patch where I took review comments into account > month ago: > > https://gcc.gnu.org/ml/gcc-patches/2015-12/msg01328.html I'm OK with this version.

Re: [doc, committed] document RL78 saddr attribute

> I've checked in this patch to add some minimal documentation for the > RL78 "saddr" variable attribute. That's pretty much all there is to say about the saddr attribute, too.

Re: [PATCH 6/6] [DJGPP] configure.ac: enable LTO

> You can list me as your sponsor. I've been wanting him to be a djgpp target/host maintainer for years anyway, so +1 from me :-)

Re: Free up bits in DECLs and TYPEs

I'm OK with the msp430 part :-)

Re: [PATCH 1/6] [DJGPP] libstdc++-v3/config/os/djgpp/error_constants.h: Update according to errno codes available for DJGPP

> I can't really judge this one. Either DJ or Jon would need to some in > on this. Looks OK to me, although in the default configuration (plain DJGPP) the #ifdefs will always be false (omitted), which is harmless.

[rx] avoid long calls

Immediate mode jumps have limits; this new option tells gcc to avoid those instructions (by using indirect mode ones) in those rare cases where the user has a program that big. Committed. * config/rx/rx.opt (-mjsr): Add. * config/rx/predicates.md (rx_call_operand): Avoid

[rl78] fix far addressing etc

Various fixes for far memory addressing (and large programs in general). Committed. * config/rl78/constraints.md (Wfr): Change to be a non-memory constraint. * config/rl78/rl78-protos.h (rl78_one_far_p): Declare. * config/rl78/rl78.c (rl78_one_far_p): Define.

msp430: fix alignment in multiply

Minor fix, committed. 2015-11-19 DJ Delorie <d...@redhat.com> * config/msp430/lib2hw_mul.S: Fix alignment. Index: libgcc/config/msp430/lib2hw_mul.S === --- libgcc/config/msp430/lib2hw_mul.S (revision 230632) +++

Re: [PATCH] ctype functions and signedness

> --- libiberty/pex-win32.c > +++ /tmp/cocci-output-25924-3a75ca-pex-win32.c > @@ -547,8 +547,8 @@ env_compare (const void *a_ptr, const vo > >do > { > - c1 = (unsigned char) tolower (*a++); > - c2 = (unsigned char) tolower (*b++); > + c1 = (unsigned char) tolower

Re: [RFA] Do not use libiberty's getpagesize on Android

> libiberty/ChangeLog: > > * configure.ac: Set AC_CV_FUNC_GETPAGESIZE to "yes" on > Android hosts. > * configure: Regenerate. > > OK to apply? Ok.

Re: [PATCH] replace BITS_PER_UNIT with __CHAR_BIT__ in target libs

> $subject as far as I am aware these are the same on all supported targets. The documentation for __CHAR_BIT__ says not to use it... @item __CHAR_BIT__ Defined to the number of bits used in the representation of the @code{char} data type. It exists to make the standard header given

Re: [PATCH: RL78] libgcc fixes for divmodsi, divmodhi and divmodqi

> This is regression tested for RL78 -msim. Please let me know if it is > OK to commit. I've committed this patch for you. Thanks! > Best Regards, > Kaushik > > Changelog: > 2015-08-21 Kaushik Phatak > > * config/rl78/divmodqi.S: Return 0x00 by default for div by

Re: [PATCH : RL78] Disable interrupts during hardware multiplication routines

I have worked out an updated patch, which would save the MDUC specific registers in the interrupt routine when the option '-msave-mduc-in-interrupts' is passed. This gets active only for the G13 targets. Perhaps we should have both a -msave... and -mno-save... (gcc provides these by

Re: rx: remove some asserts

Hi DJ, There is no need to assert these just to say not supported and gcc may rarely generate addresses from valid code which trigger these asserts. Ok? OK - please apply. Thanks, committed.

Re: [PATCH] toplevel: fixes for in-tree libiconv

I have applied and committed these patches, both in gcc and binutils-gdb.

Re: RFA: RL78: Fix multiply costs when optimizing for size

OK to apply ? Ok. Thanks! gcc/ChangeLog 2015-08-05 Nick Clifton ni...@redhat.com * config/rl78/rl78.c (rl78_rtx_costs): Treat MULT insns as cheap if optimizing for size. Index: gcc/config/rl78/rl78.c ===

Re: RFA: RL78: Remove far operand optimization in rl78_force_nonfar_3

This is OK, but note that it prevents some operations like: __far int i; foo() { i ++; } from being implemented with a minimum set of opcodes. This might be particularly troublesome for volatile far things.

Re: RFA: RL78: Add an optimization to the addsi3 pattern

Ok, but please don't put non-public issue numbers in the comments.

Re: libstdc++: more __intN tweaks

* include/bits/functional_hash.h: Add specializations for __intN types. * include/ext/pb_ds/detail/thin_heap_/thin_heap_.hpp (__gnu_pbds): Guard against values that might exceed size_t's precision. Yes, OK - thanks. Committed. Thanks!

  1   2   3   4   5   6   >