Re: strub causing libgcc to fail to build on rl78-elf
Alexandre Oliva writes: > This looks like a latent bug in the port. I'm not surprised, that port was weird. > This was just a plain asm insn in strub.c: > > /* Make sure the stack overwrites are not optimized away. */ > asm ("" : : "m" (end[0])); > > whose constraint passes during reload, rl78_alloc_physical_registers > leaves it alone and clears virt_insns_ok, so when cprog_hardreg attempts > to extract constraints again, rl78_as_legitimate_address rejects r8 as > the address because virt insns are no longer ok. Some background: the "virtual" registers are memory-mapped registers that use a common addressing scheme to access non-mapped registers. When we convert from virtual to physical, we can map that reg to a physical reg, or we replace the reg with a mem, but then usually have to split up the insn. For this insn, "converting" should have mapped or reloaded r8 to a valid address register. I doubt we have a way to have two patterns for user asms like we do for, say, addhi3. I suspect that something in the virt->phys logic just doesn't know how to check for mem constraints in user asms. > I'm not at all familiar with this port, and I don't know what was > supposed to happen here, but ISTM that either physical registers should > be allocated for asms, or non-B0 regs should be accepted in asms. non-bank-zero registers aren't valid as real address registers, because in gcc's reality they *are* mems. The chip can bank switch them, but gcc doesn't (the interrupt handlers, being asm, can do so, which is why one bank is reserved for that).
Re: Update to GCC copyright assignment policy
"Maciej W. Rozycki" writes: > My interpretation of this would be for modifications rather than original > sources, so v3+ applies to unmodified sources (for obvious reasons, given > that the recipient of the sources is not a copyright holder), however as a > copyright holder I can release my modifications say under v4 or v4+. It > is unclear to me if the newer licence will then "stick" to the rest of the > sources, but I suspect it will. A copyright assignment made to FSF (or > another legal entity) prevents this complication from happening. I see two cases here: 1. You release a modified copy of gcc, your parts can be whatever you want, sure, as long as it's GPLv3 compatible. 2. You're contributing *to* gcc, in which case, I'd hope that any attempts to impose a different license would be rejected at the patch review step.
Re: Update to GCC copyright assignment policy
Paul Koning via Gcc writes: >> GCC's license is "GPL version 3 or later", so if there ever needed to be a >> GPL v4, we could move to it without needing permission from anyone. > > I don't think that is what the license says. It says: > > GCC is free software; you can redistribute it and/or modify > it under the terms of the GNU General Public License as published by > the Free Software Foundation; either version 3, or (at your option) > any later version. > > To me that means the recipient of the software can relicense it under > a later license. It doesn't say to me that the original distribution > can do so. I've never read it that way. To me it says "a recipient may redistribute it under terms of a newer license, but the license remains v3+ even if they do" - we're giving the recipient a choice of actions, but not power to relicense. I.e. a recipient is not permitted to relicense the code, ever. However, they may act as if it's licensed under a newer license. If they share the code, *that* recipient gets to make the same choice - v3 or newer. So if the original copyright holder can't change the license, nobody can.
Re: [PATCH] Fix DJGPP LTO with debug
Richard Biener writes: > DJ, did you ever run the testsuite with a configuration that has LTO > enabled? I don't see any djgpp results posted to gcc-testresults. > Quick googling doesn't yield anything useful with regarding on how to > do actual testing with a cross so I only built a 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...
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
That's fine too, I was thinking of checking mcu_name[i] against NUL. Any of those solutions would work :-)
Re: [PATCH] [MSP430] Fix device name symbol defined for MSP430i series of devices
Jozef Lawrynowicz writes: > - for (i = start_upper; i < strlen (mcu_name); i++) > + for (i = start_upper; i < strlen (mcu_name) - 2; i++) Might be faster to test mcu_name[i] instead of calling strlen repeatedly too, but this only runs once per invocation ;-)
Re: [PATCH] [MSP430] Fix device name symbol defined for MSP430i series of devices
> + snprintf (mcu_name, sizeof (mcu_name) - 1, "__%s__", target_mcu); > + start_upper = 0; Can optimize this to 2 :-) Otherwise OK.
Re: [PATCH] [MSP430] Fix device name symbol defined for MSP430i series of devices
Jozef Lawrynowicz writes: > Word from TI is that the lowercase i is an exception, the rule is to have all > uppercase letters. No further msp430i devices are planned so the rules for > generating device names in this patch shouldn't need any future changes. So a future-proof patch would 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
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
Jozef Lawrynowicz writes: > + if (strncmp (target_mcu, "msp430i", 7) == 0) > + snprintf (mcu_name, sizeof (mcu_name) - 1, "__MSP430i%s__", > + target_mcu + 7); > + else Do you need to TOUPPER the parts of target_mcu after char 7 ?
Re: [PATCH] [MSP430] Allow interrupt handers to be static and fix __interrupt__ attribute causing an ICE
Jozef Lawrynowicz writes: > If an argument is passed to the interrupt attribute, GCC will create a section > for the interrupt vector when outputting the assembly. This, combined with the > code to ensure the interrupt function doesn't get optimized out, ensures the > symbol for the interrupt 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
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
Alexander Monakovwrites: > 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
The testsuite parts are OK with me, but the tree.c change needs separate approval...
Re: [PATCH] Use dlsym to check if libdl is needed for plugin
"H.J. Lu"writes: > config/ > > * plugins.m4 (AC_PLUGINS): Use dlsym to check if libdl is needed. This is OK.
Re: [PATCH] RL78 one_cmplhi2 improvement
"Sebastian Perta"writes: > Is this similar to what you had in mind? Yes. Did it affect code size in any of the larger tests? I was hoping that it wouldn't force too much into 8-bit registers and cause more moves to be needed elsewhere. (and even if it didn't, I 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
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
This is OK. In the future, please include the Changelog entry as a separate text, not part of the patch, as it will rarely apply cleanly. "Sebastian Perta"writes: > > * config/rl78/rl78.md (movdf): New define expand.
Re: [PATCH] RL78 new "vector" function attribute
"Sebastian Perta"writes: >>>Looks OK to me, but wait a day or two for a docs person to comment on... > 6 days no comments so far, can I check in now? Yup, go ahead. >>>if the new line is too long > There are many other lines which have the same length or are even 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
The msp43-specific parts look OK to me, but obviously they're kinda useless without the core changes :-)
Re: [PATCH] RL78 new "vector" function attribute
Sebastian Pertawrites: > 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
If the RX and RL78 now share interrupt/vector semantics, can we combine the docs? I.e. instead of a new section for RL78, can we change the RX section to say something like "For RX and RL78..." ?
Re: [PATCH] RL78 addsi3 improvement
This is OK. I wonder if these types of optimizations should be added to the assembler too? At least, if relaxation is enabled...
Re: [PATCH] rl78 anddi3 improvement
Jeff Lawwrites: > 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
"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
Sebastian Pertawrites: > * 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
Eli Zaretskiiwrites: > 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
Well, it should all work fine as long as the xcoff64 file is less than 4 Gb. And it's not the host's bit size that counts; there are usually ways to get 64-bit file operations on 32-bit hosts.
Re: Compilation warning in simple-object-xcoff.c
I think that warning is valid - the host has a 32-bit limit to file sizes (off_t) but it's trying to read a 64-bit offset (in that clause). It's warning you that you won't be able to handle files as large as the field implies. Can we hide the warning? Probably. Should we? Debatable, as long 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: Status of m32c target?
Jeff Lawwrites: > A change in reload back in 2016 (IIRC) has effectively made m32c > unusable. The limits of the register file create horrible problems for > reload. > > I was going to suggest deprecation for gcc-8 given how badly it was > broken in gcc-7 and the lack of maintenance on the target. I gave this another shot Friday, I was thinking maybe we could retire the m32cm cpu and keep the r8c cpu, since the M32C family is essentially dead part-wise but there are still new R8C chips being made. The reload problems for r8c are still there, but I also discovered a bug in the m32cm cpu that might be generic... Are there any other targets that push large structures on the call stack via memcpy? I'm seeing failures due to mis-calculating stack adjustments in that case. $ m32c-elf-gcc -c -mcpu=m32cm -O3 dj.c typedef struct { void *a, *b, *c, *d; void *e, *f, *g; } cookie_io_functions_t; void *_impure_ptr; void * _fopencookie_r (void *ptr, void *cookie, const char *mode, cookie_io_functions_t functions); void * fopencookie ( void *cookie , const char *mode , cookie_io_functions_t functions) { return _fopencookie_r ( _impure_ptr , cookie, mode, functions); } dj.c: In function ‘fopencookie’: dj.c:16:10: internal compiler error: in expand_call, at calls.c:4426 return _fopencookie_r ( _impure_ptr , cookie, mode, functions); ^~~ printf("%x %x, %d %d %d\n", flags, ECF_NORETURN, old_stack_allocated, stack_pointer_delta, pending_stack_adjust); /* Verify that we've deallocated all the stack we used. */ gcc_assert ((flags & ECF_NORETURN) || (old_stack_allocated == stack_pointer_delta - pending_stack_adjust)); IIRC when this happens, "stack_pointer_delta" doesn't account for the size of the large-structure-argument - it has all the push'd args, but not the memcpy'd one. I.e. that printf I added prints this: 0 8, 0 12 40
Re: [PATCH] RL78 UNUSED note setting bug fix in rl78_note_reg_set
"Sebastian Perta"writes: > Please let me know if this is OK. Thank you! Do you have checkin privs yet? This is ok aside from.. > + /* 'dead' keeps track of the QImode registers if r is of different size > + we need to check the other subparts as well */ 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: Status of m32c target?
Jeff Lawwrites: > I was going to suggest deprecation for gcc-8 given how badly it was > broken in gcc-7 and the lack of maintenance on the target. As much as I use the m32c target, I have to agree. I've tried many times to fix its reload problems to no avail, and just don't have time to work on gcc ports much any more.
Re: [PATCH] RL78 movdi improvement
I saw one regression with this patch: PASS-FAIL: gcc.dg/torture/vshuf-v8qi.c -O2 execution test Could you confirm this? Note: I'm testing with your other (pre-2018 at least) patches applied at the same time (smax etc, anddi, bswaphi) so it might be an interaction, but the code looks like a movdi bug. The other patches look OK otherwise.
Re: [PATCH] rl78 anddi3 improvement
Right, when doing 64-bit operations on an 8-bit mcu with limited registers, a hand-written assembler routine that you call as needed will beat anything gcc spits out - for size-per-call. And I had a lot of trouble getting gcc to deal with the rl78's limited register set and addressing modes - 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: targetm.calls.promote_prototypes parameter
Jason Merrillwrites: > I'm inclined to change the C++ FE to pass NULL_TREE instead until such > time as someone cares. The sh backend will at least not choke on that ;-)
Re: targetm.calls.promote_prototypes parameter
In my original proposal, I said this: > It includes a bunch of macro->hook conversions, mostly because the > hooks need an additional parameter (the function) to detect which ones > are Renesas ABI and which are GCC ABI. The original documentation at least hinted that the parameter was a function type: > @deftypefn {Target Hook} bool TARGET_PROMOTE_PROTOTYPES (tree @var{fntype}) Kazu's calls are in the C++ stuff, I don't know if g++ and Renesas C++ are compatible anyway (I doubt it), but that's what would be affected. The original work was for C compatibility.
Re: [RFTesting] New POINTER_DIFF_EXPR
Richard Bienerwrites: > 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
Committed. Thanks! Note: your diff program isn't producing valid diffs... * it's dropping leading tabs * it's not putting a space after file names in the headers I have to manually fix these to apply the patch; if you could fix it on your end that would be appreciated :-)
Re: [PATCH] PR target/82624 msp430-elf target must allow for NULL pointer dereferences
Thanks for your patch; I applied it with some minor changes. Please note that you don't need to submit patches to generated files (*.1 and *.info), that patches are customarily made against the development tree not a released tarball (which is probably why you thought you had to patch the 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
Sebastian Pertawrites: > Please let me know if this is OK, Thank you! Sorry for the delay, it's OK and I committed it for you with a few minor changes to make it work with today's tree. Thanks!
Re: [PATCH] [MSP430] [PR80993] Prevent lto removing interrupt handlers
Richard Bienerwrites: > 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
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: [Bug target/78804] [RX] -m64bit-doubles does not work
"olegendo at gcc dot gnu.org"writes: > I don't know why it was decided to use this ABI. Maybe some legacy > stuff. Compatibility with Renesas's compiler.
Re: [PATCH,AIX] Enable libiberty to read AIX XCOFF
"REIX, Tony"writes: > It appears that XNEWVEC() calls xmalloc which prints a message and > calls xexit if malloc fails. Objection removed then ;-) > So, yes, we check if (strtab == NULL) though there is no way that > XDELETEVEC(NULL) breaks something. However, it is a classic > programming style. Yup, I noted that. Just mentioning the inconsistency.
Re: [PATCH,AIX] Enable libiberty to read AIX XCOFF
David Edelsohnwrites: > 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
Eli Zaretskiiwrites: > Seems to work fine, thanks. Checked into gcc trunk then :-)
Re: MinGW compilation warnings in libiberty's xstrndup.c
Please try this patch: Index: config.in === --- config.in (revision 248482) +++ config.in (working copy) @@ -76,12 +76,16 @@ #undef HAVE_DECL_SBRK /* Define to 1 if you have the declaration of `snprintf', and to 0 if you 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
Joel Brobeckerwrites: > 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
Thanks. Committed!
Re: MinGW compilation warnings in libiberty's waitpid.c
Eli Zaretskiiwrites: >> What about mingw64? > > It will be covered as well, because it defines __MINGW32__, Ah, OK. > Is there anything else I need to do about this part to get it solved > in the upstream repository? A ChangeLog entry would be nice, so I don't have to write one ;-)
Re: MinGW compilation warnings in libiberty's waitpid.c
Eli Zaretskiiwrites: > 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
Eli Zaretskiiwrites: > 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
Eli Zaretskiiwrites: > 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
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
Pedro Alveswrites: > 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
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
Pedro Alveswrites: > 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
Right, I meant, libiberty's configure, gcc's configure, binutils' configure, and gdb's configure, all need to agree on whether strnlen is a HAVE or a HAVE_DECL type symbol. If they don't, the header can't provide "one" working solution.
Re: MinGW compilation warnings in libiberty's xstrndup.c
Eli Zaretskiiwrites: > 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
Joe Seymourwrites: >> 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
Committed. Thanks!
Re: [PATCH 1/2] [msp430] Remove source files from libmul archives
Committed. Thanks!
Re: [PATCH] [msp430] Sync msp430_mcu_data with devices.csv
Committed for you, thanks!
Re: Why are GCC Internals not Specification Driven ?
Seima Raowrites: > Has gcc become proprietory/commercial ? By definition: no, yes. It's been this way since the beginning, and hasn't changed in decades. > Or has it become illegal to publish specification models > of gcc internals ? Does this make the product sell less ? This sounds like you're trying to start an argument, instead of asking a simple question. It is certainly not illegal to publish our specifications, and we certainly *do* publish many of our specifications (have you read the internals manual? You don't say whether or not you did, but that would be a key bit of information to have disclosed). Whether the product "sells" or not is rarely a driving factor for our project. Most of us work on it because we need it to work better for our own purposes. If you have specific questions about our documentation or development process, please ask them. Please do not ask vague, leading, and emotionally loaded questions. RTL and Gimple are documented. Are they documemented well? That depends on your needs. Are they documented as well as they could be? Probably not, but good enough for us so far. And as always, if you want to improve the situation, by all means feel free to volunteer to do so ;-)
[patch] libiberty/78584
While the root solution for the bug is "don't do that", we should at least try to detect the obviously wrong case more gracefully. Committed. * argv.c (expandargv): Check for directories passed as @-files. Index: argv.c === --- 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
Jason Merrillwrites: > 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
Florian Weimerwrites: > 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
Ozkan Sezerwrites: > 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
Eli Zaretskiiwrites: >> 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
Eli Zaretskiiwrites: > 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
Most of the files in include/ are GPL, not LGPL. Why is this one different?
Re: [PATCH][Libiberty] Support empty arguments in pex-win32
This is OK. Thanks!
Re: [PATCH][msp430] Don't output __interrupt_vector sections for weak functions
Approved and committed. Thanks! Sorry for the delay, I was away for the holiday weekend and it slipped through the cracks when I returned.
Re: [Bug target/77570] New: [msp430-elf] Wrong assembly in delay_cycles_32x insn declaration
Patch applied as per bug report... 2016-09-12 Orlando AriasPR 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
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
ayush goelwrites: > 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: [GCC Steering Committee attention] [PING] [PING] [PING] libgomp: In OpenACC testing, cycle though $offload_targets, and by default only build for the offload target that we're actually going to te
Manuel Lpez-Ibñezwrites: > Another question is how to help existing maintainers such that they > are more motivated to review patches. Is it a lack of time? lack of > Interest in the project? do patches simply fall through the cracks? is > it a dead-lock of people waiting for each other to comment? In my case, I became a build/libiberty maintainer a long time ago (20 years or so), when DJGPP was a much more active project, and it made sense for me to be involved in parts of GCC that were sensitve to the needs of DOS and NTFS filesystems and OSs. This is not the case any more, and my justification for maintaining those parts of gcc have evaporated. Fortunately, a very minimal effort was involved to continue. However, since then, I've not only taken on maintainerships in other areas (mostly backends, which I need to wean off of eventually) but I've also switched groups at work, and am no longer focused on gcc (I'm focused on glibc now). Also, I've always been opposed to libiberty being a "catch-all" for cross-useful functionality, so I'm anti-motivated to work on those portions of libiberty that aren't strictly portability-layer-related (specifically, the demangler, which I leave to Ian). So... considering your big-picture-problem, where do I fit in? How can I make the big picture better, given what you now know about my situtation? What changes do you think would make sense?
Re: [GCC Steering Committee attention] [PING] [PING] [PING] libgomp: In OpenACC testing, cycle though $offload_targets, and by default only build for the offload target that we're actually going to te
Manuel Lpez-Ibñezwrites: > I don't see how that helps. Neither my message nor Thomas's is a > criticism of people. The question is how to get more people to help > and how to improve the situation. For sure, everybody is doing the > best that they can with the time that they have. You complained that there were no libiberty maintainers (there are two) or build maintainers (there are many). As I am listed as one of each of those, this makes me wonder if there's no longer a need for such people (we're involved so infrequently that nobody notices) or that I'm just not able to put enough effort into it to be noticed (which may be true anyway). Either way, this is a part of your "problem" that I can address directly, so I'm doing so. > This is a problem throughout GCC. We have a single C++ maintainer, a > single part-time C maintainer, none? for libiberty, no regular > maintainer for build machinery, and so on and so forth.
Re: [GCC Steering Committee attention] [PING] [PING] [PING] libgomp: In OpenACC testing, cycle though $offload_targets, and by default only build for the offload target that we're actually going to te
Manuel Lpez-Ibñezwrites: > none? for libiberty, no regular maintainer for build machinery, Perhaps this is a sign that I should step down as maintainers for those?
Re: [PATCH 1/4][Ada,DJGPP] Ada support for DJGPP
> Frankly at this stage, I do not think it makes sense to maintain an > Ada port for DJGPP and in particular maintain all these extra > special cases and #ifdefs. I don't think this is a reasonable attitude to take with people who are willing to do the work to do it. Frankly, I'd like to take 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.
Re: gcc/libcpp: non-UTF-8 source or execution encodings?
David Edelsohnwrites: > GCC on the system is not self-hosting -- I believe that GCC only is > used as a cross-compiler. I can confirm this - GCC for TPF is always a cross compiler, it never runs *on* a TPF system.
Re: Deprecating basic asm in a function - What now?
Given how many embedded ports have #defines in external packages for basic asms for instructions such as nop, enable/disable interrupts, other system-level opcodes, etc... I think this is a bad idea. Even glibc would break. #define enable() asm("eint") __asm__ __volatile__ ("fwait");
[target/71338]: enable mulu for RL78/G10
Reverts https://gcc.gnu.org/ml/gcc-patches/2014-08/msg01538.html - G10 supports MULU but not other multiplication methods. Committed. PR target/71338 * config/rl78/rl78-expand.c (umulqihi3): Enable for G10. * config/rl78/rl78-virtual.c (umulhi3_shift_virt): Likewise. (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
David Malcolmwrites: > gcc/ChangeLog: > * config/rl78/rl78.c (rl78_expand_prologue): Convert local > from int to unsigned. Ok. I'm going to note that the corresponding loop in the epilogue also uses signed, but in that case, it must.
Re: libiberty: Don't needlessly clear xmemdup allocated memory
Ok then. Thanks!
Re: libiberty: Don't needlessly clear xmemdup allocated memory
Alan Modrawrites: > * 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
Kaushik Phatakwrites: > 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
> 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: 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 be deprecated in GCC 6 and removed in 7. MeP is now deprecated.
Re: RFA: MEP: Add newlib-stdint.h to tm_file.
> Looks good to me. Obviously you'll need appropriate ChangeLogs. OK > with the ChangeLogs added. Done.
Re: RFA: MEP: Add newlib-stdint.h to tm_file.
> Write a patch to deprecate it in config.gcc (search for openbsd2 to help > you find the right spot) and an update to the gcc6 webpage. How's this? Index: htdocs/gcc-6/changes.html === RCS file: /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.
> Can we make that official? 64402, 49401 & 24998 go away when MEP is > deprecated. We can, what's the next step? I announced intent in Dec, nobody commented or stepped up to take it.
Re: RFA: MEP: Add newlib-stdint.h to tm_file.
Note, though, that I'm in the process of deprecating mep...
Re: RFA: MEP: Add newlib-stdint.h to tm_file.
Ok.
who owns stack args?
Consider this example (derived from gcc.c-torture/execute/920726-1.c): extern int a(int a, int b, int c, int d, int e, int f, const char *s1, const char *s2) __attribute__((pure)); int foo() { if (a(0,0,0,0,0,0,"abc","def") || a(0,0,0,0,0,0,"abc","ghi")) return 0; return 1; } On rl78-elf I'm seeing a bug that only happens if a() is declared "pure". When the bug triggers, the address of "abc" in the second call is *not* written to the stack. Instead, the move is deleted by DCE in postreload. It's not deleted if you remove the "pure". The bug was exposed when strcmp() became able to increment incoming stack arguments in-place, instead of copying them to registers. The example was intended to reproduce the bug on intel or arm, but it doesn't. If there's an obvious fix for this, I'm all ears, but... The real question is: are stack arguments call-clobbered or call-preserved? Does the answer depend on the "pure" attribute?
msp430: fix function type declarations
Minor bug, fixed, committed. * config/msp430/msp430.c (msp430_start_function): Add function type. 2016-02-04 Uros BizjakIndex: 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
> I posted last version of patch where I took review comments into account > month ago: > > https://gcc.gnu.org/ml/gcc-patches/2015-12/msg01328.html I'm OK with this version.
Re: [doc, committed] document RL78 saddr attribute
> I've checked in this patch to add some minimal documentation for the > RL78 "saddr" variable attribute. That's pretty much all there is to say about the saddr attribute, too.
Re: [PATCH 6/6] [DJGPP] configure.ac: enable LTO
> You can list me as your sponsor. I've been wanting him to be a djgpp target/host maintainer for years anyway, so +1 from me :-)