Bugzilla entries for arc-elf32 target
hi, This is to follow up on a patch for PR8972 [1] submitted by me on the gcc-patches list some time back. it would be really nice if someone could have a look at the patch and commit it in. Presently all the execute tests time out because of the bug in code generation for multiple shift operations for ARCtangent-A4. The testsuite results with the patch applied to the mainline have been posted on gcc-testresults list [2]. May i also take this opportunity to ask for a localized write permission for the ARC back-end in the gcc cvs tree. We at codito have a GNU Tools port that supports the latest processors from ARC International, and would like to integrate this support into the mainline. With the commits happening more frequently, we can look ahead to scheduling this integration in the near future. Thanks in advance saurabh Links: ~ 1. http://gcc.gnu.org/ml/gcc-patches/2005-03/msg02171.html 2. http://gcc.gnu.org/ml/gcc-testresults/2005-06/msg01276.html 3. http://gcc.gnu.org/ml/gcc-patches/2005-06/msg00951.html (another pending patch:PR 8973) -- Saurabh Verma GNU Tools Team codito ergo sum (www.codito.com)
Query regarding execute test 960521-1. c in gcc.c-torture
hi,
i had a query regarding testcase gcc.c-torture/execute/960521-1.c [Link
below]. The testcase does the following:
i) mallocs two integer arrays a and b of size n each
ii) *b=0 and increment b
{lets call the new b as bnew, and the old b as bold, so
that bnew = bold+1,and bold[0]=bnew[-1]=0 }
iii) sets a[0] to a[n-1] to -1
iv) sets bnew[0] to bnew[BLOCK_SIZE-2] to -1
=> bold [1] to bold [BLOCK_SIZE-1] to -1
v) results in PASS if bnew [-1] {i.e. bold[0]} is still zero
FAILs otherwise
Now this test fails for a particular architecture, because on of the
mallocs returned zero (the amount of stack and heap available being 65K
and 20K respectively). This is because the testcase decides the size to
be malloc'ed based on the stack available. Since the heap space
available to me is much smaller than the stack, this calculation ( size
of each array = (STACK_SIZE / (sizeof (*a) + sizeof (*b results in
an impossibly large malloc request, and the array value setting
overwrites the text.
Before making any changes to the testcase to adapt it to our
requirements, i wanted to be sure about the reason for the test, i.e.
what exactly is the testcase supposed to check for? This is a very old
testcase and a look at viewcvs shows it as an initial import from egcs
testsuite base.
thanks in advance for any help
regards
saurabh
Link:
http://savannah.gnu.org/cgi-bin/viewcvs/*checkout*/gcc/gcc/gcc/testsuite/gcc.c-torture/execute/960521-1.c?rev=1.2&content-type=text/plain
Regarding delayed branches and CFGs
hi, On a target that supports delayed branches, i have the following code generated by gcc-3.4.4: Before dbr_schedule: ~~~ 1- label1: 2- cmp r0,100 3- branch.eq label2 ... 4- move r1, 0 ... 5- label2: 6- cmp r1, 0 7- branch.eq label1 After dbr_schedule: ~~ 1- label1: 2- cmp r0,100 3- branch.eq.delay label3 6- cmp r1, 0 ... 4- move r1, 0 ... 6- cmp r1, 0 8- label3: 7- branch.eq label1 Thus the cmp instruction is moved to the branch's(3) delay slot, and the branch is redirected to a new label(8) to avoid redundant comparison. Now, the problem is that, in absence of a cfg based optimization after the delayed branch, i end up with a pair of useless move-cmp instructions (4,6) in the same basic block. I saw a thread on the list, discussing why cfg build cannot be repeated after the delayed branch scheduler has been run. So, what would be the best approach to handle this situation? Thanx in advance for any suggestions/hints regards saurabh
Re: Regarding gcc Makefile.in
hi ashit, On Tue, 2006-01-24 at 15:39 +0530, Ashit Kumar wrote: > I am a newbie for GCC internals.Actually i want to build the GCC (say it > compile the GCC).Now during this i want to study the build process of it. a good starting point could be building gcc natively and looking at the build logs, to understand how make runs through the source tree during the build, i.e. builddir/> $GCCSRCDIR/configure builddir/> make 2>&1 |tee make.log And look at the make.log file to see how the build proceeds. HTH regards saurabh
Re: Information about .debug and .line section in elf files
Hello Olivier, I would suggest looking at ELF and DWARF specifications [1] for the standards documentation, and gcc/dwarf2out.c for the implementation. HTH Best regards saurabh Links: ~ 1. http://refspecs.freestandards.org/ On Wed, 2006-06-28 at 09:01 +0200, Oliver Eichler wrote: > Can anyone give me a > hint where to find more information? Or where to look within the gcc > source for stucture definitions.
Re: Call for port conversions to MD define_constraint
On Fri, 2007-05-25 at 12:41 -0700, Zack Weinberg wrote: > but there are still a lot left to go: > > arc bfin c4x cris crx fr30 frv h8300 iq2000 m32c m32r m68hc11 mcore mmix > mn10300 mt pa pdp11 score sh sparc stormy16 v850 vax I can provide the patch for arc sometime soon regards saurabh
Re: How to use GCC testsuite..?
The testsuite can be run with a simulator too (in absence of real hardware). You can refer to the *-sim.exp files in the dejagnu baseboards directory for sample specifications. HTH regards saurabh On Wed, 2007-06-27 at 00:18 +0300, Tehila Meyzels wrote: > > AFAIK, if you don't have such machine, you won't be able to run all > the > "need-to-be-executed" tests. > Only the tests that not suppose to run will be tested (like > compilation-only tests).
