Re: Supporting 'MAC' instruction on gcc v4.1.1
On Wed, May 16, 2007 at 11:16:59AM +0530, Rahul wrote: > But for -O0 optimization, even the 'progname.c.*.combine file' is > *not* getting generated for '-fdump-rtl-all / -fdump-rtl-combine' > options. The *.combine dumpfile is generated when the combine pass runs. > Please tell me whether the combining of related instructions, by the > combiner, will be taking place only when optimization is enabled? Combination of instructions is an optimization and needs at least -O1. > if > that is the case, is there any way to make gcc recognize the 'MAC" > pattern for -O0 optimisation? It would be entirely possible to add an option such as -fcombine-instructions to enable the life1 and combine passes separately. -- Rask Ingemann Lambertsen
Doubt regarding dwarf info generated for var_args function
Hi all,
I need some clarification regarding the debug information generated
for var_args function. I am working with GCC 4.1.1. In my target,
var_args registers are saved in stack frame during function prologue
(similiar to fr30).
### sample program ###
#include
int fun(const char *temp,...)
{
return 9;
}
int main()
{
fun("Hello World",1,2);
return 0;
}
# objdump###
SP - stack pointer
FP - Frame Pointer
0294 <_fun>:
294:STR D3,-(SP)
296:STR D2,-(SP)// value '2'
298:STR D1,-(SP) // value '1'
29a:STR D0,-(SP) // value representing variable "temp",
address of Hello World
29c:STR FP,-(SP)
29e: MOV SP,FP
2a0: MOV 0x9,D0
2a2: LDR (SP)+,FP
2a4: ADD 0x10,SP
2a6: RTS
# readelf output ###
<1><102>: Abbrev Number: 6 (DW_TAG_subprogram)
DW_AT_sibling : <130>
DW_AT_external: 1
DW_AT_name: fun
DW_AT_decl_file : 10
DW_AT_decl_line : 4
DW_AT_prototyped : 1
DW_AT_type: <52>
DW_AT_low_pc : 0x294
DW_AT_high_pc : 0x2a8
DW_AT_frame_base : 0 (location list)
<2><11f>: Abbrev Number: 7 (DW_TAG_formal_parameter)
DW_AT_name: temp
DW_AT_decl_file : 10
DW_AT_decl_line : 3
DW_AT_type:
DW_AT_location: 2 byte block: 91 0 (DW_OP_fbreg: 0)
Contents of the .debug_loc section:
OffsetBegin EndExpression
0294 0296 (DW_OP_regSP)
0296 0298 (DW_OP_bregSP: 4)
0298 029a (DW_OP_bregSP: 8)
029a 029c (DW_OP_bregSP: 12)
029c 029e (DW_OP_bregSP: 16)
029e 02a0 (DW_OP_bregSP: 20)
02a0 02a8 (DW_OP_bregFP: 20)
From the debug info generated, frame base for "fun" starts from 0x00.
The corresponding location expression for "temp" in address range
0x294 -0x296 is SP (Stack Pointer). But at that instant, it is not
correct.
The value of "temp" is in register D0 which gets stored in stack only
when instruction at 0x29a is executed. Until then this value is
undefined. Is it right?
Is this the right behavior or am i missing something?
Regards,
Rohit
trimming excess errors from -Werror
Hey. I'm looking at some of the new fails on cygwin and AIX. Both of these platforms have fails that don't happen on linux. These fails look like: cc1plus: warnings being treated as errors /cygdrive/e/gnu/gcc-4.3-20070511/libstdc++-v3/testsuite/17_intro/headers/all_c++200x_compatibility.cc:1: error: -ffunction-sections may affect debugging on some targets compiler exited with status 1 output is: cc1plus: warnings being treated as errors /cygdrive/e/gnu/gcc-4.3-20070511/libstdc++-v3/testsuite/17_intro/headers/all_c++200x_compatibility.cc:1: error: -ffunction-sections may affect debugging on some targets FAIL: 17_intro/headers/all_c++200x_compatibility.cc (test for excess errors) Excess errors: cc1plus: warnings being treated as errors The compile lines look the same, ie same flags on AIX, linux, cygwin. Why is the behavior different? Is this actually an error with -ffunction-sections on these platforms? I certainly don't see this warning/error on linux: what's up? If so, why is dejagnu giving me the incorrect info? (Is it because of ffunction-sections warnings being trimmed?) And if this is an issue with -ffunction-sections, why not just say that function-sections is not supported on this platform, full stop? This certainly seems to be the case: http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#Optimize-Options -benjamin
some errors while compiling gcc-4.2.1 on windows
Hello, Please excuse me if this email would have had its place on the bugzilla, like for my poor English, but I met some erros while trying to compile GCC-4.2.1. under windows xp, with an athlon-xp based pc. First one appeard in gfortran.h. It seems that uint is not recognized as a good type name while declaring try gfc_add_attribute (symbol_attribute *, locus *, uint); (line 1741) The options passed at configure were: --prefix=/mingw --target=mingw32 --host=mingw32 --program-prefix="" \ --with-as=/mingw/bin/as.exe --with-ld=/mingw/bin/ld.exe --enable-threads --enable-nls \ --enable-languages=c,c++,fortran,ada,java,objc,obj-c++,treelang \ --enable-stage1-languagess=c,c++ --disable-win32-registry \ --disable-shared --without-x --enable-interpreter --enable-hash-synchronization \ --enable-libstdcxx-debug --with-gmp=/mingw --with-mpfr=/mingw where /mingw is a toplevel directory where can be found as, binutils tools, winsup headers and gmp/mpfr just compiled libraries and make: make CFLAGS="-O2 -fomit-frame-pointer " CXXFLAGS="-O2 fno-omit-frame-pointer -mthreads" LDFLAGS=-s bootstrap-lean It appears that uint is only like UINT, or nested other thinks like uint32_t or uint64_t I temporarily solved this problem by inserting lines #ifndef uint #define uint unsigned int #endif at the beginning gfortran.h file (line 73), but can be would be it interesting to be able another way (by placing a test in config/using a definition in gmp?)? Second one appears in gnat_ugn.texi at line 110 (@syncodeindex fn cp) temporarily solved by comment it Last one appeares while making gnattools, and i didn't find any solution. While performing xgcc -B../../ -c -g -O2 -W -Wall -gnatpg a-calend.adb -o a-caland.o" make exists on error a-calend.adb:44:17: "Ada.Calendar" is not a predefinded library unit Hoping this mail will help. Regards Philippe Dunski
RE: trimming excess errors from -Werror
> > cc1plus: warnings being treated as errors > > /cygdrive/e/gnu/gcc-4.3-20070511/libstdc++-v3/testsuite/17_int > ro/headers/all_c++200x_compatibility.cc:1: > error: -ffunction-sections may affect debugging on some targets > This is actually a useful warning, since -ffunction-sections not only affects debugging but also adds unnecessary size to executables on PE-COFF targets (and others where ld does not support --gc-sections). One way to avoid is to add --enable-cxx-flags='-fno-function-sections -fno-data-sections' to configure Danny
Re: trimming excess errors from -Werror
This is actually a useful warning, since -ffunction-sections not only
affects debugging but also adds unnecessary size to executables on
PE-COFF targets (and others where ld does not support --gc-sections).
One way to avoid is to add --enable-cxx-flags='-fno-function-sections
-fno-data-sections' to configure
libstdc++ configure is already probing to see if the target supports the
use of this flag without errors. It thinks AIX and cygwin can use this
flag without errors or warnings, which is clearly wrong.
So, something needs to be fixed.
Can you try
int i;
with "-Werror -ffunction-sections -fdata-sections" and see if you get an
error with g++?
if not, can you try
int i;
void bar() { }
with the same flags and see if you get the error?
best,
benjamin
Re: trimming excess errors from -Werror
[EMAIL PROTECTED] wrote: cc1plus: warnings being treated as errors /cygdrive/e/gnu/gcc-4.3-20070511/libstdc++-v3/testsuite/17_int ro/headers/all_c++200x_compatibility.cc:1: error: -ffunction-sections may affect debugging on some targets This is actually a useful warning, since -ffunction-sections not only affects debugging but also adds unnecessary size to executables on PE-COFF targets (and others where ld does not support --gc-sections). One way to avoid is to add --enable-cxx-flags='-fno-function-sections -fno-data-sections' to configure Danny Another way is to add this warning to the list of warnings which will be accepted by dejagnu.
Re: libffi & powerpc
ok, I've created PR31937 related to the libffi bug and I've also submitted a quick patch to the gcc-patches mailing list Patrick On 5/16/07, Mike Stump <[EMAIL PROTECTED]> wrote: On May 15, 2007, at 2:20 AM, Patrick Olinet wrote: > Finally, I've tried it the dirty way, ie by commenting out all the > "stfd" instructions at the beginning of the ppc_closure.S file and > things seem to work !!! Wonderful. If you could, would you submit the patch to gcc- patches... I suspect it is better than nothing, and it might be trivial enough to go in without paperwork. Additionally, it might provide a basis for another contributor to build upon, as they then only have to do half the work. Thanks. > What worries me a bit is that "stfd" instructions are used to save > fpu registers states before the call (it's my guess) and I would > expect them to be restored afterwards, probably with "lfd" assembly > instructions (that I would need to comment out as well). But I > can't see such instructions... > Any thoughts about that ? Sure, don't worry about it, there is no matching instruction. You just can't do functions that return float/double/long double from my quick reading. > And should I report a new bug for this libffi/powerpc problem ? We prefer to have a bug report for each bug... :-)
RE: trimming excess errors from -Werror
>
> libstdc++ configure is already probing to see if the target
> supports the
> use of this flag without errors. It thinks AIX and cygwin can
> use this
> flag without errors or warnings, which is clearly wrong.
>
> So, something needs to be fixed.
>
> Can you try
>
> int i;
>
> with "-Werror -ffunction-sections -fdata-sections" and see if
> you get an
> error with g++?
With GNU C++ version 4.3.0 20070513 (experimental) (i686-pc-mingw32dw2)
No error. i is put in its own section .data$i
>
> if not, can you try
>
> int i;
> void bar() { }
>
> with the same flags and see if you get the error?
>
No error. bar is put in .text$_Z3barv
Danny
Re: trimming excess errors from -Werror
Weird. Does -std=c++0x or -std=gnu++0x make a difference? I'm trying to figure out why I see this warning/error for things like 17_intro/headers/all_c++200x_compatibility.cc but not always. -benjamin
Problems with compiling svn trunk
This also occurred with the latest snapshot: Configure syntax was: ./configure --prefix=/opt/gcc-4.3 Configure completed fine. Make is getting stuck at: /part/build/mark/gcc/host-x86_64-unknown-linux-gnu/gcc/xgcc -B/part/build/mark/gcc/host-x86_64-unknown-linux-gnu/gcc/ -B/opt/gcc-4.3/x86_64-unknown-linux-gnu/bin/ -B/opt/gcc-4.3/x86_64-unknown-linux-gnu/lib/ -isystem /opt/gcc-4.3/x86_64-unknown-linux-gnu/include -isystem /opt/gcc-4.3/x86_64-unknown-linux-gnu/sys-include -g -fkeep-inline-functions -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 -I. -I. -I../../host-x86_64-unknown-linux-gnu/gcc -I../.././libgcc -I../.././libgcc/. -I../.././libgcc/../gcc -I../.././libgcc/../include -I../.././libgcc/../libdecnumber/bid -I../.././libgcc/../libdecnumber -I../../libdecnumber -o decContext.o -MT decContext.o -MD -MP -MF decContext.dep -c ../.././libgcc/../libdecnumber/decContext.c In file included from ../.././libgcc/../libdecnumber/decContext.c:36: ../.././libgcc/../libdecnumber/decContext.h:52:50: error: gstdint.h: No such file or directory ... lots of other errors ... gstdint.h seems to be at: /part/build/mark/gcc/host-x86_64-unknown-linux-gnu/libdecnumber/gstdint.h I'm a bit lost at the moment as I've never had to figure out how the gcc make/bootstrap works until now, nor has it ever failed me in the past. Any ideas? Thanks, mark -- [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] __ . . _ ._ . . .__. . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/|_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/
Re: Problems with compiling svn trunk
In file included from ../.././libgcc/../libdecnumber/decContext.c:36: ../.././libgcc/../libdecnumber/decContext.h:52:50: error: gstdint.h: No such file or directory ... lots of other errors ... gstdint.h seems to be at: /part/build/mark/gcc/host-x86_64-unknown-linux-gnu/libdecnumber/ gstdint.h I'm a bit lost at the moment as I've never had to figure out how the gcc make/bootstrap works until now, nor has it ever failed me in the past. I ran into this recently too, I thought it was a local OS issue since we've had some header churn recently, but this appears to be a general issue. Should look to see if we can track down which patch did it. -eric
RE: trimming excess errors from -Werror
> > Can you try
> >
> > int i;
> >
> > with "-Werror -ffunction-sections -fdata-sections" and see if
> > you get an
> > error with g++?
>
> With GNU C++ version 4.3.0 20070513 (experimental)
> (i686-pc-mingw32dw2)
> No error. i is put in its own section .data$i
But error when I add "-g" to above
> >
> > if not, can you try
> >
> > int i;
> > void bar() { }
> >
> > with the same flags and see if you get the error?
> >
> No error. bar is put in .text$_Z3barv
And also error when I add "-g"
Danny
Re: Problems with compiling svn trunk
On 5/16/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: This also occurred with the latest snapshot: Configure syntax was: ./configure --prefix=/opt/gcc-4.3 Configure completed fine. Make is getting stuck at: You are compiling in the source directory which is not a well supported way of compiling GCC. Thanks, Andrew Pinski
Re: Problems with compiling svn trunk
On May 16, 2007, at 1:53 PM, Andrew Pinski wrote: On 5/16/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: This also occurred with the latest snapshot: Configure syntax was: ./configure --prefix=/opt/gcc-4.3 Configure completed fine. Make is getting stuck at: You are compiling in the source directory which is not a well supported way of compiling GCC. Yeah, but I wasn't and still ran into that (or similar) problem. :) -eric
backport of Revision 120684 for Macintel into gcc 4.2.1?
Currently gcc 4.2.0 suffers from 90 libjava failures on i686-apple-darwin8 including the boehm gctest. Backporting the changes from revision 120684... http://gcc.gnu.org/viewcvs?view=rev&revision=120684 as suggested in... http://article.gmane.org/gmane.comp.programming.garbage-collection.boehmgc/1416/match=xcode http://article.gmane.org/gmane.comp.programming.garbage-collection.boehmgc/1542/match=xcode reduces the number of failures to 27. The remaining failures in the libjava testsuite are now... WARNING: program timed out. FAIL: Process_5 -O3 execution - bytecode->native test FAIL: StackTrace2 output - gij test FAIL: StackTrace2 output - gij test FAIL: StackTrace2 output - gij test FAIL: StackTrace2 output - gij test FAIL: SyncTest execution - gij test FAIL: SyncTest execution - gij test FAIL: SyncTest execution - gij test FAIL: SyncTest execution - gij test FAIL: Throw_2 execution - source compiled test FAIL: Throw_2 execution - gij test FAIL: Throw_2 execution - bytecode->native test FAIL: Throw_2 execution - gij test FAIL: Throw_2 -findirect-dispatch execution - bytecode->native test FAIL: Throw_2 -O3 execution - source compiled test FAIL: Throw_2 execution - gij test FAIL: Throw_2 -O3 execution - bytecode->native test FAIL: Throw_2 execution - gij test FAIL: Throw_2 -O3 -findirect-dispatch execution - bytecode->native test FAIL: initexc execution - gij test FAIL: initexc execution - gij test FAIL: initexc execution - gij test FAIL: initexc execution - gij test FAIL: stacktrace output - gij test FAIL: stacktrace output - gij test FAIL: stacktrace output - gij test FAIL: stacktrace output - gij test which includes one new failure (Process_5). Shouldn''t the changes in revision 120684 be backported to gcc 4.2.1? Also does anyone know if additional fixes to eliminate these remaining failures currently reside in gcc trunk? Thanks in advance. Jack
Re: backport of Revision 120684 for Macintel into gcc 4.2.1?
On May 16, 2007, at 8:00 PM, Jack Howarth wrote: Currently gcc 4.2.0 suffers from 90 libjava failures on i686- apple-darwin8 including the boehm gctest. Backporting the changes from revision 120684... http://gcc.gnu.org/viewcvs?view=rev&revision=120684 as suggested in... which includes one new failure (Process_5). Shouldn''t the changes in revision 120684 be backported to gcc 4.2.1? Also does anyone know if additional fixes to eliminate these remaining failures currently reside in gcc trunk? Thanks in advance. Sure, seems reasonable. -eric
