Re: " throw logic error" abort, but print no error message out
Hello Jonathan
On 14.11.08, you wrote:
>If exceptions are enabled
> __throw_logic_error will throw std::logic_error, otherwise it will
> call abort().
On the amigaos compiler is sjlj enabled, i see in asm debugger after
single
stepping long it call std::logic_error.but this func do nothing print.
so i simplyfy the testprogram and see std::logic_error("test\n"); does not
output anything.
I test this too on cygwin gcc 3.4 x86 compiler(on amigaos i use 4.3.2
compiler and the attached libstdc++).Its the same output(cout and assert
work ok) but std::logic_error not.
i look to find in sourcecode the place where logic_error do any action and
print out text, but i dont find a print command.
maybe you can tell me the place where logic_error do action to print, so i
can set a breakpoint on that
place and singlestep to see whats go wrong.
---the testprog --
#include
#include
int main(int argc, char *argv[])
{
std::cout<<"Hallo World\n";
std::logic_error("test\n");
assert(0);
}
If so assert does not work when
> 2008/11/12 Bernd Roesch:
>>
>> But in libstdc++v3/src/functexcept.cc
>>
>> void
>> __throw_logic_error(const char*)
>> { std::abort(); }
>>
>> this call abort and there is no string print out, because abort get no
>> Parameter as far i see.
>>
>> How can this work ?
>
> It works by calling abort(), as intended.
>
> If you take another look in functexcept.cc you'll see that when
> __EXCEPTIONS is defined the following definition is used:
>
> void
> __throw_logic_error(const char* __s)
> { throw logic_error(_(__s)); }
>
> This allows the library to call __throw_logic_error without caring
> whether the target supports exceptions, or whether they have been
> disabled with -fno-exceptions. If exceptions are enabled
> __throw_logic_error will throw std::logic_error, otherwise it will
> call abort().
>
> It seems that the 68k amigaos port does not support exceptions, or
> your GCC was configured without support for exceptions.
>
> Hope that helps,
>
> Jonathan
Regards
ARM machine description: how are pool_ranges calculated
Hi! I'd appreciate help with my learner's questions about GCC machine descriptions, about the ARM code generator. I'm trying to fix code generation for the Cirrus MaverickCrunch FPU by trying to understand several sets of patches, figure out which are bogus which are buggy and which need reimplementing, and to distill the essence of them into one "proper" set, but each day I'm ending up confused by too many things about MDs that I am not certain of, so some help would be appreciated. On with the first question... ARM machine description and pool ranges: How should the value in the pool_range and neg_pool_range attributes be calculated? What precisely do the values represent? Here's how far I got: In the machine description, the pool_range and neg_pool_range attributes tell how far ahead or behind the current instruction a constant can be loaded relative to the current instruction. The most common values are: - a sign bit and a 12-bit byte offset for ARM load insns (+/- 0 to 4095 bytes, max usable of 4092 for 4-byte-aligned words) - a sign bit and an 8-bit word offset for Maverick and VFP load insns (+/- 0 to 1020 bytes) - other ranges for thumb instructions and iwmmxt, depending on insn and addressing mode When the offsets stored in the instructions are used, they refer to offsets from the address of the instruction (IA) plus 8 bytes. Are the pool_ranges also calculated from IA+8, from the address of the instruction itself or even from the address of the following instruction (IA+4)? In the md, the most common pairs of values are (-4084, +4096) (-1008, +1020) but there several other values in use for no obvious reason: +4092, -1004, -1012, +1024 The +4096 (>4092) suggests that they are not the values as encoded in the instruction, but are offset by at least 4. The full useful ranges offset by 8 would give (-4084, +4100) (-1016, +1028) I can't find a mathematically explicit comment about it, and can't make sense of the values. In practice, by compiling autogenerated test programs and objdumping them -d: 32-bit integer constants use from [pc, #-4092] to [pc, #4084] 64-bit constants in pairs of ARM registers use from [pc, #-3072] to [pc, #3068] (??) Alternating 32- and 64-bit constants use from [pc, #-3412] to [pc, #3404] (???) 64-bit doubles in Maverick registers use from [pc, #-1020] to [pc, #1008] (these are the exact values specified in the attributes fields of cirrus.md for the cfldrd insn, without any IA+8 adjustment!) Two non-issues - 64-bit alignment requirement for 64-bit quantities in EABI is not applied to the constant pools - 64-bit data is 32-bit aligned there, so no allowance of a possible extra 4 bytes for alignment is necessary. - the -mcirrus-fix-invalid-insns flag, which peppers the output with NOPs, causes no problems since the constant pool calculations are done after the NOP-insertion. Hoping I haven't just failed to spot some large and obvious comment... M
Re: Cygwin support
On Fri, 14 Nov 2008, Brian Dessent wrote: > "Joseph S. Myers" wrote: > > > As I understand it, there is an alternative - put all the shared code in a > > DLL on Windows if configuring with plugins enabled, and link both the > > plugins and cc1, cc1plus etc. with that DLL. If people wish to enable > > The problem with that approach is that people have so far said they want > access to every aspect of the compiler from within the plugin, i.e. to > poke and prod at the full symbol table, without being tied down by a > limited, designated access route of a plugin API. This means you'd have > to move essentially everything into this mega-DLL, leaving cc1 and > friends as merely stubs that set a flag and then call into the DLL never > to return, since anything left in cc1 would not be accessible from the > plugin. > > That would present a problem to packagers. Since the code for all the > language backends would be in this one mega-DLL, it would be impossible > to install one language's compiler without installing all of them. > Sure, you could still split it up into separate packages for the sake of > the other runtime library support components and headers, but the user > would still be paying the price in terms of disk and memory consumption > of this mega-DLL that supports all languages when only using one of > them. Is there some reason there couldn't be one DLL for the code shared between all languages and separate DLLs with each language's front end code? So a plugin that only plugs in to the language-independent code would only need the common DLL, and only plugins for front ends would need that front end's DLL. cc1 would load just the two DLLs for C and for shared code, not all of them. -- Joseph S. Myers [EMAIL PROTECTED]
Get function declaration on GCC 3.3
Hi all, I am using GCC 3.3. In macro INIT_CUMULATIVE_ARGS(CUM, FNTYPE, LIBNAME, INDIRECT), I want to know the declaration of callee function (fndecl). I know the function get_callee_fndecl(call_expr) to use in this case, but I don't know how to get call_expr in this step. I use callee's fndecl to determine whether passing arguments for callee by registers or by stack by initialize CUM perspective. Can you help me in this situation? Thanks in advance. Le Ton Chanh email:letonchanh at yahoo dot com
