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.
Is there an option that I missed to force it to build for the non
MSP430X memory-model?
If you specify -mmcu= when compiling, specify the same -mmcu= when
linking, else the tools don't know which libraries to use.
If that fails, add -mcpu=msp430x or -mcpu=msp430 to force the issue.
main() is not a root with gcc, start() is (defined by your linker
script), and is usually provided by crt0.o - except you told it not to
with -nodefaultlibs.
The flag you really want is -minrt, which tells gcc to encode extra
information in each object that helps the linker reduce the amount of
The map file is telling me a few small functions are being linked in
(memset, memcpy) and I assume that since the standard library wasn't built
with -ffunction-sections or -fdata-sections that it then links the entire
library.
-ffunction-sections affects multiple functions in the same
For the journal you always keep all log history in it's original
state
On low-bandwidth systems, like laptops or diskless nodes, it's a
performance hit to generate the log entry in the first place. It's
really important to be able to configure the system to *generate* a
minimal amount of
It's not really feasible to extract those changes and apply them to a
non-bundled source directory since the base version isn't exactly GCC
4.9.1.If you or TI could provide information on whether those
patches are likely to get refactored and merged upstream, and any
timeline information
-mmcu=msp430f449 -O2 -Wall -Wno-old-style-declaration -std=c99
By specifying -std=c99 you have disabled all the GNU extensions, including
asm.
Try --std=gnuc99 instead, or replace asm with __asm__ in those headers.
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.
The coding in assembly is necessary currently?
Yes, but only for limited cases where a higher level language is
inappropriate or insufficient.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct:
that question makes no sense at all and it's the wrong mailing-list
The question made sense to me, and where else would one discuss
development besides a devel@ list?
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of
The GCC manual, chapter Extensions to the C Language Family section
Function Attributes documents the interrupt attribute:
void f () __attribute__ ((interrupt (15)));
or
void __attribute__ ((interrupt (15))) f ()
{
}
Note that the attribute tells gcc to
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.
What's the rationale here? I mean, we have so many dependencies, if
you want to minimize them, you have a lng way to go...
When I bootstrapped Fedora for ARM way back when, I had to deal with
these dependencies. A lot. Finding a minimal set of RPMs to
cross-compile to get a bootable core
If I saw systemd-filesystem installed, then I would think that
something needs to be placed into the systemd folder structure,
Perhaps the bug is this: that you need to install a whole other RPM
just to make a directory exist so you can put a file in it.
Why can't the RPM providing the file
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
Thanks. I see that arm-elf-gcc includes newlib in the compiler
package. I’m able to build binutils just fine, unfortunately gcc has
some errors with clang (stray ‘-static-libgcc’ options that are not
supported by clang).
While a native GCC build is likely to be built with alternate
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
Welcome to the 21st century!
Do we have different eyes and brains than we did last century?
Because otherwise, excessively wide paragraphs are just as hard to
read now as they were then.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
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?
Also, why are you building msp430-elf-gcc in two steps, Peter? Can I
build newlib first and then msp430-elf-gcc?
How do you build newlib without a C compiler?
--
Open source business process management suite built on
Ah, yes, sorry. What I meant was can msp430-elf-gcc be built without
newlib? I wanted to create a separate package for newlib.
Typically, the gcc runtime (libgcc) needs to know what the usual
runtime will be, as some routines in libgcc may need to call C library
functions. The usual way to
Will TI be providing sufficient documentation on the CIO API that the
msp430 implementation can be completed, thus making the system
interface usable in other frameworks?
http://processors.wiki.ti.com/index.php/CIO_System_Call_Protocol
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
Since the test on __STRICT_ANSI__ is removed for all other uses, it would
seem consistent to me to remove this one as well. Besides, you are already
testing __GLIBCXX_USE_INT_N_0, which as far as I understand is protected
by !flag_iso (with the exception of size_t).
Yup, I'll clean that
The changes to dwarf2asm.c, cppbuiltin.c, optabs.c, defaults.h, expr.c,
expmed.c, tree-dfa.c, simplify-rtx.c, lto-object.c, loop-iv.c, varasm.c,
the msp430 back end and some of the stor-layout.c changes don't look like
they should depend on the rest of the patch. I think it would help
Looks ok to me, but can you add a testcase please?
I have a testcase, but if -flto the testcase doesn't include *any*
definition of the test function, just all the LTO data. Is this
normal?
Also check if 4.9 is affected.
It is... same fix works, though.
If you have any other suggestions other than keeping the name, we
will be open to consider them.
My suggestion is to keep the name, but as you're not open to that
option, there's no point in me bothering, is there?
--
devel mailing list
devel@lists.fedoraproject.org
Nothing will change for you, the yum command will still exist for a
few more Fedora releases,
Which only postpones the problem.
just as the `service` command that was superseded by systemctl like
5 releases of Fedora ago exists.
Which is currently annoying me, for the same reason.
--
Actually it is. The pretty much part is exactly the reason why to
change the name. If we didn't, a ton of users who are not reading
this conversation would start filing regression bugs. If we set
their expectations right, warning them that yum is no more, they are
far less likely to do so.
Forcing the users to type a different command name to get exactly the
same functionality only serves to annoy the user.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Please review the patch and let me know if there should be any modifications
in it?
Have you checked the other alignment macros to see if they need to be
fixed too?
* config/rx/rx.h (Corrected macro LABEL_ALIGN).
This should be :
* config/rx/rx.h (LABEL_ALIGN): description
Minor tweak to space optimization. Committed.
* config/rx/rx.c (rx_max_skip_for_label): Don't skip anything if -Os.
Index: config/rx/rx.c
===
--- config/rx/rx.c (revision 211479)
+++ config/rx/rx.c (working copy)
The RX100/200 families have 4 byte cache lines, vs 8 bytes for the
RX600 family. Applied.
* config/rx/rx.h (FUNCTION_BOUNDARY): Adjust for RX100/200 4-byte
cache lines.
* config/rx/rx.c (rx_option_override): Likewise.
(rx_align_for_label): Likewise.
Index:
If the combined bitfields are exactly the size of the mode, the logic
for detecting range overflow is flawed - it calculates an ending
position that's the position of the first bit in the next field.
In the case of short for example, you get 16 15 without this
patch (comparing size to
The reason msp430 is different is because CIO *can* be used on real
hardware, to communicate through a hardware debugger or emulator pod.
Perhaps moving the cio-enabled nosys to a libcio.a? Then we'd need a
-mcio option to gcc to enable it, but could default to doing the
generic nosys thing...
Could you try the gdb from the FSF's source tree? It's version 7.7
and has the RH simulator in it. However, I don't think the profiling
results from the RH simulator will be useful to you if you want
cycle-accurate counts, but it will show you every single instruction
being executed.
Also,
Is there any best way to pass data in / out of the simulator? I
guess I can use the run program and set up a memory region for the
input data, and write a little main() to feed it into through the
algorithm. But if there's an easier way, I'd like to hear about it
before I do it the hard
Wait, a write() syscall made in the msp430 binary can show up on stdout of
the simulator? How does that work? Do I need to link in any special
function for that?
The RH simulator (msp430-elf-run, not msp430-run) supports TI's CIO
interface, at least for write(), which means the RH simulator
You need to be using msp430-elf-gcc for that feature, not mspgcc as
Right, as previously agreed on, we're using msp430-foo for the
non-RH tools, and msp430-elf-foo for the RH tools.
--
Learn Graph Databases - Download
Will TI be providing sufficient documentation on the CIO API that the
msp430 implementation can be completed, thus making the system
interface usable in other frameworks?
I have enough information to finish the msp interface, I've just had
no reason to do so so far. CIO doesn't have exit()
Is this documented? How can I write drivers to this standard?
That's the catch. It's not documented. I have a sample
implementation from TI that I used (with permission) to write the
simulator/libgloss code.
In general, though, the target side works like this: fill up a
command buffer at
That doesn't really help the rest of us, though.
Yup, I've complained to TI about that. I'll bring it up again.
I'm interfacing with other external hardware including LCDs and FAT
file systems, and I want to re-use the standard libc interface at
the application layer.
Could you elaborate
I'd already outlined my expectations in the earlier thread; see for
example
http://www.mail-archive.com/mspgcc-users@lists.sourceforge.net/msg12038.html.
If the msp430 version supplies a weak definition of _write() (not
write())
newlib uses either write() or _write() depending on which
Can you elaborate on branch-to-self opcode?
Any branch opcode that branches to itself, i.e. a one-opcode infinite
loop.
1: BR #1b
This also works with any indirect or conditional branch, as long as
the target of the branch is the address of the branch opcode. Here's
the code in the
You can do that with the RH newlib as long as you don't link in
libgloss's versions of the low-level routines - i.e. remove -lgloss
from your link line and add -lbspacm.
To clarify: don't link in -lnosys if you're not compiling with -msim
or don't link in -lsim if you are compiling with -msim
Sorry, I don't know anything about CCS, just about the gnu tools
themselves. You'll have to wait for someone from TI to reply.
--
Time is money. Stop wasting it! Get your web API in 5 minutes.
www.restlet.com/download
The right way to enable large model is to use -mlarge
If that causes problems, we'd need to know more about the problem to
try to diagnose it.
Note that adding -mlarge means that *all* objects and libraries must
be recompiled with -mlarge, you can't mix and match large and small
model.
401 - 500 of 6592 matches
Mail list logo
