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,
"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
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
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
iq2000 portNick Clifton
lm32 port Sebastien Bourdeauducq
-m32c port DJ Delorie
m32r port Nick Clifton
m68k port (?) Jeff Law
m68k port Andreas Schwab
m68k
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
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
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
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
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
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
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
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
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
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
"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".
>
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:
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
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
Jeff Law writes:
> 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
"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 */
Jeff Law writes:
> 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
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
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 -
Jason Merrill writes:
> 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 ;-)
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
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
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
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
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.
> *
"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.
"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
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
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
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
>
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
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
>
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
+
+
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
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,
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
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
Committed. Thanks!
Committed. Thanks!
Committed for you, thanks!
Seima Rao writes:
> 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
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
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
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:
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
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,
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
===
---
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
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.
Manuel Lpez-Ibñez writes:
> 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
Manuel Lpez-Ibñez writes:
> 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
Manuel Lpez-Ibñez writes:
> none? for libiberty, no regular maintainer for build machinery,
Perhaps this is a sign that I should step down as maintainers for those?
> 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
David Edelsohn writes:
> 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.
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");
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
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
> 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
> 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
> 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:
> 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.
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
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
> 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 :-)
1 - 100 of 1257 matches
Mail list logo