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
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.
Ok, but the converse — if the general_operand is accessed by more
than one instruction, it is not safe — is correct, right?
In general, I'd agree, but the ISO spec talks about sequence points
and there are times when you *can* access a volatile multiple times as
long as the state is correct at
Matt Godbolt m...@godbolt.org writes:
GCC's code generation uses a load; add; store for volatiles, instead
of a single add 1, [metric].
GCC doesn't know if a target's load/add/store patterns are
volatile-safe, so it must avoid them. There are a few targets that have
been audited for
What is involved with the auditing?
Each pattern that (directly or indirectly) uses general_operand,
memory_operand, or nonimmediate_operand needs to be checked to see if
it's volatile-safe. If so, you need to change the predicate to
something that explicitly accepts volatiles.
There's been
One question: do you have an example of a non-volatile-safe machine so
I can get a feel for the problems one might encounter? At best I can
imagine a machine that optimizes add 0, [mem] to avoid the
read/write, but I'm not aware of such an ISA.
For example, the MSP430 backend uses a macro
I looked in the documentation and didn’t see this described.
AFAIK it's not documented. Only recently was it agreed (and even
then, reluctantly) that the ISO spec could be met by such opcodes.
To try to generalize from that: it looks like the operating
principle is that an insn that expands into multiple references to a
given operand isn’t volatile-safe, but one where there is only a
single reference is safe?
No, if the expanded list of insns does what the standard says, no
more,
The code that this macro enables will never do anything anyway on
RL78. Applied.
2014-12-15 DJ Delorie d...@redhat.com
* config/rl78/rl78.h: Remove SHORT_IMMEDIATES_SIGN_EXTEND.
Index: config/rl78/rl78.h
===
--- config
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...
Fixes newlib/libgcc build problems, many test cases. No regressions.
Applied.
* config/m32c/cond.md (movqicc_code_mode): Remove mode of
conditional.
(movhicc_code_mode): Likewise.
* config/m32c/m32c.c (encode_pattern_1): Specialise PSImode
subregs.
Last time you mentioned this, I asked what the contents of that
config.log were...
Ok. For the branch please wait until after 4.9.2 is out.
4.9.2 being out, I applied this to the branch.
Ok. For the branch please wait until after 4.9.2 is out.
Thanks! Committed to trunk.
, x86 32/64, and arm32.
2014-10-29 DJ Delorie d...@redhat.com
* expmed.c (strict_volatile_bitfield_p): Fix off-by-one error.
2014-10-29 DJ Delorie d...@redhat.com
* gcc.dg/20141029-1.c: New.
Index: expmed.c
Fixed PR/63582. Tested with no regressions on x86-64 and ix86. Ok?
* tree.c (build_common_tree_nodes): Don't even store the
__int128 types if they're not supported.
OK.
Thanks! Committed.
* config/mep/mep.c: Include rtl-iter.h.
(global_reg_mentioned_p_1): Take a const_rtx and return a bool.
(xtensa_tls_referenced_p): Return a bool. Use FOR_EACH_SUBRTX.
OK.
* config/mep/mep.c (mep_store_find_set): Take a const_rtx and
return a bool. Replace void * with specific type. Iterate
over all subrtxes.
(mep_store_data_bypass_1): Update calls accordingly.
OK.
gcc/
* config/mep/mep.c (mep_mul_hilo_bypass_1): Delete.
(mep_mul_hilo_bypass_p): Use FOR_EACH_SUBRTX.
OK.
Fixed PR/63582. Tested with no regressions on x86-64 and ix86. Ok?
* tree.c (build_common_tree_nodes): Don't even store the
__int128 types if they're not supported.
Index: tree.c
===
--- tree.c (revision
Fixes BISX.A bug. Committed.
2014-10-23 DJ Delorie d...@redhat.com
* config/msp430/msp430.c (msp430_print_operand): 'x' modifier is
independend of -mlarge.
* config/msp430/constraints.md (Ys): Update comment.
Index: config/msp430/constraints.md
This is okay.
Thanks! Committed.
With a ChangeLog entry yes.
Thanks! Committed.
In the event that pointer sizes aren't powers of two, choose a more
suitable alignment than (unsigned)(-1), which results in HUGE file
sizes. Ok?
Ok.
Thanks! Committed.
FAIL: g++.dg/init/enum1.C -std=gnu++11 (test for errors, line 12)
FAIL: g++.dg/init/enum1.C -std=gnu++1y (test for errors, line 12)
FAIL: g++.dg/init/enum1.C -std=gnu++98 (test for errors, line 12)
That used to complain about enum1.C:12:1: error: no integral type can
represent all of
As long as you commit to gcc first, or at the same time as other
commits, you'll be fine. If you commit elsewhere first or only, it
may be reverted by a script.
If you could implement the second option, it would be appreciated.
Could you please test this for me? It builds as a powerpc-elf
cross-compiler (at least the host half) but I don't have a power
machine here to test on.
Index: rs6000-c.c
In the event that pointer sizes aren't powers of two, choose a more
suitable alignment than (unsigned)(-1), which results in HUGE file
sizes. Ok?
Index: gcc/lto/lto-object.c
===
--- gcc/lto/lto-object.c(revision 216287)
+++
Since flag-types.h is used in target code, it needs to be -Wall-safe
for targets with 16-bit int. OK?
Index: gcc/flag-types.h
===
--- gcc/flag-types.h(revision 216287)
+++ gcc/flag-types.h(working copy)
@@ -229,17 +229,17
A few more cases where pointers were assumed to be whole bytes.
Ok?
Index: gcc/c-family/c-cppbuiltin.c
===
--- gcc/c-family/c-cppbuiltin.c (revision 216287)
+++ gcc/c-family/c-cppbuiltin.c (working copy)
@@ -668,13 +668,13 @@
I don't see what the stor-layout.c changes have to do with that
description, or why they are correct (they look wrong to me; the
existing addition of BITS_PER_UNIT_LOG + 1 looks logically correct
for bitsizetype).
sooo... the type for bitsizetype will *always* be a bigger type than
sizetype?
The other changes are OK.
Committed those then. Thanks!
extensions. Is this OK? If so, is there anything else, or can I
check the whole mess in yet?
Go ahead.
Thanks! Committed.
../../gcc/gcc/config/rs6000/rs6000-c.c:237:24: error: ‘RID_INT128’ was not
declared in this scope
Two options:
1. If you know the RS6000 will never have any __intN other than
__int128, just use RID_INT_N_0, although this is a hack it will
work as long as there *is* an __int128 for
This is the MSP430-specific use of the new intN framework to enable
true 20-bit pointers. Since I'm one of the MSP430 maintainers, this
patch is being posted for reference, not for approval.
Now that the other parts are committed, I'm checking this one in too.
gcc/config/msp430
*
This is what I ended up with for the test case. It was a bit tricky
since it only works with msp430x (not msp430) and requires the gnu
extensions. Is this OK? If so, is there anything else, or can I
check the whole mess in yet?
// { dg-do compile { target msp430*-*-* } }
// { dg-options
if (same_type_p (TYPE_MAIN_VARIANT (t1), long_long_unsigned_type_node)
|| same_type_p (TYPE_MAIN_VARIANT (t2),
long_long_unsigned_type_node))
return build_type_attribute_variant (long_long_unsigned_type_node,
Otherwise, I don't see what moving the test would accomplish. If
long is never 128 bits, it doesn't matter if the int128 test is
before or after it, and the other intN are never the same size as
standard types,
I don't see how you can assert that these will never happen.
It's checked
Note that there is a separate __int128_t type that isn't part of the
standard extension. Maybe it's there for that type?
Otherwise, I don't see what moving the test would accomplish. If
long is never 128 bits, it doesn't matter if the int128 test is
before or after it, and the other intN are
The C++ standard says that extended integer types participate in the
usual arithmetic conversions. If I add a 32-bit int and an __int48, the
usual arithmetic conversions should convert the int to __int48.
Except the code you're referring to isn't part of that conversion. It
only handles
Ah, good point. In which case I don't see what this code is trying to
accomplish relative to falling through to the prefer the unsigned one
code below. Shall we just remove it?
I don't know for sure. There was __int128 code there, I replaced it
with the same code, so as to avoid any
The test would only pass for msp430x (and fail for msp430, which is
the same target back-end). Do I need to redo the big patch, or would
a separate one suffice?
Separate is fine.
Turns out it's mangled like this:
__int20 foo (__int20 a, unsigned __int20 b);
_Z3foou5int20u6uint20
It seems like the int128 code here was broken and this is continuing
that brokenness. Extended integer types have integer conversion rank
corresponding to their bitsize, so int128 should have higher rank than
long long, but here it was being checked after long long, and your code
also
Joseph S. Myers jos...@codesourcery.com wrote:
The non-C++/libstdc++ parts are OK with those changes.
Jonathan Wakely jwak...@redhat.com wrote:
* libstdc++-v3/
* src/c++11/limits.cc: Add support for __intN types.
* include/std/type_traits: Likewise.
* include/std/limits:
Joseph S. Myers jos...@codesourcery.com wrote:
The non-C++/libstdc++ parts are OK with those changes.
Jonathan Wakely jwak...@redhat.com wrote:
These libstdc++ changes are OK for trunk.
Jason/Nathan,
Could one of you two please review the remaining C++ parts (cp/*) ?
Just one question about the include/std/limits changes below.
It seems that __glibcxx_signed_b isn't strictly necessary as it
doesn't use the B argument, so is it just there for consistency?
Yup.
This fixes cases where negative indices are used for array offsets.
Committed.
* config/msp430/msp430.md (extendhipsi2): Use 20-bit form of RLAM/RRAM.
(extend_and_shift1_hipsi2): Likewise.
(extend_and_shift2_hipsi2): Likewise.
Index: gcc/config/msp430/msp430.md
This fixes cases where negative indices are used for array offsets.
Committed.
* config/msp430/msp430.md (extendhipsi2): Use 20-bit form of RLAM/RRAM.
(extend_and_shift1_hipsi2): Likewise.
(extend_and_shift2_hipsi2): Likewise.
Committed to 4.9 branch too.
I fixed this (in patch 5) by introducing a new local rtx set for the
result of single_set, and hence not overwriting insn within the loop.
That said I've only tested that it compiles for rl78, I've not yet
forced line 3605 to execute, and not simulated the resulting code.
Seems
Minor bit of docs for an msp430 option. OK for trunk and 4.9 branch?
Ok.
* doc/invoke.texi (MSP430 Options): Add -minrt.
Thanks! Committed.
Minor bit of docs for an msp430 option. OK for trunk and 4.9 branch?
* doc/invoke.texi (MSP430 Options): Add -minrt.
Index: doc/invoke.texi
===
--- doc/invoke.texi (revision 214976)
+++ doc/invoke.texi (working
On 08/13/14 16:10, DJ Delorie wrote:
The purpose of this set of changes is to remove assumptions in GCC
about type sizes. Previous to this patch, GCC assumed that all types
were powers-of-two in size, and used naive math accordingly.
Old:
POINTER_SIZE / BITS_PER_UNIT
* testsuite/
* lib/target-supports.exp (check_effective_target_size32plus):
Increase size to avoid false positives on 24-bit address spaces.
* gcc.c-torture/compile/limits-stringlit.c: Skip if msp430.
* gcc.dg/lto/pr54709_1.c: Fix memcpy prototype.
*
* expr.c (convert_move): If the target has an explicit converter,
use it.
OK.
Thanks! Committed.
gcc/
* cppbuiltin.c (define_builtin_macros_for_type_sizes): Round
pointer size up to a power of two.
* defaults.h (DWARF2_ADDR_SIZE): Round up.
(POINTER_SIZE_UNITS): New, rounded up value.
* dwarf2asm.c (size_of_encoded_value): Use it.
The m32c-elf with -mcpu=m32c has a word-aligned stack and uses pushes
for arguments (i.e. not accumulate_outgoing_args). In this test case,
one of the arguments is memcpy'd into place, and an assert fails:
typedef struct {
int a, b, c, d, e, f, g, h;
} foo;
int x;
void
dj (int a, int b, foo
This patch should fix it. Okay to apply?
Ok. Thanks!
2014-08-28 Jan-Benedict Glaw jbg...@lug-owl.de
* config/mep/mep-pragma.c (mep_pragma_coprocessor_subclass): Rework
to silence warning.
* config/mep/mep.c (VECTOR_TYPE_P): Remove duplicate definition.
Maybe you need to refactor __glibcxx_digits so there is a version taking
the bitsize as an argument rather than using sizeof(T) * __CHAR_BIT__,
but
that should be the only change needed to handle such types with the
existing macros. The bitsize macros should be the only ones
I don't see flag_iso as relevant here (since the macros are in the
implementation namespace). The definitions could reasonably be restricted
to c_dialect_cxx (), though, given that they are specifically for use by
libstdc++ (and it's easier to add a macro later for C if needed, than to
Why are types only entered in integer_types if wider than long long?
IIRC it was so that TImode (__int128) could get into the array (it was
there before) without adding the other smaller types, which (I think)
don't need to be in there. I don't recall why they're left out,
but... ah, I
I don't see any corresponding HOST_BITS_PER_WIDE_INT test for __int128
being removed (and anyway HOST_BITS_PER_WIDE_INT is now always 64, so such
a test for __int128 would be dead code).
It was there when I started the patch, honest! :-)
Removed ;-)
For each __intN we need to provide
Maybe you need to refactor __glibcxx_digits so there is a version taking
the bitsize as an argument rather than using sizeof(T) * __CHAR_BIT__, but
that should be the only change needed to handle such types with the
existing macros. The bitsize macros should be the only ones needing
Minor tweak, committed.
* config/rl78/rl78-virt.md (movhi_virt): Allow const-far moves.
Index: config/rl78/rl78-virt.md
===
--- config/rl78/rl78-virt.md(revision 213994)
+++ config/rl78/rl78-virt.md(working copy)
@@
The G10 family doesn't support this opcode. Committed.
* config/rl78/rl78-expand.md (umulqihi3): Disable for G10.
* config/rl78/rl78-virt.md (umulhi3_shift_virt): Likewise.
(umulqihi3_virt): Likewise.
* config/rl78/rl78-real.md (umulhi3_shift_real): Likewise.
Letting GCC think that any mem-mem alternative is OK leads to trouble
with far mem to far mem moves, so split out the moves we can make.
Committed.
* config/rl78/predicates.md (rl78_near_mem_operand): New.
* config/rl78/rl78-virt.md (movqi_virt_mm, movqi_virt)
Minor optimization. Committed.
* config/rl78/rl78-real.md (addqi3_real): Allow adding global
variables to the accumulator.
Index: config/rl78/rl78-real.md
===
--- config/rl78/rl78-real.md(revision 213996)
+++
The following five patches are the latest in my ongoing work to
replace the hard-coded __int128 type with a more flexible __intN
system that allows target-specific types that correspond to
partial-int modes. Specifically, this will allow targets to have
pointers that aren't powers-of-two in
This patch is part of the __intN series, but is independent. It
provides an additional optimization opportunity, since the MSP430 does
a lot of conversions between HImode and PSImode.
* expr.c (convert_move): If the target has an explicit converter,
use it.
Index: gcc/expr.c
The purpose of this set of changes is to remove assumptions in GCC
about type sizes. Previous to this patch, GCC assumed that all types
were powers-of-two in size, and used naive math accordingly.
Old:
POINTER_SIZE / BITS_PER_UNIT
TYPE_SIZE
GET_MODE_BITSIZE
New:
This is the MSP430-specific use of the new intN framework to enable
true 20-bit pointers. Since I'm one of the MSP430 maintainers, this
patch is being posted for reference, not for approval.
gcc/config/msp430
* config/msp430/msp430-modes.def (PSI): Add.
*
Changes to the testsuite to make tests more portable to targets with
unusual address spaces.
* testsuite/
* lib/target-supports.exp (check_effective_target_size32plus):
Increase size to avoid false positives on 24-bit address spaces.
*
A while ago I've removed a couple of those 'typedef struct' things, as
they are not required in C++ anymore. Is there any particular reason
why this couldn't be simply 'struct int_n_data_t' ?
No particular reason.
Ah, cool, I didn't know all that was in.
Well, the precision part is in, but the __intN part isn't yet. Each
time I do a final check for regressions, something new has been
added to gcc which breaks it all again... :-P
As for PSImode, I dunno - seems only m32c and AVR use that? I have no
way how to perform testing on such targets.
and msp430. m32c and msp430 have simulators in gdb.
Responding wrt DJ's proposed changes:
As to what bits are modified, that's target dependent as the
precise size of the partial modes is target dependent.
GET_MODE_PRECISION (mode) is the precision of all modes.
True, but not all the compiler uses that info when it should. There
are even
There's still lots of places in gcc that use SIZE where they should
use PRECISION.
Yes, and in time, they’ll all get cleaned up.
Hopefully not much time, if I can get my patches commit-worthy. I'm
actually debugging a pointer-signed-math regression now.
I also added a step that looks
sorry for late reply. Patch is ok. Please apply.
Applied. Thanks!
This patch changes the logic in crtbegin that looks for libgcc.dll
such that the test is only done once, guaranteeing consistent results
between the register and deregister cases.
Previously, a crash occurred if the application (directly or
indirectly) caused libgcc.dll to load after main() was
I just tried a 4.9.1 build and got this error:
configure:4222: checking whether to use setjmp/longjmp exceptions
configure:: /greed/dj/gnu/gcc/m32c-elf/gcc-4_9-branch/./gcc/xgcc
-B/greed/dj/gnu/gcc/m32c-elf/gcc-4_9-branch/./gcc/
-B/greed/dj/m32c/install/m32c-elf/bin/
We see other failures in the log because newlib/targ-include
isn't created. The rtems build include path includes that and
needs it but it isn't created before libgcc is built. That isn't a
problem on other targets. I don't see anything odd in the top
configurery magic for m32c which could
What's the next step?
Someone finds time and desire to debug it ;-)
Minor bugfix, committed.
* config/rx/rx.c (rx_option_override): Fix alignment values.
(rx_align_for_label): Likewise.
Index: config/rx/rx.c
===
--- config/rx/rx.c (revision 212709)
+++ config/rx/rx.c
PSImode is 20 bits, fits in a 20 bit register, and uses 20 bit operations.
Then why do you need this change?
Because parts of the gcc code use the byte size instead of the bit
size, or round up, or assume powers-of-two sizes.
- TYPE_SIZE (type) = bitsize_int (GET_MODE_BITSIZE
which means that the precision of the mode is used to set the size
of the type, which very likely means that the size of the mode is
larger. So the size of the mode will be larger than the size of the
type, which is a lie.
For partial int modes, the precision and size are the same, and
Ok, but as we are dealing exclusively with bitfields there is
already output_constructor_bitfield which uses an intermediate
state to pack bits into units that are then emitted. It shouldn't
be hard to change that to make it pack into the appropriate bits
instead.
That assumes that the
I'm very skeptical... In any case, having a type whose TYPE_SIZE is smaller
than the size of its MODE is a lie which will bite you back at some point.
Except gcc now knows the size of partial int modes. In this case,
PSImode is 20 bits and TYPE_SIZE is 20 bits, so they match.
The code was
And the hardware really loads 20 bits and not 24 bits? If so, I
think you might want to consider changing the unit to 4 bits instead
of 8 bits. If no, the mode is padded and has 24-bit size so why is
setting TYPE_PRECISION to 20 not sufficient to achieve what you
want?
The hardware
That's what'll need fixing then.
Can I change TYPE_SIZE to TYPE_SIZE_WITH_PADDING then? Because it's
not reflecting the type's size any more. Why do we have to round up a
type's size anyway? That's a pointless assumption *unless* you're
allocating memory space for it, and in that case, you
Do you have modes whose size is not multiple of the unit?
Yes. That's exactly the problem I'm trying to solve here. I'm making
partial int modes have real corresponding types, and they can be any
bit size, with target PS*modes to match. The MSP430, for example, has
20-bit modes, 20-bit
Revisiting an old thread, as I still want to get this feature in...
https://gcc.gnu.org/ml/gcc/2012-10/msg00099.html
Why do you need to change varasm.c at all? The hunks seem to be
completely separate of the attribute.
Because static constructors have fields in the original order, not
If you find a particular use of TYPE_SIZE is using a size that isn't
correct for your type whose precision is not a multiple of
BITS_PER_UNIT, then in my model the correct fix is to change that
use of TYPE_SIZE rather than to change the value of TYPE_SIZE for
that type - and such a change
https://gcc.gnu.org/ml/gcc-patches/2014-05/msg01860.html
Build parts are approved.
No stor-layout.c listed here but...
I knew I'd miss at least one in the split-up...
Index: gcc/stor-layout.c
===
--- gcc/stor-layout.c (revision 211858)
+++ gcc/stor-layout.c (working copy)
@@ -2123,13
Are you proposing we remove TYPE_SIZE completely?
Yes; I think that makes sense, unless someone produces a clearer
definition of what TYPE_SIZE means that isn't redundant.
Does TYPE_SIZE have a different meaning than TYPE_PRECISION
for non-integer types? Floats, vectors, complex?
The RX toolchain has a similar patch where the option is doubles
while the folder name is double.
There's no reason for one toolchain to be consistent with another,
though.
Would it be ok to revert this line from 64-bit-doubles to 64-bit-double
as this?
+MULTILIB_DIRNAMES = g10
Part 1 of 4, split from the full patch. The purpose of this set of
changes is to remove assumptions in GCC about type sizes. Previous to
this patch, GCC assumed that all types were powers-of-two in size, and
used naive math accordingly.
Old:
POINTER_SIZE / BITS_PER_UNIT
Part 3 of 4, split from the full patch. Additional optimization
opportunity, since the MSP430 does a lot of conversions between HImode
and PSImode.
gcc/
* expr.c (convert_move): If the target has an explicit converter,
use it.
Index: gcc/expr.c
Part 4 of 4, split from the full patch. This is the MSP430-specific
use of the new intN framework to enable true 20-bit pointers. Since
I'm one of the MSP430 maintainers, this patch is being posted for
reference, not for approval.
gcc/config/msp430
* config/msp430/msp430-protos.h
201 - 300 of 1257 matches
Mail list logo
