Re: regeneration of files
I commited the regenerated libgfortran files on mainline (rev. 118140): 2006-10-29 Francois-Xavier Coudert <[EMAIL PROTECTED]> * configure: Regenerate. * Makefile.in: Regenerate. * aclocal.m4: Regenerate. Maybe you have an old version of libgfortran/config.h.in, because when I regenerate it there's nothing changed. FX
Build failure in dwarf2out
I am being hit by this: rf2out.c -o dwarf2out.o ../../trunk/gcc/dwarf2out.c: In function `file_name_acquire': ../../trunk/gcc/dwarf2out.c:7672: error: `files' undeclared (first use in this f unction) ../../trunk/gcc/dwarf2out.c:7672: error: (Each undeclared identifier is reported only once ../../trunk/gcc/dwarf2out.c:7672: error: for each function it appears in.) ../../trunk/gcc/dwarf2out.c:7672: error: `i' undeclared (first use in this funct ion) make[2]: *** [dwarf2out.o] Error 1 make[2]: Leaving directory `/svn/build/gcc' make[1]: *** [all-gcc] Error 2 make[1]: Leaving directory `/svn/build' make: *** [all] Error 2 No matter how I configure the build on a system (Cygwin_NT/amd64) with which I have never had any problem before. Can someone advise, please? Paul
Re: Build failure in dwarf2out
Paul Thomas wrote: I am being hit by this: rf2out.c -o dwarf2out.o ../../trunk/gcc/dwarf2out.c: In function `file_name_acquire': ../../trunk/gcc/dwarf2out.c:7672: error: `files' undeclared (first use in this f unction) ../../trunk/gcc/dwarf2out.c:7672: error: (Each undeclared identifier is reported only once ../../trunk/gcc/dwarf2out.c:7672: error: for each function it appears in.) ../../trunk/gcc/dwarf2out.c:7672: error: `i' undeclared (first use in this funct ion) My guess is that the #define activating that region of code is erroneously triggered. I am running the 2-day (on cygwin with a substandard BIOS) testsuite now.
Splay Tree
Could this patch be applied now? http://gcc.gnu.org/ml/gcc/2006-07/msg00210.html Discussion starts here: http://gcc.gnu.org/ml/gcc/2006-07/msg00147.html (benchmarks are wrong) Original patch posted by Brian Makin here: http://gcc.gnu.org/ml/gcc-patches/2005-10/msg00762.html Quote: I've been recently looking at the splay tree implementation. I've noticed that this revision http://gcc.gnu.org/viewcvs?view=rev&revision=106584 does a strange splaying. It does a bottom up splaying but starting at the root (not the same that top down). It works but performs worst. One example of this is that while in the implementation described in http://www.cs.cmu.edu/~sleator/papers/self-adjusting.pdf the root node ends at most two levels down, in the current implementation it can end at an arbiratry depth (example attached). So the property of keeping recently used nodes up doesn't work. ian
Re: Build failure in dwarf2out
Tim,
My guess is that the #define activating that region of code is
erroneously triggered. I am running the 2-day (on cygwin with a
substandard BIOS) testsuite now.
I decided to set it to #if 0 just as I saw your mail - it is now
building just fine; I haven't tested it yet but I guess, since it got
past stage 2, all is well.
Nathan,
dwarf2 is throughly foreign territory for me - however, I notice your
ChangeLog entry of 2006-10-24. I suppose the patch must have included:
#if defined (DIR_SEPARATOR_2)
{
char *g = strrchr (files[i].path, DIR_SEPARATOR_2);
if (g != NULL)
{
if (f == NULL || f < g)
f = g;
}
}
#endif
This is breaks Cygwin_NT (CYGWIN_NT-5.2-WOW64 NONE-X6EIN5I8FN
1.5.19(0.150/4/2) 2006-01-20 13:28 i686 Cygwin)/amd64 build for any
configuration that I have been able to dream up.
Cheers
Paul
Bug? Exceptions and implicit constructors.
Hi all,
Is this a bug in GCC or does the code below incorrectly use exceptions
and virtual inheritance?
I expect the code below to display:
Constructing child2.
Caught exception: 3
However it causes an abort after displaying the first line. Looking
further into this i found that when GCC creates the implicit default
constructor for the GrandChild class, it gives it a no-throw specifier:
throw()
Usually when GCC creates an implicit default constructor it gives it a
no-throw specifier if that class and all its parents only construct
primitive data without calling on user defined constructors. In the case
below GCC seems to ignore that it uses a user defined constructor
defined in Child2() I assume because of the virtual inheritance.
To work around the problem, it is a simple matter of defining a default
constructor in GandChild OR even adding an attribute to the GandChild
class that has complex construction like std::string. E.g. Change
GrandChild class to look like:
class GrandChild : public Child1, public Child2
{
public:
std::string s;
};
Thanks,
Brendon.
class Parent
{
public:
int data;
};
class Child1 : public virtual Parent
{
};
class Child2 : public virtual Parent
{
public:
Child2()
{
std::cout << "Constructing child2." << std::endl;
throw 3;
}
};
class GrandChild : public Child1, public Child2
{
};
int main()
{
try
{
GrandChild c;
}
catch(int i)
{
std::cout << "Caught exception: " << i << std::endl;
}
return 0;
}
Povray benchmark results
Hello! Following are the results of povray 3.6.1 official benchmark (benchmark.ini) on: vendor_id : AuthenticAMD cpu family : 15 model : 47 model name : AMD Athlon(tm) 64 Processor 3000+ stepping: 2 cpu MHz : 1809.278 cache size : 512 KB Base compile flags of "gcc version 4.3.0 20061029" were set to: -O3 -msse3 -ffast-math -march=k8 -mtune=k8 -minline-all-stringops Different -mpfmath selections were benchmarked: a) -mfpmath=sse user27m33.848s b) -mfpmath=387 user27m42.136s c) -mfpmath=sse,387 user26m0.312s These results were obtained with Richard's SSE rounding functions, top of ChangeLog was: 2006-10-29 Richard Guenther <[EMAIL PROTECTED]> * config/i386/i386-protos.h (ix86_expand_trunc): Declare. Nice to see that there is life in -mfpmath=sse,387 ;) It was faster than a) and b) by some 6%. Uros.
Re: submitting patches before copyright assignment fully done?
Basile STARYNKEVITCH <[EMAIL PROTECTED]> writes: > My copyright assignment is not yet signed, but I am pretty confident that it > will be signed (hopefully soon, and surely in 2006 ie before Christmas). > > Can I submit patches (to gcc-patches@) which are not trivial (ie more than > 10 lines of code), or should I wait till the copyriight assigment has been > recieved by the FSF (signed by my employing organisation and by FSF? The safest approach for all is to wait until the copyright assignment has been received. Thanks, and sorry for the inconvenience. Ian
Re: wiki topics wish (configuration related)
> 0. I am not sure to understand exactly the steps (and commands to > run) when touching to a configure.ac file... I made an educated > guess which happens to work most of the time. (In particular it > seems that autconf2.60 works even if 2.59 is required) If you only modify `configure.ac', then it is sufficient to run autoconf. However, if you aren't sure about what you're doing, it is better to configure your build tree with --enable-maintainer-mode and then the Makefiles will take care of regenerating files for you. Ben
Re: regeneration of files
> "Mike" == Mike Stump <[EMAIL PROTECTED]> writes: Mike> I found quite a few files out of date... [...] Mike> libjava/configure I updated (svn trunk) and re-ran autoconf here, and didn't see any change. What version of autoconf are you using? I'm using the 2.59 that comes with FC5. Mike> I noticed quite a variety in the options for aclocal. :-( This isn't a necessarily a problem -- e.g. the libjava ACLOCAL_AMFLAGS includes '-I .' to pick up local .m4 files, and this is ok as a difference from, say, the boehm-gc value. Offhand libffi's looks incorrect, it should probably include ../config. zlib should probably have this setting too (though I didn't look to see whether this makes a difference). Tom
Re: Abt RTL expression - Optimization
Hi all,
The problem due to which the below mentioned program was not working
is because of CODE HOISTING pass. I just masked the code hoisting step
and the program worked fine.
1. The instruction no's 11, 12, 13 are removed when -Os optimization
is enabled (it considers n, h as dead). Is there any way to emit RTL
Instruction such that it can be neglected by Code Hoisting pass.
; Start of basic block 0, registers live: (nil)
(note 9 6 11 0 [bb 0] NOTE_INSN_BASIC_BLOCK)
(insn 11 9 12 0 (parallel [
(set (reg/f:SI 28)
(symbol_ref:SI ("n") [flags 0x2] ))
(clobber (reg:CC 21 cc))
]) 22 {movsi_long_const} (nil)
(nil))
(insn 12 11 13 0 (set (reg:SI 29 [ n ])
(mem/c/i:SI (reg/f:SI 28) [2 n+0 S4 A32])) 15 {movsi_load} (nil)
(expr_list:REG_EQUAL (mem/c/i:SI (symbol_ref:SI ("n") [flags 0x2]
) [2 n+0 S4 A32])
(nil)))
(insn 13 12 50 0 (set (reg:CC 21 cc)
(compare:CC (reg:SI 29 [ n ])
(const_int 30 [0x1e]))) 68 {*cmpsi_internal} (nil)
(nil))
2. Any documentation on Code Hoisting Algorithm used by GCC 4.1.1?
Regards,
Rohit
On 26 Oct 2006 22:30:43 -0700, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
"Rohit Arul Raj" <[EMAIL PROTECTED]> writes:
> > > This small bit of code worked fine with all optimization except Os.
unsigned int p;
> > > unsigned int n = 30;
> > > void x ()
> > > {
> > > unsigned int h;
> > > h = n <= 30; // Line 1
> > > if (h)
> > >p = 1;
> > > else
> > >p = 0;
> > > }
> > >
> > > when we tried to debug the emitted RTL instruction for Os, it was
> > > found that RTL instruction for Line #1 (Compare and gtu) were not at
> > > all emitted. i.e. there is no reference with respect to "h or n". For
> > > the same optimization Os, if we declare the identifier "h" as global,
> > > it generates the instructions properly.
> >
> > That small bit of code won't compile, since 'p' is undeclared. If 'p'
> > is a global variable, then this certainly seems to be a bug. But you
> > should be aware that -Os changes inlining behaviour, and different
> > inlining may cause different behaviour here depending on how 'p' is
> > used.
>
> p is a global variable. But the problem is not with p, but with
> codegeneration for h, n.
Sure. But the most likely reason that the test of 'h' is being
removed is that the compiler thinks that there is no need to store to
'p'. And once the test of 'h' is removed, there is no need to test
'n'.
> In the RTL dump after cse2 pass, i do have the code for h, n. But in
> the RTL dump after life analysis, that part of code is missing.
> Is this output of cse2 pass used for life analysis?
If I understand the question correctly, then the answer is yes. The
compiler works by creating an intermediate representation (IR) and
then manipulating it. The cse2 pass runs on the IR, then the life1
pass runs on the IR. The .cse2 file contains a dump of the IR after
the cse2 pass is complete.
> > > 3. What are the probable causes for the elimination of RTL code's
> > > (Compare & gtu) between the above mentioned passes?
> >
> > The probable cause is that 'p' appears to be unused, and the
> > assignment to 'p' is dead.
> >
> since p is a global variable, it can be used in other functions. Any
> other causes?
I can't think of any.
> 4. If i disable gcse optimization pass, (i.e. -Os -fno-gcse), the code
> is generated properly for h , n and the program works fine (it failed
> for -Os). How does gcse affect code generation at .life1 pass.
The gcse pass can change the IR significantly, and thus affects the
life1 pass in many different ways which are difficult to characterize.
You really have to look at what exactly is going on.
ian
