Re: [PATCH] Fix DJGPP LTO with debug

[DJ Delorie]

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 i686-pc-msdosdjgpp
> cross cc1/lto1 from x86_64-linux which went fine.

CC's Andris, our current gcc maintainer within DJGPP.  I know he just
built 8.2 binaries for us, I don't know what his testing infrastructure
looks like.

Stepping down, mostly...

[DJ Delorie]

This has been a long time coming, but as most of you know I've changed
groups at Red Hat and my new duties don't give me the time or focus I
used to have for all my various upstream maintainerships.  To be fair
to the community, I'm making this change official by stepping down
from the ones I can no longer give sufficient attention to:

m32c
rx
rl78
v850
msp430
libiberty
build machinery

I'm recommending Sebastian Perta  for the
Renesas targets (m32c, rx, rl78, v850) and Jozef Lawrynowicz
 for the TI target (msp430), if they so
desire.

I'll keep my DJGPP-related maintainerships of course :-)

Specific patches to MAINAINERS attached.

Reply-to set to me due to cross-posting.



[gcc]
* MAINTAINERS (m32c, msp43, rl78, libiberty, build): Remove myself
as maintainer.

Index: MAINTAINERS
===
--- MAINTAINERS (revision 262891)
+++ MAINTAINERS (working copy)
@@ -67,38 +67,35 @@ hppa port   John David Anglin   
 i386 port  Uros Bizjak 
 i386 vector ISA extns  Kirill Yukhin   
 ia64 port  Jim Wilson  
 iq2000 portNick Clifton
 lm32 port  Sebastien Bourdeauducq  
-m32c port  DJ Delorie  
 m32r port  Nick Clifton
 m68k port (?)  Jeff Law
 m68k port  Andreas Schwab  
 m68k-motorola-sysv portPhilippe De Muyter  
 mcore port Nick Clifton
 microblaze Michael Eager   
 mips port  Matthew Fortune 
 mmix port  Hans-Peter Nilsson  
 mn10300 port   Jeff Law
 mn10300 port   Alexandre Oliva 
 moxie port Anthony Green   
-msp430 portDJ Delorie  
 msp430 portNick Clifton
 nds32 port Chung-Ju Wu 
 nds32 port Shiva Chen  
 nios2 port Chung-Lin Tang  
 nios2 port Sandra Loosemore
 nvptx port Tom de Vries
 pdp11 port Paul Koning 
 powerpcspe portAndrew Jenner   

 riscv port Kito Cheng  
 riscv port Palmer Dabbelt  
 riscv port Andrew Waterman 
 riscv port Jim Wilson  
-rl78 port  DJ Delorie  
 rs6000/powerpc portDavid Edelsohn  
 rs6000/powerpc portSegher Boessenkool  
 rs6000 vector extnsAldy Hernandez  
 rx portNick Clifton
 s390 port  Hartmut Penner  
 s390 port  Ulrich Weigand  
@@ -162,13 +159,12 @@ libcppAll C and C++ front end maintai
 libcpp David Malcolm   
 fp-bit Ian Lance Taylor
 libdecnumber   Ben Elliston
 libgcc Ian Lance Taylor
 libgo  Ian Lance Taylor
 libgompJakub Jelinek   
-libiberty  DJ Delorie  
 libiberty  Ian Lance Taylor
 libitm Torvald Riegel  
 libobjcNicola Pero 

 libobjcAndrew Pinski   
 libquadmathTobias Burnus   
 libquadmathJakub Jelinek   
@@ -206,13 +202,12 @@ web pages Gerald Pfeifer  
 i18n   Philipp Thomas  
 i18n   Joseph Myers
 diagnostic messagesDodji Seketeli  
 diagnostic messagesDavid Malcolm   
 build machinery (*.in) Paolo Bonzini   
-build machinery (*.in) DJ Delorie  
 build machinery (*.in) Nathanael Nerode
 build machinery (*.in) Alexandre Oliva 
 build machinery (*.in) Ralf Wildenhues 
 docs co-maintainer Gerald Pfeifer  
 docs co-maintainer Joseph Myers
 docs co-maintainer Sandra Loosemore


[binutils]
* MAINTAINERS (RL78, RX): Remove myself as maintainer.

diff --git a/binutils/MAINTAINERS b/binutils/MAINTAINERS
index 8a1b152..5b3a6c8 100644
--- a/binutils/MAINTAINERS
+++ b/binutils/MAINTAINERS
@@ -119,8 +119,6 @@ responsibility among the other maintainers.
   PPC vector ext   Aldy Hernandez 
   RISC-V   Palmer Dabbelt 
   RISC-V   Andrew Waterman  
-  RL78 DJ Delorie 
-  RX   DJ Delorie 
   RX   Nick Clifton 
   s390, s390x Martin Schwidefsky 
   s390, s390x Andreas Krebbel 

[sim]
* MAINTAINERS (rl78, m32c, rx, v850): Remove myself as maintainer.

diff --git a/sim/MAINTAINERS b/sim/MAINTAINERS
index 62887d4

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

[DJ Delorie]

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

[DJ Delorie]

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

[DJ Delorie]

> +   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

[DJ Delorie]

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 TOUPPER the 430i suffixes, but the
expectation is that there will never be anything for the TOUPPER to
upper, yes?

If so, no further objections from me.  It can be tweaked later if they
change their minds.

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

[DJ Delorie]

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
lower-case-letter symbols?

Just trying to think of all the possibilities here.

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

[DJ Delorie]

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

[DJ Delorie]

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 function is available when it comes to linking.

> I did also test on hardware that static interrupts works as expected, and they
> do.

It sounds like things have changed since I first wrote that code, so as
long as it works now, I'm OK with it :-)

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

[DJ Delorie]

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 table as well.

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

[DJ Delorie]

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 work around differences in underlying operating
systems.  The xfoo() variants often handle error conditions also, as
that has traditionally been something that OSs do differently anyway.

Having said that, adding something to libiberty is more complicated than
adding something to gcc (it didn't used to be), and if nobody else needs
a more portable qsort, it's a wasted effort.

Libiberty is *not* a generic "toss things in here because they're useful
and generic" library, despite being used as such.  However, it is common
among a few large projects (which used to share a repo, limiting copies
of libiberty to one), and does help in code re-use.

Given all that, I'd say that an xqsort might be appropriate in
libiberty, if it was (1) able to take over for the generic qsort[1] ,
and (2) the changes are also needed or useful in one of the other
projects using libiberty.  But given that it's currently written in C++
(it would need to be C-compatible) and only used by gcc, IMHO putting it
in libiberty would be inappropriate at this time.  The fact that qsort
is defined to be nondeterministic is not a portability issue[2].

Consider that there is also gnulib, which serves a similar purpose.

[1] i.e. if replacing qsort() with xqsort() in a C or C++ program
resulted in the same behavior as far as standards imply.

[2] if the nondeterminism is a problem, you probably need to fix your
compare function ;-)

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

[DJ Delorie]

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

[DJ Delorie]

"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

[DJ Delorie]

"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 think this one feels "more correct" than the
other, as it retains more of the "I'm 16 bits"-ness of the operand)

>> If it doesn't work out, consider this patch approved, though.
> Can I checkin now?

Yes.  Thanks!

Make sure the indentation is correct, of course.  It wasn't in the
email, and that confused me at first.

Re: [PATCH] RL78 one_cmplhi2 improvement

[DJ Delorie]

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 in all cases,
but it's worth trying.

If it doesn't work out, consider this patch approved, though.

Thanks!

Re: {PATCH] RL78 movdf define expand

[DJ Delorie]

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

[DJ Delorie]

"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 longer
> this is why I let it as it is.

Ok.

> Also based on comments from Jakub (on a different patch) I corrected the
> Changelog entry for this patch (see below). Is this OK?

Yup.  Thanks!

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

[DJ Delorie]

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

[DJ Delorie]

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 numbers as arguments
> +On RX and RL78 targets, you may specify one or more vector numbers as 
> arguments

...if the new line is too long and if a paragraph reformat is warranted.

Thanks!

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

[DJ Delorie]

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

[DJ Delorie]

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

[DJ Delorie]

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 not reduced to
SImode, they're reduced to QImode.  If you want SImode instead, you need
to intervene.

Re: FW: [PATCH] rl78 umaxdi3 improvement

[DJ Delorie]

"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".
>   * config/rl78/rl78.md: New define_expand "anddi3".
>
>   * config/rl78/rl78-protos.h: New function declaration rl78_split_movdi
>   * config/rl78/rl78.md: New define_expand "movdi"
>   * config/rl78/rl78.c: New function definition rl78_split_movdi
>
>   * config/rl78/rl78-expand.md: New define_expand "bswaphi2"
>   * config/rl78/rl78-virt.md: New define_insn "*bswaphi2_virt"
>   * config/rl78/rl78-real.md: New define_insn "*bswaphi2_real"

These are OK.  thanks!

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

[DJ Delorie]

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: config/rl78/rl78.c
> ===
> --- config/rl78/rl78.c(revision 256590)
> +++ config/rl78/rl78.c(working copy)
> @@ -3792,7 +3792,7 @@
>  rl78_note_reg_set (char *dead, rtx d, rtx insn)
>  {
>int r, i;
> -
> +  bool is_dead;
>if (GET_CODE (d) == MEM)
>  rl78_note_reg_uses (dead, XEXP (d, 0), insn);
>
> @@ -3799,9 +3799,15 @@
>if (GET_CODE (d) != REG)
>  return;
>
> + /* Do not mark the reg unused unless all QImode parts of it are dead.  */
>r = REGNO (d);
> -  if (dead [r])
> -add_reg_note (insn, REG_UNUSED, gen_rtx_REG (GET_MODE (d), r));
> +  is_dead = true;
> +  for (i = 0; i < GET_MODE_SIZE (GET_MODE (d)); i ++)
> +  if (!dead [r + i])
> +  is_dead = false;
> +  if(is_dead)
> +add_reg_note (insn, REG_UNUSED, gen_rtx_REG (GET_MODE (d), r));
>if (dump_file)
>  fprintf (dump_file, "note set reg %d size %d\n", r, GET_MODE_SIZE 
> (GET_MODE (d)));
>for (i = 0; i < GET_MODE_SIZE (GET_MODE (d)); i ++)

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

[DJ Delorie]

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 callback with known bogus data.  I suppose
the usefulness of that depends on how often you'll encounter 4Gb+ xcoff64
files on mingw32 ?

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

[DJ Delorie]

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

[DJ Delorie]

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 as
we want 64-bit xcoff support in 32-bit filesystems.

Otherwise, we'd need to detect off_t overflow somehow, down the slippery
slope of reporting the error to the caller...

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

[DJ Delorie]

"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  */

Missing period at the end of a sentence; should capitalize first word
but it's a variable, which should be block caps anyway, and it reads
better as two sentences:

> +  /* DEAD keeps track of the QImode registers.  If R is of different size
> +  we need to check the other subparts as well.  */

Or rewrite to not mention variables?

> + /* Do not mark the reg unused unless all QImode parts of it are dead.  */

Re: [PATCH] RL78 movdi improvement

[DJ Delorie]

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 movdi bug.  The other
patches look OK otherwise.

Re: [PATCH] rl78 anddi3 improvement

[DJ Delorie]

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 - compiling libgcc/libstdc++ is a torture test for
alloc/reload on small mcus.  That forced me to be conservative, and add
the virtual ISA that gcc can work with.

So I'm OK with your approach, and if you come up with something even
better, I'm OK with that too :-)

(pending reviews, of course, that's next ;)

Re: [RFTesting] New POINTER_DIFF_EXPR

[DJ Delorie]

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 than the default.
rl78 for example has a 16-bit default pointer and a 32-bit far pointer.

Re: [PATCH] rl78 subdi3 improvement

[DJ Delorie]

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

[DJ Delorie]

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 generated files), and a ChangeLog entry is needed (I wrote one
for you).

Please see https://gcc.gnu.org/contribute.html for more details; the
better prepared your patch is, the easier it is to accept it ;-)

Thanks!
DJ

Re: [PATCH] rl78 adddi3 improvement

[DJ Delorie]

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

[DJ Delorie]

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 them into the interrupt table for
you.  So, adding "used" is consistent with this method, as the interrupt
attribute *is* the registration.

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

[DJ Delorie]

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.

>   * gcc/config/msp430/msp430.h: Don't pass -mmcu to the assembler.

Does this break compatibility with older versions of binutils?

> +/* This structure is no longer being maintained.  Up-to-date data is read 
> from
> +   a devices.csv file on the user's system.

I think occasional updates to the table are still warranted from a
philosophical and GPL point of view, although I expect the average user
to use the latest devices.csv anyway.  If gcc stops working properly for
lack of a proprietary file, that's a problem.

[rest of review later]

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

[DJ Delorie]

"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 classic
> programming style.

Yup, I noted that.  Just mentioning the inconsistency.

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

[DJ Delorie]

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 only affect your OS.  I see no reason to reject the
patch myself, other than:

+  symtab = XNEWVEC (struct external_syment, ocr->nsyms * SYMESZ);
+  if (!simple_object_internal_read (sobj->descriptor,

There's no check to see if XNEWVEC succeeded.


Also, the use of XDELETEVEC is inconsistently protected with a "if (foo
!= NULL)" throughout, but passing NULL to XDELETEVEC (essentially,
free()) is allowed anyway, so this is only a stylistic issue, which I'm
not particularly worried about.

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

[DJ Delorie]

Eli Zaretskii  writes:
> Seems to work fine, thanks.

Checked into gcc trunk then :-)

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

[DJ Delorie]

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
don't. */
 #undef HAVE_DECL_SNPRINTF
 
+/* Define to 1 if you have the declaration of `strnlen', and to 0 if you
+   don't. */
+#undef HAVE_DECL_STRNLEN
+
 /* Define to 1 if you have the declaration of `strtol', and to 0 if you don't.
*/
 #undef HAVE_DECL_STRTOL
 
 /* Define to 1 if you have the declaration of `strtoll', and to 0 if you
don't. */
Index: configure
===
--- configure   (revision 248482)
+++ configure   (working copy)
@@ -5861,12 +5861,22 @@ else
   ac_have_decl=0
 fi
 
 cat >>confdefs.h <<_ACEOF
 #define HAVE_DECL_STRTOULL $ac_have_decl
 _ACEOF
+ac_fn_c_check_decl "$LINENO" "strnlen" "ac_cv_have_decl_strnlen" 
"$ac_includes_default"
+if test "x$ac_cv_have_decl_strnlen" = x""yes; then :
+  ac_have_decl=1
+else
+  ac_have_decl=0
+fi
+
+cat >>confdefs.h <<_ACEOF
+#define HAVE_DECL_STRNLEN $ac_have_decl
+_ACEOF
 
 
 $as_echo "#define HAVE_SYS_ERRLIST 1" >>confdefs.h
 
 
 $as_echo "#define HAVE_SYS_NERR 1" >>confdefs.h
@@ -7002,12 +7012,23 @@ else
 fi
 
 cat >>confdefs.h <<_ACEOF
 #define HAVE_DECL_STRVERSCMP $ac_have_decl
 _ACEOF
 
+  ac_fn_c_check_decl "$LINENO" "strnlen" "ac_cv_have_decl_strnlen" 
"$ac_includes_default"
+if test "x$ac_cv_have_decl_strnlen" = x""yes; then :
+  ac_have_decl=1
+else
+  ac_have_decl=0
+fi
+
+cat >>confdefs.h <<_ACEOF
+#define HAVE_DECL_STRNLEN $ac_have_decl
+_ACEOF
+
   { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether 
canonicalize_file_name must be declared" >&5
 $as_echo_n "checking whether canonicalize_file_name must be declared... " >&6; 
}
 if test "${libiberty_cv_decl_needed_canonicalize_file_name+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   cat confdefs.h - <<_ACEOF >conftest.$ac_ext
Index: configure.ac
===
--- configure.ac(revision 248482)
+++ configure.ac(working copy)
@@ -413,13 +413,13 @@ if test "x" = "y"; then
  stpcpy stpncpy strcasecmp strchr strdup \
  strerror strncasecmp strndup strnlen strrchr strsignal strstr strtod \
  strtol strtoul strtoll strtoull strverscmp sysconf sysctl sysmp \
 table times tmpnam \
 vasprintf vfprintf vprintf vsprintf \
 wait3 wait4 waitpid)
-  AC_CHECK_DECLS([basename(char *), ffs, asprintf, vasprintf, snprintf, 
vsnprintf, strtol, strtoul, strtoll, strtoull])
+  AC_CHECK_DECLS([basename(char *), ffs, asprintf, vasprintf, snprintf, 
vsnprintf, strtol, strtoul, strtoll, strtoull, strnlen])
   AC_DEFINE(HAVE_SYS_ERRLIST, 1, [Define if you have the sys_errlist 
variable.])
   AC_DEFINE(HAVE_SYS_NERR,1, [Define if you have the sys_nerr variable.])
   AC_DEFINE(HAVE_SYS_SIGLIST, 1, [Define if you have the sys_siglist 
variable.])
 fi
 
 # For each of these functions, if the host does not provide the
@@ -686,12 +686,13 @@ if test -z "${setobjs}"; then
 
   AC_CHECK_FUNCS($checkfuncs)
   AC_CHECK_DECLS([basename(char *), ffs, asprintf, vasprintf, snprintf, 
vsnprintf])
   AC_CHECK_DECLS([calloc, getenv, getopt, malloc, realloc, sbrk])
   AC_CHECK_DECLS([strtol, strtoul, strtoll, strtoull])
   AC_CHECK_DECLS([strverscmp])
+  AC_CHECK_DECLS([strnlen])
   libiberty_NEED_DECLARATION(canonicalize_file_name)
 fi
 
 # Figure out which version of pexecute to use.
 case "${host}" in
  *-*-mingw* | *-*-winnt*)  pexecute=pex-win32  ;;

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

[DJ Delorie]

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 git, I announced that I would no longer be auto-syncing.  So
it's up to the projects using copies of libiberty to make sure they stay
in sync with the gcc master copy.

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

[DJ Delorie]

Thanks.  Committed!

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

[DJ Delorie]

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

[DJ Delorie]

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
> +++ libiberty/waitpid.c   2017-05-23 21:19:34.302415000 +0300
> @@ -23,6 +23,11 @@ does the return value.  The third argume
>  #include 
>  #endif
>  
> +#ifdef __MINGW32__
> +#include 
> +#define wait(s)  _cwait(s,pid,_WAIT_CHILD)
> +#endif
> +
>  pid_t
>  waitpid (pid_t pid, int *stat_loc, int options ATTRIBUTE_UNUSED)
>  {

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

[DJ Delorie]

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 a bit, I come to the following
conclusions...

* $funcs is a list of functions libiberty should provide if the host
  doesn't have them.

* We can override what the host *has* but not what it *shouldn't* have.

Since (or "if") nobody will (should) use waitpid() on mingw anyway, and
since libiberty really wants to include waitpid.o, how difficult would
it be to use some #ifdefs to have waitpid() just return an error on
mingw?  That at least gets past the mingw build problem.

> One caveat: I needed to hack config/override.m4 to allow me to run
> autoconf 2.69 I have installed, because otherwise it insists on
> autoconf 2.64 which I don't have.  I hope this isn't the reason for
> the incomplete solution.

I have many versions of autoconf installed, each in their own
directories, and add the right one to my $PATH on a per-project basis.
Autoconf works just fine that way, and there have been plenty of cases
of autoconf output changing in, er, "unexpected" ways across autoconf
releases.  If you regen configure and an "svn diff" (or git diff) shows
unexpected changes, check your autoconf :-)

Same for automake and autogen.

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

[DJ Delorie]

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
> projects doesn't (or shouldn't) change that ;-)

:-)

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

[DJ Delorie]

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 
+
+   * configure.ac (*-*-mingw*): Don't build waitpid.c.
+
 2017-05-02  Iain Buclaw  
 
* d-demangle.c (dlang_hexdigit): New function.
Index: libiberty/configure.ac
===
--- libiberty/configure.ac  (revision 248307)
+++ libiberty/configure.ac  (working copy)
@@ -493,7 +493,6 @@
 AC_LIBOBJ([strnlen])
 AC_LIBOBJ([strverscmp])
 AC_LIBOBJ([vasprintf])
-AC_LIBOBJ([waitpid])
 
 for f in $funcs; do
   case "$f" in

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

[DJ Delorie]

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 configure.ac.

environ is tricky because it's typically messy on platforms, unlike a
standard C function.  You can't use a generic check if the macro expands
to something that interferes with the check.

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

[DJ Delorie]

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 configure).  It also checks against a patch against a stale
copy of the sources; if your patch doesn't apply that's a hint to the
maintainer that the patch needs to be looked at more closely.

The easier you can make it for the maintainer (me!), the more likely
your patch will get handled quickly.

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

[DJ Delorie]

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, we didn't put in declarations at all... until "char *"
became a different size than "int" and we started needing them.

So some functions in libiberty are HAVE_DECL and others are still HAVE.

Ah, found it, this commit is incomplete:

https://gcc.gnu.org/ml/gcc-patches/2014-06/msg00784.html

It changes gcc's configure but nobody else's (and now we have an answer
to the three-year-old question "why don't we have a more liberal commit
policy?" ;) which breaks both libiberty and libgfortran.

> BTW, I once proposed a new libiberty.m4 file that all libiberty
> clients would source so that these checks are all centralized.

I have no philosophical problem with that type of change, but I have the
usual fear of touching anything in libiberty that's been around this
long ;-)

(this bug being a prime example of how subtle an incorrect change can be)

(and honestly, my upstream attention is elsewhere these days)

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

[DJ Delorie]

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

[DJ Delorie]

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 users, not just libiberty.

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

[DJ Delorie]

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 complained that libstdc++ has a hard-coded list, rather
than using a configure-time check, in the past...

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

[DJ Delorie]

Committed.  Thanks!

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

[DJ Delorie]

Committed.  Thanks!

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

[DJ Delorie]

Committed for you, thanks!

[patch] libiberty/78584

[DJ Delorie]

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
===
--- argv.c  (revision 243279)
+++ argv.c  (working copy)
@@ -32,12 +32,19 @@ Boston, MA 02110-1301, USA.  */
 /*  Routines imported from standard C runtime libraries. */
 
 #include 
 #include 
 #include 
 #include 
+#include 
+#ifdef HAVE_UNISTD_H
+#include 
+#endif
+#if HAVE_SYS_STAT_H
+#include 
+#endif
 
 #ifndef NULL
 #define NULL 0
 #endif
 
 #ifndef EOS
@@ -384,22 +391,34 @@ expandargv (int *argcp, char ***argvp)
   char *buffer;
   /* Dynamically allocated storage for the options read from the
 response file.  */
   char **file_argv;
   /* The number of options read from the response file, if any.  */
   size_t file_argc;
+#ifdef S_ISDIR
+  struct stat sb;
+#endif
   /* We are only interested in options of the form "@file".  */
   filename = (*argvp)[i];
   if (filename[0] != '@')
continue;
   /* If we have iterated too many times then stop.  */
   if (-- iteration_limit == 0)
{
  fprintf (stderr, "%s: error: too many @-files encountered\n", 
(*argvp)[0]);
  xexit (1);
}
+#ifdef S_ISDIR
+  if (stat (filename+1, ) < 0)
+   continue;
+  if (S_ISDIR(sb.st_mode))
+   {
+ fprintf (stderr, "%s: error: @-file refers to a directory\n", 
(*argvp)[0]);
+ xexit (1);
+   }
+#endif
   /* Read the contents of the file.  */
   f = fopen (++filename, "r");
   if (!f)
continue;
   if (fseek (f, 0L, SEEK_END) == -1)
goto error;

Re: [PATCH] Implement new hook for max_align_t_align

[DJ Delorie]

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 of
malloc?

Re: Change license of filenames.h to LGPL

[DJ Delorie]

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 later
> version” regime.)

That's not what that means.  The license terms cannot be changed, and
remain "version X or later", even if the user chooses to apply the terms
of some later version.

The "or later" allows the users alternatives for when the FSF fixes a
"license bug" in a newer version; it avoids needing to update all the
licenses.  It also future-proofs the older code, ensuring it's
license-compatible with newer code.

Re: Change license of filenames.h to LGPL

[DJ Delorie]

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: http://gcc.gnu.org/ml/gcc-patches/2016-09/msg02048.html )

I wonder if us relicensing our modified copy would apply to your old
copy.  I mean, are we sure RMS knows you're also relicensing an old
copy, and that the current copy is being relicensed only to avoid future
issues.  If we're only doing it to document the decision, the fact that
hashtab.h and filename_cmp.c are still GPL mostly negates the
effectiveness of our change anyway.

(i.e. it seems like you can get what you need whether we relicense ours
or not, and relicensing ours doesn't have much actual effect).

(again, not opposed to the change, just clarifying everything)

Re: Change license of filenames.h to LGPL

[DJ Delorie]

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 GPL unless
filename_cmp.c is changed also.

> Why would it need to
> change?  It's perfectly okay to link GPL code with LGPL code, we do
> this all the time with libgcc, no?  Or am I missing something?

libgcc has an exception that covers most of those cases; be careful when
comparing those to your (his) use case.

Re: Change license of filenames.h to LGPL

[DJ Delorie]

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, or elsewhere?  Is
he aware that filenames.h includes hashtab.h, which is GPL?

(I'm not opposed to the change, just trying to make sure I understand
it's scope)

Re: Change license of filenames.h to LGPL

[DJ Delorie]

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

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

[DJ Delorie]

This is OK.  Thanks!

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

[DJ Delorie]

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

[DJ Delorie]

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
===
--- config/msp430/msp430.md (revision 240100)
+++ config/msp430/msp430.md (revision 240101)
@@ -1456,21 +1456,21 @@
 
 (define_insn "delay_cycles_32x"
   [(unspec_volatile [(match_operand 0 "immediate_operand" "i")
 (match_operand 1 "immediate_operand" "i")
 ] UNS_DELAY_32X)]
   ""
-  "PUSHM.A #2,r13
+  "PUSHM.A #2,r14
MOV.W   %A0, r13
MOV.W   %B0, r14
 1: SUB.W   #1, r13
SUBC.W  #0, r14
JNE 1b
TST.W   r13
JNE 1b
-   POPM.A  #2,r13"
+   POPM.A  #2,r14"
   )
 
 (define_insn "delay_cycles_16"
   [(unspec_volatile [(match_operand 0 "immediate_operand" "i")
 (match_operand 1 "immediate_operand" "i")
 ] UNS_DELAY_16)]

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

[DJ Delorie]

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 error, so the user must fix it
right away, or ignore the weak, which results in a linker error
(somehow? maybe?) if the user specifies two handlers for the same
interrupt.

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

[DJ Delorie]

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

[DJ Delorie]

> 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 Ada
out of gcc completely - after all, *I* don't use it, and it's a huge
amount of overhead that I have to deal with all the time.  But I
recognize that others benefit from, and are willing to maintain, the
Ada front-end.  You should allow others to maintain DJGPP ports for
it.

> How many users are we talking about here?

Zero if you reject the patches, of course.

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

[DJ Delorie]

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.
(umulqihi3_virt): Likewise.
* config/rl78/rl78-real.c (umulhi3_shift_real): Likewise.
(umulqihi3_real): Likewise.

Index: gcc/config/rl78/rl78-expand.md
===
--- gcc/config/rl78/rl78-expand.md  (revision 237565)
+++ gcc/config/rl78/rl78-expand.md  (working copy)
@@ -156,13 +156,13 @@
 )
 
 (define_expand "umulqihi3"
   [(set (match_operand:HI 0 "register_operand")
 (mult:HI (zero_extend:HI (match_operand:QI 1 "register_operand"))
  (zero_extend:HI (match_operand:QI 2 "register_operand"]
-  "!TARGET_G10"
+  ""
   ""
 )
 
 (define_expand "andqi3"
   [(set (match_operand:QI 0 "rl78_nonimmediate_operand")
(and:QI (match_operand:QI 1 "rl78_general_operand")
Index: gcc/config/rl78/rl78-real.md
===
--- gcc/config/rl78/rl78-real.md(revision 237565)
+++ gcc/config/rl78/rl78-real.md(working copy)
@@ -176,23 +176,23 @@
 )
 
 (define_insn "*umulhi3_shift_real"
   [(set (match_operand:HI 0 "register_operand" "=A,A")
 (mult:HI (match_operand:HI 1 "rl78_nonfar_operand" "0,0")
  (match_operand:HI 2 "rl78_24_operand" "N,i")))]
-  "rl78_real_insns_ok () && !TARGET_G10"
+  "rl78_real_insns_ok ()"
   "@
shlw\t%0, 1
shlw\t%0, 2"
 )
 
 (define_insn "*umulqihi3_real"
   [(set (match_operand:HI 0 "nonimmediate_operand" "=A")
 (mult:HI (zero_extend:HI (match_operand:QI 1 "general_operand" "%a"))
  (zero_extend:HI (match_operand:QI 2 "general_operand" "x"]
-  "rl78_real_insns_ok () && !TARGET_G10"
+  "rl78_real_insns_ok ()"
   "mulu\t%2"
 )
 
 (define_insn "*andqi3_real"
   [(set (match_operand:QI 0 "rl78_nonimmediate_operand"  
"=WsfWsaWhlWab,A,R,vWsa")
(and:QI (match_operand:QI 1 "rl78_general_operand"   "%0,0,0,0")
Index: gcc/config/rl78/rl78-virt.md
===
--- gcc/config/rl78/rl78-virt.md(revision 237565)
+++ gcc/config/rl78/rl78-virt.md(working copy)
@@ -113,22 +113,22 @@
 )
 
 (define_insn "*umulhi3_shift_virt"
   [(set (match_operand:HI  0 "register_operand" "=v")
 (mult:HI (match_operand:HI 1 "rl78_nonfar_operand" "%vim")
  (match_operand:HI 2 "rl78_24_operand" "Ni")))]
-  "rl78_virt_insns_ok () && !TARGET_G10"
+  "rl78_virt_insns_ok ()"
   "v.mulu\t%0, %1, %2"
   [(set_attr "valloc" "umul")]
 )
 
 (define_insn "*umulqihi3_virt"
   [(set (match_operand:HI  0 "register_operand" "=v")
 (mult:HI (zero_extend:HI (match_operand:QI 1 "rl78_nonfar_operand" 
"%vim"))
  (zero_extend:HI (match_operand:QI 2 "general_operand" 
"vim"]
-  "rl78_virt_insns_ok () && !TARGET_G10"
+  "rl78_virt_insns_ok ()"
   "v.mulu\t%0, %2"
   [(set_attr "valloc" "umul")]
 )
 
 (define_insn "*andqi3_virt"
   [(set (match_operand:QI 0 "rl78_nonimmediate_operand" "=vm,  *Wfr,  
vY")

Re: [PATCH] rl78.c: fix warning

[DJ Delorie]

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

[DJ Delorie]

Ok then.  Thanks!

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

[DJ Delorie]

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 considered these cases?

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

[DJ Delorie]

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 Likewise.
>   * config/rl78/fpbit-sf.S Likewise.
>   * config/rl78/fpmath-sf.S Likewise.
>   * config/rl78/mulsi3.S Likewise.

This patch is fine, please apply once gcc is in stage 1 again.

Thanks!

Re: [PATCH] Fix compiling large files

[DJ Delorie]

> 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 macros grow exponentially, we could do it there, if we can get it
to preserve (inject?) line breaks.  But I wouldn't want to be the poor
developer on a 4Gb 32-bit system trying to run it...

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

[DJ Delorie]

> 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.

[DJ Delorie]

> 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: /cvs/gcc/wwwdocs/htdocs/gcc-6/changes.html,v
retrieving revision 1.64
diff -p -U 5 -r1.64 changes.html
--- htdocs/gcc-6/changes.html   26 Feb 2016 14:51:16 -  1.64
+++ htdocs/gcc-6/changes.html   1 Mar 2016 19:39:19 -
@@ -424,10 +424,17 @@ within strings:
   the -march=znver1 and -mtune=znver1 options.
  

 
 
+MeP
+  
+Support for the MeP (mep-elf) architecture has been
+  deprecated and will be removed in a future GCC release.
+
+  
+
 MSP430
   
 The MSP430 compiler now has the ability to automatically distribute 
code
   and data between low memory (addresses below 64K) and high memory.  This 
only
   applies to parts that actually have both memory regions and only if the


Index: contrib/config-list.mk
===
--- contrib/config-list.mk  (revision 233861)
+++ contrib/config-list.mk  (working copy)
@@ -36,13 +36,13 @@ LIST = aarch64-elf aarch64-linux-gnu aar
   i686-wrs-vxworksae \
   i686-cygwinOPT-enable-threads=yes i686-mingw32crt ia64-elf \
   ia64-freebsd6 ia64-linux ia64-hpux ia64-hp-vms iq2000-elf lm32-elf \
   lm32-rtems lm32-uclinux m32c-rtems m32c-elf m32r-elf m32rle-elf m32r-rtems \
   m32r-linux m32rle-linux m68k-elf m68k-netbsdelf \
   m68k-openbsd m68k-uclinux m68k-linux m68k-rtems \
-  mcore-elf mep-elf microblaze-linux microblaze-elf \
+  mcore-elf mep-elfOPT-enable-obsolete microblaze-linux microblaze-elf \
   mips-netbsd \
   mips64el-st-linux-gnu mips64octeon-linux mipsisa64r2-linux \
   mipsisa32r2-linux-gnu mipsisa64r2-sde-elf mipsisa32-elfoabi \
   mipsisa64-elfoabi mipsisa64r2el-elf mipsisa64sr71k-elf mipsisa64sb1-elf \
   mipsel-elf mips64-elf mips64vr-elf mips64orion-elf mips-rtems \
   mips-wrs-vxworks mipstx39-elf mmix-knuth-mmixware mn10300-elf moxie-elf \
Index: gcc/config.gcc
===
--- gcc/config.gcc  (revision 233861)
+++ gcc/config.gcc  (working copy)
@@ -240,12 +240,13 @@ case ${target} in
  | *-knetbsd-* \
  | *-openbsd2* \
  | *-openbsd3* \
  | avr-*rtems* \
  | h8300-*rtems*   \
  | m32r-*rtems*\
+ | mep-*   \
  )
 if test "x$enable_obsolete" != xyes; then
   echo "*** Configuration ${target} is obsolete." >&2
   echo "*** Specify --enable-obsolete to build it anyway." >&2
   echo "*** Support will be REMOVED in the next major release of GCC," >&2
   echo "*** unless a maintainer comes forward." >&2

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

[DJ Delorie]

> 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.

[DJ Delorie]

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

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

[DJ Delorie]

Ok.

msp430: fix function type declarations

[DJ Delorie]

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 233155)
+++ config/msp430/msp430.c  (working copy)
@@ -2108,12 +2108,13 @@ msp430_start_function (FILE *file, const
  fputc ('\n', file);
  fputc ('\t', file);
}
 }
 
   switch_to_section (function_section (decl));
+  ASM_OUTPUT_TYPE_DIRECTIVE(file, name, "function");
   ASM_OUTPUT_FUNCTION_LABEL (file, name, decl);
 }
 
 static const char * const lower_prefix = ".lower";
 static const char * const upper_prefix = ".upper";
 static const char * const either_prefix = ".either";

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

[DJ Delorie]

> 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

[DJ Delorie]

> 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

[DJ Delorie]

> 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

[DJ Delorie]

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

[DJ Delorie]

> 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

[DJ Delorie]

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 overflowing
calls when -mjsr.
* config/rx/rx.c (rx_function_ok_for_sibcall): Likewise for
overflowing jumps.
* doc/invoke.texi (-mjsr): Document it.

Index: doc/invoke.texi
===
--- doc/invoke.texi (revision 231438)
+++ doc/invoke.texi (working copy)
@@ -965,12 +965,13 @@ See RS/6000 and PowerPC Options.
 -mas100-syntax -mno-as100-syntax@gol
 -mrelax@gol
 -mmax-constant-size=@gol
 -mint-register=@gol
 -mpid@gol
 -mallow-string-insns -mno-allow-string-insns@gol
+-mjsr@gol
 -mno-warn-multiple-fast-interrupts@gol
 -msave-acc-in-interrupts}
 
 @emph{S/390 and zSeries Options}
 @gccoptlist{-mtune=@var{cpu-type}  -march=@var{cpu-type} @gol
 -mhard-float  -msoft-float  -mhard-dfp -mno-hard-dfp @gol
@@ -20682,12 +20683,21 @@ disabled automatically.  Instead it is r
 use the @option{-mno-allow-string-insns} option if their program
 accesses I/O space.
 
 When the instructions are enabled GCC defines the C preprocessor
 symbol @code{__RX_ALLOW_STRING_INSNS__}, otherwise it defines the
 symbol @code{__RX_DISALLOW_STRING_INSNS__}.
+
+@item -mjsr
+@itemx -mno-jsr
+@opindex mjsr
+@opindex mno-jsr
+Use only (or not only) @code{JSR} instructions to access functions.
+This option can be used when code size exceeds the range of @code{BSR}
+instructions.  Note that @option{-mno-jsr} does not mean to not use
+@code{JSR} but instead means that any type of branch may be used.
 @end table
 
 @emph{Note:} The generic GCC command-line option @option{-ffixed-@var{reg}}
 has special significance to the RX port when used with the
 @code{interrupt} function attribute.  This attribute indicates a
 function intended to process fast interrupts.  GCC ensures
Index: config/rx/predicates.md
===
--- config/rx/predicates.md (revision 231438)
+++ config/rx/predicates.md (working copy)
@@ -21,13 +21,15 @@
 
 
 ;; Check that the operand is suitable for a call insn.
 ;; Only registers and symbol refs are allowed.
 
 (define_predicate "rx_call_operand"
-  (match_code "symbol_ref,reg")
+  (ior (match_code "reg")
+   (and (match_test "!TARGET_JSR")
+   (match_code "symbol_ref")))
 )
 
 ;; For sibcall operations we can only use a symbolic address.
 
 (define_predicate "rx_symbolic_call_operand"
   (match_code "symbol_ref")
Index: config/rx/rx.c
===
--- config/rx/rx.c  (revision 231438)
+++ config/rx/rx.c  (working copy)
@@ -2854,12 +2854,15 @@ rx_warn_func_return (tree decl)
 /* Return nonzero if it is ok to make a tail-call to DECL,
a function_decl or NULL if this is an indirect call, using EXP  */
 
 static bool
 rx_function_ok_for_sibcall (tree decl, tree exp ATTRIBUTE_UNUSED)
 {
+  if (TARGET_JSR)
+return false;
+
   /* Do not allow indirect tailcalls.  The
  sibcall patterns do not support them.  */
   if (decl == NULL)
 return false;
 
   /* Never tailcall from inside interrupt handlers or naked functions.  */
Index: config/rx/rx.opt
===
--- config/rx/rx.opt(revision 231438)
+++ config/rx/rx.opt(working copy)
@@ -146,6 +146,12 @@ Enable the use of the LRA register alloc
 
 ;---
 
 mallow-string-insns
 Target Report Var(rx_allow_string_insns) Init(1)
 Enables or disables the use of the SMOVF, SMOVB, SMOVU, SUNTIL, SWHILE and 
RMPA instructions.  Enabled by default.
+
+;---
+
+mjsr
+Target Report Mask(JSR)
+Always use JSR, never BSR, for calls.

[rl78] fix far addressing etc

[DJ Delorie]

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.
* config/rl78/rl78-virt (movqi_virt): Fix far memory
alternatives.
(movhi_virt): Likewise.
(zero_extendqihi2_virt): Likewise.
(extendqihi2_virt): Likewise.
(add3_virt): Likewise.
(sub3_virt): Likewise.
(andqi3_virt): Likewise.
(iorqi3_virt): Likewise.
(xorqi3_virt): Likewise.
* config/rl78/rl78-real.md (bf,br): Use long forms to avoid reloc
overflow in large files.

Index: gcc/config/rl78/constraints.md
===
--- gcc/config/rl78/constraints.md  (revision 231385)
+++ gcc/config/rl78/constraints.md  (working copy)
@@ -361,13 +361,13 @@
 (define_memory_constraint "Ws1"
   "es:word8[SP]"
   (match_test "(rl78_es_addr (op) && satisfies_constraint_Cs1 (rl78_es_base 
(op)))
|| satisfies_constraint_Cs1 (op)")
   )
 
-(define_memory_constraint "Wfr"
+(define_constraint "Wfr"
   "ES/CS far pointer"
   (and (match_code "mem")
(match_test "rl78_far_p (op)"))
   )
 
 (define_memory_constraint "Wsa"
Index: gcc/config/rl78/rl78-protos.h
===
--- gcc/config/rl78/rl78-protos.h   (revision 231385)
+++ gcc/config/rl78/rl78-protos.h   (working copy)
@@ -51,6 +51,8 @@ bool  rl78_flags_already_set (rtx, rtx);
 void   rl78_output_symbol_ref (FILE *, rtx);
 void   rl78_output_labelref (FILE *, const char *);
 intrl78_saddr_p (rtx x);
 intrl78_sfr_p (rtx x);
 void   rl78_output_aligned_common (FILE *, tree, const char *,
int, int, int);
+
+intrl78_one_far_p (rtx *operands, int num_operands);
Index: gcc/config/rl78/rl78-real.md
===
--- gcc/config/rl78/rl78-real.md(revision 231385)
+++ gcc/config/rl78/rl78-real.md(working copy)
@@ -586,25 +586,25 @@
(if_then_else (eq (and (reg:QI A_REG)
   (match_operand 0 "immediate_operand" "n"))
  (const_int 0))
  (label_ref (match_operand 1 "" ""))
  (pc)))]
   ""
-  "bf\tA.%B0, $%1"
+  "bt\tA.%B0, $1f\n\tbr !!%1\n\t1:"
   [(set (attr "update_Z") (const_string "clobber"))]
 )
 
 (define_insn "bt"
   [(set (pc)
(if_then_else (ne (and (reg:QI A_REG)
   (match_operand 0 "immediate_operand" "n"))
  (const_int 0))
  (label_ref (match_operand 1 "" ""))
  (pc)))]
   ""
-  "bt\tA.%B0, $%1"
+  "bf\tA.%B0, $1f\n\tbr !!%1\n\t1:"
   [(set (attr "update_Z") (const_string "clobber"))]
 )
 
 ;; NOTE: These peepholes are fragile.  They rely upon GCC generating
 ;; a specific sequence on insns, based upon examination of test code.
 ;; Improvements to GCC or using code other than the test code can result
Index: gcc/config/rl78/rl78-virt.md
===
--- gcc/config/rl78/rl78-virt.md(revision 231385)
+++ gcc/config/rl78/rl78-virt.md(working copy)
@@ -39,14 +39,14 @@
   "rl78_virt_insns_ok ()"
   "v.mov %0, %1"
   [(set_attr "valloc" "op1")]
 )
 
 (define_insn "*movqi_virt"
-  [(set (match_operand:QI 0 "nonimmediate_operand" "=vY,v,Wfr")
-   (match_operand1 "general_operand" "vInt8J,YWfr,vInt8J"))]
+  [(set (match_operand:QI 0 "nonimmediate_operand" "=vY,v,*Wfr,Y,*Wfr,*Wfr")
+   (match_operand1 "general_operand" 
"vInt8JY,*Wfr,vInt8J,*Wfr,Y,*Wfr"))]
   "rl78_virt_insns_ok ()"
   "v.mov %0, %1"
   [(set_attr "valloc" "op1")]
 )
 
 (define_insn "*movhi_virt_mm"
@@ -55,33 +55,33 @@
   "rl78_virt_insns_ok ()"
   "v.movw %0, %1"
   [(set_attr "valloc" "op1")]
 )
 
 (define_insn "*movhi_virt"
-  [(set (match_operand:HI 0 "nonimmediate_operand" "=vS,  Y,   v,   Wfr")
-   (match_operand:HI 1 "general_operand"  "viYS, viS, Wfr, vi"))]
+  [(set (match_operand:HI 0 "nonimmediate_operand" "=vS,  Y,   v,   *Wfr")
+   (match_operand:HI 1 "general_operand"  "viYS, viS, *Wfr, vi"))]
   "rl78_virt_insns_ok ()"
   "v.movw %0, %1"
   [(set_attr "valloc" "op1")]
 )
 
 ;;-- Conversions 
 
 (define_insn "*zero_extendqihi2_virt"
-  [(set (match_operand:HI 0 "rl78_nonfar_nonimm_operand" "=vm")
-   (zero_extend:HI (match_operand:QI 1 "general_operand" "vim")))]
-  "rl78_virt_insns_ok ()"
+  [(set (match_operand:HI 0 "rl78_nonfar_nonimm_operand" 
"=vY,*Wfr")
+   (zero_extend:HI (match_operand:QI 1 "general_operand" "vim,viY")))]
+  

msp430: fix alignment in multiply

[DJ Delorie]

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)
+++ libgcc/config/msp430/lib2hw_mul.S   (working copy)
@@ -19,13 +19,13 @@
 ; a copy of the GCC Runtime Library Exception along with this program;
 ; see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
 ; <http://www.gnu.org/licenses/>.
 
 .macro start_func name
.pushsection .text.\name,"ax",@progbits
-   .align 2
+   .p2align 1
.global \name
.type \name , @function
 \name:
PUSH.W  sr  ; Save current interrupt state
DINT; Disable interrupts
NOP ; Account for latency

Re: [PATCH] ctype functions and signedness

[DJ Delorie]

> --- 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 ((unsigned char)*a++);
> +  c2 = (unsigned char) tolower ((unsigned char)*b++);
>  
>if (c1 == '=')
>  c1 = '\0';

Since the only use of a and b in this function are to pass to tolower,
changing the type of a and b to unsigned char (and updating the casts
where they're initialized) would make more sense.

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

[DJ Delorie]

> 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

[DJ Delorie]

> $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
  numerical limits work correctly.  You should not use
  this macro directly; instead, include the appropriate headers.

And the definition of BITS_PER_UNIT is more appropriate anyway:

  @item BITS_PER_UNIT
  The number of bits in an addressable storage unit (byte).  If you do
  not define this, the default is 8.

If a target had a sizeof(char) != 1, __CHAR_BIT__ and BITS_PER_UNIT
would be different, and IMHO BITS_PER_UNIT is the one we want to use
in the runtime, unless you're specifically talking about the "char"
type:

  cpp_define_formatted (pfile, "__CHAR_BIT__=%u",
TYPE_PRECISION (char_type_node));

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

[DJ Delorie]

> 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 0.
> * config/rl78/divmodsi.S: Update return register to r8.
> * config/rl78/divmodhi.S: Update return register to r8,r9.
>   Branch to main_loop_done_himode to pop registers before return.

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

[DJ Delorie]

 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 default) with the default if neither is provided, to be save
if g13?

As an optimization, gcc could test the interrupt function to see if it
has any multiplcation or call insns, and if not, don't bother with the
(determined to be unneeded) saves.

 +(define_insn movqi_from_mduc
 +  [(set (match_operand:QI 0 register_operand =a)
 +(unspec_volatile:QI [(match_operand:QI 1  )] UNS_BUILTIN_MDUC))]
 +  
 +  mov\t%0, !0xf00e8
 +)

You shouldn't need special move insns for these; they're regular
variables.  Just generate the RTL for the memory references (make sure
they're volatile) and use the standard movhi patterns.

Unspec patterns are typically used for unknown *opcodes*, not special
registers or memory locations.

 @@ -1273,6 +1280,7 @@
int i, fs;
rtx sp = gen_rtx_REG (HImode, STACK_POINTER_REGNUM);
rtx ax = gen_rtx_REG (HImode, AX_REG);
 +  rtx operand1;
int rb = 0;
 
if (rl78_is_naked_func ())
 @@ -1330,6 +1338,39 @@
F (emit_insn (gen_push (ax)));
  }
 
 +  /* Save MDUC register from interrupt routine.  */
 +  if (MUST_SAVE_MDUC_REGISTER)
 +{
 +  emit_insn (gen_movqi_from_mduc (gen_rtx_REG (QImode, A_REG),
 +  gen_rtx_UNSPEC_VOLATILE (QImode, gen_rtvec (1, operand1),
 +   UNS_BUILTIN_MDUC)));

You never set operand1 to anything.  Since you never use it, you don't
really need it in the patterns either (just put [(const_int 0)] in the
unspec).  (but better to use a regular movhi as described above).

 +as this makes the interrupt handlers faster. The target option -mg13

That last bit is not a complete sentence.

 This message contains information that may be privileged or
 confidential . . .

Reminder that such notices are inappropriate for public mailing lists.

Re: rx: remove some asserts

[DJ Delorie]

 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

[DJ Delorie]

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

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

[DJ Delorie]

   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
 ===
 RCS file: /cvs/cvsfiles/gnupro/gcc/config/rl78/rl78.c,v
 retrieving revision 1.12.6.15
 diff -u -3 -p -r1.12.6.15 rl78.c
 --- gcc/config/rl78/rl78.c29 Jul 2015 12:24:04 -  1.12.6.15
 +++ gcc/config/rl78/rl78.c30 Jul 2015 15:20:10 -
 @@ -4161,7 +4161,9 @@ static bool rl78_rtx_costs (rtx   x,
switch (code)
   {
   case MULT:
 -   if (RL78_MUL_G14)
 +   if (! speed)
 + * total = COSTS_N_INSNS (5);
 +   else if (RL78_MUL_G14)
   *total = COSTS_N_INSNS (14);
 else if (RL78_MUL_G13)
   *total = COSTS_N_INSNS (29);
 

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

[DJ Delorie]

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

[DJ Delorie]

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

Re: libstdc++: more __intN tweaks

[DJ Delorie]

  * 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!