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-ms
t Jim Wilson
iq2000 portNick Clifton
lm32 port Sebastien Bourdeauducq
-m32c port DJ Delorie
m32r port Nick Clifton
m68k port (?) Jeff Law
m68k port Andre
That's fine too, I was thinking of checking mcu_name[i] against NUL.
Any of those solutions would work :-)
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 ;-)
> + snprintf (mcu_name, sizeof (mcu_name) - 1, "__%s__", target_mcu);
> + start_upper = 0;
Can optimize this to 2 :-)
Otherwise OK.
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
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-
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 ?
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 func
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 tab
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
The testsuite parts are OK with me, but the tree.c change needs
separate approval...
"H.J. Lu" writes:
> config/
>
> * plugins.m4 (AC_PLUGINS): Use dlsym to check if libdl is needed.
This is OK.
"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 corr
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
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.
"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 a
The msp43-specific parts look OK to me, but obviously they're kinda
useless without the core changes :-)
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
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..." ?
This is OK.
I wonder if these types of optimizations should be added to the
assembler too? At least, if relaxation is enabled...
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
SIm
"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:
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
> ==
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
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.
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
"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 sent
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 m
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 - com
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 ex
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 :-)
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 generat
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!
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 f
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/
"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 st
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.
Eli Zaretskii writes:
> Seems to work fine, thanks.
Checked into gcc trunk then :-)
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
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 wou
Thanks. Committed!
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 ;-)
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/wa
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 t
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
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
+
+ * configu
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
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
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 decl
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.
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 jus
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++
Committed. Thanks!
Committed. Thanks!
Committed for you, thanks!
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
===
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?
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
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/msg02
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
filen
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?
Most of the files in include/ are GPL, not LGPL. Why is this one
different?
This is OK. Thanks!
Approved and committed. Thanks! Sorry for the delay, I was away for
the holiday weekend and it slipped through the cracks when I returned.
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 (revisi
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 erro
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.
> 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 Ad
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.
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.
Ok then. Thanks!
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?
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.
>
> 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 macr
> Looks good to me. Obviously you'll need appropriate ChangeLogs. OK
> with the ChangeLogs added.
Done.
> 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/chang
> 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.
Note, though, that I'm in the process of deprecating mep...
Ok.
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/msp
> 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.
> 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.
> 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 :-)
> 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.
I'm OK with the msp430 part :-)
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 overflow
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.
Minor fix, committed.
2015-11-19 DJ Delorie
* 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
> --- 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 ((unsig
> libiberty/ChangeLog:
>
> * configure.ac: Set AC_CV_FUNC_GETPAGESIZE to "yes" on
> Android hosts.
> * configure: Regenerate.
>
> OK to apply?
Ok.
> $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
num
> 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/divmods
> 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.
This is OK.
> 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 d
> 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.
I have applied and committed these patches, both in gcc and binutils-gdb.
> OK to apply ?
Ok. Thanks!
> gcc/ChangeLog
> 2015-08-05 Nick Clifton
>
> * config/rl78/rl78.c (rl78_rtx_costs): Treat MULT insns as cheap
> if optimizing for size.
>
> Index: gcc/config/rl78/rl78.c
> ===
> RCS f
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.
Ok, but please don't put non-public issue numbers in the comments.
1 - 100 of 581 matches
Mail list logo