How to assign proper static_pass_number and recalculate other ones?
Hi, I am creating my own RTL pass inside private backend (GCC 5.2.0) and I want to register it via register_pass call from override_options hook, to not interfere with platform-independent GCC code. register_pass (new my_cool_rtl_pass (g, "my_cool_pass"), PASS_POS_INSERT_AFTER, "sched1", 1); Everything just fine except the number of pass to print a dump file name is assigned the very last one (about 280), whereas pass itself should go immediately after sched1, so I want it to have static number 234 and dump file name as test.c.234.my_cool_pass. Now it runs after sched1 correctly, but have large number and visually goes in dump-all list at the end. Can I inside pass manager update all pass numbers after pass insertion to preserve visible dump order the same as run order? --- With best regards, Konstantin
Re: Debugger support for __float128 type?
On Thu, Oct 01, 2015 at 12:42:05AM +0200, Mark Kettenis wrote: > > Date: Wed, 30 Sep 2015 19:33:44 +0200 (CEST) > > From: "Ulrich Weigand" > > > > Hello, > > > > I've been looking into supporting __float128 in the debugger, since we're > > now introducing this type on PowerPC. Initially, I simply wanted to do > > whatever GDB does on Intel, but it turns out debugging __float128 doesn't > > work on Intel either ... > > > > The most obvious question is, how should the type be represented in > > DWARF debug info in the first place? Currently, GCC generates on i386: > > > > .uleb128 0x3# (DIE (0x2d) DW_TAG_base_type) > > .byte 0xc # DW_AT_byte_size > > .byte 0x4 # DW_AT_encoding > > .long .LASF0 # DW_AT_name: "long double" > > > > and > > > > .uleb128 0x3# (DIE (0x4c) DW_TAG_base_type) > > .byte 0x10# DW_AT_byte_size > > .byte 0x4 # DW_AT_encoding > > .long .LASF1 # DW_AT_name: "__float128" > > > > On x86_64, __float128 is encoded the same way, but long double is: > > > > .uleb128 0x3# (DIE (0x31) DW_TAG_base_type) > > .byte 0x10# DW_AT_byte_size > > .byte 0x4 # DW_AT_encoding > > .long .LASF0 # DW_AT_name: "long double" > > > > Now, GDB doesn't recognize __float128 on either platform, but on i386 > > it could at least in theory distinguish the two via DW_AT_byte_size. > > > > But on x86_64 (and also on powerpc), long double and __float128 have > > the identical DWARF encoding, except for the name. > > > > Looking at the current DWARF standard, it's not really clear how to > > make a distinction, either. The standard has no way to specifiy any > > particular floating-point format; the only attributes for a base type > > of DW_ATE_float encoding are related to the size. > > > > (For the Intel case, one option might be to represent the fact that > > for long double, there only 80 data bits and the rest is padding, via > > some combination of the DW_AT_bit_size and DW_AT_bit_offset or > > DW_AT_data_bit_offset attributes. But that wouldn't help for PowerPC > > since both long double and __float128 really use 128 data bits, > > just different encodings.) > > > > Some options might be: > > > > - Extend the official DWARF standard in some way > > > > - Use a private extension (e.g. from the platform-reserved > > DW_AT_encoding value range) > > > > - Have the debugger just hard-code a special case based > > on the __float128 name > > > > Am I missing something here? Any suggestions welcome ... > > > > B.t.w. is there interest in fixing this problem for Intel? I notice > > there is a GDB bug open on the issue, but nothing seems to have happened > > so far: https://sourceware.org/bugzilla/show_bug.cgi?id=14857 > > Perhaps you should start with explaining what __float128 actually is > on your specific platform? And what long double actually is. > > I'm guessing long double is a what we sometimes call an IBM long > double, which is essentially two IEEE double-precision floating point > numbers packed together and that __float128 is an attempt to fix > history and have a proper IEEE quad-precision floating point type ;). > And that __float128 isn't actually implemented in hardware. An IBM mainframe might want to discuss this point with you :-). See pages 24-25 of http://arith22.gforge.inria.fr/slides/s1-schwarz.pdf Latencies are decent, not extremely low, but we are speaking of a processor clocked at 5GHz, so the latencies are 2.2ns for add/subtract, 4.6ns for multiplications, and ~10ns for division. To put things in perspective, how many cycles is a memory access which misses in both L1 and L2 caches these days? > The reason people haven't bothered to fix this, is probably because > nobody actually implements quad-precision floating point in hardware. > And software implementations are so slow that people don't really use > them unless they need to. Like I did to nomerically calculate some > asymptotic expansions for my Thesis work... Which would probably run much faster if ported to a z13. Gabriel
Re: Clarifying attribute-const
On Fri, 25 Sep 2015, Eric Botcazou wrote: > > First, a belated follow-up to https://gcc.gnu.org/PR66512 . The bug is > > asking why attribute-const appears to have a weaker effect in C++, compared > > to C. The answer in that bug is that GCC assumes that attribute-const > > function can terminate by throwing an exception. > > FWIW there is an equivalent semantics in Ada: the "const" functions can throw > and the language explicitly allows them to be CSEd in this case, etc. Can you expand on the "etc." a bit, i.e., may the compiler ... - move a call to a "const" function above a conditional branch, causing a conditional throw to happen unconditionally? - move a call to a "const" function below a conditional branch, causing an unconditional throw to happen only conditionally? - reorder calls to "const" functions w.r.t. code with side effects, or other throwing functions? (all of the above in the context of Ada) Thanks. Alexander
Re: How to assign proper static_pass_number and recalculate other ones?
On 10/01/2015 02:47 AM, Konstantin Vladimirov wrote: Hi, I am creating my own RTL pass inside private backend (GCC 5.2.0) and I want to register it via register_pass call from override_options hook, to not interfere with platform-independent GCC code. register_pass (new my_cool_rtl_pass (g, "my_cool_pass"), PASS_POS_INSERT_AFTER, "sched1", 1); Everything just fine except the number of pass to print a dump file name is assigned the very last one (about 280), whereas pass itself should go immediately after sched1, so I want it to have static number 234 and dump file name as test.c.234.my_cool_pass. Now it runs after sched1 correctly, but have large number and visually goes in dump-all list at the end. Can I inside pass manager update all pass numbers after pass insertion to preserve visible dump order the same as run order? David probably knows best what's currently possible with dump numbers in the pass manager. He's on PTO this week. ISTM that whatever we're currently doing that if a pass is inserted by a plug-in that pass #s ought to auto-magically update themselves. jeff
Re: Debugger support for __float128 type?
Joseph Myers wrote: > On Wed, 30 Sep 2015, Ulrich Weigand wrote: > > > - Extend the official DWARF standard in some way > > I think you should do this. > > Note that TS 18661-4 will be coming out very soon, and includes (optional) > types > > * _FloatN, where N is 16, 32, 64 or >= 128 and a multiple of 32; > > * _DecimalN, where N >= 32 and a multiple of 32; > > * _Float32x, _Float64x, _Float128x, _Decimal64x, _Decimal128x > > so this is not simply a matter of supporting a GNU extension (not that > it's simply a GNU extension on x86_64 anyway - __float128 is explicitly > mentioned in the x86_64 ABI document), but of supporting an ISO C > extension, in any case where one of the above types is the same size and > radix as float / double / long double but has a different representation. Ah, thanks for pointing these out! The _DecimalN types are already supported by DWARF using a base type with encoding DW_ATE_decimal_float and the appropriate DW_AT_byte_size. For the interchange type, it seems one could define a new encoding, e.g. DW_ATE_interchange_float, and use this together with the appropriate DW_AT_byte_size to identify the format. However, for the extended types, the standard does not define a storage size or even a particular encoding, so it's not quite clear how to handle those. In theory, two different extended types could even have the same size ... On the other hand, in practice on current systems, it will probably be true that if you look at the set of all of the basic and extended (binary) types, there will be at most two different encodings for any given size, one corresponding to the interchange format of that size, and one other; so mapping those to DW_ATE_float vs. DW_ATE_interchange_float might suffice. I'm not sure how to handle an extended decimal format that does not match any of the decimal interchange formats. Does this occur in practice at all? > (All the above are distinct types in C, and distinct from float, double, > long double even if the representations are the same. But I don't think > DWARF needs to distinguish e.g. float and _Float32 other than by their > name - it's only the case of different representations that needs > distinguishing. The _Float* and _Float*x types have corresponding complex > types, but nothing further should be needed in DWARF for those once you > can represent _Float*.) Well, complex types have their own encoding (DW_ATE_complex_float), so we'd have to define the corresponding variants for those as well, e.g. DW_ATE_complex_interchange_float or the like. Bye, Ulrich -- Dr. Ulrich Weigand GNU/Linux compilers and toolchain ulrich.weig...@de.ibm.com
Re: Debugger support for __float128 type?
On Thu, 1 Oct 2015, Ulrich Weigand wrote: > The _DecimalN types are already supported by DWARF using a base type with > encoding DW_ATE_decimal_float and the appropriate DW_AT_byte_size. Which doesn't actually say whether the DPD or BID encoding is used, but as long as each architecture uses only one that's not a problem in practice. > For the interchange type, it seems one could define a new encoding, > e.g. DW_ATE_interchange_float, and use this together with the > appropriate DW_AT_byte_size to identify the format. It's not clear to me that (for example) distinguishing float and _Float32 (other than by name) is useful in DWARF (and if you change float from DW_ATE_float to DW_ATE_interchange_float that would affect old debuggers - is the idea to use DW_ATE_interchange_float only for the new types, not for old types with the same encodings, so for _Float32 but not float?). But it's true that if you say it's an interchange type then together with size and endianness that uniquely determines the encoding. > I'm not sure how to handle an extended decimal format that does not > match any of the decimal interchange formats. Does this occur in > practice at all? I don't know, but I doubt it. > Well, complex types have their own encoding (DW_ATE_complex_float), so we'd > have to define the corresponding variants for those as well, e.g. > DW_ATE_complex_interchange_float or the like. And DW_ATE_imaginary_interchange_float, I suppose. -- Joseph S. Myers jos...@codesourcery.com
Re: Clarifying attribute-const
> Can you expand on the "etc." a bit, i.e., may the compiler ... > > - move a call to a "const" function above a conditional branch, > causing a conditional throw to happen unconditionally? > > - move a call to a "const" function below a conditional branch, > causing an unconditional throw to happen only conditionally? The implementation permission is that you may omit calls to such functions, not that you can introduce them, so No and Yes respectively. > - reorder calls to "const" functions w.r.t. code with side effects, or > other throwing functions? This one is less clear, but I'd say Yes. -- Eric Botcazou
Minimal linker script for cortex M3 and M4 using gcc for c language applications
Hi list!,
I'm working in a project using gcc to develop applications using c
language for embedded systems based on ARM Cortex M3 and M4. I have
found some linker script used by commercial tools like lpcxpresso
(from NXP) or Code Composer Studio (from TI) and others frecuently
used for other developers with a lot of entries not documented. Where
can I find the minimal entries required to make a linker script for c
language applications using segments RAM and FLASH memories? As
example (because I think my english is not so good) look at the sample
code attached. Where can I find information about the entries marked
with ???->
Thanks a lot!
Sergio
MEMORY
{
flash(rx) : ORIGIN = 0, LENGTH = 512K
ram(wx) : ORIGIN = 0x2200, LENGTH = 64K-0x200
}
SECTIONS
{
. = 0;
.text :
{
KEEP(*(.isr_vector))
*(.text)
*(.text.*)
???-> *(.gnu.linkonce.t.*)
???->*(.glue_7)
???->*(.glue_7t)
???->*(.gcc_except_table)
???->*(.gcc_except_table.*)
???->*(.ARM.extab*)
???->*(.gnu.linkonce.armextab.*)
. = ALIGN(4);
*(.rodata)
*(.rodata.*)
???->*(.gnu.linkonce.r.*)
} > flash
???->__exidx_start = .;
???->.ARM.exidx :
???->{
???->*(.ARM.exidx* .gnu.linkonce.armexidx.*)
???->} > flash
???->__exidx_end = .;
. = ALIGN(8);
_etext = .;
.data : ALIGN(8)
{
_data = .;
*(.data)
*(.data.*)
???->*(.gnu.linkonce.d.*)
. = ALIGN(8);
_edata = .;
} > ram AT > flash
.bss :
{
_bss_start = .;
*(.bss)
*(.bss.*)
???->*(.gnu.linkonce.b.*)
. = ALIGN(8);
_bss_end = .;
} > ram
_end = .;
PROVIDE(end = .);
}
Re: Clarifying attribute-const
> On Oct 1, 2015, at 11:34 AM, Alexander Monakov wrote: > > Can you expand on the "etc." a bit, i.e., may the compiler ... > > - move a call to a "const" function above a conditional branch, >causing a conditional throw to happen unconditionally? No, calls may only be omitted, not moved. > > - move a call to a "const" function below a conditional branch, >causing an unconditional throw to happen only conditionally? > No, calls may only be omitted, not moved. > > - reorder calls to "const" functions w.r.t. code with side effects, or >other throwing functions? A call to a pure function (Ada's version of "const") may be omitted if its result is not used, or if results of an earlier call with the same argument values (including referenced values) can be used. This is allowed regardless of whether the original function had any side effects. Note that if a function raised an exception (threw) the call can only be replaced with throwing that exception. So, reordering is not allowed, but omitting is, in the context of Ada. -Geert
