Re: __intN patch 3/5: main __int128 - __intN conversion.
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 types that are the same size, not different sizes, and as I said the __intN types are never the same size as standard types (except __int128) so there are no conversions to worry about - in the code you're referring to. In the common parts of the MI the __intN types are handled separately, in each case where i_t[] is referenced. We still need mangling tests for __int20, though. 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?
Re: __intN patch 3/5: main __int128 - __intN conversion.
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 functional differences on mainstream targets. I imagine the code is there for when __int128 is the same size as some other types besides long long.
Re: __intN patch 3/5: main __int128 - __intN conversion.
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
Re: __intN patch 3/5: main __int128 - __intN conversion.
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 follows the long long code. Also, we should be checking for both signed and unsigned variants. In this case, we know that the two types are the same bitsize. We also know that no __intN type has the same size as a standard type (__int128 being an exception). So in any case where other __intN types match, they won't match any of the other tests in this area anyway. Aside from choosing unsigned vs sighed (which the code does), there are no other conversions within those bitsizes. So if you think the __int128 case should be elsewhere in that logic (and it seems to me that long long *should* be preferred over __int128 if they're ths same bitsize) I can move it, but I don't think there's any need to worry about other __intN types here. If you plan to allow __intN with sizes between those of int and long long, they need to have the appropriate intermediate conversion rank for their size. But... we don't know the bit sizes at the gcc source level, we only know them by iterating the array. We'd have to iterate the array at evey step to see if it's between bitsize N and M, or add the standard types to some array, or add the __intN variants to integer_types[] and re-sort i_t[]. However, doing that introduces the __intN types to *everything* that uses integer_types[]. I was hesitant to add nonstandard types to the standard promotion rules. Basically I think the integral conversion code in cp_common_type ought to be rewritten to work on integer_types rather than naming specific types. That would be the re-sort it option. - 'n', /* itk_int128 */ - 'o', /* itk_unsigned_int128 */ + /* __intN types are handled separately */ Where are they mangled now? I also don't see any mangling tests. They mangle as Inn like I20 or I128 (that might be the wrong letter, but the syntax is like that). It surprised me that there was a case for other unknown types, but there's a case for it :-) The NULs are there just to ensure the array access works, and to tell the code that there isn't a special case for those types.
Re: __intN patch 3/5: main __int128 - __intN conversion.
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: Likewise. * include/c_std/cstdlib: Likewise. * include/bits/cpp_type_traits.h: Likewise. * include/c_global/cstdlib: Likewise. These libstdc++ changes are OK for trunk. Do I still need approval for gcc/cp/* or do these cover it?
Re: __intN patch 3/5: main __int128 - __intN conversion.
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/*) ? https://gcc.gnu.org/ml/gcc-patches/2014-08/msg02360.html Thanks!
Re: __intN patch 3/5: main __int128 - __intN conversion.
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.
Re: [Mspgcc-users] msp430-gcc-full-linux-installer-2.1.1.0.run
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. -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] msp430-elf-g++ optimizing out main()
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 runtime needed to only the routines that will actually do something useful (and, most likely, remove C++ constructors/destructors at the same time). If even with that flag the code still doesn't fit, add -Wl,-Map,somemap.txt and see *what* functions are getting included, and why. It may turn out to be something silly. Also, if main() returns a value, the runtime may include extra processing to happen at exit() time, which is kinda pointless on an MCU. main() should end in a while(1); so it doesn't return. -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] msp430-elf-g++ optimizing out main()
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 object. It has no effect on separate objects. Functions like memcpy() and memset() are in separate source files in the library, so will be linked in or not depending only on whether or not they're actually needed. Is this also a side effect of the library not being build with those sections flags? If so, why isn't the library built like that for cases like this where you want to have only a few small functions? One could argue that the library should be built with whatever flags the user specifies. This quickly turns into thousands, if not millions, of permutations of builds, and is not practical. The only way to solve this is to build the whole library as part of your project, so you can choose the flags you want. Also, the -ffunction-section and -fdata-section flags are mostly useless for the standard libraries *anyway*, as, as I mentioned already, they're already broken into one function per section. The -minrt option is designed to work mostly with the startup code, by selectively linking in parts of (what is normally) crt0.s based on a more global knowledge of features used by the program. If you use a C++ function that uses exceptions, the exception startup gets linked in. Without -minrt, the exception startup gets linked in even if nothing uses exceptions. -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
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 communications. Being able to filter the results later is a separate issue. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Mspgcc-users] replacing libgloss in msp430-elf
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 that's available, I think most folks here would be interested. You need my __intN patch set, currently being reviewed upstream. Some parts have been approved and applied, but you still need the main conversion (3/5, pending libg++ review) and the msp430-specific part (5/5, just waiting on part 3/5). This patch set is based on the TI-specific patch in their 4.9 sources. https://gcc.gnu.org/ml/gcc-patches/2014-08/threads.html#01398 -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] No clue for thsi....
-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. -- Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
[msp430] fix RLAM opcodes
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
===
--- gcc/config/msp430/msp430.md (revision 215228)
+++ gcc/config/msp430/msp430.md (working copy)
@@ -565,13 +565,13 @@
)
(define_insn extendhipsi2
[(set (match_operand:PSI 0 nonimmediate_operand =r)
(subreg:PSI (sign_extend:SI (match_operand:HI 1 nonimmediate_operand
0)) 0))]
TARGET_LARGE
- RLAM #4, %0 { RRAM #4, %0
+ RLAM.A #4, %0 { RRAM.A #4, %0
)
;; Look for cases where integer/pointer conversions are suboptimal due
;; to missing patterns, despite us not having opcodes for these
;; patterns. Doing these manually allows for alternate optimization
;; paths.
@@ -593,21 +593,21 @@
(define_insn extend_and_shift1_hipsi2
[(set (subreg:SI (match_operand:PSI 0 nonimmediate_operand =r) 0)
(ashift:SI (sign_extend:SI (match_operand:HI 1 nonimmediate_operand
0))
(const_int 1)))]
TARGET_LARGE
- RLAM #4, %0 { RRAM #3, %0
+ RLAM.A #4, %0 { RRAM.A #3, %0
)
(define_insn extend_and_shift2_hipsi2
[(set (subreg:SI (match_operand:PSI 0 nonimmediate_operand =r) 0)
(ashift:SI (sign_extend:SI (match_operand:HI 1 nonimmediate_operand
0))
(const_int 2)))]
TARGET_LARGE
- RLAM #4, %0 { RRAM #2, %0
+ RLAM.A #4, %0 { RRAM.A #2, %0
)
; Nasty - we are sign-extending a 20-bit PSI value in one register into
; two adjacent 16-bit registers to make an SI value. There is no MSP430X
; instruction that will do this, so we push the 20-bit value onto the stack
; and then pop it off as two 16-bit values.
Re: [msp430] fix RLAM opcodes
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.
Re: The coding in binary code and assembly are necessary currently?
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: http://fedoraproject.org/code-of-conduct
Re: The coding in binary code and assembly are necessary currently?
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 Conduct: http://fedoraproject.org/code-of-conduct
Re: [Mspgcc-users] msp430-elf-gcc (GCC) 4.9.1 20140707 (prerelease (msp430-14r1-10)) (GNUPro 14r1) (Based on: GCC 4.8 GDB 7.7 Binutils 2.24 Newlib 2.1)
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 create a section
__interrupt_vector_15 (in this case) that contains a pointer to the
function. It's up to the linker to combine these sections into your
interrupt vector table, so make sure you either use TI's runtime or
understand what gcc is doing behind the scenes. Use msp430-elf-gcc
-S file.c or msp430-elf-gcc --save-temps ... to get access to the
*.s assembly files to see what's going on.
--
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [PATCH 0/5] Yet more use of rtx subclasses; possible rl78 bug
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 reasonable. DJ might want to chime in here with a comment or two for testing, but I'm comfortable with how you've addressed this issue. Given the amount of dead sets in rl78's code, I think you'd have a hard time *not* executing that line ;-) But yes, your interpretation of what should have been happening is correct. Thanks! Given that this type of bug is what your changes are *supposed* to catch, I think you should claim success now!
Re: [msp430] add missing option documentation
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.
[msp430] add missing option documentation
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 copy)
@@ -834,13 +834,13 @@ Objective-C and Objective-C++ Dialects}.
@emph{Moxie Options}
@gccoptlist{-meb -mel -mno-crt0}
@emph{MSP430 Options}
@gccoptlist{-msim -masm-hex -mmcu= -mcpu= -mlarge -msmall -mrelax @gol
--mhwmult=}
+-mhwmult= -minrt}
@emph{NDS32 Options}
@gccoptlist{-mbig-endian -mlittle-endian @gol
-mreduced-regs -mfull-regs @gol
-mcmov -mno-cmov @gol
-mperf-ext -mno-perf-ext @gol
@@ -18583,12 +18583,19 @@ routine. This saves space in the genera
inline. This makes for bigger, but faster code.
The hardware multiply routines disable interrupts whilst running and
restore the previous interrupt state when they finish. This makes
them safe to use inside interrupt handlers as well as in normal code.
+@item -minrt
+@opindex minrt
+Enable the use of a minimum runtime environment - no static
+initializers or constructors. This is intended for memory-constrained
+devices. The compiler will include special symbols in some objects
+that tell the linker and runtime which code fragments are required.
+
@end table
@node NDS32 Options
@subsection NDS32 Options
@cindex NDS32 Options
Re: __intN patch 2/5: Fix assumptions about mode precisions
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 TYPE_SIZE GET_MODE_BITSIZE New: POINTER_SIZE_UNITS (ceil, not floor) TYPE_PRECISION GET_MODE_PRECISION 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. (dw2_output_indirect_constant_1): Likewise. * expmed.c (init_expmed_one_conv): We now know the sizes of partial int modes. * loop-iv.c (iv_number_of_iterations): Use precision, not size. * optabs.c (expand_float): Use precision, not size. (expand_fix): Likewise. * simplify-rtx (simplify_unary_operation_1): Likewise. * tree-dfa.c (get_ref_base_and_extent): Likewise. * varasm.c (assemble_addr_to_section): Round up pointer sizes. (default_assemble_integer) Likewise. (dump_tm_clone_pairs): Likewise. * dwarf2out.c (mem_loc_descriptor): Allow partial-int modes also. * var-tracking.c (adjust_mems): Allow partial-int modes also. (prepare_call_arguments): Likewise. * stor-layout.c (finalize_type_size): Preserve precision. (layout_type): Use precision, not size. Didn't see a note if this had been boostrapped/regression tested independently or not, but it's still good to go in my mind. I didn't test this one independently because it doesn't really *do* anything if you don't have a non-power-of-two type. I did test the whole set of patches with full bootstrap-regression though, both on x86_64 and msp430. I strongly suspect we'll find other places which need conversion and we can fault in those fixes if/when we find them. I suspect that also, despite grepping and reviewing the whole source tree. I wonder if this will fix a long standing h8 dwarf2out bug... I guess I'll have the chance to check relatively soon. :-)
Re: __intN patch 4/5: testsuite updates
* 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. * gcc.dg/torture/pta-ptrarith-3.c: Use __SIZE_TYPE__ instead of int. * gcc.dg/torture/pr36373-10.c: Use __SIZE_TYPE__ if present. * gcc.dg/torture/pr57864.c: Use __SIZE_TYPE__. * gcc.dg/torture/pr26763-2.c: Use __SIZE_TYPE__ instead of int. * gcc.dg/tree-ssa/isolate-3.c: Use __SIZE_TYPE__ instead of long unsigned int. * gcc.dg/tree-ssa/isolate-3.c: Likewise. * gcc.dg/pr52549.c: Use __SIZE_TYPE__ if present. OK. jeff Thanks! Committed.
Re: __intN patch 1/5: convert-move optimization
* expr.c (convert_move): If the target has an explicit converter, use it. OK. Thanks! Committed.
Re: __intN patch 2/5: Fix assumptions about mode precisions
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. (dw2_output_indirect_constant_1): Likewise. * expmed.c (init_expmed_one_conv): We now know the sizes of partial int modes. * loop-iv.c (iv_number_of_iterations): Use precision, not size. * optabs.c (expand_float): Use precision, not size. (expand_fix): Likewise. * simplify-rtx (simplify_unary_operation_1): Likewise. * tree-dfa.c (get_ref_base_and_extent): Likewise. * varasm.c (assemble_addr_to_section): Round up pointer sizes. (default_assemble_integer) Likewise. (dump_tm_clone_pairs): Likewise. * dwarf2out.c (mem_loc_descriptor): Allow partial-int modes also. * var-tracking.c (adjust_mems): Allow partial-int modes also. (prepare_call_arguments): Likewise. * stor-layout.c (finalize_type_size): Preserve precision. (layout_type): Use precision, not size. Didn't see a note if this had been boostrapped/regression tested independently or not, but it's still good to go in my mind. I strongly suspect we'll find other places which need conversion and we can fault in those fixes if/when we find them. Thanks! Committed. (and I think I found another case to fix just today, which affects m32c :-P )
push_rounding vs memcpy vs stack_pointer_delta
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 c)
{
dj2 (x, a, b, c);
}
if (pass == 0)
{
. . .
}
else
{
normal_call_insns = insns;
/* Verify that we've deallocated all the stack we used. */
gcc_assert ((flags ECF_NORETURN)
|| (old_stack_allocated
== stack_pointer_delta - pending_stack_adjust));
}
After much debugging, it turns out that the argument that's memcpy'd
to stack doesn't adjust stack_pointer_delta the same way that the
other arguments do (i.e. push_block and push_args don't adjust it
consistently, or something like that.)
I came up with this patch:
Index: expr.c
===
--- expr.c (revision 214599)
+++ expr.c (working copy)
@@ -4234,12 +4234,16 @@ emit_push_insn (rtx x, enum machine_mode
/* Get the address of the stack space.
In this case, we do not deal with EXTRA separately.
A single stack adjust will do. */
if (! args_addr)
{
temp = push_block (size, extra, where_pad == downward);
+#ifdef PUSH_ROUNDING
+ if (CONST_INT_P (size))
+ stack_pointer_delta += INTVAL (size) + extra;
+#endif
extra = 0;
}
else if (CONST_INT_P (args_so_far))
temp = memory_address (BLKmode,
plus_constant (Pmode, args_addr,
skip + INTVAL (args_so_far)));
But builds of libstdc++v3 demonstrate that sometimes
stack_pointer_delta *is* adjusted consistently, thus there must be
some more complex logic for determining when the extra adjustment
(i.e. my patch) should be made, or it's in the wrong place.
So... could someone more familiar with this code enlighten me on the
actual rules for what stack_pointer_delta means and when it gets
adjusted, and where (in theory) a memcpy'd argument on a push_args
target should update it (if at all)?
Thanks!
DJ
Re: [BUILDROBOT][PATCH] Fix warnings in the mep-elf target
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.
Re: systemd dependencies
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 was very difficult because of dependencies, and managing the path up to koji was a nightmare. Even after that, there were some packages that couldn't be built *at all* because of circuilar dependencies or dependencies on them. So, to all of you who say oh well to dependencies... I hate you. Seriously. Not only have you made my personal job miserable for a while, but you demonstrate the worst traits of engineering. If there's a problem, you don't hide it or just let it be because we're used to it. You *fix* it. And you make sure it *stays* fixed. Take some pride in your work! Do the best you can! If you're only willing to do mediocre work and let problems exist because you can't be bothered to fix them, then Fedora will at best be a mediocre product. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: systemd dependencies
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 just make the directory and not have a dependency at all? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: __intN patch 3/5: main __int128 - __intN conversion.
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
predefining to pass information to libstdc++.
Like this?
Yes (well, the libstdc++ changes will need to go to the libstdc++ mailing
list for review there, but this is the sort of thing I'd expect to keep
the way libstdc++ defines these limits as consistent as possible between
different types).
Ok, here's the updated c-cppbuiltins.c and all the libstdc++-v3
changes, cross-posted to the libstdc++ list. I tested the macros on
x86-64 (before and after) and msp430 (after) with __int128 and __int20
and get the right values in all cases.
Index: gcc/c-family/c-cppbuiltin.c
===
--- gcc/c-family/c-cppbuiltin.c (revision 213886)
+++ gcc/c-family/c-cppbuiltin.c (working copy)
@@ -775,12 +775,14 @@ cpp_iec_559_complex_value (void)
}
/* Hook that registers front end and target-specific built-ins. */
void
c_cpp_builtins (cpp_reader *pfile)
{
+ int i;
+
/* -undef turns off target-specific built-ins. */
if (flag_undef)
return;
define_language_independent_builtin_macros (pfile);
@@ -845,12 +847,29 @@ c_cpp_builtins (cpp_reader *pfile)
builtin_define_type_minmax (__WCHAR_MIN__, __WCHAR_MAX__,
underlying_wchar_type_node);
builtin_define_type_minmax (__WINT_MIN__, __WINT_MAX__, wint_type_node);
builtin_define_type_max (__PTRDIFF_MAX__, ptrdiff_type_node);
builtin_define_type_max (__SIZE_MAX__, size_type_node);
+ for (i = 0; i NUM_INT_N_ENTS; i ++)
+if (int_n_enabled_p[i])
+ {
+ char buf[35+20+20];
+
+ /* These are used to configure the C++ library. */
+
+ if (!flag_iso || int_n_data[i].bitsize == POINTER_SIZE)
+ {
+ sprintf (buf, __GLIBCXX_TYPE_INT_N_%d=__int%d, i,
int_n_data[i].bitsize);
+ cpp_define (parse_in, buf);
+
+ sprintf (buf, __GLIBCXX_BITSIZE_INT_N_%d=%d, i,
int_n_data[i].bitsize);
+ cpp_define (parse_in, buf);
+ }
+ }
+
/* stdint.h and the testsuite need to know these. */
builtin_define_stdint_macros ();
/* Provide information for library headers to determine whether to
define macros such as __STDC_IEC_559__ and
__STDC_IEC_559_COMPLEX__. */
@@ -993,15 +1012,20 @@ c_cpp_builtins (cpp_reader *pfile)
else if (flag_stack_protect == 1)
cpp_define (pfile, __SSP__=1);
if (flag_openmp)
cpp_define (pfile, _OPENMP=201307);
- if (int128_integer_type_node != NULL_TREE)
-builtin_define_type_sizeof (__SIZEOF_INT128__,
- int128_integer_type_node);
+ for (i = 0; i NUM_INT_N_ENTS; i ++)
+if (int_n_enabled_p[i])
+ {
+ char buf[15+20];
+ sprintf(buf, __SIZEOF_INT%d__, int_n_data[i].bitsize);
+ builtin_define_type_sizeof (buf,
+ int_n_trees[i].signed_type);
+ }
builtin_define_type_sizeof (__SIZEOF_WCHAR_T__, wchar_type_node);
builtin_define_type_sizeof (__SIZEOF_WINT_T__, wint_type_node);
builtin_define_type_sizeof (__SIZEOF_PTRDIFF_T__,
unsigned_ptrdiff_type_node);
/* A straightforward target hook doesn't work, because of problems
Index: libstdc++-v3/src/c++11/limits.cc
===
--- libstdc++-v3/src/c++11/limits.cc(revision 213886)
+++ libstdc++-v3/src/c++11/limits.cc(working copy)
@@ -385,60 +385,72 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
const bool numeric_limitsunsigned long long::is_bounded;
const bool numeric_limitsunsigned long long::is_modulo;
const bool numeric_limitsunsigned long long::traps;
const bool numeric_limitsunsigned long long::tinyness_before;
const float_round_style numeric_limitsunsigned long long::round_style;
-#if !defined(__STRICT_ANSI__) defined(_GLIBCXX_USE_INT128)
- const bool numeric_limits__int128::is_specialized;
- const int numeric_limits__int128::digits;
- const int numeric_limits__int128::digits10;
- const int numeric_limits__int128::max_digits10;
- const bool numeric_limits__int128::is_signed;
- const bool numeric_limits__int128::is_integer;
- const bool numeric_limits__int128::is_exact;
- const int numeric_limits__int128::radix;
- const int numeric_limits__int128::min_exponent;
- const int numeric_limits__int128::min_exponent10;
- const int numeric_limits__int128::max_exponent;
- const int numeric_limits__int128::max_exponent10;
- const bool numeric_limits__int128::has_infinity;
- const bool numeric_limits__int128::has_quiet_NaN;
- const bool numeric_limits__int128::has_signaling_NaN;
- const float_denorm_style numeric_limits__int128::has_denorm;
- const bool
Re: __intN patch 3/5: main __int128 - __intN conversion.
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 remove one after adding it). They reflect a previous check in libstdc++ to remove __int128 specializations for non-ISO cases. Now, though, libstdc++ doesn't know which types are needed for pointers and which aren't, so the check was moved to inside gcc, which does know.
Re: __intN patch 3/5: main __int128 - __intN conversion.
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 remember. ITK has to be sorted by bitsize and it's used
for type promotion, we don't want types promoted *to* the __intN
types, just *from* them.
+static bool
+standard_type_bitsize (int bitsize)
+{
+ /* As a special exception, we always want __int128 enabled if possible.
*/
+ if (bitsize == 128)
+return false;
+ if (bitsize == CHAR_TYPE_SIZE
+ || bitsize == SHORT_TYPE_SIZE
+ || bitsize == INT_TYPE_SIZE
+ || bitsize == LONG_TYPE_SIZE
+ || (bitsize == LONG_LONG_TYPE_SIZE LONG_LONG_TYPE_SIZE
GET_MODE_BITSIZE (TImode)))
I don't think there should be a special case depending on the size of long
long here.
I think it was from before I had the special case for bitsize == 128. I'll
remove it.
+ /* This must happen after the backend has a chance to process
+command line options, but before the parsers are
+initialized. */
+ for (i = 0; i NUM_INT_N_ENTS; i ++)
+ if (targetm.scalar_mode_supported_p (int_n_data[i].m)
+! standard_type_bitsize (int_n_data[i].bitsize)
+int_n_data[i].bitsize = HOST_BITS_PER_WIDE_INT * 2)
+ int_n_enabled_p[i] = true;
This HOST_BITS_PER_WIDE_INT * 2 check seems wrong.
That check was there before, for __int128, I left it as-is. There is no
__int128 (currently) if it's bigger then HBPWI*2.
mode_for_size (unsigned int size, enum mode_class mclass, int limit)
{
- enum machine_mode mode;
+ enum machine_mode mode = BLKmode;
+ int i;
I don't see any need for this initialization to be added.
Removed.
bprecision
-= MIN (precision + BITS_PER_UNIT_LOG + 1, MAX_FIXED_MODE_SIZE);
+= MIN (precision, MAX_FIXED_MODE_SIZE);
This change doesn't make sense to me - if it is needed, I think it should
be separated out, not included in this patch which should simply about
providing generic __intN support in the cases where __int128 is currently
supported.
Perhaps is belongs in the 1/5 patch, where I removed lots of assume
all types are powers-of-two sizes logic? I split up the patch and
logs by hand from a master patch, I'm not surprised I got a few
mis-placed.
@@ -1157,13 +1165,13 @@ enum omp_clause_map_kind
OMP_CLAUSE_MAP_ALLOC,
OMP_CLAUSE_MAP_TO,
OMP_CLAUSE_MAP_FROM,
OMP_CLAUSE_MAP_TOFROM,
/* The following kind is an internal only map kind, used for pointer
based
array sections. OMP_CLAUSE_SIZE for these is not the pointer size,
- which is implicitly POINTER_SIZE / BITS_PER_UNIT, but the bias. */
+ which is implicitly POINTER_SIZE_UNITS, but the bias. */
POINTER_SIZE_UNITS changes belong in another patch, not this one.
Again, probably the 1/5 patch.
/* ptr_type_node can't be used here since ptr_mode is only set when
toplev calls backend_init which is not done with -E or pch. */
- psize = POINTER_SIZE / BITS_PER_UNIT;
+ psize = POINTER_SIZE_UNITS;
Likewise.
Likewise :-)
@@ -844,12 +846,47 @@ c_cpp_builtins (cpp_reader *pfile)
builtin_define_type_max (__LONG_LONG_MAX__,
long_long_integer_type_node);
builtin_define_type_minmax (__WCHAR_MIN__, __WCHAR_MAX__,
underlying_wchar_type_node);
builtin_define_type_minmax (__WINT_MIN__, __WINT_MAX__,
wint_type_node);
builtin_define_type_max (__PTRDIFF_MAX__, ptrdiff_type_node);
builtin_define_type_max (__SIZE_MAX__, size_type_node);
+ for (i = 0; i NUM_INT_N_ENTS; i ++)
+if (int_n_enabled_p[i])
+ {
+ char buf[35+20+20];
+ char buf_min[15+20];
+ char buf_max[15+20];
+
+ sprintf(buf_min, __INT%d_MIN__, int_n_data[i].bitsize);
+ sprintf(buf_max, __INT%d_MAX__, int_n_data[i].bitsize);
All this block of code appears to be new rather than replacing any
existing code doing something similar with __int128. As such, I think
it's best considered separately from the main __intN support.
For each __intN we need to provide an __INTN_MIN__ and
__INTN_MAX__, just like for char we provide __CHAR_MIN__ and
__CHAR_MAX__.
Also note missing spaces before '(' in this code.
Fixed.
Some of this may be needed for libstdc++, but not all. As far as I can
tell, the existing __glibcxx_min, __glibcxx_max, __glibcxx_digits,
__glibcxx_digits10, __glibcxx_max_digits10 macros can be used in most
cases and avoid any need to predefine macros for the min or max of __intN;
you only need to communicate which types exist and their sizes in bits
(that is, a single macro predefine for each N, with anything else being
considered separately if otherwise thought desirable).
I tried that, and wasn't able to get a simpler macro to do it inline
Re: __intN patch 3/5: main __int128 - __intN conversion.
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 an __INTN_MIN__ and __INTN_MAX__, just like for char we provide __CHAR_MIN__ and __CHAR_MAX__. No, those are provided for use by limits.h, which only covers standard C types (and in particular does not cover __int128). Ok, removed. 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. Since the other macros use this macro, we'd need a complete second set of macros just for the __intN types anyway, each of which takes a bitsize and passes it down. Since gcc already knows all the right answers for the __intN types and needs to emit other macros for them anyway, where's the benefit? Also, consider that the specialization for all the other types is duplicated in full, I'm already using less source code for my 1..4 types than the library would have used for its 1..4 types ;-)
Re: __intN patch 3/5: main __int128 - __intN conversion.
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 predefining to pass information to libstdc++. Like this? #define __glibcxx_signed_b(T,B) ((T)(-1) 0) #define __glibcxx_min_b(T,B)\ (__glibcxx_signed_b (T,B) ? -__glibcxx_max_b (T,B) - 1 : (T)0) #define __glibcxx_max_b(T,B)\ (__glibcxx_signed_b (T,B) ? \ (T)1 (__glibcxx_digits_b (T,B) - 1)) - 1) 1) + 1) : ~(T)0) #define __glibcxx_digits_b(T,B) \ (B - __glibcxx_signed_b (T,B)) // The fraction 643/2136 approximates log10(2) to 7 significant digits. #define __glibcxx_digits10_b(T,B) \ (__glibcxx_digits_b (T,B) * 643L / 2136) #define __glibcxx_signed(T) \ __glibcxx_signed_b (T, sizeof(T) * __CHAR_BIT__) #define __glibcxx_min(T) \ __glibcxx_min (T, sizeof(T) * __CHAR_BIT_) #define __glibcxx_max(T) \ __glibcxx_max (T, sizeof(T) * __CHAR_BIT_) #define __glibcxx_digits(T) \ __glibcxx_digits (T, sizeof(T) * __CHAR_BIT_) #define __glibcxx_digits10(T) \ __glibcxx_digits10 (T, sizeof(T) * __CHAR_BIT_)
[rl78] allow const-far moves
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) @@ -43,7 +43,7 @@ (define_insn *movhi_virt [(set (match_operand:HI 0 nonimmediate_operand =vS, Y, v, Wfr) - (match_operand:HI 1 general_operand viYS, viS, Wfr, v))] + (match_operand:HI 1 general_operand viYS, viS, Wfr, vi))] rl78_virt_insns_ok () v.movw %0, %1 [(set_attr valloc op1)]
[rl78] disable umul for G10
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. (umulqihi3_real): Likewise. Index: config/rl78/rl78-expand.md === --- config/rl78/rl78-expand.md (revision 213995) +++ config/rl78/rl78-expand.md (working copy) @@ -145,8 +145,8 @@ [(set (match_operand:HI 0 register_operand) (mult:HI (zero_extend:HI (match_operand:QI 1 register_operand)) (zero_extend:HI (match_operand:QI 2 register_operand] + !TARGET_G10 - ) (define_expand andqi3 Index: config/rl78/rl78-real.md === --- config/rl78/rl78-real.md(revision 213995) +++ config/rl78/rl78-real.md(working copy) @@ -157,7 +157,7 @@ [(set (match_operand:HI 0 register_operand =A,A) (mult:HI (match_operand:HI 1 rl78_nonfar_operand 0,0) (match_operand:HI 2 rl78_24_operand N,i)))] - rl78_real_insns_ok () + rl78_real_insns_ok () !TARGET_G10 @ shlw\t%0, 1 shlw\t%0, 2 @@ -167,7 +167,7 @@ [(set (match_operand:HI 0 nonimmediate_operand =A) (mult:HI (zero_extend:HI (match_operand:QI 1 general_operand %a)) (zero_extend:HI (match_operand:QI 2 general_operand x] - rl78_real_insns_ok () + rl78_real_insns_ok () !TARGET_G10 mulu\t%2 ) Index: config/rl78/rl78-virt.md === --- config/rl78/rl78-virt.md(revision 213995) +++ config/rl78/rl78-virt.md(working copy) @@ -91,7 +91,7 @@ [(set (match_operand:HI 0 register_operand =vm) (mult:HI (match_operand:HI 1 rl78_nonfar_operand %vim) (match_operand:HI 2 rl78_24_operand Ni)))] - rl78_virt_insns_ok () + rl78_virt_insns_ok () !TARGET_G10 v.mulu\t%0, %1, %2 [(set_attr valloc umul)] ) @@ -100,7 +100,7 @@ [(set (match_operand:HI 0 register_operand =vm) (mult:HI (zero_extend:HI (match_operand:QI 1 rl78_nonfar_operand %vim)) (zero_extend:HI (match_operand:QI 2 general_operand vim] - rl78_virt_insns_ok () + rl78_virt_insns_ok () !TARGET_G10 v.mulu\t%0, %2 [(set_attr valloc umul)] )
[rl78] split mem-mem moves
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) (movhi_virt_mm): Split out near mem-mem moves to avoid problems with far-far moves. Index: config/rl78/predicates.md === --- config/rl78/predicates.md (revision 213995) +++ config/rl78/predicates.md (working copy) @@ -30,12 +30,17 @@ (define_predicate rl78_nonfar_nonimm_operand (and (match_operand 0 nonimmediate_operand) (not (match_test rl78_far_p (op ) +(define_predicate rl78_near_mem_operand + (and (match_code mem) + (match_test !rl78_far_p (op) rl78_as_legitimate_address (VOIDmode, XEXP (op, 0), true, ADDR_SPACE_GENERIC))) +) + (define_predicate ubyte_operand (and (match_code const_int) (match_test IN_RANGE (INTVAL (op), 0, 255 (define_predicate rl78_24_operand (and (match_code const_int) Index: config/rl78/rl78-virt.md === --- config/rl78/rl78-virt.md(revision 213996) +++ config/rl78/rl78-virt.md(working copy) @@ -30,20 +30,36 @@ (define_attr valloc op1,op2,ro1,cmp,umul,macax (const_string op2)) ;;-- Moving +(define_insn *movqi_virt_mm + [(set (match_operand:QI 0 rl78_near_mem_operand =Y) + (match_operand1 rl78_near_mem_operand Y))] + rl78_virt_insns_ok () + v.mov %0, %1 + [(set_attr valloc op1)] +) + (define_insn *movqi_virt [(set (match_operand:QI 0 nonimmediate_operand =vY,v,Wfr) - (match_operand1 general_operand vInt8JY,Wfr,vInt8J))] + (match_operand1 general_operand vInt8J,YWfr,vInt8J))] rl78_virt_insns_ok () v.mov %0, %1 [(set_attr valloc op1)] ) +(define_insn *movhi_virt_mm + [(set (match_operand:HI 0 rl78_near_mem_operand =Y) + (match_operand:HI 1 rl78_near_mem_operand Y))] + rl78_virt_insns_ok () + v.movw %0, %1 + [(set_attr valloc op1)] +) + (define_insn *movhi_virt [(set (match_operand:HI 0 nonimmediate_operand =vS, Y, v, Wfr) (match_operand:HI 1 general_operand viYS, viS, Wfr, vi))] rl78_virt_insns_ok () v.movw %0, %1 [(set_attr valloc op1)]
[rl78] allow global+acc
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) +++ config/rl78/rl78-real.md(working copy) @@ -96,13 +96,13 @@ ;;-- Arithmetic (define_insn *addqi3_real [(set (match_operand:QI 0 nonimmediate_operand =rvWabWhlWh1,rvWabWhlWh1,a,*bcdehl) (plus:QI (match_operand:QI 1 general_operand %0,0,0,0) -(match_operand:QI 2 general_operand K,L,RWhlWh1i,a))) +(match_operand:QI 2 general_operand K,L,RWhlWh1Wabi,a))) ] rl78_real_insns_ok () @ inc\t%0 dec\t%0 add\t%0, %2
__intN patch 0/5: summary
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 size. Tested on x86-64 with no regressions and msp430-elf with a few where I couldn't figure out how to fix the testsuite to properly detect the msp430's 20-bit pointer size (but the msp430 results had a lot more new passes with my patches ;) I'm pretty sure I've addressed everyone's concerns, and once again I've manually split up the ChangeLog and patch into multiple posts for the convenience of review __intN patch 1/5: convert-move optimization A standalone patch that allows targets to provide a converter (trunc/extend) between *any* two modes. Needed for the msp430 patch. __intN patch 2/5: Fix assumptions about mode precisions Many places in gcc use TYPE_SIZE instead of TYPE_PRECISION. This patch set fixes many (I doubt I found *all* of them) such cases. __intN patch 3/5: main __int128 - __intN conversion. This is the main part of the patch. Doesn't require the other patches for targets that only have power-of-two pointers. __intN patch 4/5: testsuite updates Some of the tests had their own assumption about pointer sizes :-P __intN patch 5/5: msp430-specific changes For completeness, this is the msp430-specific fixes and optimizations to fully support 20-bit pointers.
__intN patch 1/5: convert-move optimization
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
===
--- gcc/expr.c (revision 213886)
+++ gcc/expr.c (working copy)
@@ -406,12 +406,32 @@ convert_move (rtx to, rtx from, int unsi
from)
: gen_rtx_FLOAT_EXTEND (to_mode, from));
return;
}
/* Handle pointer conversion. *//* SPEE 900220. */
+ /* If the target has a converter from FROM_MODE to TO_MODE, use it. */
+ {
+convert_optab ctab;
+
+if (GET_MODE_PRECISION (from_mode) GET_MODE_PRECISION (to_mode))
+ ctab = trunc_optab;
+else if (unsignedp)
+ ctab = zext_optab;
+else
+ ctab = sext_optab;
+
+if (convert_optab_handler (ctab, to_mode, from_mode)
+ != CODE_FOR_nothing)
+ {
+ emit_unop_insn (convert_optab_handler (ctab, to_mode, from_mode),
+ to, from, UNKNOWN);
+ return;
+ }
+ }
+
/* Targets are expected to provide conversion insns between PxImode and
xImode for all MODE_PARTIAL_INT modes they use, but no others. */
if (GET_MODE_CLASS (to_mode) == MODE_PARTIAL_INT)
{
enum machine_mode full_mode
= smallest_mode_for_size (GET_MODE_BITSIZE (to_mode), MODE_INT);
__intN patch 2/5: Fix assumptions about mode precisions
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:
POINTER_SIZE_UNITS (ceil, not floor)
TYPE_PRECISION
GET_MODE_PRECISION
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.
(dw2_output_indirect_constant_1): Likewise.
* expmed.c (init_expmed_one_conv): We now know the sizes of
partial int modes.
* loop-iv.c (iv_number_of_iterations): Use precision, not size.
* optabs.c (expand_float): Use precision, not size.
(expand_fix): Likewise.
* simplify-rtx (simplify_unary_operation_1): Likewise.
* tree-dfa.c (get_ref_base_and_extent): Likewise.
* varasm.c (assemble_addr_to_section): Round up pointer sizes.
(default_assemble_integer) Likewise.
(dump_tm_clone_pairs): Likewise.
* dwarf2out.c (mem_loc_descriptor): Allow partial-int modes also.
* var-tracking.c (adjust_mems): Allow partial-int modes also.
(prepare_call_arguments): Likewise.
* stor-layout.c (finalize_type_size): Preserve precision.
(layout_type): Use precision, not size.
Index: gcc/cppbuiltin.c
===
--- gcc/cppbuiltin.c(revision 213886)
+++ gcc/cppbuiltin.c(working copy)
@@ -172,13 +172,13 @@ define_builtin_macros_for_type_sizes (cp
? __ORDER_BIG_ENDIAN__
: __ORDER_LITTLE_ENDIAN__));
/* ptr_type_node can't be used here since ptr_mode is only set when
toplev calls backend_init which is not done with -E switch. */
cpp_define_formatted (pfile, __SIZEOF_POINTER__=%d,
- POINTER_SIZE / BITS_PER_UNIT);
+ 1 ceil_log2 ((POINTER_SIZE + BITS_PER_UNIT - 1) /
BITS_PER_UNIT));
}
/* Define macros builtins common to all language performing CPP
preprocessing. */
void
Index: gcc/defaults.h
===
--- gcc/defaults.h (revision 213886)
+++ gcc/defaults.h (working copy)
@@ -448,13 +448,13 @@ see the files COPYING3 and COPYING.RUNTI
/* The size of addresses as they appear in the Dwarf 2 data.
Some architectures use word addresses to refer to code locations,
but Dwarf 2 info always uses byte addresses. On such machines,
Dwarf 2 addresses need to be larger than the architecture's
pointers. */
#ifndef DWARF2_ADDR_SIZE
-#define DWARF2_ADDR_SIZE (POINTER_SIZE / BITS_PER_UNIT)
+#define DWARF2_ADDR_SIZE ((POINTER_SIZE + BITS_PER_UNIT - 1) / BITS_PER_UNIT)
#endif
/* The size in bytes of a DWARF field indicating an offset or length
relative to a debug info section, specified to be 4 bytes in the
DWARF-2 specification. The SGI/MIPS ABI defines it to be the same
as PTR_SIZE. */
@@ -748,12 +748,16 @@ see the files COPYING3 and COPYING.RUNTI
#endif
/* Width in bits of a pointer. Mind the value of the macro `Pmode'. */
#ifndef POINTER_SIZE
#define POINTER_SIZE BITS_PER_WORD
#endif
+#ifndef POINTER_SIZE_UNITS
+#define POINTER_SIZE_UNITS ((POINTER_SIZE + BITS_PER_UNIT - 1) / BITS_PER_UNIT)
+#endif
+
#ifndef PIC_OFFSET_TABLE_REGNUM
#define PIC_OFFSET_TABLE_REGNUM INVALID_REGNUM
#endif
#ifndef PIC_OFFSET_TABLE_REG_CALL_CLOBBERED
Index: gcc/dwarf2asm.c
===
--- gcc/dwarf2asm.c (revision 213886)
+++ gcc/dwarf2asm.c (working copy)
@@ -387,13 +387,13 @@ size_of_encoded_value (int encoding)
if (encoding == DW_EH_PE_omit)
return 0;
switch (encoding 0x07)
{
case DW_EH_PE_absptr:
- return POINTER_SIZE / BITS_PER_UNIT;
+ return POINTER_SIZE_UNITS;
case DW_EH_PE_udata2:
return 2;
case DW_EH_PE_udata4:
return 4;
case DW_EH_PE_udata8:
return 8;
@@ -917,13 +917,13 @@ dw2_output_indirect_constant_1 (splay_tr
if (USE_LINKONCE_INDIRECT)
DECL_VISIBILITY (decl) = VISIBILITY_HIDDEN;
}
sym_ref = gen_rtx_SYMBOL_REF (Pmode, sym);
assemble_variable (decl, 1, 1, 1);
- assemble_integer (sym_ref, POINTER_SIZE / BITS_PER_UNIT, POINTER_SIZE, 1);
+ assemble_integer (sym_ref, POINTER_SIZE_UNITS, POINTER_SIZE, 1);
return 0;
}
/* Emit the constants queued through dw2_force_const_mem. */
Index: gcc/expmed.c
===
--- gcc/expmed.c(revision 213886)
+++ gcc/expmed.c(working copy)
@@ -115,19 +115,25 @@ static void
init_expmed_one_conv (struct
__intN patch 5/5: msp430-specific changes
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.
* config/msp430/msp430-protos.h (msp430_hard_regno_nregs_has_padding):
New.
(msp430_hard_regno_nregs_with_padding): New.
* config/msp430/msp430.c (msp430_scalar_mode_supported_p): New.
(msp430_hard_regno_nregs_has_padding): New.
(msp430_hard_regno_nregs_with_padding): New.
(msp430_unwind_word_mode): Use PSImode instead of SImode.
(msp430_addr_space_legitimate_address_p): New.
(msp430_asm_integer): New.
(msp430_init_dwarf_reg_sizes_extra): New.
(msp430_print_operand): Use X suffix for PSImode even in small model.
* config/msp430/msp430.h (POINTER_SIZE): Use 20 bits, not 32.
(PTR_SIZE): ...but 4 bytes for EH.
(SIZE_TYPE): Use __int20.
(PTRDIFF_TYPE): Likewise.
(INCOMING_FRAME_SP_OFFSET): Adjust.
* config/msp430/msp430.md (movqi_topbyte): New.
(movpsi): Use fixed suffixes.
(movsipsi2): Enable for 430X, not large model.
(extendhipsi2): Likewise.
(zero_extendhisi2): Likewise.
(zero_extendhisipsi2): Likewise.
(extend_and_shift1_hipsi2): Likewise.
(extendpsisi2): Likewise.
(*bitbranchmode4_z): Fix suffix logic.
Index: gcc/config/msp430/msp430-protos.h
===
--- gcc/config/msp430/msp430-protos.h (revision 213886)
+++ gcc/config/msp430/msp430-protos.h (working copy)
@@ -27,12 +27,15 @@ voidmsp430_expand_epilogue (int);
void msp430_expand_helper (rtx *operands, const char *, bool);
void msp430_expand_prologue (void);
const char * msp430x_extendhisi (rtx *);
void msp430_fixup_compare_operands (enum machine_mode, rtx *);
intmsp430_hard_regno_mode_ok (int, enum machine_mode);
intmsp430_hard_regno_nregs (int, enum machine_mode);
+intmsp430_hard_regno_nregs_has_padding (int, enum machine_mode);
+intmsp430_hard_regno_nregs_with_padding (int, enum machine_mode);
+boolmsp430_hwmult_enabled (void);
rtxmsp430_incoming_return_addr_rtx (void);
void msp430_init_cumulative_args (CUMULATIVE_ARGS *, tree, rtx, tree, int);
intmsp430_initial_elimination_offset (int, int);
boolmsp430_is_interrupt_func (void);
const char * msp430x_logical_shift_right (rtx);
const char * msp430_mcu_name (void);
Index: gcc/config/msp430/msp430.md
===
--- gcc/config/msp430/msp430.md (revision 213886)
+++ gcc/config/msp430/msp430.md (working copy)
@@ -176,12 +176,19 @@
@
MOV.B\t%1, %0
MOV%X1.B\t%1, %0
)
+(define_insn movqi_topbyte
+ [(set (match_operand:QI 0 msp_nonimmediate_operand =r)
+ (subreg:QI (match_operand:PSI 1 msp_general_operand r) 2))]
+ msp430x
+ PUSHM.A\t#1,%1 { POPM.W\t#1,%0 { POPM.W\t#1,%0
+)
+
(define_insn movqi
[(set (match_operand:QI 0 msp_nonimmediate_operand =rYs,rm)
(match_operand:QI 1 msp_general_operand riYs,rmi))]
@
MOV.B\t%1, %0
@@ -220,27 +227,27 @@
;; Some MOVX.A cases can be done with MOVA, this is only a few of them.
(define_insn movpsi
[(set (match_operand:PSI 0 msp_nonimmediate_operand =r,Ya,rm)
(match_operand:PSI 1 msp_general_operand riYa,r,rmi))]
@
- MOV%Q0\t%1, %0
- MOV%Q0\t%1, %0
- MOV%X0.%Q0\t%1, %0)
+ MOVA\t%1, %0
+ MOVA\t%1, %0
+ MOVX.A\t%1, %0)
; This pattern is identical to the truncsipsi2 pattern except
; that it uses a SUBREG instead of a TRUNC. It is needed in
; order to prevent reload from converting (set:SI (SUBREG:PSI (SI)))
; into (SET:PSI (PSI)).
;
; Note: using POPM.A #1 is two bytes smaller than using POPX.A
(define_insn movsipsi2
[(set (match_operand:PSI0 register_operand =r)
(subreg:PSI (match_operand:SI 1 register_operand r) 0))]
- TARGET_LARGE
+ msp430x
PUSH.W\t%H1 { PUSH.W\t%L1 { POPM.A #1, %0 ; Move reg-pair %L1:%H1 into
pointer %0
)
;;
;; Math
@@ -564,49 +571,49 @@
{ return msp430x_extendhisi (operands); }
)
(define_insn extendhipsi2
[(set (match_operand:PSI 0 nonimmediate_operand =r)
(subreg:PSI (sign_extend:SI (match_operand:HI 1 nonimmediate_operand
0)) 0))]
- TARGET_LARGE
+ msp430x
RLAM #4, %0 { RRAM #4, %0
)
;; Look for cases where integer/pointer conversions are suboptimal due
;; to missing patterns, despite us not having opcodes for these
;; patterns. Doing these manually allows for alternate optimization
;; paths.
(define_insn zero_extendhisi2
[(set (match_operand:SI 0 nonimmediate_operand =rm)
(zero_extend:SI (match_operand:HI 1 nonimmediate_operand 0)))]
- TARGET_LARGE
+ msp430x
MOV.W\t#0,%H0
)
(define_insn
__intN patch 4/5: testsuite updates
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.
* gcc.c-torture/compile/limits-stringlit.c: Skip if msp430.
* gcc.dg/lto/pr54709_1.c: Fix memcpy prototype.
* gcc.dg/torture/pta-ptrarith-3.c: Use __SIZE_TYPE__ instead of int.
* gcc.dg/torture/pr36373-10.c: Use __SIZE_TYPE__ if present.
* gcc.dg/torture/pr57864.c: Use __SIZE_TYPE__.
* gcc.dg/torture/pr26763-2.c: Use __SIZE_TYPE__ instead of int.
* gcc.dg/tree-ssa/isolate-3.c: Use __SIZE_TYPE__ instead of long
unsigned int.
* gcc.dg/tree-ssa/isolate-3.c: Likewise.
* gcc.dg/pr52549.c: Use __SIZE_TYPE__ if present.
Index: gcc/testsuite/lib/target-supports.exp
===
--- gcc/testsuite/lib/target-supports.exp (revision 213886)
+++ gcc/testsuite/lib/target-supports.exp (working copy)
@@ -1806,17 +1806,18 @@ proc check_effective_target_ptr32plus {
return [check_no_compiler_messages ptr32plus object {
int dummy[sizeof (void *) = 4 ? 1 : -1];
}]
}
# Return 1 if we support 32-bit or larger array and structure sizes
-# using default options, 0 otherwise.
+# using default options, 0 otherwise. Avoid false positive on
+# targets with 20 or 24 bit address spaces.
proc check_effective_target_size32plus { } {
return [check_no_compiler_messages size32plus object {
- char dummy[65537];
+ char dummy[16777217L];
}]
}
# Returns 1 if we're generating 16-bit or smaller integers with the
# default options, 0 otherwise.
Index: gcc/testsuite/gcc.c-torture/compile/limits-stringlit.c
===
--- gcc/testsuite/gcc.c-torture/compile/limits-stringlit.c (revision
213886)
+++ gcc/testsuite/gcc.c-torture/compile/limits-stringlit.c (working copy)
@@ -1,7 +1,7 @@
-/* { dg-skip-if Array too big { avr-*-* picochip-*-* m32c-*-* pdp11-*-* } {
* } { } } */
+/* { dg-skip-if Array too big { avr-*-* picochip-*-* m32c-*-* pdp11-*-*
msp430-*-* } { * } { } } */
#define STR2 012345678901234567890123456789012345678901234567890123456789\
0123456789012345678901234567890123456789
#define STR3 STR2 STR2 STR2 STR2 STR2 STR2 STR2 STR2 STR2 STR2
#define STR4 STR3 STR3 STR3 STR3 STR3 STR3 STR3 STR3 STR3 STR3
#define STR5 STR4 STR4 STR4 STR4 STR4 STR4 STR4 STR4 STR4 STR4
Index: gcc/testsuite/gcc.dg/lto/pr54709_1.c
===
--- gcc/testsuite/gcc.dg/lto/pr54709_1.c(revision 213886)
+++ gcc/testsuite/gcc.dg/lto/pr54709_1.c(working copy)
@@ -1,5 +1,5 @@
-void * memcpy (void *, void *, long);
+void * memcpy (void *, void *, __SIZE_TYPE__);
void bar (void *p, void *q, unsigned s)
{
memcpy (p, q, s);
}
Index: gcc/testsuite/gcc.dg/torture/pta-ptrarith-3.c
===
--- gcc/testsuite/gcc.dg/torture/pta-ptrarith-3.c (revision 213886)
+++ gcc/testsuite/gcc.dg/torture/pta-ptrarith-3.c (working copy)
@@ -6,13 +6,13 @@ extern void abort (void);
struct X {
int *p;
int *q;
int *r;
};
int __attribute__((noinline))
-foo(int i, int j, int k, int off)
+foo(int i, int j, int k, __SIZE_TYPE__ off)
{
struct X x;
int **p, *q;
x.p = i;
x.q = j;
x.r = k;
Index: gcc/testsuite/gcc.dg/torture/pr36373-10.c
===
--- gcc/testsuite/gcc.dg/torture/pr36373-10.c (revision 213886)
+++ gcc/testsuite/gcc.dg/torture/pr36373-10.c (working copy)
@@ -1,9 +1,11 @@
/* { dg-do run } */
-#if (__SIZEOF_LONG_LONG__ == __SIZEOF_POINTER__)
+#ifdef __SIZE_TYPE__
+typedef __SIZE_TYPE__ uintptr_t;
+#elif (__SIZEOF_LONG_LONG__ == __SIZEOF_POINTER__)
typedef unsigned long long uintptr_t;
#elif (__SIZEOF_LONG__ == __SIZEOF_POINTER__)
typedef unsigned long uintptr_t;
#elif (__SIZEOF_INT__ == __SIZEOF_POINTER__)
typedef unsigned int uintptr_t;
#else
Index: gcc/testsuite/gcc.dg/torture/pr57864.c
===
--- gcc/testsuite/gcc.dg/torture/pr57864.c (revision 213886)
+++ gcc/testsuite/gcc.dg/torture/pr57864.c (working copy)
@@ -12,18 +12,18 @@ int c;
static void fn1(union U *p1, int p2, _Bool p3)
{
union U *e;
if (p2 == 0)
- a = ((union U*)((unsigned long)p1 ~1))-val;
+ a = ((union U*)((__SIZE_TYPE__)p1 ~1))-val;
if (b) {
e = p1;
} else if (c) {
- e = ((union U*)((unsigned long)p1 ~1))-ptr;
+ e = ((union U*)((__SIZE_TYPE__)p1 ~1))-ptr;
d = e;
} else {
e = 0;
d = ((union U*)0)-ptr;
}
Index: gcc/testsuite/gcc.dg/torture/pr26763-2.c
Re: __intN patch 3/5: main __int128 - __intN conversion.
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.
Re: [C PATCH] Discard P - (P + CST) optimization in pointer_diff (PR c/61240)
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
Re: [C PATCH] Discard P - (P + CST) optimization in pointer_diff (PR c/61240)
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.
Re: [C PATCH] Discard P - (P + CST) optimization in pointer_diff (PR c/61240)
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 testsuite cases that get it wrong. That's one of the things that would be largely made irrelevant by DJ's proposed changes. Instead of using PSImode, What’s PSImode? PSImode is a mode with more precision than HImode, but less than SImode. we'd be able to define modes of precisely the number of bits one of these targets needs. Not quite, Jeff. We still use PSImode but now it has a known defined precision, not just fits in SImode, and may correspond to one of the __intN types. Gosh, we already do that. GET_MODE_PRECISION (mode) is exactly the width: There's still lots of places in gcc that use SIZE where they should use PRECISION. I also added a step that looks for target-defined conversions between, for example, HImode and PSImode (rather than go HI-SI-PSI). Plus, as there was no real C type for partial int modes, a lot of gcc made assumptions about type sizes. The addition of arbitrary __intN types means there are more places in the code that are able to properly handle partial integer modes.
Re: [C PATCH] Discard P - (P + CST) optimization in pointer_diff (PR c/61240)
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 for target-defined conversions between, for example, HImode and PSImode (rather than go HI-SI-PSI). I hope they always fall back to the usual conversions. On my port, I can move them into gprs and do all the usual gpr instructions on them. The register allocator allocates the mode specific registers and moves them around as appropriate. Yeah, it's a check before the usual conversions that just says if the target has a MODE1 to MODE2 converter of the right type, just use it. Without this check, the only mode conversions are (for example) HI-SI and PSI-SI. The check allows for HI-PSI or QI-PTI or whatever the target has opcodes for.
Re: [cygming] make sure libgcc logic is consistent
sorry for late reply. Patch is ok. Please apply. Applied. Thanks!
[cygming] make sure libgcc logic is consistent
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 called
(i.e. dlopen'd a DLL which required libgcc). In that case, the
register test would return no libgcc and register with the local
copy, yet the deregister test would return yes libgcc and try to
deregister something with libgcc.dll that hadn't been registered.
Index: cygming-crtbegin.c
===
--- cygming-crtbegin.c (revision 212915)
+++ cygming-crtbegin.c (working copy)
@@ -99,12 +99,13 @@ static EH_FRAME_SECTION_CONST char __EH_
= { };
static struct object obj;
/* Handle of libgcc's DLL reference. */
HANDLE hmod_libgcc;
+static void * (*deregister_frame_fn) (const void *) == NULL;
#endif
#if TARGET_USE_JCR_SECTION
static void *__JCR_LIST__[]
__attribute__ ((used, section(JCR_SECTION_NAME), aligned(4)))
= { };
@@ -130,15 +131,20 @@ __gcc_register_frame (void)
if (h)
{
/* Increasing the load-count of LIBGCC_SONAME DLL. */
hmod_libgcc = LoadLibrary (LIBGCC_SONAME);
register_frame_fn = (void (*) (const void *, struct object *))
GetProcAddress (h, __register_frame_info);
+ deregister_frame_fn = (void* (*) (const void *))
+ GetProcAddress (h, __deregister_frame_info);
+}
+ else
+{
+ register_frame_fn = __register_frame_info;
+ deregister_frame_fn = __deregister_frame_info;
}
- else
-register_frame_fn = __register_frame_info;
if (register_frame_fn)
register_frame_fn (__EH_FRAME_BEGIN__, obj);
#endif
#if TARGET_USE_JCR_SECTION
if (__JCR_LIST__[0])
@@ -158,19 +164,12 @@ __gcc_register_frame (void)
}
void
__gcc_deregister_frame (void)
{
#if DWARF2_UNWIND_INFO
- void * (*deregister_frame_fn) (const void *);
- HANDLE h = GetModuleHandle (LIBGCC_SONAME);
- if (h)
-deregister_frame_fn = (void* (*) (const void *))
- GetProcAddress (h, __deregister_frame_info);
- else
-deregister_frame_fn = __deregister_frame_info;
if (deregister_frame_fn)
deregister_frame_fn (__EH_FRAME_BEGIN__);
if (hmod_libgcc)
FreeLibrary (hmod_libgcc);
#endif
}
Re: m32c-*-* Build Issue (Multilib?)
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/ -B/greed/dj/m32c/install/m32c-elf/lib/
-isystem /greed/dj/m32c/install/m32c-elf/include -isystem
/greed/dj/m32c/install/m32c-elf/sys-include -mcpu=m32cm -c --save-temps
-fexceptions conftest.c 5
conftest.c: In function 'foo':
conftest.c:19:1: error: insn does not satisfy its constraints:
}
^
(insn 52 38 23 (set (reg:SI 2 r1 [29])
(reg:SI 4 a0)) 99 {movsi_24}
(nil))
conftest.c:19:1: internal compiler error: in final_scan_insn, at final.c:2891
0x7a56a8 _fatal_insn(char const*, rtx_def const*, char const*, int, char const*)
/greed/dj/gnu/gcc/svn/gcc-4_9-branch/gcc/rtl-error.c:109
0x7a56cf _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/greed/dj/gnu/gcc/svn/gcc-4_9-branch/gcc/rtl-error.c:120
0x6256c9 final_scan_insn(rtx_def*, _IO_FILE*, int, int, int*)
/greed/dj/gnu/gcc/svn/gcc-4_9-branch/gcc/final.c:2891
0x6258ef final(rtx_def*, _IO_FILE*, int)
/greed/dj/gnu/gcc/svn/gcc-4_9-branch/gcc/final.c:2023
0x626035 rest_of_handle_final
/greed/dj/gnu/gcc/svn/gcc-4_9-branch/gcc/final.c:4427
0x626035 execute
/greed/dj/gnu/gcc/svn/gcc-4_9-branch/gcc/final.c:4502
Re: m32c-*-* Build Issue (Multilib?)
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 cause this but I could easily be missing something. If you're building in separate trees, you need to build gcc-host, then newlib, then gcc-target. If you're building in a combined tree, I don't know.
Re: m32c-*-* Build Issue (Multilib?)
What's the next step? Someone finds time and desire to debug it ;-)
[rx] fix some alignment constants
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 (working copy) @@ -2787,12 +2787,13 @@ rx_override_options_after_change (); + /* These values are bytes, not log. */ if (align_jumps == 0 ! optimize_size) -align_jumps = ((rx_cpu_type == RX100 || rx_cpu_type == RX200) ? 2 : 3); +align_jumps = ((rx_cpu_type == RX100 || rx_cpu_type == RX200) ? 4 : 8); if (align_loops == 0 ! optimize_size) -align_loops = ((rx_cpu_type == RX100 || rx_cpu_type == RX200) ? 2 : 3); +align_loops = ((rx_cpu_type == RX100 || rx_cpu_type == RX200) ? 4 : 8); if (align_labels == 0 ! optimize_size) -align_labels = ((rx_cpu_type == RX100 || rx_cpu_type == RX200) ? 2 : 3); +align_labels = ((rx_cpu_type == RX100 || rx_cpu_type == RX200) ? 4 : 8); } @@ -3199,9 +3200,10 @@ if (optimize_size) return 0; + /* These values are log, not bytes. */ if (rx_cpu_type == RX100 || rx_cpu_type == RX200) -return 2; - return 2; +return 2; /* 4 bytes */ + return 3; /* 8 bytes */ } static int
Re: [patch 1/4] change specific int128 - generic intN
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 (TYPE_MODE (type))); + TYPE_SIZE (type) = bitsize_int (GET_MODE_PRECISION (TYPE_MODE (type))); TYPE_SIZE_UNIT (type) = size_int (GET_MODE_SIZE (TYPE_MODE (type))); break; What are GET_MODE_BITSIZE and GET_MODE_PRECISION for PSImode? It *should* be 20 and 20 for msp430. But GET_MODE_BITSIZE returns 32, because it's a macro that does GET_MODE_SIZE * BITS_PER_UNIT, so it cannot return 20. If a type is 17-20 bits, PSImode is chosen. If it's 21 bits or larger, SImode is chosen. If it's 16 or fewer bits, HImode is chosen. Size or precision? That's the crux of the matter. GCC typically uses size for fits in a tests.
Re: [patch 1/4] change specific int128 - generic intN
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 normally not a power of two. The assumption that PSImode is the same size as SImode is no longer valid. The code was biting me when TYPE_SIZE was bigger than PSImode, and the code kept choosing SImode instead. IMO you're papering over the real issue, which appears to be the choice of the mode. Why does the code choose PSImode instead of SImode, if the type and the mode have the same precision (20) and size (24)? PSImode is 20 bits, fits in a 20 bit register, and uses 20 bit operations. SImode is 32 bits, fits in two 16 bit registers, and uses 32 bit operations. If a type is 17-20 bits, PSImode is chosen. If it's 21 bits or larger, SImode is chosen. If it's 16 or fewer bits, HImode is chosen. If you look at part 2 of the patch, you'll see lots of code that implements this logic, although the change to specify the sizes of partial int modes has been in for a while.
Re: reverse bitfield patch
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 output unit is only emitted once per string of bitfields. If the total amount of data to output is larger than the unit size, then the units themselves need to be output in the other order also. Note that code expects that representatives are byte-aligned so better would be to not assign representatives or make the code work with the swapped layout (I see no reason why that shouldn't work - maybe it works doing before swapping the layout)? I'm OK with not assigning them, but I couldn't figure out from the code what they were for. I'm still not happy about the idea in general (why is this a bitfield exclusive thing? If a piece of HW is big/little-endian then even regular fields would have that property. A bi-endian MCU with memory-mapped peripherals needs this to properly and portably describe the fields within the peripheral's registers. Without this patch, there's no way (short of two independent definitions) of assigning a name to, for example, the LSB of such a device's registers. Your patch comes with no testcase - testcases should cover all attribute variants, multiple bitfield (group) sizes and mixed initializations / reads / writes and be best execute testcases. I wrote testcases, perhaps I just forgot to attach them.
Re: [patch 1/4] change specific int128 - generic intN
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 biting me when TYPE_SIZE was bigger than PSImode, and the code kept choosing SImode instead.
Re: [patch 1/4] change specific int128 - generic intN
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 transfers data in and out of byte-oriented memory in TYPE_SIZE_UNITS chunks. Once in a hardware register, all operations are either 8, 16, or 20 bits (TYPE_SIZE) in size. So yes, values are padded in memory, but no, they are not padded in registers. Setting TYPE_PRECISION is mostly useless, because most of gcc assumes it's the same as TYPE_SIZE and ignores it. Heck, most of gcc is oblivious to the idea that types might not be powers-of-two in size. GCC doesn't even bother with a DECL_PRECISION. Thus, in these cases, TYPE_SIZE and TYPE_SIZE_UNIT no longer have a * BITS_PER_UNIT mathematical relationship. I'm skeptical this can work, it's pretty fundamental. It seems to work just fine in testing, and I'm trying to make it non-fundamental.
Re: [patch 1/4] change specific int128 - generic intN
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 want TYPE_SIZE_UNITS anyway. I doubt there are too many places that require changing. I don't doubt it, because I've been fighting these assumptions for years. Heck, most of gcc is oblivious to the idea that types might not be powers-of-two in size. GCC doesn't even bother with a DECL_PRECISION. Sure - why would you even need one? Why do we need to have DECL_SIZE_UNITS (the size of the type, rounded up to whole number of bytes) and DECL_SIZE (the size of the type, rounded up to whole number of bytes), yet not have something that says how big the decl *really is* ? A pointer on MSP430 is 20 bits. All the general registers are 20 bits. Not 16, and not 24. 20. There's nothing in a decl that says I'm 20 bits and inevitably it ends up being SImode instead of PSImode. It seems to work just fine in testing, and I'm trying to make it non-fundamental. I also think this is not a very good idea. Then please provide a very good idea for how to teach gcc about true 20-bit types in a system with 8-bit memory and 16-bit words.
Re: [patch 1/4] change specific int128 - generic intN
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 operands, and __int20. Rounding up to byte sizes forces everything into an emulated SImode which makes code size huge and performance much worse. Thus, in these cases, TYPE_SIZE and TYPE_SIZE_UNIT no longer have a * BITS_PER_UNIT mathematical relationship.
Re: reverse bitfield patch
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 the
reversed order. Otherwise code like this is miscompiled:
Err - the struct also has fields in the original order - only the bit
positions
of the fields are different because of the layouting option.
The order of the field decls in the type (stor-layout.c) is not
changed, only the bit position information. The order here *can't* be
changed, because the C language assumes that parameters, initializers,
etc are presented in the same order as the original declaration,
regardless of the target-specific layout.
When the program includes an initializer:
struct foo a = { 1, 2, 3 };
The order of 1, 2, and 3 need to correspond to the order of the
bitfields in 'a', so we can change neither the order of the bitfields
in 'a' nor the order of constructor fields.
However, when we stream the initializer out to the .S file, we need to
pack the bitfields in the right sequence to generate the right bit
patterns in the final output image. The code in varasm.c exists to
make sure that the initializers for bitfields are written/packed in
the correct order, to correspond to the bitfield positions. I.e. the
1,2,3 initializer needs to be written to the .S file as either 0x0123
or 0x3210 depending on the bit positions.
In neither case do we change the order of the fields in the type
itself, i.e. the array/chain order.
And you expect no other code looks at fields of a structure and its
initializer? It's bad to keep this not in-sync. Thus I don't think it's
viable to re-order fields just because bit allocation is reversed.
The fields are in sync. The varasm.c change sorts the elements as
they're being output into the byte stream in the .S, it doesn't sort
the field definitions themselves.
+ /* If the bitfield-order attribute has been used on this
+structure, the fields might not be in bit-order. In that
+case, we need a separate representative for each
+field. */
The typical use-case for this feature is memory-mapped hardware, where
pessimum access is preferred anyway.
I doubt that, looking at constraints for strict volatile bitfields.
The code that handles representatives requires (via an assert, IIRC)
that the bit offsets within a representative be in ascending order.
I.e. gcc ICEs if I don't bypass this. In the case of volatile
bitfields, which would be the typical use case for a reversed
bitfield, the access mode is going to match the type size regardless,
so performance is not changed by this patch.
Re: [Mspgcc-users] Packaging for msp430-elf-*
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 compilers, most cross compilers assume they're being built with gcc itself. I don't do anything gcc-specific myself, but the general framework might be so. Is msp430 support present in the latest gdb, too? Yes. If you want to debug the built-in simulator, use target sim. To debug hardware, you'll need a gdb-remote-compatible hardware driver, such as the TI debug DLLs, and use target remote. -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [patch 1/4] change specific int128 - generic intN
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 (to use TYPE_PRECISION, maybe) would also be incremental progress towards eliminating TYPE_SIZE. What about DECL_SIZE ? It's set from TYPE_SIZE but there is no DECL_PRECISION. Also, TYPE_PRECISION is an integer, where TYPE_SIZE is a tree. They're not universally swappable code-wise. And I noticed that sizetype and bitsizetype are not really any different any more either, why have both?
Re: Bugzilla column width - only 80+1 characters!?
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 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Unreviewed build patch
https://gcc.gnu.org/ml/gcc-patches/2014-05/msg01860.html Build parts are approved.
Re: [patch 1/4] change specific int128 - generic intN
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 +2142,13 @@ layout_type (tree type) case BOOLEAN_TYPE: case INTEGER_TYPE: case ENUMERAL_TYPE: SET_TYPE_MODE (type, smallest_mode_for_size (TYPE_PRECISION (type), MODE_INT)); - TYPE_SIZE (type) = bitsize_int (GET_MODE_BITSIZE (TYPE_MODE (type))); + TYPE_SIZE (type) = bitsize_int (GET_MODE_PRECISION (TYPE_MODE (type))); TYPE_SIZE_UNIT (type) = size_int (GET_MODE_SIZE (TYPE_MODE (type))); break; This doesn't look correct, you might end up with types smaller than their modes and breaking the TYPE_SIZE/TYPE_SIZE_UNIT relationship. The whole point of using _PRECISION is to have the size be exactly the same as the mode (bitsize is bigger than the mode for partial-int modes). TYPE_SIZE_UNIT should be its storage size, right? If the type is not a multiple of BITS_PER_UNIT, the actual size and stored-in-memory size are going to be different. The problem in the old code is that BITSIZE is not the size in bits of the type, it's the size in bytes times BITS_PER_UNIT. This meant that all partial-int modes would be converted into their non-partial modes eventually. Most of my patch is about avoiding that. If you still disagree, let's first figure out what the right relationship between TYPE_SIZE and TYPE_SIZE_UNIT is, for types that aren't a multiple of BITS_PER_UNIT. @@ -2516,16 +2535,33 @@ initialize_sizetypes (void) precision = LONG_TYPE_SIZE; else if (strcmp (SIZETYPE, long long unsigned int) == 0) precision = LONG_LONG_TYPE_SIZE; else if (strcmp (SIZETYPE, short unsigned int) == 0) precision = SHORT_TYPE_SIZE; else gcc_unreachable (); bprecision -= MIN (precision + BITS_PER_UNIT_LOG + 1, MAX_FIXED_MODE_SIZE); += MIN (precision, MAX_FIXED_MODE_SIZE); bprecision = GET_MODE_PRECISION (smallest_mode_for_size (bprecision, MODE_INT)); if (bprecision HOST_BITS_PER_DOUBLE_INT) bprecision = HOST_BITS_PER_DOUBLE_INT; /* Create stubs for sizetype and bitsizetype so we can create constants. Why are you reducing the precision here? I'm not reducing it, I'm removing a case where it's rounded up. Rounding up a 20-bit PSImode gives you SImode eventually.
Re: [patch 1/4] change specific int128 - generic intN
Are you proposing we remove TYPE_SIZE completely?
Re: [patch 1/4] change specific int128 - generic intN
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?
Re: [Mspgcc-users] Packaging for msp430-elf-*
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 Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] Packaging for msp430-elf-*
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 build it is to do it in two steps so that things like stdio.h et al are available to the libgcc build. I haven't tried to build libgcc before newlib in a long time, but if it works, either things have changed or you just haven't noticed the problem yet ;-) -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] MSP430 simulator in gdb
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 -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Patch: RL78] Add support for 64-bit doubles
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 64-bit-double https://gcc.gnu.org/ml/gcc-patches/2014-05/msg02350.html It doesn't matter to me, but there's no rule in gcc that the directory names need to match anything, so if your software depends on that, your software has a problem.
Re: [patch 1/4] change specific int128 - generic intN
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
TYPE_SIZE
GET_MODE_BITSIZE
New:
POINTER_SIZE_UNITS (ceil, not floor)
TYPE_PRECISION
GET_MODE_PRECISION
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.
(dw2_output_indirect_constant_1): Likewise.
* expmed.c (init_expmed_one_conv): We now know the sizes of
partial int modes.
* loop-iv.c (iv_number_of_iterations): Use precision, not size.
* optabs.c (expand_float): Use precision, not size.
(expand_fix): Likewise.
* simplify-rtx (simplify_unary_operation_1): Likewise.
* tree-dfa.c (get_ref_base_and_extent): Likewise.
* varasm.c (assemble_addr_to_section): Round up pointer sizes.
(default_assemble_integer) Likewise.
(dump_tm_clone_pairs): Likewise.
* tree-core.c: Adjust comment.
gcc/lto/
* lto-object.c (lto_obj_begin_section): Do not assume pointers are
powers-of-two in size.
gcc/c-family/
* c-cppbuiltin.c (cpp_atomic_builtins): Round pointer sizes up.
(type_suffix): Use type precision, not specific types.
Index: gcc/dwarf2asm.c
===
--- gcc/dwarf2asm.c (revision 211858)
+++ gcc/dwarf2asm.c (working copy)
@@ -387,13 +387,13 @@ size_of_encoded_value (int encoding)
if (encoding == DW_EH_PE_omit)
return 0;
switch (encoding 0x07)
{
case DW_EH_PE_absptr:
- return POINTER_SIZE / BITS_PER_UNIT;
+ return POINTER_SIZE_UNITS;
case DW_EH_PE_udata2:
return 2;
case DW_EH_PE_udata4:
return 4;
case DW_EH_PE_udata8:
return 8;
@@ -917,13 +917,13 @@ dw2_output_indirect_constant_1 (splay_tr
if (USE_LINKONCE_INDIRECT)
DECL_VISIBILITY (decl) = VISIBILITY_HIDDEN;
}
sym_ref = gen_rtx_SYMBOL_REF (Pmode, sym);
assemble_variable (decl, 1, 1, 1);
- assemble_integer (sym_ref, POINTER_SIZE / BITS_PER_UNIT, POINTER_SIZE, 1);
+ assemble_integer (sym_ref, POINTER_SIZE_UNITS, POINTER_SIZE, 1);
return 0;
}
/* Emit the constants queued through dw2_force_const_mem. */
Index: gcc/cppbuiltin.c
===
--- gcc/cppbuiltin.c(revision 211858)
+++ gcc/cppbuiltin.c(working copy)
@@ -172,13 +172,13 @@ define_builtin_macros_for_type_sizes (cp
? __ORDER_BIG_ENDIAN__
: __ORDER_LITTLE_ENDIAN__));
/* ptr_type_node can't be used here since ptr_mode is only set when
toplev calls backend_init which is not done with -E switch. */
cpp_define_formatted (pfile, __SIZEOF_POINTER__=%d,
- POINTER_SIZE / BITS_PER_UNIT);
+ 1 ceil_log2 ((POINTER_SIZE + BITS_PER_UNIT - 1) /
BITS_PER_UNIT));
}
/* Define macros builtins common to all language performing CPP
preprocessing. */
void
Index: gcc/c-family/c-cppbuiltin.c
===
--- gcc/c-family/c-cppbuiltin.c (revision 211858)
+++ gcc/c-family/c-cppbuiltin.c (working copy)
@@ -675,13 +675,13 @@ cpp_atomic_builtins (cpp_reader *pfile)
to a boolean truth value, let the library work around that. */
builtin_define_with_int_value (__GCC_ATOMIC_TEST_AND_SET_TRUEVAL,
targetm.atomic_test_and_set_trueval);
/* ptr_type_node can't be used here since ptr_mode is only set when
toplev calls backend_init which is not done with -E or pch. */
- psize = POINTER_SIZE / BITS_PER_UNIT;
+ psize = POINTER_SIZE_UNITS;
if (psize = SWAP_LIMIT)
psize = 0;
builtin_define_with_int_value (__GCC_ATOMIC_POINTER_LOCK_FREE,
(have_swap[psize]? 2 : 1));
}
@@ -1227,18 +1269,21 @@ builtin_define_with_hex_fp_value (const
static const char *
type_suffix (tree type)
{
static const char *const suffixes[] = { , U, L, UL, LL, ULL };
int unsigned_suffix;
int is_long;
+ int tp = TYPE_PRECISION (type);
if (type == long_long_integer_type_node
- || type == long_long_unsigned_type_node)
+ || type == long_long_unsigned_type_node
+ || tp TYPE_PRECISION (long_integer_type_node))
is_long = 2;
else if (type == long_integer_type_node
- || type == long_unsigned_type_node)
+ || type == long_unsigned_type_node
+ || tp TYPE_PRECISION (integer_type_node))
is_long = 1;
else if (type == integer_type_node
||
Re: [patch 3/4] change specific int128 - generic intN
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
===
--- gcc/expr.c (revision 211858)
+++ gcc/expr.c (working copy)
@@ -405,12 +405,32 @@ convert_move (rtx to, rtx from, int unsi
from)
: gen_rtx_FLOAT_EXTEND (to_mode, from));
return;
}
/* Handle pointer conversion. *//* SPEE 900220. */
+ /* If the target has a converter from FROM_MODE to TO_MODE, use it. */
+ {
+convert_optab ctab;
+
+if (GET_MODE_PRECISION (from_mode) GET_MODE_PRECISION (to_mode))
+ ctab = trunc_optab;
+else if (unsignedp)
+ ctab = zext_optab;
+else
+ ctab = sext_optab;
+
+if (convert_optab_handler (ctab, to_mode, from_mode)
+ != CODE_FOR_nothing)
+ {
+ emit_unop_insn (convert_optab_handler (ctab, to_mode, from_mode),
+ to, from, UNKNOWN);
+ return;
+ }
+ }
+
/* Targets are expected to provide conversion insns between PxImode and
xImode for all MODE_PARTIAL_INT modes they use, but no others. */
if (GET_MODE_CLASS (to_mode) == MODE_PARTIAL_INT)
{
enum machine_mode full_mode
= smallest_mode_for_size (GET_MODE_BITSIZE (to_mode), MODE_INT);
Re: [patch 4/4] change specific int128 - generic intN
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 (msp430_hard_regno_nregs_has_padding):
New.
(msp430_hard_regno_nregs_with_padding): New.
* config/msp430/msp430.c (msp430_scalar_mode_supported_p): New.
(msp430_hard_regno_nregs_has_padding): New.
(msp430_hard_regno_nregs_with_padding): New.
(msp430_unwind_word_mode): Use PSImode instead of SImode.
(msp430_addr_space_legitimate_address_p): New.
(msp430_asm_integer): New.
(msp430_init_dwarf_reg_sizes_extra): New.
(msp430_print_operand): Use X suffix for PSImode even in small model.
* config/msp430/msp430.h (POINTER_SIZE): Use 20 bits, not 32.
(PTR_SIZE): ...but 4 bytes for EH.
(SIZE_TYPE): Use __int20.
(PTRDIFF_TYPE): Likewise.
(INCOMING_FRAME_SP_OFFSET): Adjust.
* config/msp430/msp430.md (movqi_topbyte): New.
(movpsi): Use fixed suffixes.
(movsipsi2): Enable for 430X, not large model.
(extendhipsi2): Likewise.
(zero_extendhisi2): Likewise.
(zero_extendhisipsi2): Likewise.
(extend_and_shift1_hipsi2): Likewise.
(extendpsisi2): Likewise.
(*bitbranchmode4_z): Fix suffix logic.
Index: gcc/config/msp430/msp430-protos.h
===
--- gcc/config/msp430/msp430-protos.h (revision 211858)
+++ gcc/config/msp430/msp430-protos.h (working copy)
@@ -27,12 +27,15 @@ voidmsp430_expand_epilogue (int);
void msp430_expand_helper (rtx *operands, const char *, bool);
void msp430_expand_prologue (void);
const char * msp430x_extendhisi (rtx *);
void msp430_fixup_compare_operands (enum machine_mode, rtx *);
intmsp430_hard_regno_mode_ok (int, enum machine_mode);
intmsp430_hard_regno_nregs (int, enum machine_mode);
+intmsp430_hard_regno_nregs_has_padding (int, enum machine_mode);
+intmsp430_hard_regno_nregs_with_padding (int, enum machine_mode);
+boolmsp430_hwmult_enabled (void);
rtxmsp430_incoming_return_addr_rtx (void);
void msp430_init_cumulative_args (CUMULATIVE_ARGS *, tree, rtx, tree, int);
intmsp430_initial_elimination_offset (int, int);
boolmsp430_is_interrupt_func (void);
const char * msp430x_logical_shift_right (rtx);
const char * msp430_mcu_name (void);
Index: gcc/config/msp430/msp430.md
===
--- gcc/config/msp430/msp430.md (revision 211858)
+++ gcc/config/msp430/msp430.md (working copy)
@@ -176,12 +176,19 @@
@
MOV.B\t%1, %0
MOV%X1.B\t%1, %0
)
+(define_insn movqi_topbyte
+ [(set (match_operand:QI 0 msp_nonimmediate_operand =r)
+ (subreg:QI (match_operand:PSI 1 msp_general_operand r) 2))]
+ msp430x
+ PUSHM.A\t#1,%1 { POPM.W\t#1,%0 { POPM.W\t#1,%0
+)
+
(define_insn movqi
[(set (match_operand:QI 0 msp_nonimmediate_operand =rYs,rm)
(match_operand:QI 1 msp_general_operand riYs,rmi))]
@
MOV.B\t%1, %0
@@ -220,27 +227,27 @@
;; Some MOVX.A cases can be done with MOVA, this is only a few of them.
(define_insn movpsi
[(set (match_operand:PSI 0 msp_nonimmediate_operand =r,Ya,rm)
(match_operand:PSI 1 msp_general_operand riYa,r,rmi))]
@
- MOV%Q0\t%1, %0
- MOV%Q0\t%1, %0
- MOV%X0.%Q0\t%1, %0)
+ MOVA\t%1, %0
+ MOVA\t%1, %0
+ MOVX.A\t%1, %0)
; This pattern is identical to the truncsipsi2 pattern except
; that it uses a SUBREG instead of a TRUNC. It is needed in
; order to prevent reload from converting (set:SI (SUBREG:PSI (SI)))
; into (SET:PSI (PSI)).
;
; Note: using POPM.A #1 is two bytes smaller than using POPX.A
(define_insn movsipsi2
[(set (match_operand:PSI0 register_operand =r)
(subreg:PSI (match_operand:SI 1 register_operand r) 0))]
- TARGET_LARGE
+ msp430x
PUSH.W\t%H1 { PUSH.W\t%L1 { POPM.A #1, %0 ; Move reg-pair %L1:%H1 into
pointer %0
)
;;
;; Math
@@ -564,49 +571,49 @@
{ return msp430x_extendhisi (operands); }
)
(define_insn extendhipsi2
[(set (match_operand:PSI 0 nonimmediate_operand =r)
(subreg:PSI (sign_extend:SI (match_operand:HI 1 nonimmediate_operand
0)) 0))]
- TARGET_LARGE
+ msp430x
RLAM #4, %0 { RRAM #4, %0
)
;; Look for cases where integer/pointer conversions are suboptimal due
;; to missing patterns, despite us not having opcodes for these
;; patterns. Doing these manually allows for alternate optimization
;; paths.
(define_insn zero_extendhisi2
[(set (match_operand:SI 0 nonimmediate_operand =rm)
(zero_extend:SI (match_operand:HI 1 nonimmediate_operand 0)))]
- TARGET_LARGE
+ msp430x
MOV.W\t#0,%H0
)
(define_insn zero_extendhisipsi2
Re: [patch] change specific int128 - generic intN
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 up. -#if !defined(__STRICT_ANSI__) defined(_GLIBCXX_USE_INT128) + // Conditionalizing on __STRICT_ANSI__ here will break any port that + // uses one of these types for size_t. +#if defined(__GLIBCXX_USE_INT_N_0) template -struct __is_integral_helper__int128 +struct __is_integral_helper__GLIBCXX_TYPE_INT_N_0 Since the check for __STRICT_ANSI__ is removed, do we need to add __extension__ in front of __GLIBCXX_TYPE_INT_N_0 to avoid warning with -Wsystem-headers? I copied the code from the __int128 case, and it explicitly bypassed -Wsystem-headers... so we don't have that problem. Not sure if we *should* have that problem, but we didn't before... I can only assume that either (1) someone found it too difficult to get __extension__ to work right in all those cases, or (2) it's a bug. Or (3) for some reason they decided to do it that way anyway. I don't know. That seems complicated. You just need to call emit_support_tinfo_1 on each of the types (see how fundamentals is used at the end of the function), no need to put everything in the array. Sure, *now* you tell me that :-) I can do it either way, but it's the same overhead to iterate through the types. Shoving it into the array is a bit more future-proof, but keeping the index in sync is a bit of work if the table ever changes. Your choice ;-)
Re: [patch] change specific int128 - generic intN
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 review if anything that can reasonably be separated from the main intN support is posted separately, as a much smaller patch with its own self-contained rationale (I presume all those changes should work fine without the main intN support), and then the intN patch only contains things directly related to intN support. There are basically three types of changes working together here: 1. Changes that remove the types are powers of two assumptions throughout gcc. At least, as many as I could find. These could be applied without the intN support, but serve no purpose without it. 2. The intN patch itself. 3. The msp430's changes to use __int20 for size_t, which depends on the above two. I'll split them up but I hope progress on set #2 isn't stalled on bikeshedding set #1, especially since set #1 doesn't solve any problems (or really, change *anything*) on its own.
Re: fix math wrt volatile-bitfields vs C++ model
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.
Re: F22 System Wide Change: Replace Yum With DNF
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 https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Replace Yum With DNF
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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Replace Yum With DNF
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. The right way to handle this is the way that every other package handles it. Detect the no-longer-compatible option and tell the user that option is no longer available. That way, the only users who are ever inconvenienced are the few that are using the obsolete option. The wrong way to solve this is to inconvenience *every* user for the sake of the few who need it. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Replace Yum With DNF
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
Re: [PATCH][RX] Patch to correct the functionality of compiler option -falign-labels=n
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 goes here It's always: * file (function/macro): Description. Otherwise OK.
[rx] further optimize alignment with -Os
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)
@@ -3207,12 +3207,15 @@ rx_align_for_label (rtx lab, int uses_th
static int
rx_max_skip_for_label (rtx lab)
{
int opsize;
rtx op;
+ if (optimize_size)
+return 0;
+
if (lab == NULL_RTX)
return 0;
op = lab;
do
{
[rx] adjust alignments for RX100/200 families
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: config/rx/rx.h
===
--- config/rx/rx.h (revision 211479)
+++ config/rx/rx.h (working copy)
@@ -139,13 +139,13 @@
#endif
#define DEFAULT_SIGNED_CHAR0
/* RX load/store instructions can handle unaligned addresses. */
#define STRICT_ALIGNMENT 0
-#define FUNCTION_BOUNDARY 8
+#define FUNCTION_BOUNDARY ((rx_cpu_type == RX100 || rx_cpu_type
== RX200) ? 4 : 8)
#define BIGGEST_ALIGNMENT 32
#define STACK_BOUNDARY 32
#define PARM_BOUNDARY 8
#define STACK_GROWS_DOWNWARD 1
#define FRAME_GROWS_DOWNWARD 0
Index: config/rx/rx.c
===
--- config/rx/rx.c (revision 211480)
+++ config/rx/rx.c (working copy)
@@ -2789,17 +2789,17 @@ rx_option_override (void)
if (flag_strict_volatile_bitfields 0 abi_version_at_least(2))
flag_strict_volatile_bitfields = 1;
rx_override_options_after_change ();
if (align_jumps == 0 ! optimize_size)
-align_jumps = 3;
+align_jumps = ((rx_cpu_type == RX100 || rx_cpu_type == RX200) ? 2 : 3);
if (align_loops == 0 ! optimize_size)
-align_loops = 3;
+align_loops = ((rx_cpu_type == RX100 || rx_cpu_type == RX200) ? 2 : 3);
if (align_labels == 0 ! optimize_size)
-align_labels = 3;
+align_labels = ((rx_cpu_type == RX100 || rx_cpu_type == RX200) ? 2 : 3);
}
static bool
rx_allocate_stack_slots_for_args (void)
{
@@ -3198,13 +3198,17 @@ rx_align_for_label (rtx lab, int uses_th
because the delay due to the inserted NOPs would be greater than the delay
due to the misaligned branch. If uses_threshold is zero then the
alignment
is always useful. */
if (LABEL_P (lab) LABEL_NUSES (lab) uses_threshold)
return 0;
- return optimize_size ? 1 : 3;
+ if (optimize_size)
+return 0;
+ if (rx_cpu_type == RX100 || rx_cpu_type == RX200)
+return 2;
+ return 2;
}
static int
rx_max_skip_for_label (rtx lab)
{
int opsize;
fix math wrt volatile-bitfields vs C++ model
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 position), and 15 15 with (comparing position to position). Ok to apply? * expmed.c (strict_volatile_bitfield_p): Fix off-by-one error. Index: expmed.c === --- expmed.c(revision 211479) +++ expmed.c(working copy) @@ -472,13 +472,13 @@ strict_volatile_bitfield_p (rtx op0, uns bitnum % GET_MODE_ALIGNMENT (fieldmode) + bitsize modesize)) return false; /* Check for cases where the C++ memory model applies. */ if (bitregion_end != 0 (bitnum - bitnum % modesize bitregion_start - || bitnum - bitnum % modesize + modesize bitregion_end)) + || bitnum - bitnum % modesize + modesize - 1 bitregion_end)) return false; return true; } /* Return true if OP is a memory and if a bitfield of size BITSIZE at
Re: [Mspgcc-users] replacing libgloss in msp430-elf
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... -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/NeoTech ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] MSP430 simulator in gdb
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, there's a standalone simulator msp430-elf-run that has some profiling command line options, not sure if those would be helpful. -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/NeoTech ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] MSP430 simulator in gdb
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 way. If you link in your input data via a linker script, and write() out the output data to stdout and redirect it, it should be pretty easy to set up. msp430-elf-run also has command line options to map files to memory regions, see msp430-elf-run --help for help. (er, a note about msp430-elf-run - the --trace-vpu command traces register changes, not the vpu) -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/NeoTech ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] MSP430 simulator in gdb
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 can write to stdout (we use it for testing). CIO supports a range of file I/O operations, but we only implemented write(). The code in libgloss (part of newlib) has an implementation of CIO and write() that works with the simulator. I don't know what a vpu is, so I am spared from confusion... I dodn't know either, but it was an unused command line option so I used it :-) -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/NeoTech ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] MSP430 simulator in gdb
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 FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/NeoTech ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] MSP430 simulator in gdb
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() though so the RH simulator *also* has its own syscall interface, just for that call. If you just want to exit cleanly a branch-to-self opcode will also trigger an exit(0) from the RH simulator. I personally would wish that newlib prefer APIs that are not proprietary. My intent for my own msp430-elf projects is to implement a msp430 libgloss approach that's much closer to what was done in the arm target for libgloss. If there's a chance that'd be adopted upstream as an alternative to the CIO one, it'd motivate me to make that a priority. CIO was used at TI's request, to be compatible with their simulators and their hardware drivers - I.e. a CIO library in your app would work in the simulator *and* on real hardware - I think this works with msp430-elf-gdb also. -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/NeoTech ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] MSP430 simulator in gdb
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 __CIOBUF__ and branch/call an opcode at C$$IO$$ The host sets a breakpoint at C$$IO$$. When it's hit, it reads the command from __CIOBUF__ and does it, which may involve reading data from the buffer and/or writing results back, then resumes the target. The target then looks at __CIOBUF__ to get the results of the syscall. The target side of this is at newlib's libgloss/msp430/ (part in cio.* and part in write.c) The simulator side of this is at gdb's sim/msp430/msp430-sim.c in msp430_cio(). A lot of the to/from buffering is common. -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/NeoTech ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] MSP430 simulator in gdb
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 on this? Are you talking about real hardware talking to real peripherals, or is there a host involved? Like Mark, one of my needs is for input as well as output. For ARM, I can take a binary toolchain from launchpad with a pre-built newlib and substitute a new system interface that meets my requirements. As long as I can do the same thing for the msp430 one, I'll have no issues with the default solution being CIO. None of the CIO stuff interferes with the ANSI routines in newlib/libc. You still use printf() and fopen() etc. The CIO code is at the very bottom in libgloss, where it provides a CIO-specific write() call. If you have some other low-level I/O routines, like a serial port or lcd, just provide your own read() and write() functions and the rest of newlib will just work. -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/NeoTech ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] MSP430 simulator in gdb
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 the underlying libraries provide. There's no difference between then as far as which you provide. If you'd like to propose changing which of the two newlib looks for by default, I'm OK with that. There's no standard there, and newlib doesn't provide a write() that calls _write_r() regardless. that goes through CIO, we're good because I can replace it *If* you link in libgloss (you don't have to), *and* you don't provide a copy of write(), *then* a copy that uses CIO is linked in via -lgloss. So go ahead and replace it. with one that delegates to a descriptor-specific implementation. If the definitions aren't weak, we're probably not good. It's in a library, one per object. If you provide your own, the linker won't link in the libgloss version. It doesn't need to be weak. I'll hold off on further comment until I have an opportunity to see what actually needs to be done to make this work. I expect something that allows me to do for the msp430 what I did for ARM as described at: http://pabigot.github.io/bspacm/newlib.html#newlib_sys 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. -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/NeoTech ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] MSP430 simulator in gdb
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 simulator at the end of the branch handler (u1 is
the true/false conditional, which is true for unconditional branches
of cours):
if (u1)
{
if (TRACE_BRANCH_P (MSP430_CPU (sd)))
trace_generic (sd, MSP430_CPU (sd), TRACE_BRANCH_IDX,
J%s: pc %#x - %#x sr %#x, taken,
cond_string (opcode-cond), PC, i, SR);
PC = i;
if (PC == opcode_pc)
exit (0);
}
else
if (TRACE_BRANCH_P (MSP430_CPU (sd)))
trace_generic (sd, MSP430_CPU (sd), TRACE_BRANCH_IDX,
J%s: pc %#x to %#x sr %#x, not taken,
cond_string (opcode-cond), PC, i, SR);
The other way to call exit() (in the RH simulator) is to call 0x181 as
if it were the C function exit(). The simulator traps call to
0x18N and does a syscall N instead of the call. This is a
non-standard interface though, but the only way to call exit() with a
non-zero return code.
What is the inline asm syntax that will give me this?
Just do this:
for(;;);
or this:
#define exit() __asm__ volatile (1: BR #1b)
--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] MSP430 simulator in gdb
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 Both of these are linked at the same point as libc and libgcc, by the gcc driver, depending on whether or not you use the -msim option. Both are from libgloss, but have slightly different versions of some functions to compensate for the differences between the simulator and real hardware, mostly the non-CIO system calls like exit(). -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/NeoTech ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] Unable to use LARGE MEMORY MODEL with RH GCC
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 http://p.sf.net/sfu/restlet ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] Unable to use LARGE MEMORY MODEL with RH GCC
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. -- Time is money. Stop wasting it! Get your web API in 5 minutes. www.restlet.com/download http://p.sf.net/sfu/restlet ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
