Can I trace the process of C++ template Instantiation?
Hi,all: How can I trace the process of C++ template Instantiation? I study Loki and some library is very complex, so I want to see how gcc compiler instance the template class. alex ___ 雅虎免费G邮箱－中国第一绝无垃圾邮件骚扰超大邮箱 http://cn.mail.yahoo.com/?id=77071
Re: Problem with Delayed Branch Scheduling
On Monday 04 July 2005 07:59, Balaji S wrote: > Hi everybody, > > I have a problem with delayed branch scheduling. Problem in a DSP porting > which has VLIW instructions and delayed branches. While scheduling delayed > branches, GCC (3.4.3) schedules an instruction which is a part of a VLIW > instruction. Is this the problem of the following define_delay description? > > (define_delay (eq_attr "type" "jump") > [(eq_attr "type" "!jump") (nil) (nil) >(eq_attr "type" "!jump") (nil) (nil)]) Add an attribute to those instructions that cannot be in delay slots, and change this define_delay to disallow instructions with that attr? Gr. Steven
Re: Problem with Delayed Branch Scheduling
_On 04-Jul-2005 15:31, Steven Bosscher san wrote_: Add an attribute to those instructions that cannot be in delay slots, and change this define_delay to disallow instructions with that attr? Any instruction other than jump can be placed in the delay slot. I hope "!jump" can fulfill this requirement. I don't have any idea to identify a part of a VLIW instruction and disallow it delay slot. I only know that TImode of insn signifies a new cycle start. please hlep me by giving some pointers.
Re: Problem with Delayed Branch Scheduling
On Monday 04 July 2005 12:41, Balaji S wrote: > _On 04-Jul-2005 15:31, Steven Bosscher san wrote_: > > Add an attribute to those instructions that cannot be in delay slots, > > and change this define_delay to disallow instructions with that attr? > > Any instruction other than jump can be placed in the delay slot. I hope > "!jump" can fulfill this requirement. > > I don't have any idea to identify a part of a VLIW instruction and disallow > it delay slot. I only know that TImode of insn signifies a new cycle start. > please hlep me by giving some pointers. Ah, I think I misunderstood your problem. So you have a few instructions bundled into a VLIW instruction, and one of the instructions in the bundle is moved into the delay slot, thus breaking your VLIW bundle. Right? That is a much harder problem... I don't think it is really possible with the existing dbr scheduling pass, but maybe someone else knows a trick for this... Gr. Steven
Bugzilla does not let me in
Hi, I've got a problem: bugzilla sends me no registration e-mails. I tried two times with different e-mail addresses and got nothing. So I cannot report a gcj bug :( You've got a nice page "Reporting Bugs" that explains what needs to be sent, but doesn't contain a word about *where* to send. That's not a flame, just a silly user's troubles. Respectfully yours, Ilya
Re: matching '-Wl,' in a specs file
On Fri, Jul 01, 2005 at 03:19:28PM -0700, James E Wilson wrote:
> Gunther Nikl wrote:
> >A few LINK_SPEC definitions contain a "%{Wl,*:%*}" sequence.
>
> There is no need to match -Wl options in LINK_SPEC, as it is handled by
> the gcc.c driver. The driver support was added in gcc-2.5.8. I believe
> all of these LINK_SPEC checks for -Wl are obsolete code from gcc-2.4.x
> and earlier that never got cleaned up. I confirmed this for a two of
> the older ports, sol2.h and svr4.h. The rest appear to have copied it
> from one of these two files.
Thanks for these interesting historical information.
> Is there are particular reason you are asking about this?
Sometimes I use -Wl,-r and I tried to change what options to pass
depending on -r.
> If not, then I think the only thing we need to do here is delete all
> of this obsolete code.
IMHO if thats really obsolete code, then it should get removed.
Gunther
Re: matching '-Wl,' in a specs file
Gunther Nikl writes:
> On Fri, Jul 01, 2005 at 03:19:28PM -0700, James E Wilson wrote:
> > Gunther Nikl wrote:
> > >A few LINK_SPEC definitions contain a "%{Wl,*:%*}" sequence.
> >
> > There is no need to match -Wl options in LINK_SPEC, as it is handled by
> > the gcc.c driver. The driver support was added in gcc-2.5.8. I believe
> > all of these LINK_SPEC checks for -Wl are obsolete code from gcc-2.4.x
> > and earlier that never got cleaned up. I confirmed this for a two of
> > the older ports, sol2.h and svr4.h. The rest appear to have copied it
> > from one of these two files.
>
> Thanks for these interesting historical information.
>
> > Is there are particular reason you are asking about this?
>
> Sometimes I use -Wl,-r and I tried to change what options to pass
> depending on -r.
IMO that would be really bad. The point of "-Wl" is to pass arguments
unmolested to the linker, bypassing gcc's spec mechanism. This si for
people who really understand what they're doing.
> > If not, then I think the only thing we need to do here is delete all
> > of this obsolete code.
>
> IMHO if thats really obsolete code, then it should get removed.
Yup.
Andrew.
Re: Can I trace the process of C++ template Instantiation?
zheng wang <[EMAIL PROTECTED]> wrote: >How can I trace the process of C++ template > Instantiation? I study Loki and some library is very > complex, so I want to see how gcc compiler instance > the template class. The source code for template processing is mostly contained in the file cp/pt.c. The instantiation happens in the function tsubst_copy_and_build. You can place a breakpoint there and see what happens within GDB. -- Giovanni Bajo
Re: Bugzilla does not let me in
Ilya Mezhirov <[EMAIL PROTECTED]> wrote: > I've got a problem: bugzilla sends me no registration e-mails. > I tried two times with different e-mail addresses and got nothing. > So I cannot report a gcj bug :( > > You've got a nice page "Reporting Bugs" that explains what needs to be > sent, but doesn't contain a word about *where* to send. That's not a > flame, just a silly user's troubles. I see you already have an account. Login is [EMAIL PROTECTED] Try logging in with the password you provided. Otherwise, I can reset the password for you. -- Giovanni Bajo
Re: GCC 4.0.1 RC3
Mark Mitchell wrote: > GCC 4.0.1 RC3 is now available here: > >ftp://gcc.gnu.org/pub/gcc/prerelease-4.0.1-20050702/ > > With luck, this will be the last 4.0.1 release candidate. > > Please do download tarballs from the above URL and confirm that they > work OK on your systems. s390(x)-ibm-linux is still looking good: http://gcc.gnu.org/ml/gcc-testresults/2005-07/msg00182.html http://gcc.gnu.org/ml/gcc-testresults/2005-07/msg00183.html Bye, Ulrich -- Dr. Ulrich Weigand Linux on zSeries Development [EMAIL PROTECTED]
MIPS-X
Hi all, I am wondering if MIPS-X has been supported. Thanks. IM
Re: matching '-Wl,' in a specs file
On Mon, Jul 04, 2005 at 01:15:19PM +0100, Andrew Haley wrote: > Gunther Nikl writes: > > > > Sometimes I use -Wl,-r and I tried to change what options to pass > > depending on -r. > > IMO that would be really bad. The point of "-Wl" is to pass arguments > unmolested to the linker, bypassing gcc's spec mechanism. I was imprecise :-/ I have a m-option which I would like to use for (roughly) the same purpose when invoking assembler and linker. This option selects the objectcode format during assembling and linking by passing special flags to either as or ld. When assembling this is always ok but when linking I would like to ignore this m-option unless -r was specified too. Of course, I could remove the test for this m-option in LINK_SPEC (making it an assembly-only option) and demand using -Wl to select the objectcode format when linking. However, I feel that it is much more convenient to have a frontend option that does the right thing behind the scenes. > This si for people who really understand what they're doing. I agree. Gunther
Re: Problem with Delayed Branch Scheduling
So you have a few instructions bundled into a VLIW instruction, and one of the instructions in the bundle is moved into the delay slot, thus breaking your VLIW bundle. Right? That is a much harder problem... I don't think it is really possible with the existing dbr scheduling pass, but maybe someone else knows a trick for this... So the problem is that we represent instructions that don't actually exist as individual instructions? I think it is legitimate to use machine_dependent_reorg to make the actual instructions explicit. However, in order to do this without exploding the machine description, you'd probvably have to revive match_insn (the one formerly named match_insn2).
The origin of scalar evolutions?
Hi,
I am interested in the recent work in gcc 4.0 with respect to "scalar
evolutions". The students in my compiler laboratory studied the
algorithm implemented in gcc 4.0. We are considering extending this
work based on our experience [4] building a similar framework for
symbolic analysis with chains of recurrences for SUIF and Polaris
(since we introduced this approach in 2001 [1]).
However, after reading the paper on "Fast Recognition of Scalar
Evolutions on Three-Address SSA Code", we have a couple of questions.
1. After reading the paper, we concluded that the scalar evolutions are
actually a restricted polynomial form of chains of recurrences by
Bachmann and Zima [6,8]. Is this true? Or is there an essential
difference with multi-variate chains of recurrences [7]? Does the
"scalar evolutions" name suggest something else beyond the recurrence
forms. Are we missing a crucial point?
2. What is the difference between the SSA-based algorithm described in
the paper and the G-SSA form proposed in 1995 by Tu and Padua [9]. The
G-SSA algorithms compute recurrence relations from which chains of
recurrences can be easily constructed using the construction algorithm
presented in [1].
3. Do you compute recurrence forms for pointer variables? If so, what
is the difference compared to the method described in our 2001 paper
[2]?
4. The "peeled" forms are described as "wrap around" forms in the paper
but do not seem to handle true wrap around variable. How do you handle
wrap around variables, i.e. those that have the form:
k = 9;
for (i=0; i < 10; i++)
{ a[k] = ...
k = i;
}
Can you please explain?
5. Do you plan on implementing dependence testing and range analysis on
chains of recurrences as described in [3,4,5]?
With respect to our first question, we felt that the use of a new name
for an existing technique is confusing. For example, by calling a
"matrix" from linear algebra a "scalar square" we do not change its
semantics. The (algebraic) operations on matrices are still the same.
So are the operations on scalar evolutions the same as those on chains
of recurrences. Janson's classic "History of Art" has apt advice: "It
has always been easier to invent new labels than to create a movement
in art that truly deserves a new name."
References
[1] Robert A. van Engelen, "Efficient Symbolic Analysis for Optimizing
Compilers", in proceedings of the International Conference on Compiler
Construction, ETAPS 2001, LNCS 2027, pages 118-132
[2] Robert A. van Engelen and Kyle A. Gallivan, "An Efficient Algorithm
for Pointer-to-Array Access Conversion for Compiling and Optimizing DSP
Applications", in proceedings of the 2001 International Workshop on
Innovative Architectures for Future Generation High-Performance
Processors and Systems (IWIA 2001), 18-19 January 2001, Maui, Hawaii,
pages 80-89.
[3] Robert van Engelen, Johnnie Birch, and Kyle Gallivan, "Array Data
Dependence Testing with the Chains of Recurrences Algebra", in the
proceedings of the IEEE International Workshop on Innovative
Architectures for Future Generation High-Performance Processors and
Systems (IWIA), January 2004, pages 70-81.
[4] Robert van Engelen, Johnnie Birch, Yixin Shou, Burt Walsh, and Kyle
Gallivan, "A Unified Framework for Nonlinear Dependence Testing and
Symbolic Analysis", in the proceedings of the ACM International
Conference on Supercomputing (ICS), 2004, pages 106-115.
[5] Johnnie Birch, Robert van Engelen, and Kyle Gallivan, "Value Range
Analysis of Conditionally Updated Variables and Pointers", in the
proceedings of Compilers for Parallel Computing (CPC), 2004, pages
265-276.
[6] O. Bachmann, P.S. Wang and E.V. Zima, "Chains of Recurrences - a
Method to Expedite the Evaluation of Closed-Form Functions",in
proceedings of the International Symposium on Symbolic and Algebraic
Computing (ISSAC), 1994, pages 242-249.
[7] O. Bachmann, "Chains of Recurrences for Functions of Two Variables
and Their Application to Surface Plotting", in "Human Interaction for
Symbolic Computation, 1996.
[8] E.V. Zima, "On computational properties of chains of recurrences",
in proceedings of the 2001 International Symposium on Symbolic and
Algebraic Computation, pages 345.
[9] P. Tu and D. Padua, "Gated SSA-Based Demand-Driven Symbolic
Analysis for Parallelizing Compilers", in proceedings of the ACM
International Conference on Supercomputing (ICS), 1995, pages 414-423.
- Robert van Engelen
Robert van Engelen: Associate Professor, Computer Science Department
Florida State University, 162 J. Love Bldg., Tallahassee, FL32306-4530
Offices: 162LOV/471DSL, (850)644-9661/645-0309, Fax: (850)644-0058
Email: [EMAIL PROTECTED], URL: http://www.cs.fsu.edu/~engelen
SVN test repo updated and call for help
The svn test repo has been updated on dberlin.org. Please don't rape my bandwidth or my disk i/o :) svn://www.dberlin.org/ Commits to the hooks dir will be reflected in the actual repository hooks through the nice sync script. If people help convert the contrib scripts and the current cvs repository hooks, we can convert to svn faster. The web interface is available at http://www.dberlin.org/cgi-bin/viewcvs.cgi
Re: Bugzilla does not let me in
On Mon, 2005-07-04 at 15:03 +0400, Ilya Mezhirov wrote: > Hi, > > > I've got a problem: bugzilla sends me no registration e-mails. > I tried two times with different e-mail addresses and got nothing. > So I cannot report a gcj bug :( I verified the emails were getting sent to your address (or at least, they were delivered to your mail server). So i'm not sure what's going on there. Maybe it's getting marked as spam?
Re: GCC 4.0.1 RC3
On Sun, Jul 03, 2005 at 11:21:15AM -0700, Mark Mitchell wrote: > GCC 4.0.1 RC3 is now available here: > > ftp://gcc.gnu.org/pub/gcc/prerelease-4.0.1-20050702/ > > With luck, this will be the last 4.0.1 release candidate. > > Please do download tarballs from the above URL and confirm that they > work OK on your systems. > Can someone verify the missing debug info bug: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22295 It is a regression from 3.4. Is a known issue? H.J.
Re: GCC 4.0.1 RC3
On Jul 4, 2005, at 1:48 PM, H. J. Lu wrote: On Sun, Jul 03, 2005 at 11:21:15AM -0700, Mark Mitchell wrote: GCC 4.0.1 RC3 is now available here: ftp://gcc.gnu.org/pub/gcc/prerelease-4.0.1-20050702/ With luck, this will be the last 4.0.1 release candidate. Please do download tarballs from the above URL and confirm that they work OK on your systems. Can someone verify the missing debug info bug: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22295 It is a regression from 3.4. Is a known issue? Yes it is PR 21828. -- Pinski
Re: Problem with Delayed Branch Scheduling
Steven Bosscher <[EMAIL PROTECTED]> writes: > So you have a few instructions bundled into a VLIW instruction, and > one of the instructions in the bundle is moved into the delay slot, > thus breaking your VLIW bundle. Right? I think there are two natural approaches. 1) Do the VLIW bundling after delayed branch scheduling. The way to do that is to the bundling in TARGET_ASM_FUNCTION_PROLOGUE. The FRV backend does this. I've done this successfully in the past. 2) When you do the VLIW bundling, put the instructions into a PARALLEL. In general the gcc scheduler does not handle VLIW scheduling very well, and it needs a fair amount of target specific help. Ian
Re: byteswap.c and endian.c for gcc?
"Sung-Gu" <[EMAIL PROTECTED]> writes: > I thought I might find a specfic directory in gcc sources whether it supports > the files. > I don't want to compile the whole source files. :( gcc is just the compiler. Header files like byteswap.c and endian.c are part of the system library. gcc does not provide a system library. I don't know where to find those header files for Solaris, but it is not here. Ian
Re: initializing wider-than-pointers
On Fri, Jul 01, 2005 at 09:27:48PM -0400, DJ Delorie wrote: > Note that my complaint about the lack of endian support in that code > still stands ;-) I seem to recall running into this before. It's not a lack of endian support, it's one piece lying to another about the size of the object. Which results in too few bytes being emitted, and later generic bits adding padding. Or something like that. r~
[st20] seeking implementation advice for stack architectures (long)
I plan to up-port my ST20 port to the mainline. I thought I'd first give a description of the port and ask for some opinion. Basically, I would like to hear, would an implementation along these lines be acceptable in principle, and otherwise, what are the main no-go points ? I'll try to keep it short. ST20 CPU (a transputer derivative) is a (register-)stack architecture and has no general registers. Our ports too use memory cells from the stack frame to allocate pseudos. This makes a lot of sense on ST20, as the first 16 words of the stack frame have special properties and are a scarce resource, and reloading these memory cells from other memory cells actually makes the code smaller and faster. The first port (by Fabio Riccardi, against 2.95.2) was done in a common way -- mapping pseudos to such "memory registers", then trying to save the situation in the MACHINE_DEPENDENT_REORG pass by combining several insns into one -- as long as it evaluates on the 3-level-deep regstack, then eliminating the memory registers becoming unused. While maintaining the port to pass the test suite, I had to constantly extend the machine-dep-reorg pass which started to seriously resemble to the combine pass in the core. Besides, I felt the port lacked flexibility, as one couldn't freely use 'define_expand's without modifying also 'machine-reorg'. Thirdly, combining insns after reload was frequently yielding suboptimal use of memory registers. The current port, done from scratch, tried to fix the above and employ the 'combine' pass to its maximum, instead of duplicating the code: -- the .md grammar was extended to describe separate stack operations making up an insn (like, load first word on the stack, load second word on the stack, subtract, store the result. I named the operation 'define_nonterm'.). Old-style 'define_insn's are fully supported and are usually intermixed with the new one in the .md file, as some insns won't use the regstack. -- generated 'recog_insn' is essentially a BURM labeler (I modified the algorithm from [1] to account for a finite stack depth and hacked 'genrecog' to generate it.) -- RTL expansion uses mostly 'define_expand' from .md. -- 'legitimate_address_p' has the usual sense before 'combine'. -- 'combine' combines insns into one iff the combination can be BURM- labeled by 'recog_insn'. -- past 'combine', 'legitimate_address_p' says OK to any RTX that evaluates on the regstack of depth 3, whatever the form the address parts of it might have. -- at the point where no new insns are emitted and their relative order won't change anymore (after reload?), the labeled insns are BURM-reduced back to separate stack operations. This time, regstack registers are explicitly mentioned in the RTX, and the .md must have a 'define_insn' matching each stack op. Splitting insns becomes possible again after this point. -- RTX_COST returns the BURM cost of the RTL expression. The downside: -- the RTX structure had to be extended, to store the BURM label data. This is per-port and may be configured in 'config.sub' via a corresponding compilation option. In my implementation, 12 to 16 results are bytes were added. I didn't attempt to compress this data as proposed in [1]. -- due to the way the substitution in 'combine' works, insns will frequently lose their BURM label data, thus requiring relabeling (the result of recognition is less cacheable than before). This probably could be improved to some extent. (I followed the posts on GCC's speed and memory consumption, and am very well aware of the implications this would have. Please just bear in mind that currently ST20 developers simply have no alternative to the only compiler there is. If somebody knows a less costly algorithm for BURM- labeling RTX, please please let me know.) -- 'extract_operand' and some other routines expecting operands at fixed places in an insn had to be made more intelligent, so other 'genxxx' generators had to be modified too. The results: -- actually, rather encouraging. The quality of the emitted code is largely comparable to the one from the manufacturer's compiler, sometimes better, and there still is a small margin for improvement. [1] C.W.Fraser, D.R.Hanson, T.A. Proebsting, Engineering a simple, efficient code-generator generator. LOPLAS Vol 1, issue 3 (Sep. 1992) Thanks in advance, Dimitri
Re: MIPS-X
"IM.Nobody" <[EMAIL PROTECTED]> writes: > I am wondering if MIPS-X has been supported. Not by FSF releases, no. I'm not aware of a private port either, but perhaps others know better. Richard
Re: GCC 4.0.1 RC3
AIX is good: http://gcc.gnu.org/ml/gcc-testresults/2005-07/msg00216.html David
RE: byteswap.c and endian.c for gcc?
I have another Linux machine. And I found the following messages: $cd /usr/include $ more endian.h /* Copyright (C) 1992, 1996, 1997, 2000 Free Software Foundation, Inc. This file is part of the GNU C Library. /* This file defines `__BYTE_ORDER' for the particular machine. */ #include $more byteswap.h /* Copyright (C) 1997 Free Software Foundation, Inc. This file is part of the GNU C Library. /* Get the machine specific, optimized definitions. */ #include -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ian Lance Taylor Sent: Tuesday, July 05, 2005 4:29 AM To: Sung-Gu Cc: gcc@gcc.gnu.org Subject: Re: byteswap.c and endian.c for gcc? "Sung-Gu" <[EMAIL PROTECTED]> writes: > I thought I might find a specfic directory in gcc sources whether it > supports the files. I don't want to compile the whole source files. :( gcc is just the compiler. Header files like byteswap.c and endian.c are part of the system library. gcc does not provide a system library. I don't know where to find those header files for Solaris, but it is not here. Ian
Re: byteswap.c and endian.c for gcc?
"Sung-Gu" <[EMAIL PROTECTED]> writes: > I have another Linux machine. > And I found the following messages: > > > $cd /usr/include > > $ more endian.h > /* Copyright (C) 1992, 1996, 1997, 2000 Free Software Foundation, Inc. >This file is part of the GNU C Library. Yes. gcc is not the GNU C library. The GNU C library can be found here: http://www.gnu.org/software/libc/ But note that the GNU C library does not run on Solaris. Also, even if these files were part of gcc, note that this is the wrong mailing list for these questions. You should be using gcc-help. Thanks. Ian
Re: The origin of scalar evolutions?
On Mon, 2005-07-04 at 12:31 -0400, Robert van Engelen wrote:
> Hi,
>
> I am interested in the recent work in gcc 4.0 with respect to "scalar
> evolutions". The students in my compiler laboratory studied the
> algorithm implemented in gcc 4.0. We are considering extending this
> work based on our experience [4] building a similar framework for
> symbolic analysis with chains of recurrences for SUIF and Polaris
> (since we introduced this approach in 2001 [1]).
(I've snipped the paper references because i've read all these papers in
the past, and i'm pretty sure Sebastian has as well :P)
That would be great! We'd be glad to work with you to extend this and
contribute the work to gcc. (We being Sebastian and I. Together we are
responsible for maintenance of the chains of recurrence/scalar
evolutions code and the data dependence analysis)
I should note that we have significantly advanced data dependence work
going on based on chrecs on the autovect-branch of gcc cvs (it's just a
convenient place for the work, most of the autovectorization
improvements from that code tree have already been put into 4.1)
In addition, you probably want to look at the current code, as it is
changing as we speak as the final "non-bugfixing" phase of gcc 4.1
closes in the next few days.
Things like range analysis using the results of the analysis are also in
4.1.
You can get a snapshot of the 4.1 code from
ftp://gcc.gnu.org/pub/gcc/snapshots
This should include the Value Range Propagation that uses the results,
but won't yet include the access function information for recurrences.
>
> However, after reading the paper on "Fast Recognition of Scalar
> Evolutions on Three-Address SSA Code", we have a couple of questions.
>
> 1. After reading the paper, we concluded that the scalar evolutions are
> actually a restricted polynomial form of chains of recurrences by
> Bachmann and Zima [6,8]. Is this true?
Yes.
Or rather, the scalar evolution code uses chains of recurrences as an
internal representation.
See tree-chrec.c
"
This file implements operations on chains of recurrences. Chains
of recurrences are used for modeling evolution functions of scalar
variables.
"
> Or is there an essential
> difference with multi-variate chains of recurrences [7]?
I don't believe so, but you'll have to ask Sebastian (who i have
copied).
> Does the
> "scalar evolutions" name suggest something else beyond the recurrence
> forms.
Not really, they are evolution functions for scalar variables,
represented used chains of recurrences.
> Are we missing a crucial point?
Dunno. I should note that that we properly give credit where it is due:
" The notation used in this file is called "chains of recurrences",
and has been proposed by Eugene Zima, Robert Van Engelen, and
others for describing induction variables in programs. "
(from tree-scalar-evolution.c)
:)
Sebastian devised the notation, and nobody argued with him.
>
> 2. What is the difference between the SSA-based algorithm described in
> the paper and the G-SSA form proposed in 1995 by Tu and Padua [9]. The
> G-SSA algorithms compute recurrence relations from which chains of
> recurrences can be easily constructed using the construction algorithm
> presented in [1].
Sebastian can cover this.
>
> 3. Do you compute recurrence forms for pointer variables? If so, what
> is the difference compared to the method described in our 2001 paper
> [2]?
Yes to the first question, I don't believe anyone implemented the
method discussed in your paper. One thing to note is that we have no
direct array reference operation that operates on pointers at the
moment. So they really are just treated as pointers, and all data
dependence on pointers is very simple (mainly because we have not
implemented the symbolic differencing necessary).
You can see this basic work (originally from the autovectorization
branch of gcc cvs) in patch at
http://gcc.gnu.org/ml/gcc-patches/2005-06/msg02057.html
(and the followup patch)
This work was only recently submitted to gcc 4.1, and i am about to
approve it for gcc 4.1, so it should appear in the gcc 4.1 snapshots in
a few weeks or so.
>
> 4. The "peeled" forms are described as "wrap around" forms in the paper
> but do not seem to handle true wrap around variable. How do you handle
> wrap around variables, i.e. those that have the form:
> k = 9;
> for (i=0; i < 10; i++)
> { a[k] = ...
>k = i;
> }
> Can you please explain?
We used to handle true wraparounds, but don't anymore. This work can be
found in a branch of the gcc source tree if you would like to look at
it. It was too expensive, and didn't seem to buy us anything over what
we handle now for real code. If there comes a time this isn't true,
we'll probably bring it back (IE we are eminently pragmatic about this
stuff. Or at least, Sebastian and I am)
>
> 5. Do you plan on implementing dependence testing and range analysis on
> chains of recurrences as
Re: GCC 4.0.1 RC3
Darwin here: http://gcc.gnu.org/ml/gcc-testresults/2005-07/msg00221.html ok so far. Andreas
Re: Ada is broken in a clean directory
On Jun 30, 2005, at 4:25 PM, Paul Brook wrote: On Thursday 30 June 2005 04:24, Andrew Pinski wrote: Ada is now broken on the mainline by: 2005-06-28 Paul Brook <[EMAIL PROTECTED]> * Makefile.in: Set and use UNWIND_H. Install as unwind.h. * c-decl.c (finish_decl): Call default_init_unwind_resume_libfunc. * except.c (add_ehspec_entry): Generate arm eabi filter lists. (assign_filter_values): Ditto. ... The error is: /Users/pinskia/src/cool/gcc/gcc/ada/raise.c:98:20: unwind.h: No such file or directory /Users/pinskia/src/cool/gcc/gcc/ada/raise.c:109: error: parse error before "__gnat_Unwind_RaiseException" /Users/pinskia/src/cool/gcc/gcc/ada/raise.c:109: warning: type defaults to `int' in declaration of `__gnat_Unwind_RaiseException' None of the machines I tried even get that far in an ada bootstrap. Probably something in the ada frontend is missing a dependency on stmp-int-hdrs, or CFLAGS is missing "-Isystem ./include". I filed PR 22301 for this bug. I can attach log if you want but I will note this worked before you patch. -- Pinski
Re: GCC 4.0.1 RC3
PA is ok: http://gcc.gnu.org/ml/gcc-testresults/2005-07/msg00223.html http://gcc.gnu.org/ml/gcc-testresults/2005-07/msg00218.html http://gcc.gnu.org/ml/gcc-testresults/2005-07/msg00186.html The failure of pr21817-1.c on hppa2.0w-hp-hpux11.11 is a minor testsuite issue that is now fixed on the trunk. The failure of asm-subreg-1.c on hppa64-hp-hpux11.11 is probably a regression although there is some debate about that: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20491. The failure of ext/array_allocator/2.cc on hppa64-hp-hpux11.11 is a latent bug on 64-bit strictly aligned targets: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19495. Fixing it requires a v3 library version bump. Dave -- J. David Anglin [EMAIL PROTECTED] National Research Council of Canada (613) 990-0752 (FAX: 952-6602)
A trouble with libssp in one-tree builds
Hi Jakub,
I am having a trouble with libssp in one-tree builds. That is, if I
try to build binutils and gcc at the same time, libssp/configure
complains while compiling (and linking) the following program and the
build process stops.
/* confdefs.h. */
#define PACKAGE_NAME "libssp"
#define PACKAGE_TARNAME "libssp"
#define PACKAGE_VERSION "1.0"
#define PACKAGE_STRING "libssp 1.0"
#define PACKAGE_BUGREPORT ""
#define PACKAGE "libssp"
#define VERSION "1.0"
/* end confdefs.h. */
int
main ()
{
;
return 0;
}
The problem is that libssp/configure contains a link test, but we may
not have crt0.o built yet (assuming targets like h8300-elf,
arm-none-eabi, etc).
Is there anyway we could stop configuring libssp in this kind of case?
Or somehow work around the link test? FWIW, I am sitting on the
attached patch to disable libssp for now.
Kazu Hirata
Index: configure.in
===
RCS file: /home/gcc/repos/gcc/gcc/configure.in,v
retrieving revision 1.355
diff -u -d -p -r1.355 configure.in
--- configure.in2 Jul 2005 08:50:56 - 1.355
+++ configure.in4 Jul 2005 04:42:35 -
@@ -307,6 +307,14 @@ if test "${ENABLE_LIBADA}" != "yes" ; th
noconfigdirs="$noconfigdirs gnattools"
fi
+AC_ARG_ENABLE(libssp,
+[ --enable-libsspBuilds libssp directory],
+ENABLE_LIBSSP=$enableval,
+ENABLE_LIBSSP=yes)
+if test "${ENABLE_LIBSSP}" != "yes" ; then
+ noconfigdirs="$noconfigdirs configure-target-libssp target-libssp"
+fi
+
# Save it here so that, even in case of --enable-libgcj, if the Java
# front-end isn't enabled, we still get libgcj disabled.
libgcj_saved=$libgcj
bubblestrap and current gcc trunk gnattools
Hello,
Just today, I noticed that I couldn't use bubblestrap on current gcc
trunk... It fails like this in gnattools:
../../gnatbind -C -I- -I../rts -I. -I/usr/local/src/trunk/gcc/gcc/ada
-o b_gnatm.c gnatmake.ali
error: "g-dirope.adb" must be compiled
error: ("../rts/g-dirope.ali" is obsolete and read-only)
error: "a-filico.adb" must be compiled
error: ("../rts/a-filico.ali" is obsolete and read-only)
error: "a-finali.adb" must be compiled
error: ("../rts/a-finali.ali" is obsolete and read-only)
error: "s-finroo.adb" must be compiled
error: ("../rts/s-finroo.ali" is obsolete and read-only)
error: "a-stream.ads" must be compiled
error: ("../rts/a-stream.ali" is obsolete and read-only)
error: "a-tags.adb" has been modified and must be recompiled
error: "s-finimp.adb" must be compiled
error: ("../rts/s-finimp.ali" is obsolete and read-only)
error: "s-stratt.adb" must be compiled
error: ("../rts/s-stratt.ali" is obsolete and read-only)
make[3]: *** [b_gnatm.c] Error 5
make[3]: Leaving directory `/usr/local/src/trunk/objdir32/gcc/ada/tools'
make[2]: *** [gnattools-native] Error 2
make[2]: Leaving directory `/usr/local/src/trunk/objdir32/gnattools'
make[1]: *** [all-gnattools] Error 2
make[1]: Leaving directory `/usr/local/src/trunk/objdir32'
make: *** [bubblestrap] Error 2
Now, is this "just what to expect" or are there dependencies not being
properly updated in gnattools due to gnattools related specific
requirements making it hard to have bubblestrap working here?
--
Cheers,
/ChJ
Re: Problem with Delayed Branch Scheduling
_On 05-Jul-2005 00:14, Ian Lance Taylor san wrote_: Steven Bosscher <[EMAIL PROTECTED]> writes: So you have a few instructions bundled into a VLIW instruction, and one of the instructions in the bundle is moved into the delay slot, thus breaking your VLIW bundle. Right? I think there are two natural approaches. 1) Do the VLIW bundling after delayed branch scheduling. The way to do that is to the bundling in TARGET_ASM_FUNCTION_PROLOGUE. The FRV backend does this. I've done this successfully in the past. I think this is a good workaround but nullifying the possibility of having a VLIW bundled instruction in a branch delay slot. 2) When you do the VLIW bundling, put the instructions into a PARALLEL. I think this is the right solution which rectifies the problems. Please provide the pointer to where it has to be done. In general the gcc scheduler does not handle VLIW scheduling very well, and it needs a fair amount of target specific help. I dont know the list of known requirements (help), but from my side, currently insns are marked by TImode to signify the start of a VLIW bundle but some assemblers may require to signify the end of a VLIW bundle. There is no provision for that. Currently i have hacked GCC to meet this requirement.
Re: A trouble with libssp in one-tree builds
On Jul 5, 2005, at 12:50 AM, Kazu Hirata wrote: Hi Jakub, I am having a trouble with libssp in one-tree builds. That is, if I try to build binutils and gcc at the same time, libssp/configure complains while compiling (and linking) the following program and the build process stops. I don't see anything different between this or libstdc++ or libobjc, or any target library in libssp's configure.ac at all. -- Pinski
Re: Problem with Delayed Branch Scheduling
Ian Lance Taylor writes: > Steven Bosscher <[EMAIL PROTECTED]> writes: >> So you have a few instructions bundled into a VLIW instruction, and >> one of the instructions in the bundle is moved into the delay slot, >> thus breaking your VLIW bundle. Right? > > I think there are two natural approaches. > > 1) Do the VLIW bundling after delayed branch scheduling. The way to >do that is to the bundling in TARGET_ASM_FUNCTION_PROLOGUE. The >FRV backend does this. I've done this successfully in the past. To avoid any confusion: FR-V does indeed do the bundling here, but FR-V doesn't have delay slots, and so it isn't affected the OP's problem. (I realise you weren't claiming otherwise. I just thought I'd better mention it explicitly.) Richard
Re: GCC 4.0.1 RC3
Eric Botcazou wrote:
We have 1 new failure on SPARC/Solaris 2.5.1, 2.6 and 7 over RC2:
http://gcc.gnu.org/ml/gcc-testresults/2005-07/msg00137.html
http://gcc.gnu.org/ml/gcc-testresults/2005-07/msg00138.html
http://gcc.gnu.org/ml/gcc-testresults/2005-07/msg00139.html
WARNING: program timed out.
FAIL: 21_strings/basic_string/cons/char/1.cc execution test
try {
std::string str03(csz01 - 1, 'z'); <--- stuck here
This didn't happen in RC2 and I've not investigated what changed. The code is
the same on Solaris 7 and 8, but the Solaris 2.5.1, 2.6 and 7 machines are
substantially more limited than the Solaris 8, 9 and 10 machines.
Hmph. I'm not going to worry about this too much, on the grounds that
Solaris 7 is pretty old now...
Thanks for the report!
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
Re: GCC 4.0.1 RC3
Ulrich Weigand wrote: Mark Mitchell wrote: GCC 4.0.1 RC3 is now available here: ftp://gcc.gnu.org/pub/gcc/prerelease-4.0.1-20050702/ With luck, this will be the last 4.0.1 release candidate. Please do download tarballs from the above URL and confirm that they work OK on your systems. s390(x)-ibm-linux is still looking good: http://gcc.gnu.org/ml/gcc-testresults/2005-07/msg00182.html http://gcc.gnu.org/ml/gcc-testresults/2005-07/msg00183.html Thanks. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: [C++] Re: PARM_DECL of DECL_SIZE 0, but TYPE_SIZE of 96 bits
Daniel Berlin wrote: On Thu, 2005-06-30 at 14:11 -0700, Geoffrey Keating wrote: Certainly an option; not doing extra work is good. 4. Make sure that template types are incomplete. That is, with TYPE_SIZE/TYPE_SIZE_UNIT unset. I think this makes a lot of sense considering the language semantics. It does not make sense to make template types incomplete, as they are in fact complete, and there are situations where the compiler needs to look inside them. (For example, we need to look to see if there's a declaration of "void A::f()" when we see a declaration of such a function.) I'm not sure why any declaration with dependent type is ever reaching the middle end. That sounds like a problem to me, unless its purely in the context of debugging information. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
