Re: identifying a BB representing a self-loop
Hello, > >> If we compile this by "#gcc -c -O -da demo.c, we can see there are only > >> three BBs. Actually, BB1 is a self-looped basic block. But this loop > >> information is not explicitly expressed. > >> > > > >What do you mean "not explicitly expressed". > > > >If you call the loop finding routines (flow_loops_find), and look in the > >result loop information, does it not give you a loop with a single node? > > I meant that there is no edge like BB1-->BB1, if BB1 itself is a loop. For > example, but in your original example, this edge *is* present: > Basic block 1 > Successors: 1 2 Zdenek
Re: Segment registers support for i386
Hi people, I added an attribute "far" for the i386, this attribute takes one argument, the segment register. This attribute is intended to be use with pointers. There is something I'm not sure about Once the attribute handler has returned NULL_TREE without setting no_add_attr to true, the atribute is added in the ssa tree but how to handle this attribute after ? I must check and handle this attribute when gcc writes the .S file therefore in print_operand_address(). My problem is that print_operand_address use and rtx structure and not a tree one and I don't really understand how to access the attribute set up in the tree in the rtx struct. The patch for TLS model which uses %gs uses UNSPEC_TP and added some code in ix86_decompose_address() to check for an UNSPEC code. ok but in the same time there is some patterns defined in i386.md for UNSPEC and if I do the same, I'll probablty end up by modifying most of the patterns of the file to handle a new UNSPEC for the attribute. It seems to be too ugly so I was wondering if there is another way to do it. Thanks. Have a great day. -- Rémy SaissyJabberID: [EMAIL PROTECTED] Web: http://remysaissy.free.fr "L'homme qui a le plus vécu n'est pas celui qui a compté le plus d'années, mais celui qui a le plus senti la vie." J.-J. Rousseau, Emile.
i386.md from GCC-4.1.1-RC1 and GCC-4.2-ss has bugs!
i386.md from GCC-4.1.1-RC1 and GCC-4.2-ss has bugs! i386.md from GCC-4.1.1-RC1 has the sharp symbol '#': "f#x,x#f", "f#x,xm#f", "f#rx,..#fx,..#rf", ... i386.md from GCC-4.2-ss has corrected it and has not the sharp symbol '#': "f,x", "f,xm", ... What is the meaning of repeated words in i386.md? like: * ssemov,ssemov (in 4.1) vs sselogl,ssemov (in 4.2). * fmov,fmov,fmov,imov,imov (both) Anny
Re: GCC 4.1.1 RC1
Hi, [sorry for breaking the threading, not subscribed..] gcc-4_1-branch will fail in the install target on systems where makeinfo is too old -- or missing. See http://gcc.gnu.org/PR27516 for details and a patch which is still awaiting approval for both trunk and 4.1 Please fix this before releasing 4.1.1, TIA.
Re: i386.md from GCC-4.1.1-RC1 and GCC-4.2-ss has bugs!
On May 21, 2006, at 7:30 AM, Anny Blackyew wrote:
i386.md from GCC-4.1.1-RC1 and GCC-4.2-ss has bugs!
i386.md from GCC-4.1.1-RC1 has the sharp symbol '#':
"f#x,x#f", "f#x,xm#f", "f#rx,..#fx,..#rf", ...
i386.md from GCC-4.2-ss has corrected it and has not the sharp
symbol '#':
"f,x", "f,xm", ...
Why do you think this is a bug?
From the internals doc:
@cindex @samp{#} in constraint
@item #
Says that all following characters, up to the next comma, are to be
ignored as a constraint. They are significant only for choosing
register preferences.
* fmov,fmov,fmov,imov,imov (both)
This is just saying the instructions belong to the fmov or imov groups
for scheduling.
Thanks,
Andrew Pinski
Gcc 4.2 now passes SPEC CPU 2006
With the patch in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27592 Gcc 4.2 revision 113936 now passes SPEC CPU 2006 on Linux/x86, Linux/x86 and Linux/ia64. But I have to apply 3 patches to SPEC sources. H.J.
SVN: Checksum mismatch problem
CF: http://gcc.gnu.org/ml/gcc/2005-11/msg00950.html http://gcc.gnu.org/ml/gcc/2005-11/msg00951.html Since Google did not yield an answer, I'm re-asking the question, though with a slightly different file. Help, please, from anybody knowing how to work around the issue. Thank you! - Bruce $ sh contrib/gcc_update Updating SVN tree svn: Checksum mismatch for 'gcc/ada/.svn/text-base/sem_ch8.adb.svn-base'; expected: 'bf7be49fb4a377ca037b7c6fe02b1d5a', actual: '7160397e628c7b3dba95c55c0e50bbae' Adjusting file timestamps SVN update of full tree failed.
Re: SVN: Checksum mismatch problem
* Bruce Korb: > CF: http://gcc.gnu.org/ml/gcc/2005-11/msg00950.html >http://gcc.gnu.org/ml/gcc/2005-11/msg00951.html > > Since Google did not yield an answer, I'm re-asking the question, > though with a slightly different file. Help, please, from anybody > knowing how to work around the issue. Thank you! - Bruce Could you send us a copy of the gcc/ada/.svn/text-base/sem_ch8.adb.svn-base file, preferably in a way that is fully binary transparent?
Re: Segment registers support for i386
Remy Saissy wrote: >I don't really understand how to access the attribute set up in the >tree in the rtx struct. You won't be able to. You're going to need to write your own code that, during the conversion of the tree to RTL, creates RTL expressions which indicate that the memory references use segment registers. This probably won't be easy since there are a lot of contexts where your "far" pointer can be used. I suspect this is where you're going to give up on your project, but if you do then RTL expressions you'll need to create should probably look like: (mem:SI (plus:SI (unspec:SI [(reg:HI fs)] SEGREF) (reg:SI var))) After getting GCC to generate expressions like these, then it's a realtively simple case of modifying ix86_decompose_address() to handle the unspec. You might also need to change other backend code for handling addresses. Ross Ridge
Re: Gcc 4.2 now passes SPEC CPU 2006
On 5/21/06, H. J. Lu <[EMAIL PROTECTED]> wrote: With the patch in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27592 Gcc 4.2 revision 113936 now passes SPEC CPU 2006 on Linux/x86, Linux/x86 and Linux/ia64. But I have to apply 3 patches to SPEC sources. Good news. Do those patches fix real SPEC issues or are they necessary to work around GCC bugs? Gr. Steven
Re: SVN: Checksum mismatch problem
Bruce Korb wrote: > CF: http://gcc.gnu.org/ml/gcc/2005-11/msg00950.html > http://gcc.gnu.org/ml/gcc/2005-11/msg00951.html > > Since Google did not yield an answer, I'm re-asking the question, > though with a slightly different file. Help, please, from anybody > knowing how to work around the issue. Thank you! - Bruce > > > $ sh contrib/gcc_update > Updating SVN tree > svn: Checksum mismatch for > 'gcc/ada/.svn/text-base/sem_ch8.adb.svn-base'; expected: > 'bf7be49fb4a377ca037b7c6fe02b1d5a', actual: > '7160397e628c7b3dba95c55c0e50bbae' > Adjusting file timestamps > SVN update of full tree failed. > Generally, these are hardware errors. However, in some small number of cases, it's an svn bug (if the file looks just fine, it's usually an svn bug of some sort) What version of svn, what platform, etc.
Re: Gcc 4.2 now passes SPEC CPU 2006
On Sun, May 21, 2006 at 11:43:41PM +0200, Steven Bosscher wrote: > On 5/21/06, H. J. Lu <[EMAIL PROTECTED]> wrote: > >With the patch in > > > >http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27592 > > > >Gcc 4.2 revision 113936 now passes SPEC CPU 2006 on Linux/x86, > >Linux/x86 and Linux/ia64. But I have to apply 3 patches to SPEC > >sources. > > Good news. Do those patches fix real SPEC issues or are they > necessary to work around GCC bugs? Some of them are real issues, like #undef HASATTRIBUTE /**/ #ifndef HASATTRIBUTE #define __attribute__(_arg_) #endif But there is one Fortran patch I am not 100% sure. It has something to do with pointer initialization and association. I am working with SPEC people to address those issues. H.J.
Re: SVN: Checksum mismatch problem
Bruce Korb <[EMAIL PROTECTED]> writes: >-- declaration. It Is important that all references to the type point to The capital 'I' in 'Is' looks wrong. $ svn cat -r108304 svn://gcc.gnu.org/svn/gcc/trunk/gcc/ada/sem_ch8.adb > foo $ md5sum foo bf7be49fb4a377ca037b7c6fe02b1d5a foo $ sed 's/is import/Is import/' foo | md5sum 7160397e628c7b3dba95c55c0e50bbae - Those are the two checksums in your original error message. One way to fix your working copy is to edit the .svn-base file and fix the corruption. Another way is to delete the entire ada sub-dir from the working copy and update will download it again. -- Philip Martin
Re: SVN: Checksum mismatch problem
Philip Martin wrote: Bruce Korb <[EMAIL PROTECTED]> writes: -- declaration. It Is important that all references to the type point to The capital 'I' in 'Is' looks wrong. $ svn cat -r108304 svn://gcc.gnu.org/svn/gcc/trunk/gcc/ada/sem_ch8.adb > foo $ md5sum foo bf7be49fb4a377ca037b7c6fe02b1d5a foo $ sed 's/is import/Is import/' foo | md5sum 7160397e628c7b3dba95c55c0e50bbae - Those are the two checksums in your original error message. One way to fix your working copy is to edit the .svn-base file and fix the corruption. Another way is to delete the entire ada sub-dir from the working copy and update will download it again. Hi Philip, That's what I wanted: a nice, simple answer that was short of re-pulling the entire repository. ``delete the entire ada sub-dir from the working copy and update will download it again.'' Thank you! (I don't want to go chase how the capitalization got to be wrong. I certainly don't go fiddling with stuff in the Ada directory. Someone did something somewhere.) Cheers - Bruce
Re: SVN: Checksum mismatch problem
Bruce Korb wrote: > Philip Martin wrote: > >The capital 'I' in 'Is' looks wrong. > ... > That's what I wanted: a nice, simple answer that was short of re-pulling > the entire repository. ``delete the entire ada sub-dir from the > working copy and update will download it again.'' Thank you! > (I don't want to go chase how the capitalization got to be wrong. > I certainly don't go fiddling with stuff in the Ada directory. > Someone did something somewhere.) Cheers - Bruce Sometimes I run commands to walk down the filesystem and do things to the files in them. With CVS this was never a problem, never a false hit, because CVS did not keep a pristine copy of the database around. Example: find . -name foo -print0 | xargs -r0 sed --in-place 's/foo/bar/g' But now I find that I need to be aware that in the .svn directory is a pristine copy of the same file. The above won't match because the pristine copy always has .svn-base appended to the end. But the following would match and would edit both the working copy and the pristine copy in the .svn directory. find . -name 'foo*' -print0 | xargs -r0 sed --in-place 's/foo/bar/g' I have no idea if this is possibly the type of thing that happened to you or not. But I thought I would mention it because it seems plausible. Bob
Re: Revert patch for MIPS TImode functions for 4.1.1
On Fri, 19 May 2006, Mark Mitchell wrote:
> I'm evaluating the options. It would be helpful if someone has time to
> apply and test Richard's patch on 4.1, as that would let us know whether
> that option is viable as well.
I've bootstrapped and regression tested a backport of Richard's patch
against the gcc-4_1-branch on mips-sgi-irix6.5 with no new failures.
His mainline change also has no testsuite problems on the same machine.
The patch applies cleanly, with the exception of some mklibgcc.in
hunks, due to the fact that the _floatun* symbols were added to 4.2
and aren't available in 4.1.x libgcc, and that the LIB2FUNCS_EXCLUDE
functionality isn't on the branch. For the record, the final
mklibgcc.in changes that I tested are attached to this e-mail.
I hope this helps.
Roger
--
Index: mklibgcc.in
===
*** mklibgcc.in (revision 113936)
--- mklibgcc.in (working copy)
***
*** 17,22
--- 17,23
# LIB2ADDEHSTATIC
# LIB2ADDEHSHARED
# LIB2ADDEHDEP
+ # LIB2LITERAL_CONVERSION_MODES
# LIBUNWIND
# LIBUNWINDDEP
# SHLIBUNWIND_LINK
*** echo 'dirs = libgcc'
*** 54,63
echo
# Library members defined in libgcc2.c.
lib2funcs='_muldi3 _negdi2 _lshrdi3 _ashldi3 _ashrdi3
! _cmpdi2 _ucmpdi2 _floatdidf _floatdisf _fixunsdfsi _fixunssfsi
! _fixunsdfdi _fixdfdi _fixunssfdi _fixsfdi _fixxfdi _fixunsxfdi
! _floatdixf _fixunsxfsi _fixtfdi _fixunstfdi _floatditf _clear_cache
_enable_execute_stack _trampoline __main _absvsi2 _absvdi2 _addvsi3
_addvdi3 _subvsi3 _subvdi3 _mulvsi3 _mulvdi3 _negvsi2 _negvdi2 _ctors
_ffssi2 _ffsdi2 _clz _clzsi2 _clzdi2 _ctzsi2 _ctzdi2 _popcount_tab
--- 55,81
echo
# Library members defined in libgcc2.c.
+
+ # The floating-point conversion routines that involve a single-word integer.
+ # XX stands for the integer mode.
+ swfloatfuncs=
+ for mode in sf df xf; do
+ swfloatfuncs="$swfloatfuncs _fixuns${mode}XX"
+ done
+
+ # Likewise double-word routines.
+ dwfloatfuncs=
+ for mode in sf df xf tf; do
+ dwfloatfuncs="$dwfloatfuncs _fix${mode}XX _fixuns${mode}XX"
+ dwfloatfuncs="$dwfloatfuncs _floatXX${mode}"
+ done
+
+ # Entries of the form :: indicate that libgcc2.c
+ # should be compiled with L defined and with LIBGCC2_UNITS_PER_WORD
+ # set to . is the name of the associated object file
+
lib2funcs='_muldi3 _negdi2 _lshrdi3 _ashldi3 _ashrdi3
! _cmpdi2 _ucmpdi2 _floatdidf _clear_cache
_enable_execute_stack _trampoline __main _absvsi2 _absvdi2 _addvsi3
_addvdi3 _subvsi3 _subvdi3 _mulvsi3 _mulvdi3 _negvsi2 _negvdi2 _ctors
_ffssi2 _ffsdi2 _clz _clzsi2 _clzdi2 _ctzsi2 _ctzdi2 _popcount_tab
*** lib2funcs='_muldi3 _negdi2 _lshrdi3 _ash
*** 65,70
--- 83,103
_powixf2 _powitf2 _mulsc3 _muldc3 _mulxc3 _multc3 _divsc3 _divdc3
_divxc3 _divtc3'
+ if [ "$LIB2LITERAL_CONVERSION_MODES" ]; then
+ for func in $swfloatfuncs; do
+ sifunc=`echo $func | sed -e 's/XX/si/'`
+ lib2funcs="$lib2funcs $sifunc:$sifunc:4"
+ done
+ for func in $dwfloatfuncs; do
+ difunc=`echo $func | sed -e 's/XX/di/'`
+ tifunc=`echo $func | sed -e 's/XX/ti/'`
+ lib2funcs="$lib2funcs $difunc:$difunc:4 $tifunc:$difunc:8"
+ done
+ else
+ lib2funcs="$lib2funcs `echo $swfloatfuncs | sed -e 's/XX/si/g'`"
+ lib2funcs="$lib2funcs `echo $dwfloatfuncs | sed -e 's/XX/di/g'`"
+ fi
+
# Disable SHLIB_LINK if shared libgcc not enabled.
if [ "@enable_shared@" = "no" ]; then
SHLIB_LINK=""
*** fi
*** 145,152
# Remove any objects from lib2funcs and LIB2_DIVMOD_FUNCS that are
# defined as optimized assembly code in LIB1ASMFUNCS.
for name in $LIB1ASMFUNCS; do
! lib2funcs=`echo $lib2funcs | sed -e 's/^'$name' //' \
! -e 's/ '$name' / /' \
-e 's/ '$name'$//'`
LIB2_DIVMOD_FUNCS=`echo $LIB2_DIVMOD_FUNCS | sed -e 's/^'$name' //' \
-e 's/ '$name' / /' \
--- 178,185
# Remove any objects from lib2funcs and LIB2_DIVMOD_FUNCS that are
# defined as optimized assembly code in LIB1ASMFUNCS.
for name in $LIB1ASMFUNCS; do
! lib2funcs=`echo $lib2funcs | sed -e 's/^'$name'[ :]//' \
! -e 's/ '$name'[ :]/ /' \
-e 's/ '$name'$//'`
LIB2_DIVMOD_FUNCS=`echo $LIB2_DIVMOD_FUNCS | sed -e 's/^'$name' //' \
-e 's/ '$name' / /' \
*** for ml in $MULTILIBS; do
*** 248,263
#
for name in $lib2funcs; do
if [ "$libgcc_s_so" ]; then
out="libgcc/${dir}/${name}${objext}"
outS="libgcc/${dir}/${name}_s${objext}"
echo $outS: $libgcc2_c_dep
! echo " $gcc_s_compile" $flags -DL$name -c '$(srcdir)/libgcc2.c' \
-o $outS
echo $out: $libgcc2_c_dep
! echo
