RE: GCC Making a new PASS
Hi Prakash,
> statement ; print("%s %d\n", __FILE__, __LINE__);
> So that when program is running I know which file which line of my program
> is getting executed.
Just curious to know. Is there any real world application/product where this
will help? Can you give more context to this requirement.
Regards,
Kannan
-Original Message-
From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of Satya
Prakash Prasad
Sent: Tuesday, June 12, 2012 12:05 PM
To: Ian Lance Taylor
Cc: gcc@gcc.gnu.org
Subject: Re: GCC Making a new PASS
Thanks to all my issue got resolved.
I placed the code in 'if block' checking cfun is NULL or not and
removed gcc_assert. It worked fine for me.
My idea is to print the lines of source code gcc is compiling. Further
to that I want to update the statement with
statement ; print("%s %d\n", __FILE__, __LINE__);
So that when program is running I know which file which line of my
program is getting executed. I tried printing statements in
pass_remove_useless_stmts pass but I think these are internal GCC
stages. I see statements of code like:
if (D.3886 > 0)
{
D.3887 = obj->funcs;
D.3888 = D.3887->close;
D.3886 = obj->next_input;
D.3888 (obj, D.3886);
}
So please let me know how can I achieve the objective and which pass
should I make use of?
Regards,
Prakash
On Tue, Jun 12, 2012 at 11:06 AM, Ian Lance Taylor wrote:
> Satya Prakash Prasad writes:
>
>> But the compilation process fails further on:
>>
>> gcc/gcc-4.1.2/host-x86_64-unknown-linux-gnu/gcc/xgcc
>> -Bgcc/gcc-4.1.2/host-x86_64-unknown-linux-gnu/gcc/
>> -B/usr/local/x86_64-unknown-linux-gnu/bin/
>> -B/usr/local/x86_64-unknown-linux-gnu/lib/ -isystem
>> /usr/local/x86_64-unknown-linux-gnu/include -isystem
>> /usr/local/x86_64-unknown-linux-gnu/sys-include -O2 -O2 -g -O2
>> -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes
>> -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC
>> -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -msse -c
>> \
>> ../.././gcc/config/i386/crtfastmath.c \
>> -o crtfastmath.o
>> ../.././gcc/config/i386/crtfastmath.c:110: internal compiler error:
>> Segmentation fault
>> Please submit a full bug report,
>> with preprocessed source if appropriate.
>> See http://gcc.gnu.org/bugs.html> for instructions.
>> make[2]: *** [crtfastmath.o] Error 1
>> make[2]: Leaving directory `gcc/gcc-4.1.2/host-x86_64-unknown-linux-gnu/gcc'
>> make[1]: *** [all-gcc] Error 2
>> make[1]: Leaving directory `gcc/gcc-4.1.2'
>> make: *** [all] Error 2
>> gcc/gcc-4.1.2 1223>
>>
>> Any help - why the issue is occurring and how can I achieve the objective?
>
> The straightforward approach will be to pull out the debugger and see
> what is going on when the compiler crashes. It may help to look at
> http://gcc.gnu.org/wiki/DebuggingGCC .
>
> Ian
Re: GCC Making a new PASS
Regarding requirement - yes. I believe that it would be a powerful
debugging tool to develop. It would be so powerful for analyzing code
flow of flows for very large projects - that an ordinary developer can
understand code in minutes. Say I have 100,000,00 Lines of code.
Debugging using GDB or any other mechanism would be really difficult
that I know. If I have after each statement
print("%s %d\n", __FILE__, __LINE__);
I can know where my code is flowing during execution. I a firm
believer that this tool will help developers a lot for debugging /
analyzing and profiling code.
Regards,
Prakash
On Tue, Jun 12, 2012 at 12:43 PM, Mailaripillai, Kannan Jeganathan
wrote:
> Hi Prakash,
>
>> statement ; print("%s %d\n", __FILE__, __LINE__);
>> So that when program is running I know which file which line of my program
>> is getting executed.
>
> Just curious to know. Is there any real world application/product where this
> will help? Can you give more context to this requirement.
>
> Regards,
> Kannan
>
> -Original Message-
> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of Satya
> Prakash Prasad
> Sent: Tuesday, June 12, 2012 12:05 PM
> To: Ian Lance Taylor
> Cc: gcc@gcc.gnu.org
> Subject: Re: GCC Making a new PASS
>
> Thanks to all my issue got resolved.
>
> I placed the code in 'if block' checking cfun is NULL or not and
> removed gcc_assert. It worked fine for me.
>
> My idea is to print the lines of source code gcc is compiling. Further
> to that I want to update the statement with
>
> statement ; print("%s %d\n", __FILE__, __LINE__);
>
> So that when program is running I know which file which line of my
> program is getting executed. I tried printing statements in
> pass_remove_useless_stmts pass but I think these are internal GCC
> stages. I see statements of code like:
>
> if (D.3886 > 0)
> {
> D.3887 = obj->funcs;
> D.3888 = D.3887->close;
> D.3886 = obj->next_input;
> D.3888 (obj, D.3886);
> }
>
> So please let me know how can I achieve the objective and which pass
> should I make use of?
>
> Regards,
> Prakash
>
> On Tue, Jun 12, 2012 at 11:06 AM, Ian Lance Taylor wrote:
>> Satya Prakash Prasad writes:
>>
>>> But the compilation process fails further on:
>>>
>>> gcc/gcc-4.1.2/host-x86_64-unknown-linux-gnu/gcc/xgcc
>>> -Bgcc/gcc-4.1.2/host-x86_64-unknown-linux-gnu/gcc/
>>> -B/usr/local/x86_64-unknown-linux-gnu/bin/
>>> -B/usr/local/x86_64-unknown-linux-gnu/lib/ -isystem
>>> /usr/local/x86_64-unknown-linux-gnu/include -isystem
>>> /usr/local/x86_64-unknown-linux-gnu/sys-include -O2 -O2 -g -O2
>>> -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes
>>> -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC
>>> -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -msse -c
>>> \
>>> ../.././gcc/config/i386/crtfastmath.c \
>>> -o crtfastmath.o
>>> ../.././gcc/config/i386/crtfastmath.c:110: internal compiler error:
>>> Segmentation fault
>>> Please submit a full bug report,
>>> with preprocessed source if appropriate.
>>> See http://gcc.gnu.org/bugs.html> for instructions.
>>> make[2]: *** [crtfastmath.o] Error 1
>>> make[2]: Leaving directory `gcc/gcc-4.1.2/host-x86_64-unknown-linux-gnu/gcc'
>>> make[1]: *** [all-gcc] Error 2
>>> make[1]: Leaving directory `gcc/gcc-4.1.2'
>>> make: *** [all] Error 2
>>> gcc/gcc-4.1.2 1223>
>>>
>>> Any help - why the issue is occurring and how can I achieve the objective?
>>
>> The straightforward approach will be to pull out the debugger and see
>> what is going on when the compiler crashes. It may help to look at
>> http://gcc.gnu.org/wiki/DebuggingGCC .
>>
>> Ian
Re: GCC Making a new PASS
On Tue, Jun 12, 2012 at 8:34 AM, Satya Prakash Prasad
wrote:
> Thanks to all my issue got resolved.
>
> I placed the code in 'if block' checking cfun is NULL or not and
> removed gcc_assert. It worked fine for me.
>
> My idea is to print the lines of source code gcc is compiling. Further
> to that I want to update the statement with
>
> statement ; print("%s %d\n", __FILE__, __LINE__);
>
> So that when program is running I know which file which line of my
> program is getting executed. I tried printing statements in
> pass_remove_useless_stmts pass but I think these are internal GCC
> stages. I see statements of code like:
>
> if (D.3886 > 0)
> {
> D.3887 = obj->funcs;
> D.3888 = D.3887->close;
> D.3886 = obj->next_input;
> D.3888 (obj, D.3886);
> }
>
> So please let me know how can I achieve the objective and which pass
> should I make use of?
You probably want to modify the GENERIC representation, right before
gimplification. Look for the gimplify_function_tree function.
Richard.
> Regards,
> Prakash
>
> On Tue, Jun 12, 2012 at 11:06 AM, Ian Lance Taylor wrote:
>> Satya Prakash Prasad writes:
>>
>>> But the compilation process fails further on:
>>>
>>> gcc/gcc-4.1.2/host-x86_64-unknown-linux-gnu/gcc/xgcc
>>> -Bgcc/gcc-4.1.2/host-x86_64-unknown-linux-gnu/gcc/
>>> -B/usr/local/x86_64-unknown-linux-gnu/bin/
>>> -B/usr/local/x86_64-unknown-linux-gnu/lib/ -isystem
>>> /usr/local/x86_64-unknown-linux-gnu/include -isystem
>>> /usr/local/x86_64-unknown-linux-gnu/sys-include -O2 -O2 -g -O2
>>> -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes
>>> -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC
>>> -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -msse -c
>>> \
>>> ../.././gcc/config/i386/crtfastmath.c \
>>> -o crtfastmath.o
>>> ../.././gcc/config/i386/crtfastmath.c:110: internal compiler error:
>>> Segmentation fault
>>> Please submit a full bug report,
>>> with preprocessed source if appropriate.
>>> See http://gcc.gnu.org/bugs.html> for instructions.
>>> make[2]: *** [crtfastmath.o] Error 1
>>> make[2]: Leaving directory `gcc/gcc-4.1.2/host-x86_64-unknown-linux-gnu/gcc'
>>> make[1]: *** [all-gcc] Error 2
>>> make[1]: Leaving directory `gcc/gcc-4.1.2'
>>> make: *** [all] Error 2
>>> gcc/gcc-4.1.2 1223>
>>>
>>> Any help – why the issue is occurring and how can I achieve the objective?
>>
>> The straightforward approach will be to pull out the debugger and see
>> what is going on when the compiler crashes. It may help to look at
>> http://gcc.gnu.org/wiki/DebuggingGCC .
>>
>> Ian
Re: Is it possible to make gcc detect whether printf prints floating point numbers?
On Tue, 12 Jun 2012, Bin.Cheng wrote: > >> I noticed that GCC now can check format string of printf functions, so > >> I am wondering if it is possible to take advantage of this utility, by > >> making gcc detect whether printf prints floating point number and then > >> generate assembly directive in backend to pull in floating point > >> functions only if necessary. > > > > Obviously this won't help if the program is using functions such as > > vprintf to print things with variable format strings > One method is to analyze the type of arguments when format strings are > varying. Though this method might fail when user trying to output a > "long long" type int with conversion specifier "%f", I think it's not > a big deal. That method won't help for vprintf (unless you do something more complicated and interprocedural) since then you have just a (probably nonconstant) format strict and a (definitely nonconstant) va_list so don't know the types of the arguments at all. -- Joseph S. Myers jos...@codesourcery.com
Re: Endless "declared 'static' but never defined" warnings with stage 2 & 3 compilers
On 11/06/2012 21:20, t-rexky wrote:
#include
#include
int main() {
printf("%lf\n", acos(0.5));
return 0;
}
First, note that acos(0.5) is a "double" expression so its format should
be %f. However %lf is tolerated and this should not cause any trouble.
Second, the acos() call will be internally replaced by __builtin_acos()
which may be directly replaced by its result, if it can be computed at
compile time (which is the case in your example).
Try to add -fno-builtin on the command line to see if the same odd
things happen.
nextstep[Tests]$xgcc acos_test.c -o acos_test
:0: warning: '__builtin_acos' used but never defined
/NextDeveloper/Headers/ansi/math.h:55: warning: 'acos' used but never defined
The problem may be in your math.h. This header is not provided by GCC,
but by your math library. You should have a look to the indicated line
to see what is there.
Also, looking at the preprocessor output may help.
Try this:
xgcc -E acos_test.c
Then search for acos to see if there is nothing wierd.
Good luck.
--
Vincent Rivière
Re: Is it possible to make gcc detect whether printf prints floating point numbers?
Joseph S. Myers wrote: On Tue, 12 Jun 2012, Bin.Cheng wrote: I noticed that GCC now can check format string of printf functions, so I am wondering if it is possible to take advantage of this utility, by making gcc detect whether printf prints floating point number and then generate assembly directive in backend to pull in floating point functions only if necessary. Obviously this won't help if the program is using functions such as vprintf to print things with variable format strings One method is to analyze the type of arguments when format strings are varying. Though this method might fail when user trying to output a "long long" type int with conversion specifier "%f", I think it's not a big deal. That method won't help for vprintf (unless you do something more complicated and interprocedural) since then you have just a (probably nonconstant) format strict and a (definitely nonconstant) va_list so don't know the types of the arguments at all. The original question does not belong to gcc development. It's an embedded software tools issue. The straightforward solution is to supply the (library internal) ...printf() function that ultimately handles any C-style output format string. I mean a variant of this function that does not support floating point output. I used the word straightforward because embedded software development usually implies more intricate issues with the run-time support library (exception handling, dynamic memory, linker issues). The more serious the memory restrictions in the embedded environment, the more critical these issues become. Let gcc development proceed as a great compiler technology! Regards, -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, QC, Canada H2M 2A1 Tel. +1-514-385-5691
Re: [RFD+PATCH] ISA bit treatment on the MIPS platform
On 06/11/2012 07:20 PM, Joel Brobecker wrote: > From the ChangeLog entry, it seems like Pedro was involved in the making > of that patch, so perhaps he could be a good reviewer? All involvement I recall was updating a couple lines to new interfaces in the context of a merge from upstream. All else is pretty much as good as new to me. :-) -- Pedro Alves
tree-sra.c and BIT_FIELD_REF?
Our front end is wierd. The input is unusually low level, and so are the trees it produces. I do have a hankering to fix that (or maybe just to output more portable C...) But for now: It doesn't use component_refs, and doesn't define types much, but uses either either (type*)(base + offset) or bitfield_ref(base, offset, size). As such, it runs into occasional problems. I have had to turn off various optimizations with e.g.: flag_tree_sra = false in langhook_post_options. Looking at this briefly, I think I see one of the problems. tree-sra.c looks for component_refs to bitfields, but it doesn't look for bitfield_refs. It should? also, in fold-const: /* A bit-field-ref that referenced the full argument can be stripped. */ should probably check that the other type is integral and that the signedness matches. - Jay
Re: tree-sra.c and BIT_FIELD_REF?
Hi, On Tue, Jun 12, 2012 at 03:57:44PM +, Jay K wrote: > > Our front end is wierd. > The input is unusually low level, and so are the trees it produces. > I do have a hankering to fix that (or maybe just to output more portable C...) > But for now: > It doesn't use component_refs, and doesn't > define types much, but uses either > either (type*)(base + offset) or bitfield_ref(base, offset, size). > > As such, it runs into occasional problems. > I have had to turn off various optimizations with e.g.: > flag_tree_sra = false > in langhook_post_options. > > Looking at this briefly, I think I see one of the problems. > tree-sra.c looks for component_refs to bitfields, but > it doesn't look for bitfield_refs. It should? I am not sure what you mean, if you search for the sting BIT_FIELD_REF in tree-sra.c, you'll quickly find the places where we "look for" them (or perhaps I should write look through them). The most important ones are in functions build_access_from_expr_1 and especially sra_modify_expr. Having said that, Andrew Pinski has reported problems with SRA's handling of BIT_FIELD_REF in another special setup, so perhaps you have similar problems. Please have a look at the thread starting with message: http://gcc.gnu.org/ml/gcc-patches/2012-06/msg9.html So far it however looks that, if we ever come across such problems on trunk, we'll disable SRA for aggregate parts which are written to by a BIT_FIELD_REF on a left hand side, mainly because we do not consider them important for performance critical code. Thanks, Martin
RE: tree-sra.c and BIT_FIELD_REF?
> On Tue, Jun 12, 2012 at 03:57:44PM +, Jay K wrote: > > > > Our front end is wierd. > > The input is unusually low level, and so are the trees it produces. > > I do have a hankering to fix that (or maybe just to output more portable C...) > > But for now: > > It doesn't use component_refs, and doesn't > > define types much, but uses either > > either (type*)(base + offset) or bitfield_ref(base, offset, size). > > > > As such, it runs into occasional problems. > > I have had to turn off various optimizations with e.g.: > > flag_tree_sra = false > > in langhook_post_options. > > > > Looking at this briefly, I think I see one of the problems. > > tree-sra.c looks for component_refs to bitfields, but > > it doesn't look for bitfield_refs. It should? > > I am not sure what you mean, if you search for the sting BIT_FIELD_REF > in tree-sra.c, you'll quickly find the places where we "look for" them > (or perhaps I should write look through them). The most important > ones are in functions build_access_from_expr_1 and especially > sra_modify_expr. > > Having said that, Andrew Pinski has reported problems with SRA's > handling of BIT_FIELD_REF in another special setup, so perhaps you > have similar problems. Please have a look at the thread starting with > message: http://gcc.gnu.org/ml/gcc-patches/2012-06/msg9.html > > So far it however looks that, if we ever come across such problems on > trunk, we'll disable SRA for aggregate parts which are written to by a > BIT_FIELD_REF on a left hand side, mainly because we do not consider > them important for performance critical code. > > Thanks, > > Martin create_access is where I noticed it. Yeah, I know my report is vague and crummy. Maybe I should put together somesuch "hardcoded tree frontend" to demonstrate it. I don't think the trees I'm thinking of are producible from C, unless maybe via a gcc extension? I'll look later..like..I wonder where BIT_FIELD_REF would be used at all in a normal frontend. If I can find one, I'll maybe try to put together a test case for it. We do use them for reads and writes. Even for things like picking out exponent/mantissa from floats .. well, it used to. I changed it to prefer *(type*)(base + offset) when either base or type is floating point. Longer story: I changed to use *(type*)(base + offset) for floating point because we used to make everything addressable/volatile. Then all optimizations "worked" -- no internal compiler errors, bus errors, etc., but of course the code quality stunk. Though better with bit_field_ref than *(type*)(base + offset). In removing the addressable/volatile, I then had to work through the compiler errors, incorrect code, etc., disabling optimizations selectively, changing our trees some. I understand we generate weird trees, so I try not to complain too much. Thank you, - Jay
