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
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
The libiberty parts are OK. The only drawback I can imagine is if
someone outside our source trees has used these, and installed a
shared library, and replaced it with this new one... but that's not
our problem, since we don't support that.
> include/
> * floatformat.h (floatformat_ibm_lon
so... can I get an official "ok to commit with you and Nick as maintainers"
then?
Needed to build i586-pc-msdosdjgpp target, committed.
* config/i386/djgpp.h (ASM_DECLARE_FUNCTION_NAME): New.
Index: config/i386/djgpp.h
===
--- config/i386/djgpp.h (revision 202015)
+++ config/i386/djgpp.h (working copy)
@@
In all the real-world cases I've seen, the vendor/programmer was
careful to lay out the structs properly. I think if the struct does
not reflect a reasonable (or physically possible) layout, oh well ;-)
> I fully agree with you, the current default state of
> -fstrict-volatile-bitfields should be disabled for all targets.
Please don't do that until gcc produces code that does the same
things. Most of my targets rely on gcc not doing the old behavior, to
generate correct code.
> For portability
> You mean the C++11 application or the driver? You mean
> -fstrict-volatile-bitfields or -fno-strict-volatile-bitfields?
I mean, if the typedef for a volatile bitfield says "char" gcc can't
generate an HImode access, by default.
> How about this for a compromise: Let's make the default of
> -fstrict-volatile-bitfields an optional configure argument for gcc
> 4.9, that can be used for every target, even for X86_64 of you want ?
I don't care how it's enabled (currently, each target that wants it,
sets it) as long as a plai
I finally got around to checking this in, with your suggested change.
Thanks!
The patch is OK with me from a build machinery point of view.
Devirtualizer used to do this for us. Committed.
* config/rl78/rl78.c (rl78_expand_prologue): Use AX to copy
between SP and FP.
(rl78_expand_epilogue): Likewise.
Index: config/rl78/rl78.c
===
--- config/rl78
Committed.
* config/rl78/rl78.opt (mrelax): New.
* config/rl78/rl78.h (ASM_SPEC): New, pass on -mrelax to gas.
* config/rl78/rl78.h (LINK_SPEC): New, pass on -mrelax to ld.
Index: config/rl78/rl78.h
===
--- c
The line separator char for gas changed from | to @, so don't use line
separators at all to be most compatible. Committed.
* config/rl78/rl78-virt.md: Change from | to \; for asm line
separators.
Index: config/rl78/rl78-virt.md
===
Various optimizations. Committed.
2013-09-14 DJ Delorie
Nick Clifton
* config/rl78/mulsi3.S: Remove a few unneeded moves and branches.
* config/rl78/vregs.h: New.
* config/rl78/signbit.S: New file. Implements signbit function.
* config/rl78
This patch adds support for the RL78/G10 variant, which doesn't have
register banks like the other RL78 chips. Committed.
* config/rl78/rl78.c (rl78_asm_file_start): Specify alternate
vregs location for RL78/G10.
(rl78_expand_prologue): Avoid SEL on G10.
(rl78_exp
Forgot this bit, committed.
* config/rl78/vregs.h: Add G10 register definitions.
Index: config/rl78/vregs.h
===
--- config/rl78/vregs.h (revision 202637)
+++ config/rl78/vregs.h (working copy)
@@ -8,12 +8,35 @@ r_2 =
m32c's PSImode is 24-bits, why does it have "32" in the macro?
/* 24-bit pointers, in 32-bit units */
-PARTIAL_INT_MODE (SI);
+PARTIAL_INT_MODE_NAME (SI, 32, PSI);
Committed.
2013-09-17 Nick Clifton
* config/rl78/rl78.c (need_to_save): Change return type to bool.
For interrupt functions: save all call clobbered registers if the
interrupt handler is not a leaf function.
(rl78_expand_prologue): Always recompute the frame in
GCC typically avoids using virtual registers $r24 through $r31, as
this register bank (bank 3) is reserved for hand-written assembly
interrupt handlers. If unneeded for that, this new option lets gcc
use those registers also. Committed.
* config/rl78/constraints.md (Wcv): Allow up to $r
Track both parts of far addresses so they don't get optimized away.
Committed.
* config/rl78/constraints.md: For each W* constraint, rename to C*
and create a W* constraint that checks for an optional ES: prefix
pattern also.
* config/rl78/rl78.md (UNS_ES_ADDR): Ne
A few new patterns. Committed.
2013-09-17 Nick Clifton
* config/rl78/rl78-real.md (bf): New pattern.
(bt): New pattern.
* config/rl78/rl78.c (rl78_print_operand_1): Handle %B.
(rl78_print_operand): Do not put a # before a %B.
* config/rl78/rl78.opt: T
Mostly whitespace and comment tweaks, with a few random bug fixes.
Committed.
Note: the net result of our recent batch of patches is an
approximately 50% speed improvement :-)
* config/rl78/rl78.c: Various whitespace and comment tweaks.
(need_to_save): Save bank 0 on interrupts.
> If we instead ask, is it sane for gcc to ever want to signed extend
> in this case,
IIRC I've seen this due to the fact that pointer math is always
signed, and since gcc has no way of having a PSImode-sized size_t, all
pointer math is done in signed SImode, then the result is truncated to
PSImo
As per my previous comments on this patch, I will not approve the
changes to the m32c backend, as they will cause real bugs in real
hardware, and violate the hardware's ABI. The user may use
-fno-strict-volatile-bitfields if they do not desire this behavior and
understand the consequences.
I am
I'm typically against adding things to libiberty "because there's no
other place for them". The purpose of libiberty is to provide a
portability layer, not a trash can. However, htab is already in
there, and the argument for putting its accessors there is sound.
However, most of the other funct
Fixed 16-bit widening multiplies by a constant by limiting constant
matches to 16 bit constants. Applied.
PR target/54950
* config/m32c/predicates.md (m32c_const_u16_operand): New.
* config/m32c/muldiv.md: Use it.
Index: config/m32c/predicates.md
> Are you sure you meant to have an fprintf in a match_test ?
I definitely did not. Removed. Thanks!
Commited.
* config/rl78/rl78.c (rl78_as_legitimate_address): Do not allow
reg+addend addresses for the _far namespace.
Index: gcc/config/rl78/rl78.c
===
--- gcc/config/rl78/rl78.c (revision 192862)
+++ gcc/confi
namespaces are so small... committed.
* config/rl78/rl78.c (rl78_print_operand_1): Change %c to %C to
avoid conflict with the MI use of %c.
* config/rl78/rl78-real.md: change %c to %C throughout.
* config/rl78/rl78-virt.md: Likewise.
Index: config/rl78/rl78-real.m
Minor fix. Committed.
* config/rl78/rl78-expand.md (movqi): use operands[] not operandN.
(movhi): Likewise.
2013-10-08 Jan Hubicka
Index: config/rl78/rl78-expand.md
===
--- config/rl78/rl78-expand.md (revision
Your patch changes the rule that the application can override
xmalloc() and get functions that return NULL...
> Why would you want to do that?
I wouldn't, but gcc isn't the only user of libiberty.
PR tree-optimization/58689
* ansidecl.h (ATTRIBUTE_RETURNS_NONNULL): New macro.
* libiberty.h (basename, lbasename, dos_lbasename, unix_lbasename,
concat_copy): Mark with attributes nonnull(1) and returns_nonnull.
(concat_copy2, xstrerror): Mark with attribu
Alternatively, you could ask the other projects if they're ok with
changing the xmalloc rule...
I don't think there's an official list, but if you ask gdb, binutils,
newlib, and sid (I think), you've probably got it covered. Basically,
everything in the src/ repository.
Building newlib uncovered a few invalid assumptions... Committed.
* config/rl78/rl78.c (rl78_alloc_address_registers_macax): Verify
op is a REG before checking REGNO.
(rl78_alloc_physical_registers): Verify pattern is a SET before
checking SET_SRC.
Index: config/
> As it looks like, the -fstrict-volatile-bitfields are already totally broken,
I tested your example on rl78-elf, with and without
-fstrict-volatile-bitfields, and it generates correct code with it and
incorrect code without it. Same for m32c-elf. Same for h8300-elf.
Seems to be working OK for
> I'm curious; do all the test cases included in
> http://gcc.gnu.org/ml/gcc-patches/2013-09/msg02058.html
> work for you on those targets as well (without applying the rest of the
> patch)?
Not all of them can work, because they describe something that can't
be done in hardware. For example, t
> where in the C standard did you read the requirement that every bit
> field must be complete? (This is a serious question).
The spec doesn't say each field must be complete, but neither does it
say that the structure must be as big as the type used. If you
specify "int foo:1" then the compile
> At least on ARM, you can e.g. have a non-bit-field "char" that occupies
> part of the same 4-byte unit as an "int" bit-field.
Ok, "when the user doesn't give the compiler conflicting requirements."
(which is why I contemplated making those conflicts errors at first)
I'm a big fan of blaming t
I'm starting from an MCU that doesn't work right if GCC doesn't do
what the user tells GCC to do. I added -fstrict-volatile-bitfields to
tell gcc that it needs to be more strict than the standard allows for
bitfield access, because without that flag, there's no way to force
gcc to use a specific
> We use the container mode where possible.
> It is always possible for well-formed bit-fields.
This is the only part I really need.
> If necessary the user has to add anonymous bit field members, or
> convert normal members to bit-fields.
IIRC I added code to support normal members as well, th
> What I would suggest is to have a -fgnu-strict-volatile-bit-fields
Why a new option? The -fstrict-volatile-bitfields option is already
GCC-specific, and I think it can do what you want anyway.
I'm not sure either, but if it's been approved in gdb and you're
willing to cede control of it to gcc's policies, I'm OK with it.
Note that this will be a new directory in gcc, and I think the
automerge scripts will automatically pick it up. Which means, after
committing it, any future changes m
> have an option for true AAPCS compliance, which will
> be allowed to break the C++11 memory model and
> And an option that addresses your requirements,
> which will _not_ break the C++11 memory model
So the problem isn't that what *I* need conflicts with C++11, it's
that what AAPCS needs confl
Ok.
Yup, my registers are smaller than Pmode.
This is what I ended up with...
Some notes: I lie to gcc and tell it that $fp (reg 22) is two bytes
when it's really one. None of the register classes have reg 23 (used
for the upper half of $fp) in them. Reg 23 is also listed as being
two bytes, to ke
> > Some notes: I lie to gcc and tell it that $fp (reg 22) is two bytes
> > when it's really one.
>
> Well, it's not really a lie if you map hardware registers 22 and 23 to
> a single register for the purposes of gcc internals.
Yeah, I'm basically making those two registers into a permanent bigg
Who needs to approve this? THe target maintainers, or some global maintainer?
Sure, go for it.
Apparently, there's a subtle difference between "function that takes
no argument" and "function that takes void" :-P
Committed.
* config/rx/rx.c (ADD_RX_BUILTIN0): New macro, used for builtins
that take no arguments.
Index: config/rx/rx.c
> Seeing the patched code in its entirety like this, I notice that we
> would use HARD_REGNO_NREGS for a regno that's not ok for the mode.
> That can be avoided if we put a break into the if. And then the
> !bad term in the loop condition becomes redundant. Although the
> HARD_REGNO_NREGS defini
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
Ok.
Note, though, that I'm in the process of deprecating mep...
> 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.
> 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
> Looks good to me. Obviously you'll need appropriate ChangeLogs. OK
> with the ChangeLogs added.
Done.
Ok
> * config/msp430/msp430.c
> (msp430_attr): Use wide-int interfaces.
>
>
> diff --git a/gcc/config/msp430/msp430.c b/gcc/config/msp430/msp430.c
> index daff4ae..e3f6712 100644
> --- a/gcc/config/msp430/msp430.c
> +++ b/gcc/config/msp430/msp430.c
> @@ -1085,7 +1085,7 @@ msp430_att
Alan Modra writes:
> Bootstrapped etc. powerpc64-linux. OK mainline and 4.8 branch?
>
> * configure.ac (BUILD_CXXFLAGS) Don't use ALL_CXXFLAGS for
> build != host.
> : Clear GMPINC. Don't bother
> saving CFLAGS.
> * configure: Regenerate.
Ok for mainline, up to the
The m32c part is OK.
I went through all the patterns in the msp430 backend and converted
all those that are volatile-safe to allow volatile MEM operands.
Committed.
* config/msp430/msp430.md (movqi): replace general_operand with
msp_general_operand and nonimmediate_operand with
msp_nonimmediat
This was causing the final pattern to not match. Committed.
* config/rl78/rl78-expand.md (one_cmplqi2): Make constant signed.
Index: config/rl78/rl78-expand.md
===
--- config/rl78/rl78-expand.md (revision 205980)
+++ confi
The call change avoids a problem on hardware where indirect calls that
use SP as a base register don't seem to do what you expect. The 'J'
one fixes a link-time error wrt epilogue helper functions. Committed.
* config/msp430/msp430.md (call_internal): Don't allow memory
referenc
Nick,
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?
Index: gcc/config/rx/rx.c
===
--- gcc/config/rx/rx.c (revision 225533)
+++ g
Minor tweak to allow more addressing modes. Committed.
* config/rl78/rl78-real.md (andqi3_real): Expand operands for clr1.
(iorqi3_real): Likewise for set1.
Index: config/rl78/rl78-real.md
===
--- config/rl78/rl78-r
Another place where a list of "all" types are explicitly listed, and
the __intN types need to be included, and elsewhere protection against
errors [-Wnarrowing] on targets that have small size_t. Ok?
* include/bits/functional_hash.h: Add specializations for __intN
types.
As indicated. Committed.
* config/msp430/t-msp430 (MULTILIB_DIRNAMES): Remove trailing
slashes.
* config/msp430/msp430.md (ashlhi3): Optimize shifts of subregs.
(ashrhi3): Likewise.
(lshrhi3): Likewise.
(movhi): Take advantage of zero-extend to lo
> > * include/bits/functional_hash.h: Add specializations for __intN
> > types.
> >
> > * include/ext/pb_ds/detail/thin_heap_/thin_heap_.hpp (__gnu_pbds):
> > Guard against values that might exceed size_t's precision.
>
> Yes, OK - thanks.
Committed. Thanks!
Ok, but please don't put non-public issue numbers in the comments.
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 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 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
> $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
> libiberty/ChangeLog:
>
> * configure.ac: Set AC_CV_FUNC_GETPAGESIZE to "yes" on
> Android hosts.
> * configure: Regenerate.
>
> OK to apply?
Ok.
> --- 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
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
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.
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
I'm OK with the msp430 part :-)
> 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.
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.
"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
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
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
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
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
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:
> 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:
> 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
> + snprintf (mcu_name, sizeof (mcu_name) - 1, "__%s__", target_mcu);
> + start_upper = 0;
Can optimize this to 2 :-)
Otherwise OK.
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 ;-)
That's fine too, I was thinking of checking mcu_name[i] against NUL.
Any of those solutions would work :-)
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
"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 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
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.
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
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
> ==
1 - 100 of 581 matches
Mail list logo
