Symbols are normally PSImode, and the MSP430 has PSImode registers and
PSImode moves to reg/mem. But sometimes gcc uses an SImode move
instead, if the result will later be used in SImode (as in getP() in
gcc/testsuite/gcc.dg/torture/pr65077.c). Committed.
* config/msp430/msp430.md (movs
Have you compared the latency of the multiply instructions to the
overhead of saving those registers in the interrupt handler? What
about the case where performance is priority, and the developer knows
that the interrupt handlers don't use the multiply registers?
Also, your code doesn't properly
IBM made changes to no longer require 2 versions of libstdc++, so this
patch changes things back to the previous (compatible) way.
Also, TPF debuggers don't support discriminators, despite what GAS
supports, so disable them.
Ok?
* config/s390/tpf.h (LIBSTDCXX): Change to CPP1.
(
On targets with 2 byte "int" the vectors are 16 values long, which
breaks the index count in __builtin_shuffle() using more than one
input vector. Ok?
* gcc.dg/pr64252.c: Fix assumption about sizeof(int).
2015-06-05 Thomas Koenig
Index: gcc.dg/pr64252.c
=
Because sizeof(void*) is 4 but POINTER_SIZE is 3, we have to handle
some things manually. This is yet another one. Committed.
* config/msp430/msp430.c (msp430_asm_integer): Support addition
and subtraction too.
Index: config/msp430/msp430.c
=
Sorry, I meant unsigned int.
> OK to apply ?
Ok, but...
> - if (regno == FRAME_POINTER_REGNUM && frame_pointer_needed)
> + if (regno == FRAME_POINTER_REGNUM
> + && (frame_pointer_needed || df_regs_ever_live_p (regno)))
Do we want regs_ever_live or regs_ever_written_to ? I seem to recall
changing a port... mep per
> ; This pattern is identical to the truncsipsi2 pattern except
> ; that it uses a SUBREG instead of a TRUNC. It is needed in
> ; order to prevent reload from converting (set:SI (SUBREG:PSI (SI)))
> ; into (SET:PSI (PSI)).
>
> I'm not sure what that's supposed to mean (what's an SI set of a PSI
> * mkstemps.c: #include if HAVE_TIME_H is defined
> but not HAVE_SYS_TIME_H.
Ok.
> What I was confused about is that the first set isn't valid rtl.
> The SET_SRC and SET_DEST always have to have the same mode
> (or VOIDmode in the case of a CONST_INT, etc., where the mode
> is implicitly the same as the SET_DEST). So wouldn't it have
> to be:
>
> (set (reg:SI 1)
>(
My memories of why I did MeP the way I did are... vague. I recall it
had to do with getting the attributes to apply to C++ objects
correctly, since C++ objects tend to be "complicated" and gcc didn't
always pass me what I expected.
> think they are suppose to. They build, but I cant test them.
SFmode moves were using 8-bit transfers instead of 16-bit. This patch
copies the SImode move pattern, which expands into 16-bit moves.
Since this only affects rl78, and the SImode code is well tested, I'm
applying this now so it will be in gcc 5.
* config/rl78/rl78-protos.h (rl78_split_
> OK to apply ?
Ok.
> The problem appears to be that GCC will create a multiply-plus-add
> instruction to access the table regardless of whether the backend
> supports such an instruction. I could not work out where in the
> middle end this was occurring, so instead I created the patch below
> which contai
More edge cases regarding far addresses. Committed.
* config/rl78/rl78-real.md (*addqi_real): Allow SADDR types for
inc/dec.
(*addhi3_real): Likewise.
* config/rl78/rl78-virt.md (*inc3_virt): Additional
pattern to match incrementing memory.
* confi
Committed.
* config/rl78/rl78-virt.md (andqi3_virt): Allow far operands.
(iorqi3_virt): Likewise.
Index: config/rl78/rl78-virt.md
===
--- config/rl78/rl78-virt.md(revision 221505)
+++ config/rl78/rl78-virt.md
Mis-applied patch, committed.
* config/rl78/rl78.c (rl78_print_operand_1): Move 'p' test to
correct clause.
Index: config/rl78/rl78.c
===
--- config/rl78/rl78.c (revision 221648)
+++ config/rl78/rl78.c (working cop
> Is this ok for trunk now?
Yes.
> OK to apply ?
Ok!
> 2015-04-14 Nick Clifton
>
> * config/rl78/rl78.c (rl78_expand_prologue): Mark large stack
> decrement instruction as being frame related.
> (rl78_print_operand_1): Handle 'p' modifier to add +0 to HL
> based addresses.
> If zero extendi
> OK to apply ?
Ok.
> gcc/ChangeLog
> 2015-04-15 Nick Clifton
>
> * config/rl78/rl78-opts.h (enum rl78_mul_types): Add MUL_G14 and
> MUL_UNINIT.
> (enum rl78_cpu_type): New.
> * config/rl78/rl78-virt.md (attr valloc): Add divhi and divsi.
> (umulhi3_shift_virt
Ok. Thanks!
The testcase for pr 66345 assumes size_t is "unsigned long" instead of
using the real type, which causes failures on some 16-bit targets.
Ok?
Also, I note that some tests check for __SIZE_TYPE__ as I do below,
and others use it unconditionally as a replacement for size_t. Is
there a convention?
This was missed in the big intN patch set I did last year; it only
shows up if you have a target with an N-bit type that isn't also used
for a pointer type but is used for unwinding (which is a change I also
have pending, hence I noticed ;). Tested on x86-64 and msp430 (with
the pending patch) wi
Thanks! Committed.
> This is the first in a series of patches to make a build with an in-tree
> GNU libiconv work as designed.
>
> This patch fixes dependencies for parallel make, and avoids failures
> with make targets not supported by GNU libiconv.
This is OK. Thanks!
> Thanks. I don't have write access, could a toplevel maintainer please
> commit?
Which repos do you not have access to? Also, did you address Jeff's
comment?
> How was this patch tested? I don't see anything glaringly wrong, but
> stranger things have happened.
>
> I think just a bootstrap
> OK.
Thanks, committed.
> But don't we need to support the older system (with 2 libstdc++s) and
> the newer system (just one libstdc++)? Which implies these changes need
> to be conditional, right?
The CPP2 configuration was never shipped to TPF customers, so there's
no need to retain both ways.
> Ah, then approved.
Thanks, committed.
Ping?
https://gcc.gnu.org/ml/gcc-patches/2015-06/msg00149.html
> This patch updates gthr-tpf.h to the current gthr.h API and TPF API. Ok?
>
> * gthr-tpf.h (__GTHREADS_CXX0X): Define.
> (__gthread_t): Define.
> (__gthread_cond_t): Define.
> (__gthread_time_t): Define.
>
> Version 2 of the patch to enable the configure options
> --with-arch=native and --with-tune=native.
This patch broke cross-compiling with --target=s390-*
s390_host_detect_local_cpu is only defined if the --host is s390-*
but EXTRA_SPEC_FUNCTIONS refers to it when --target is s390-*
> Sorry about that. Does the attached Patch fix the problem?
Yup. Thanks!
> Thanks. Do I need to hear from someone else approving this, or can I
> go ahead and commit?
Go ahead and commit.
Various RL78-specific fixes and tweaks wrt volatiles and addressing
modes. Committed.
* config/rl78/rl78-real.md (addqi3_real): Allow volatiles.
(addhi3_real): Likewise. Fix [HL+0] syntax.
(subqi3_real): Likewise.
(subhi3_real): Likewise.
(cbranchqi4_real
> Here is a small patch to fix a code-gen problem for the RL78. The bug
> was that the register death pass was not looking inside PARALLELs, and
> thus missing some USE and SET cases. I considered adding code to scan
> all of the elements in the PARALLEL, but the only ones that can be
>
OK for trunk.
OK for 4.9 branch if it's OK with the release manager.
Do you need someone to apply it for you?
> I just did not post this patch earlier, because I do not have an
> environment to test the generated code on a m32c device.
You wouldn't want to wait for the results on a real device. Use the
simulator that's included with gdb for testing.
> OK to apply ?
Ok.
> OK to apply ?
Ok.
See $subj. Committed.
* config/rl78/rl78.c (move_elim_pass): Don't optimize away
volatile memory references.
Index: config/rl78/rl78.c
===
--- config/rl78/rl78.c (revision 220150)
+++ config/rl78/rl78.c (working c
#pragma diagnostic
push/pop wasn't added until a later release (4.6 I think). Attempts
to build with 4.4 (i.e. on RHEL 6) causes warnings on most files.
2010-06-21 DJ Delorie
* diagnostic.h (diagnostic_classification_change_t): New.
(diagnostic_
> Does the patch look sane?
I don't think anything in the toplevel configury looks "sane" any
more, but I think this patch is OK.
> memcpy (*argvp + i, file_argv, file_argc * sizeof (char *));
This code copies all the pointers in file_argv[] into argv[], so if
you freeargv them via file_argv, argv[] will point to free'd memory.
Hence the comment:
> /* Free up memory allocated to process the response file. We do
I can't say if this fixes a bug important enough for stage4, but if
someone wants to claim that, you won't have to wait for stage 1 :-)
Ok.
The m32c parts are OK.
The branch limits are a bit too far, resulting in reloc errors in rare
cases. Ok?
* config/v850/v850.md (branch_normal): Adjust branch limits.
(branch_invert): Likewise.
(branch_z_normal): Likewise.
(branch_z_invert): Likewise.
(branch_nz_normal): Likewise
on
rx-elf, x86 32/64, and arm32.
2014-10-29 DJ Delorie
* expmed.c (strict_volatile_bitfield_p): Fix off-by-one error.
2014-10-29 DJ Delorie
* gcc.dg/20141029-1.c: New.
Index: expmed.c
===
--- expmed.c
> Ok. For the branch please wait until after 4.9.2 is out.
Thanks! Committed to trunk.
> Ok. For the branch please wait until after 4.9.2 is out.
4.9.2 being out, I applied this to the branch.
Fixes newlib/libgcc build problems, many test cases. No regressions.
Applied.
* config/m32c/cond.md (movqicc__): Remove mode of
conditional.
(movhicc__): Likewise.
* config/m32c/m32c.c (encode_pattern_1): Specialise PSImode
subregs.
(m32c_eh_return
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.
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
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?
Ok then. Thanks!
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.
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.
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!
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
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 :-)
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/
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
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
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.
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
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:
> 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
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
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
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:
> 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:
>> 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 ;-)
Thanks. Committed!
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
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
Eli Zaretskii writes:
> Seems to work fine, thanks.
Checked into gcc trunk then :-)
Committed for you, thanks!
Committed. Thanks!
Committed. Thanks!
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++
> 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
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.
>
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
Approved and committed. Thanks! Sorry for the delay, I was away for
the holiday weekend and it slipped through the cracks when I returned.
This is OK. Thanks!
Most of the files in include/ are GPL, not LGPL. Why is this one
different?
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?
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
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
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
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?
> 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
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
===
I have applied and committed these patches, both in gcc and binutils-gdb.
> 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 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
> 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.
> 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'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.
> 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.
201 - 300 of 581 matches
Mail list logo
