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.

Proposal to deprecate: mep (Toshiba Media Processor)

Given a combination of "I have new responsibilities" and "nothing has happened with mep for a long time" I would like to step down as mep maintainer. If someone would like to pick up maintainership of this target, please contact me and/or the steering committee. Otherwise, I propose this target

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: Is anyone working on a Z80 port?

> I spec'd one out a long time ago for Cygnus/Red Hat, but we never > pursued the port. The register model on the z80 will be problematical, > though some of the lessons from the rl78 port would probably be useful. The RL78 is very much a modern decendent of the Z80 architecture so might

Re: reload question about unmet constraints

> So in general, it's really not safe to mark a constraint that accepts > only far memory as "memory constraint" with current reload. > > Note that *not* marking the constraint as memory constraint actually > does not prevent reload from fixing up illegitimate addresses, so you > shouldn't

Re: Repository for the conversion machinery

Richard Biener writes: >> Using d...@gcc.gnu.org would imply that is my email address, but email >> sent there would vanish. > > Would it? You're supposed to have a valid forwarding address on that. Frank tested it and it does seem to forward to me, so I guess so.

Re: reload question about unmet constraints

> And in fact, you should be able to decide at *expand* time which > of the two you need for the given set of operands. I already check for multiple fars at expand, and force all but one of them to registers. Somewhere before reload they get put back in. >"rl78_virt_insns_ok () &&

Re: Repository for the conversion machinery

"Frank Ch. Eigler" writes: > That makes sense, but how many people are in cagney's shoes I am one of those people - I have two email addresses listed in MAINTAINERS, with two sets of copyright papers filed with the FSF (a personal assignment and a work one). I use the

Re: reload question about unmet constraints

> You would need some way to indicate that while Y does accept a mem, > this particular mem can't be reloaded to match. We don't have a way > to do that. As a test, I added this API. It seems to work. I suppose there could be a better API where we determine if a constrain matches various

Re: reload question about unmet constraints

> I see. Is it correct then to say that reload will never be able to > change a near mem into a far mem or vice versa? If that is true, there > doesn't appear to be any real benefit to having both near and far mem > operations as *alternatives* to the same insn pattern. The RL78 has a segment

reload question about unmet constraints

Given this test case for rl78-elf: extern __far int a, b; void ffr (int x) { a = b + x; } I'm trying to use this patch: Index: gcc/config/rl78/rl78-virt.md === --- gcc/config/rl78/rl78-virt.md (revision 227360) +++

Re: reload question about unmet constraints

> It did match the first alternative (alternative 0), but it matched the > constraints Y/Y/m. It shouldn't match Y as those are for near addresses (unless it's only matching MEM==MEM), and the ones in the insn are far, but ... > Reload doesn't have any concept of two different kinds of memory >

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: Repository for the conversion machinery

Hmmm... I use two email addresses for commits, depending on which target they're for, i.e.: $ grep DJ MAINTAINERS m32c port DJ Delorie d...@redhat.com DJGPP DJ Delorie d...@delorie.com Most of the DJGPP stuff was long ago but I wonder

Re: Offer of help with move to git

In the mean time, I'm enclosing a contributor map that will need to be filled in whoever does the conversion. The right sides should become full names and preferred email addresses. This information should be gleanable from the Changelog commits... do you have a script to scan those?

Re: Question about instruction merge pass when optimizing for size

I've seen this on other targets too, sometimes so bad I write a quick target-specific stupid move optimizer pass to clean it up. A generic pass would be much harder, but very useful.

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!

libstdc++: more __intN tweaks

Another place where a list of all types are explicitly listed, and the __intN types need to be included, and elsewhere protection against errors [-Wnarrowing] on targets that have small size_t. Ok? * include/bits/functional_hash.h: Add specializations for __intN types.

[msp430] minor optimizations and tweaks

As indicated. Committed. * config/msp430/t-msp430 (MULTILIB_DIRNAMES): Remove trailing slashes. * config/msp430/msp430.md (ashlhi3): Optimize shifts of subregs. (ashrhi3): Likewise. (lshrhi3): Likewise. (movhi): Take advantage of zero-extend to

rx: remove some asserts

Nick, 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? Index: gcc/config/rx/rx.c === --- gcc/config/rx/rx.c (revision 225533) +++

[rl78] extend set1/clr1 operands

Minor tweak to allow more addressing modes. Committed. * config/rl78/rl78-real.md (andqi3_real): Expand operands for clr1. (iorqi3_real): Likewise for set1. Index: config/rl78/rl78-real.md === ---

Re: [PATCH] S390: Support -mtune=native and -march=native.

Sorry about that. Does the attached Patch fix the problem? Yup. Thanks!

Re: [PATCH] S390: Support -mtune=native and -march=native.

Version 2 of the patch to enable the configure options --with-arch=native and --with-tune=native. This patch broke cross-compiling with --target=s390-* s390_host_detect_local_cpu is only defined if the --host is s390-* but EXTRA_SPEC_FUNCTIONS refers to it when --target is s390-*

s390: larl for Simode on 64-bit

Is there any reason that LARL can't be used to load a 32-bit symbolic value, in 64-bit mode? On TPF (64-bit) the app has the option of being loaded in the first 4Gb so that all symbols are also valid 32-bit addresses, for backward compatibility. (and if not, the linker would complain) Index:

Re: s390: larl for Simode on 64-bit

In the TPF case, the software has to explicitly mark such pointers as SImode (such things happen only when structures that contain addresses can't change size, for backwards compatibility reasons[1]): int * __attribute__((mode(SImode))) ptr; ptr = some_var; so I wouldn't consider this the

Re: s390: larl for Simode on 64-bit

So in effect, we have two pointer sizes, 64 being the default, but we can also get a 32 bit pointer via the syntax above? Wow, I'm surprised that works. Yup, been that way for many years. And the only time we'd be able to use larl is a dereference of a pointer declared with the syntax

Re: rl78 vs cse vs memory_address_addr_space

Given a test case like this: typedef struct { unsigned char no0 :1; unsigned char no1 :1; unsigned char no2 :1; unsigned char no3 :1; unsigned char no4 :1; unsigned char no5 :1; unsigned char no6 :1; unsigned char no7 :1; } __BITS8; #define

Re: rl78 vs cse vs memory_address_addr_space

Did you try just a define_split instead? Ugly, but it should work I think. It doesn't seem to be able to match a define_split :-(

Re: [s390] Revert TPF C++ library changes

Ah, then approved. Thanks, committed.

Re: update gthr-tpf.h

Ping? https://gcc.gnu.org/ml/gcc-patches/2015-06/msg00149.html This patch updates gthr-tpf.h to the current gthr.h API and TPF API. Ok? * gthr-tpf.h (__GTHREADS_CXX0X): Define. (__gthread_t): Define. (__gthread_cond_t): Define. (__gthread_time_t): Define.

rl78 vs cse vs memory_address_addr_space

In this bit of code in explow.c: /* By passing constant addresses through registers we get a chance to cse them. */ if (! cse_not_expected CONSTANT_P (x) CONSTANT_ADDRESS_P (x)) x = force_reg (address_mode, x); On the rl78 it results in code that's a bit too complex for later

Re: [s390] Revert TPF C++ library changes

But don't we need to support the older system (with 2 libstdc++s) and the newer system (just one libstdc++)? Which implies these changes need to be conditional, right? The CPP2 configuration was never shipped to TPF customers, so there's no need to retain both ways.

Re: pr66345.c size_t assumption bug

OK. Thanks, committed.

dwarf DW_AT_decl_name: system headers vs source files?

Consider: # 1 dj.c # 1 dj.h 1 3 int dj(int x); # 2 dj.c 2 int dj(int x) { } If you compile with -g and look at the dwarf output, you see: 12d: Abbrev Number: 2 (DW_TAG_subprogram) 2e DW_AT_external: 1 2e DW_AT_name: dj 31 DW_AT_decl_file : 2 32

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

Thanks. I don't have write access, could a toplevel maintainer please commit? Which repos do you not have access to? Also, did you address Jeff's comment? How was this patch tested? I don't see anything glaringly wrong, but stranger things have happened. I think just a bootstrap check

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

This is the first in a series of patches to make a build with an in-tree GNU libiconv work as designed. This patch fixes dependencies for parallel make, and avoids failures with make targets not supported by GNU libiconv. This is OK. Thanks!

Re: [lto] intN follow-up patch

Thanks! Committed.

[lto] intN follow-up patch

This was missed in the big intN patch set I did last year; it only shows up if you have a target with an N-bit type that isn't also used for a pointer type but is used for unwinding (which is a change I also have pending, hence I noticed ;). Tested on x86-64 and msp430 (with the pending patch)

Re: RFA: RL78: With -mes0 put read only data in the .frodata section

Ok. Thanks!

pr66345.c size_t assumption bug

The testcase for pr 66345 assumes size_t is unsigned long instead of using the real type, which causes failures on some 16-bit targets. Ok? Also, I note that some tests check for __SIZE_TYPE__ as I do below, and others use it unconditionally as a replacement for size_t. Is there a convention?

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

Have you compared the latency of the multiply instructions to the overhead of saving those registers in the interrupt handler? What about the case where performance is priority, and the developer knows that the interrupt handlers don't use the multiply registers? Also, your code doesn't

[s390] Revert TPF C++ library changes

IBM made changes to no longer require 2 versions of libstdc++, so this patch changes things back to the previous (compatible) way. Also, TPF debuggers don't support discriminators, despite what GAS supports, so disable them. Ok? * config/s390/tpf.h (LIBSTDCXX): Change to CPP1.

[msp430] support sym+int and sym-sym

Because sizeof(void*) is 4 but POINTER_SIZE is 3, we have to handle some things manually. This is yet another one. Committed. * config/msp430/msp430.c (msp430_asm_integer): Support addition and subtraction too. Index: config/msp430/msp430.c

pr64252.c: fix sizeof(int) assumption

On targets with 2 byte int the vectors are 16 values long, which breaks the index count in __builtin_shuffle() using more than one input vector. Ok? * gcc.dg/pr64252.c: Fix assumption about sizeof(int). 2015-06-05 Thomas Koenig tkoe...@gcc.gnu.org Index: gcc.dg/pr64252.c

Re: pr64252.c: fix sizeof(int) assumption

Sorry, I meant unsigned int.

[msp430] special case sym-SI moves

Symbols are normally PSImode, and the MSP430 has PSImode registers and PSImode moves to reg/mem. But sometimes gcc uses an SImode move instead, if the result will later be used in SImode (as in getP() in gcc/testsuite/gcc.dg/torture/pr65077.c). Committed. * config/msp430/msp430.md

update gthr-tpf.h

This patch updates gthr-tpf.h to the current gthr.h API and TPF API. Ok? * gthr-tpf.h (__GTHREADS_CXX0X): Define. (__gthread_t): Define. (__gthread_cond_t): Define. (__gthread_time_t): Define. (__GTHREAD_HAS_COND): Define. (__GTHREAD_COND_INIT):

Re: RFA: RL78:

Ok. Thanks!

Re: [PATCH 14/16] gcc: Add CTIMER_PUSH/POP to gcc's copy of libiberty

This is the same patch as 09/16. There is only one libiberty master, controlled by gcc, it is not neccessary to submit separate patches for each copy of it. The convention is: Any libiberty patch approved by gcc maintainers is auto-approved for the other repos.

Re: [PATCH 08/16] libiberty.h: Provide a CLEAR_VAR macro

+/* Fill an lvalue with zero bits. */ +#define CLEAR_VAR(S) \ + do { memset ((S), 0, sizeof (S)); } while (0) Hmmm... I don't see the point in this. The macro is almost as long as a bare memset() would be, and replaces a well-known function with something unknown outside this project. It

Re: [PATCH 09/16] libiberty.h: Provide CTIMER_PUSH/POP

libiberty is not an API to gcc, it is a portability library. If GCC is exporting a timer, GCC's headers should have the interface in it.

Re: [PATCH 08/16] libiberty.h: Provide a CLEAR_VAR macro

FWIW I'm not in love with the name of the macro, but I find it useful. In the initial version of patches 10 and 12 (state purging within gas and ld subdirs) I didn't have this macro, and had about 30 memset invocations. Another option is to save the state as it was initialized, and restore

Re: [expmed] Avoid clobbering a yet-to-be-used base/index register.

* expmed.c (extract_bit_field_1): Avoid clobbering a yet-to-be-used base/index register. OK. jeff Thanks! committed.

s390: SImode pointers vs LR

In config/s390/s390.c we accept addresses that are SImode: if (!REG_P (base) || (GET_MODE (base) != SImode GET_MODE (base) != Pmode)) return false; However, there doesn't seem to be anything in the s390's opcodes that masks the top half of address

Re: [PATCH, v2] Fix bootstrap with in-tree ISL

A few minor nits... Your patch includes many whitespace changes, which makes reviewing your patch more difficult. Please limit whitespace changes when they're unrelated to the patch. Assuming you've looked at the actual diffs for them, and see nothing beyond changes related to your patch, it's

Re: fix pr65369.c testcase

Done. Thanks!

[expmed] Avoid clobbering a yet-to-be-used base/index register.

20040625-1 fails on targets with pointers bigger than WORD_SIZE (rl78, msp430/-mlarge) because the base register is clobbered, partially rebuilt with the new value, then used as a base for the second part of the calculation. Ok? * expmed.c (extract_bit_field_1): Avoid clobbering a

fix pr65369.c testcase

Copied the way other tests get uint32_t. Ok? * gcc.c-torture/execute/pr65369.c: Don't assume int is 32 bits. Index: gcc.c-torture/execute/pr65369.c === --- gcc.c-torture/execute/pr65369.c (revision 223737) +++

Re: [PATCH/libiberty] fix build of gdb/binutils with clang.

If the other c file only includes libiberty.h and does not include the libiberty/config.h and In general, such other c files should have their own config.h that does the same test and has its own HAVE_DECL_ASPRINTF. That way, the config.h matches the compiler options being used, and not the

Re: RFA: RL78: Place zero-initialised data into the .bss section

OK to apply ? Ok but.. +case SECCAT_TBSS: + return default_select_section (decl, reloc, align); + +default: + gcc_unreachable (); Would it be better to just default: everything to default_select_section, instead of enumerating everything we know about today?

Re: Remove mode argument from gen_rtx_SET

What I was confused about is that the first set isn't valid rtl. The SET_SRC and SET_DEST always have to have the same mode (or VOIDmode in the case of a CONST_INT, etc., where the mode is implicitly the same as the SET_DEST). So wouldn't it have to be: (set (reg:SI 1)

Re: Remove mode argument from gen_rtx_SET

; This pattern is identical to the truncsipsi2 pattern except ; that it uses a SUBREG instead of a TRUNC. It is needed in ; order to prevent reload from converting (set:SI (SUBREG:PSI (SI))) ; into (SET:PSI (PSI)). I'm not sure what that's supposed to mean (what's an SI set of a PSI

Re: [RFA] libiberty/mkstemps.c: Include time.h if sys/time.h not available.

* mkstemps.c: #include time.h if HAVE_TIME_H is defined but not HAVE_SYS_TIME_H. Ok.

Re: RFA: RL78: Save the frame pointer if it is used.

OK to apply ? Ok, but... - if (regno == FRAME_POINTER_REGNUM frame_pointer_needed) + if (regno == FRAME_POINTER_REGNUM + (frame_pointer_needed || df_regs_ever_live_p (regno))) Do we want regs_ever_live or regs_ever_written_to ? I seem to recall changing a port... mep perhaps...

Re: RFA: RL78: Add support for G13 and G14 multiply and divide

OK to apply ? Ok. gcc/ChangeLog 2015-04-15 Nick Clifton ni...@redhat.com * config/rl78/rl78-opts.h (enum rl78_mul_types): Add MUL_G14 and MUL_UNINIT. (enum rl78_cpu_type): New. * config/rl78/rl78-virt.md (attr valloc): Add divhi and divsi.

Re: RFA: RL78:

OK to apply ? Ok! 2015-04-14 Nick Clifton ni...@redhat.com * config/rl78/rl78.c (rl78_expand_prologue): Mark large stack decrement instruction as being frame related. (rl78_print_operand_1): Handle 'p' modifier to add +0 to HL based addresses. If

Re: [PATCH] Fix libbacktrace and libiberty tests fail on sanitized GCC due to wrong link options.

Is this ok for trunk now? Yes.

[rl78] fix 'p' test

Mis-applied patch, committed. * config/rl78/rl78.c (rl78_print_operand_1): Move 'p' test to correct clause. Index: config/rl78/rl78.c === --- config/rl78/rl78.c (revision 221648) +++ config/rl78/rl78.c (working

[rl78] fix ICE with far operands to and/ior

Committed. * config/rl78/rl78-virt.md (andqi3_virt): Allow far operands. (iorqi3_virt): Likewise. Index: config/rl78/rl78-virt.md === --- config/rl78/rl78-virt.md(revision 221505) +++ config/rl78/rl78-virt.md

Re: Newlib/Cygwin now under GIT

This is a common problem. I guess newlib/cygwin got the oldest set and, afaik, the GCC toplevel stuff is kind of the master. It would be nice if we had some automatism in place to keep all former src repos in sync. There was never any agreement on who the master was for toplevel sources -

Re: RFA: RL78: Add muladdhi3 pattern

The problem appears to be that GCC will create a multiply-plus-add instruction to access the table regardless of whether the backend supports such an instruction. I could not work out where in the middle end this was occurring, so instead I created the patch below which contains a

Re: RFA: RL78: Fix register constraints in rl78-real.md

OK to apply ? Ok.

[rl78] more far addr edge cases

More edge cases regarding far addresses. Committed. * config/rl78/rl78-real.md (*addqi_real): Allow SADDR types for inc/dec. (*addhi3_real): Likewise. * config/rl78/rl78-virt.md (*incmode3_virt): Additional pattern to match incrementing memory. *

[rl78] fix SFmode moves

SFmode moves were using 8-bit transfers instead of 16-bit. This patch copies the SImode move pattern, which expands into 16-bit moves. Since this only affects rl78, and the SImode code is well tested, I'm applying this now so it will be in gcc 5. * config/rl78/rl78-protos.h

[v850] fix branch limits

The branch limits are a bit too far, resulting in reloc errors in rare cases. Ok? * config/v850/v850.md (branch_normal): Adjust branch limits. (branch_invert): Likewise. (branch_z_normal): Likewise. (branch_z_invert): Likewise. (branch_nz_normal):

Re: emit-rtl tidy

The m32c parts are OK.

Re: RFA: RL78: Fix gcc testsuite failures

Ok.

building against a temporary install dir?

So here's what I'm trying to do... I want to build gcc, binutils, and newlib, run tests, and IF the tests pass, THEN install them all. However, gcc needs an installed newlib to build it's libraries. I tried installing newlib into $DESTDIR$PREFIX but gcc ignores $DESTDIR during the compile. Any

Re: Rename C files to .c in GCC source

Aren't current Windows file systems case-preserving? Then they shouldn't have no problems with .C files. They are case preserving, but not case sensitive. A wildcard search for *.c will match foo.C and bar.c, and foo.c can be opened as FOO.C.

Re: Rename C files to .c in GCC source

pins...@gmail.com writes: No because they are c++ code so capital C is correct. However, we should avoid relying on case-sensitive file systems (Windows) and use .cc or .cxx for C++ files (+ is not a valid file name character on Windows, so we can't use .c++).

Re: [PATCH] Fix libbacktrace and libiberty tests fail on sanitized GCC due to wrong link options.

I can't say if this fixes a bug important enough for stage4, but if someone wants to claim that, you won't have to wait for stage 1 :-)

Re: [PATCH] libiberty/argv.c: Use freeargv() instead of free() to avoid memory leak.

memcpy (*argvp + i, file_argv, file_argc * sizeof (char *)); This code copies all the pointers in file_argv[] into argv[], so if you freeargv them via file_argv, argv[] will point to free'd memory. Hence the comment: /* Free up memory allocated to process the response file. We do

Re: [PATCH] Fix libbacktrace and libiberty tests fail on sanitized GCC due to wrong link options.

Does the patch look sane? I don't think anything in the toplevel configury looks sane any more, but I think this patch is OK.

Re: [PATCH] Workaround -Wmaybe-uninitialized false positives during profiledbootstrap

a later release (4.6 I think). Attempts to build with 4.4 (i.e. on RHEL 6) causes warnings on most files. 2010-06-21 DJ Delorie d...@redhat.com * diagnostic.h (diagnostic_classification_change_t): New. (diagnostic_context): Add history and push/pop list

[rl78] avoid move-elim on volatile mems

See $subj. Committed. * config/rl78/rl78.c (move_elim_pass): Don't optimize away volatile memory references. Index: config/rl78/rl78.c === --- config/rl78/rl78.c (revision 220150) +++ config/rl78/rl78.c (working

Re: RFA: RL78: Add assembler versions of some libgcc functions.

OK to apply ? Ok.

Re: RFA: RL78: Minor prologue and epilogue enhancements

OK to apply ? Ok.

Re: [PATCH] Fix generation of m32c target (PR 50928)

OK for trunk. OK for 4.9 branch if it's OK with the release manager. Do you need someone to apply it for you?

<    1   2   3   4   5   6   7   8   9   10   >