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
There are a couple of places in gcc where wierd-sized pointers are an
issue. While you can use a partial-integer mode for pointers, the
pointer *math* is still done in standard C types, which usually don't
match the modes of pointers and often result in suboptimal code.
My proposal is to allow
Who needs to approve this? THe target maintainers, or some global maintainer?
Sure, go for it.
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 bigger
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
Ok.
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
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, the
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
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 is
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 the user
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
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:
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, the
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.
While I am at it, can I patch backends as well? For example
mep/mep.c has an occurrence of tree_code_name[TREE_CODE (...
The mep change is pre-approved :-)
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
Alternatively, you could ask the other projects if they're ok with
changing the xmalloc rule...
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:
Minor fix. Committed.
* config/rl78/rl78-expand.md (movqi): use operands[] not operandN.
(movhi): Likewise.
2013-10-08 Jan Hubicka j...@suse.cz
Index: config/rl78/rl78-expand.md
===
---
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
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
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
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.
Committed.
2013-09-17 Nick Clifton ni...@redhat.com
* 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
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
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):
A few new patterns. Committed.
2013-09-17 Nick Clifton ni...@redhat.com
* 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.
*
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.
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);
Various optimizations. Committed.
2013-09-14 DJ Delorie d...@redhat.com
Nick Clifton ni...@redhat.com
* config/rl78/mulsi3.S: Remove a few unneeded moves and branches.
* config/rl78/vregs.h: New.
* config/rl78/signbit.S: New file. Implements signbit
On behalf of myself and Nick, many thanks to everyone involved in
reviewing this port! I've checked in the port as per the last
(approved) patch set I sent out.
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
===
---
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
===
---
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
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 plain
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 ;-)
The purpose of local register variables is to tell gcc which register to
use in an inline asm, when multiple registers could be used. Other uses
are not supported and usually don't work the way you expect, especially
when optimizing.
If all you want is a function which returns the value in a
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)
so... can I get an official ok to commit with you and Nick as maintainers
then?
I'd say it's not as simple as you make it out to be. You can't blindly
combine operations on volatile memory.
I'm not blindly combining them, I'm combining them when I know the
hardware will do the volatile-correct thing.
ie, the programmer may have written them as separate statements and
You're missing the point. If the programmer wrote two statements
which hit volatile memory and you've got some pattern which matches
those two statements, then with your change you'll end up combining
them, that's wrong.
I see nothing in the ISO spec that says you can't combine a volatile
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
Go for it. The static 212 is not required as long as the pass shows
up in the right spot in the pass sequence.
comma comma comma comma comma comma
got it ;-)
What I really need is an int20_t type in the core of gcc, so I can set
Pmode to *that*, to avoid the SImode stuff completely. But that's a
core change, not a target change.
Sometimes you have to make core changes for a new port. This sounds
like something that really should be fixed
The first doesn't have a clobber, though...
Hmm. Missed that. So the only reason you'd care to include the bic
in the regular and pattern is if it were a smaller encoding than the
regular r/0/i alternative.
It is, but the separate pattern picks that out just fine.
You need to
Index: gcc/cfgexpand.c
===
--- gcc/cfgexpand.c (revision 201184)
+++ gcc/cfgexpand.c (working copy)
I thought I already approved this. Go ahead and install it.
Sorry, I forgot to split out those three patches when I
So it's a little unclear to me which patterns you removed. Your message
has two patterns attached with comments they were to work around reload
issues. Are these the patterns you removed?
Yes. I was unable to reproduce the reload problems to which those
comments referred.
First, if you
[nickc added for comments about the bits he wrote]
... define these as
(define_predicate msp_general_operand
(match_code mem,reg,subreg,const_int,const,symbol_ref,label_ref
{
int save_volatile_ok = volatile_ok;
volatile_ok = 1;
int ret = general_operand (op, mode);
I tried to reproduce the original bugs that led to these patterns, but
was unable. Testsuite results are the same with and without, and
eembc code size doesn't change.
So, I'm removing these patterns from the port.
The remaining (subreg...) patterns are just optimizations.
; This pattern is
The gcc prereq page says gettext 0.14.5 is the minimum version, but
po/zh_TW.po has lines like this:
#, fuzzy
#~| msgid Unexpected EOF
#~ msgid Unexpected type...
#~ msgstr 未預期的型態…
The | syntax appears to have been added in gettext 0.16, and gettext
0.14 can't process it.
Seems to have been a
The choice appears to be to continue to have broken volatile bitfields
on ARM with no way for users to make them conform to the ABI, or to
change things so that they conform to the ABI if you specify
-fstrict-volatile-bitfields explicitly and to the C/C++ standard by
default, without
Two weeks since the last comment... Anyone?
http://gcc.gnu.org/ml/gcc-patches/2013-06/msg01089.html
Given how much trouble I went through to make it the default, I'd
rather not revert all that work... especially since the flag is
*required* for proper operation of the hardware on many of these
targets.
This patch will, or course, silently and obscurely break existing
code.
A random spotting; copyright header replacement miss, including
but maybe not limited to:
Doh! I'll scan them all and fix them. Thanks!
Thanks!
; end of mulqi macro
+;; [(set_attr valloc umul)]
I think this one needs to be macax also, since the constraints have
v in them but the opcodes use ax.
Other than that, it's OK.
Fixes a libstdc++v3 build failure. Committed.
* config/rl78/rl78.c (TARGET_UNWIND_WORD_MODE): Define.
(rl78_unwind_word_mode): New.
Index: config/rl78/rl78.c
===
--- config/rl78/rl78.c (revision 199963)
+++
umul is used when the insn takes two operands in A and X, and
computes a value into AX. This is similar to op2 which, in general,
does AX = AX op (other register or memory). The devirtualizer will
arrange for the right values to be in real registers for these.
macax is used when the insn
@@ -986,12 +1053,10 @@ align_variable (tree decl, bool dont_out
if (! DECL_THREAD_LOCAL_P (decl) || const_align = BITS_PER_WORD)
align = const_align;
}
-#endif
}
+#endif
I think this change in get_variable_align() is wrong; it results in
unbalanced braces
This patch:
2013-05-31 Kaushik Phatak kaushik.pha...@kpitcummins.com
* config/rl78/rl78.md (mulqi3,mulhi3): New define_expands.
(*mulqi3_rl78,*mulhi3_rl78,*mulhi3_g13): New define_insns.
Uses a U constraint which isn't defined in rl78/constraints.md
What should that
This fixes a bug where cfgexpand would ICE when using far pointers,
because the SImode pointers weren't valid with the default macro.
Committed.
* config/rl78/rl78.c (rl78_valid_pointer_mode): New, implements
TARGET_VALID_POINTER_MODE.
Index: gcc/config/rl78/rl78.c
Are there any further comments on this? Do I need to post a final
patch? Can it be committed yet?
This one is OK.
2013-05-16 Nick Clifton ni...@redhat.com
* config/rl78/rl78.c (rl78_attribute_table): Add naked.
(rl78_is_naked_func): New function.
(rl78_expand_prologue): Skip prologue generation for naked
functions.
(rl78_expand_epilogue): Skip
Interestingly we have exactly that for AVR:
config/avr/avr-modes.def:FRACTIONAL_INT_MODE (PSI, 24, 3);
I know. I tried copying them, it didn't work for me.
What's the blocker to convert the existing 5 cases of
PARTIAL_INT_MODE use to specify a precision?
In general? For me, PARTIAL_INT_MODE() works, FRACTIONAL_INT_MODE()
didn't.
I thought it was the other way round - that after Bernd's fixes (July
2011) towards support for 40-bit integers, FRACTIONAL_INT_MODE worked
better than PARTIAL_INT_MODE.
Probably most accurate to say that both ways are not well supported.
In general, I always have a hard time with anything
How can you then ever truncate from SImode to PSImode?
If you use PARTIAL_INT_MODE(), you get a PSImode that has a default
bitsize (i.e. the value stored in the data structure) that's the same
as SImode, that is, 32. There is no way to specify the usable
bitsize, so it's undefined/unspecified
Can you add that (partial int modes have fewer bits than int modes)
as verification to genmodes.c:make_partial_integer_mode?
I could, but it would be a no-op for PARTIAL_INT_MODE()
I wonder if this should not use GET_MODE_PRECISION - after all it is
the precision that determines whether we
Please find below an updated patch. Let me know if ok to commit.
Yup, this is OK to commit. Thanks!
Regards,
Kaushik
2013-05-13 Kaushik Phatak kaushik.pha...@kpitcummins.com
* config/rl78/rl78.md (mulsi3_g13): Add additional 'nop' required
in multiply-accumulate
run-time, according to my reading of
http://gcc.gnu.org/codingconventions.html .
I chenged it, but I note that runtime is used much more often than
run-time and run time in the docs.
However, runtime is preferred for libraries and system support
present at run time, which is what this option
movwax, %h2
movw0x2, ax ; MDAH
nop ; mdc += mdal * mdah
+ nop ; Additional nop for MAC
mov a, #0x40
mov !0xf00e8, a ; MDUC
Shouldn't the MOV after the nop add the extra cycle here?
movwax, %H2
movw
Note that I had to make a few changes (fixes?) in the MI portions of
gcc to avoid problems I encountered, I don't know if these changes are
correct or if there are better ways to avoid those cases. Those
In any case, they should best be posted in separate messages, each one
with its
Note that I had to make a few changes (fixes?) in the MI portions of
gcc to avoid problems I encountered, I don't know if these changes are
correct or if there are better ways to avoid those cases. Those
In any case, they should best be posted in separate messages, each one
with its
Yes - in fact this appears to be a general problem with RL78 interrupt
handlers. There are no instructions to push/pop the current bank
selection, so in order for nested interrupt handlers to work they would
have to do something like:
The bank select bits are in PSW, which is
It looks like the patch also treats PSImode-SImode as a truncation though.
I'd have to check specifically for partial_int_mode, since there's
nothing in PARTIAL_INT_MODE() to set the precision, unless there's
some other way to set PSImode's bits *and* reliably use that info.
For some reason,
The assembler already exists (and is widely used, I think), and the
MSPABI specifies how registers and symbols are named at the assembler
level. Unfortunately, the MSPABI says that symbols should be like
||this|| when they need to mean not a register but our assembler
doesn't support that. The
- if (GET_MODE_BITSIZE (GET_MODE (op0)) GET_MODE_BITSIZE
(GET_MODE (op1)))
+ /* Don't try to sign-extend SImode to PSImode, for example. */
+ if (GET_MODE_BITSIZE (GET_MODE (op0)) = GET_MODE_BITSIZE
(GET_MODE (op1)))
Can't you do just nothing if
+;; This is weird. GCC testcase execute/20020615-1 compiled at -Os
Another hack around a real problem, and a potential source of wrong
code. Not OK IMHO.
I couldn't reproduce it, so I took it out. If it comes back, we'll
hit it harder :-)
* Uses register bank 3 instead of register bank 0 inside the
handler.
I wonder if nested interrupts will cause problems, since the second
interrupt will occur with RB3 already selected.
Also, there are some hand-coded routines in libgloss/libgcc that
manually swap banks, they'd have
Sorry for missing the truncation patterns, I should have grepped
more than m32c.md. They look a lot like normal moves though. Is
truncation really not a noop, or are the patterns there to work
around something (probably this :-))?
Not sure which pattern you're talking about, but in
I have patches to let one specify a precision for partial int types,
easy enough to do, and the rest of the compiler plays nicely for the
most part with it...
If you can make size_t truly be a 24-bit value, I'd be very happy :-)
For m32c chips, The address space is a flat 24-bit address space.
Address registers are 24 bits (i.e. they cannot hold an SImode) but
size_t is 16 bits originally because there aren't enough 24-bit math
ops and 32-bit math is too expensive. I've tried to use PSImode for
size_t recently
this isn't true, it would be helpful to know. Given the size_t/uintptr_t
testsuite patch I just submitted I'm thinking they don't exist, but I'm
kind of wondering about m32c, so Cc'ing DJ.
For m32c-elf with -mcpu=m32c, size_t is 16 bits but void* is 24 bits.
24 bits stored as three bytes, or four? How does this affect vtable
layout? I would have expected the C++ frontend and libsupc++ to
currently be inconsistent with each other given such a setup.
In memory, four, I think. The address registers really are three
bytes though. They're PSImode
One thing I did in libiberty was to rearrange the targets so that the
ones that took the longest started first. That way, you don't end up
building 99% of the objects then waiting for the one last one to finish.
The problem is, devirt hasn't happened yet when we compute the frame
size, so we *can't* know if bank 0 registers are used yet.
Also, I've had problems recomputing the frame size after reload. If
the frame size changes for *any* reason between reload and prologue,
you get corrupt code, as the
The DJGPP build of gcc 4.8.0 was just uploaded, it might have some
patches that haven't been committed upstream yet.
A quick grep shows not many targets would be affected, AVR, m32c, rl78 and
spu.
You should work with the maintainers of those targets to see which approach
would be the best.
For both m32c and rl78, one address space is a strict subset of the
other (16-bit near vs 20/24/32-bit far pointers,
401 - 500 of 1257 matches
Mail list logo
