Re: Problems shifting an int 32 times. Gcc 3.4.5
> I have a problem using the shift operator, maybe a bug (ok, a bug or i'm > wrong about shift operator) You are wrong about the shift operator. This is a bug in your code, not a gcc bug. Shift operators are only defined for non-negative shifts counts less than the size of the value being shifted. This is a practical necessity because hardware varies greatly on how it treats out of range shifts. Paul
Re: Solaris 9, GCC 4.1.1 and GCC 3.3.5 ... --disable-shared at build time?
> So... could someone elaborate on what it is I am doing that > is so wrong? What is the successful recipe for using GCC > 3.3.5 + 4.1.1 and/or binutils under Solaris? libgcc_s.so is backwards compatible. The 3.3 compiled code should work fine with the 4.1 libgcc. It is not forwards compatible. ie. you should make sure the newest libgcc is installed on the system. If you want to use new gcc without updating your system libgcc you'll have to use rpath or similar tricks to make sure the correct copy is used. Paul
Re: build failure, GMP not available
> Because gcc is the first step in bringing up a new system. Having > complex sets of dependencies makes people's lives harder. I'm sure > we've all had the unpleasant experience of trying to build something > from the net only to discover that we had to build five other things > first. In my experience the first thing you do bringing up a new system is build a cross compiler and use that to build glibc and coreutils/busybox. This is all done on an established host that has gmp/mpfr ported to it. Bootstrapping a native compiler comes quite late in system bringup, and only happens at all on server/workstation-class hardware. > > > I think that if we stick with our current approach, we will have a lot > > > of bug reports and dissatisfied users when gcc 4.3 is released. > > > > I'd argue that the minority of people who are building from source > > should not be our primary concern. Obviously, all other things being > > equal, we should try to make that easy -- but if we can deliver a > > better compiler (as Kaveh has already shown we can with his patch > > series), then we should prioritize that. For those that want to build > > from source, we should provide good documentation, and clear > > instructions as to where to find what they need, but we should assume > > they can follow complicated instructions -- since the process is > > already complicated. > > I disagree: the process of building gcc from a release (as opposed to > building the development version of gcc) really isn't complicated. > The only remotely non-standard thing that is required is GNU make. > Given that, all you need to do is "SRCDIR/configure; make". > Admittedly, people often get even that simple instruction wrong. But > it is easy to explain what to do. Last time I tried that it didn't work anyway because it got --enable-__atexit wrong. Paul
Re: Even stricter implicit conversions between vectors
On Tuesday 31 October 2006 19:02, Mike Stump wrote: > On Oct 31, 2006, at 10:47 AM, Mark Shinwell wrote: > > What do others think? > > My only concern is that we have tons of customers with tons of code > and you don't have any and that you break their code. I don't have > any idea if this would be the case or not, I don't usually do the > vector bugs. We're adding a new vector target, so have the opposite concern. We want to prevent sloppy code from ever appearing. Other toolchains implementing the ARM NEON extensions disallow these conversions, so allowing them in gcc is not advantageous. I've been told by contacts at ARM that they believe there is value in strict checking of vector types. I've no idea if there are significant quantities of code out there that rely on implicit conversions. Paul
Re: Using an automodified register twice in the same insn
On Wednesday 01 November 2006 17:39, Richard Sandiford wrote: > Can a register be used more than once in an insn if one of those uses is > an auto-modification? I've looked at this several times in the past and > never come to a conclusion. doc/rtl.texi says: We have a related problem on ARM. The ISA does not allow the base of a automodify address to be used as a source register. ie. (set (mem (post_inc (reg X)) (reg Y)) Is not valid when X == Y. Currently there is no way of expressing this, which leads to invalid asm being generated in some obscure cases. Paul
Re: Threading the compiler
> The competition is already starting to make progress in this area. > > We don't want to spend time in locks or spinning and we don't want to > liter our code with such things, so, if we form areas that are fairly > well isolated and independent and then have a manager, manage the > compilation process we can have just it know about and have to deal > with such issues. The rules would be something like, while working > in a hunk, you'd only have access to data from your own hunk, and > global shared read only data. > > The hope is that we can farm compilation of different functions out > into different cores. All global state updates would be fed back to > the manager and then the manager could farm out the results into > hunks and so on until done. I think we can also split out lexing out > into a hunk. We can have the lexer give hunks of tokens to the > manager to feed onto the parser. We can have the parser feed hunks > of work to do onto the manager and so on. > > How many hunks do we need, well, today I want 8 for 4.2 and 16 for > mainline, each release, just 2x more. I'm assuming nice, equal sized > hunks. For larger variations in hunk size, I'd need even more hunks. > > Or, so that is just an off the cuff proposal to get the discussion > started. > > Thoughts? Can you make it run on my graphics card too? Seriously thought I don't really understand what sort of response you're expecting. You've described how an ideal compiler would work, in fact how pretty much any parallel system should be designed to work. Do you have any justification for aiming for 8x parallelism in this release and 2x increase in parallelism in the next release? Why not just aim for 16x in the first instance? 16-way SMP isn't that rare even today. You mention that "competition is already starting to make progress". Have they found it to be as easy as you imply? whole-program optimisation and SMP machines have been around for a fair while now, so I'm guessing not. I realise this is a very negative reply, and please don't take it personally. However I don't think there's much to be gained by vague proposals saying "Lets make gcc threaded and not do it in a way that sucks". Like with LTO, until someone comes up with a concrete proposal and starts hacking on a branch It's all just hot air. Paul
Re: Threading the compiler
> Let's just say, the CPU is doomed. So you're building consensus for something that is doomed? > > Seriously thought I don't really understand what sort of response > > you're expecting. > > Just consensus building. To build a consensus you have to have something for people to agree or disagree with. > > Do you have any justification for aiming for 8x parallelism in this > > release and 2x increase in parallelism in the next release? > > Our standard box we ship today that people do compiles on tends to be > a 4 way box. If a released compiler made use of the hardware we ship > today, it would need to be 4 way. For us to have had the feature in > the compiler we ship with those systems, the feature would have had > to be in gcc-4.0. Intel has already announced 4 core chips that are > pin compatible with the 2 core chips. Their ship date is in 3 days. > People have already dropped them in our boxes and they have 8 way > machines, today. For them to make use of those cores, today, gcc-4.0 > would had to have been 8 way capable. The rate of increase in cores > is 2x every 18 months. gcc releases are about one every 12-18 > months. By the time I deploy gcc-4.2, I could use 8 way, by the time > I stop using gcc-4.2, I could make use of 16-32 cores I suspect. :-( > > > Why not just aim for 16x in the first instance? > > If 16x is more work than 8x, then I can't yet pony up the work > required for 16x myself. If cheap enough, I'll design a system where > it is just N-way. Won't know til I start doing code. 4.2 is already frozen for release, and the feature list for 4.3 is pretty much fixed at this point. I wouldn't expect any work of this scale to be released before gcc4.4. By your own numbers this means you should be aiming for 32x. > > You mention that "competition is already starting to make > > progress". Have they found it to be as easy as you imply? > > I didn't ask if they found it easy or not. Do you have any evidence the scheme you're proposing is even feasible? > > whole-program optimisation and SMP machines have been around for a > > fair while now, so I'm guessing not. > > I don't know of anything that is particularly hard about it, but, if > you know of bits that are hard, or have pointer to such, I'd be > interested in it. You imply you're considering backporting this to 4.2. I'd be amazed if that was worthwhile. I'd expect changes to be required in pretty much the whole compiler. Your strategy is built around the assumption that the majority of the work can be split into multiple independent chunks of work. There are several fairly obvious places where that is hard. eg. the frontend probably needs to process the whole file in series because previous declarations effect later code. And inter-procedural optimisations (eg. inlining) don't lend themselves to splitting on function boundaries. For other optimisations I'm not convinced there's an easy win compared with make -j. You have to make sure those passes don't have any global state, and as other people have pointed out garbage collection gets messy. The compile server project did something similar, and that seems to have died. If you're suggesting it's possible to make minor changes to gcc, and hide all the threading bits in a "manager" module then simply I don't believe you. Come back when you have a working prototype. I don't know how much of the memory allocated is global readonly data (ie. suitable for sharing between threads). I wouldn't be surprised if it's a relatively small fraction. If you have answers for the above questions, or some sort of feasibility study, maybe you could publish them? That would give people something to build a consensus on. So far you've given a suggestion of how we might like it to work but no indication of feasibility, level of effort, or where problems are likely to occur. Paul
Re: Reducing the size of C++ executables - eliminating malloc
On Sunday 12 November 2006 22:46, Michael Eager wrote: > Mark Mitchell wrote: > > Michael Eager wrote: > >> Why should the personality routine be included in all C++ programs? > > > > Because all non-trivial, exceptions-enabled programs, may need to do > > stack unwinding. > > It would seem that the place to require the personality > routine would be in the routine which causes the stack > unwinding, not in every C++ object file, whether needed > or not. The problem is that the places that knows we're using exceptions don't know how to do the stack unwinding, or what we're unwinding through. Only the code being unwound knows how to do the unwinding. The frame unwind information contains a function pointer that is called to interpret the rest of the frame data. eg. C, C++ and Java all have different exception table formats, and different personality routines to interpret those tables. The code that calls throw(), and the implementation of thow() don't know which of these routines are needed. The code being unwound through (ie. with frame data) needs to be able to say "I need routine X if __Unwind_Raise is used anywhere in this program". I'm not aware of any way of doing this, other than trying it and starting again if you guessed wrong. Paul
Re: Reducing the size of C++ executables - eliminating malloc
On Monday 13 November 2006 00:53, Daniel Jacobowitz wrote: > On Sun, Nov 12, 2006 at 11:17:14PM +0000, Paul Brook wrote: > > The code being unwound through (ie. with frame data) needs to be able to > > say "I need routine X if __Unwind_Raise is used anywhere in this > > program". I'm not aware of any way of doing this, other than trying it > > and starting again if you guessed wrong. > > Again, IIRC ARM's linker does something clever here. Of course the ABI > in use there is somewhat different, but I suspect it could be adapted. Probably. I don't think the ABI differences are relevant here. > On Sun, Nov 12, 2006 at 03:20:48PM -0800, Mark Mitchell wrote: > > But, the way the ABI works requires a reference from each unit which may > > cause unwinding. Even if you lose the personality routine, you will > > still have the exception tables, which themselves are a significant > > cost. If you don't want to pay for exceptions, you really have to > > compile with -fno-exceptions. In that case, certainly, we should be > > able to avoid pulling in the personality routine. > > If you try what Michael's been saying, you'll notice that trivial > C++ files get the personality routine reference even if they don't > have anything with a destructor which would need cleaning up. We ought > to be able to emit (somewhat smaller) unwind information which doesn't > reference the personality routine if it's going to have nothing to do, > shouldn't we? Ah, ok, sorry. ARM unwinding works a bit differently, and you always need a personality routine. Paul
Re: build failure, GMP not available
> Thanks for the report. I believe some of your issues can be addressed. > I'll add what I can to my TODO list. However I don't know if anything > will be done for the 4.1.x series given the restriction for regression > fixes only. I guess it depends on your definition of "regression", these > problems have always existed since we started relying on gmp/mpfr in 4.0. > However the 3.4 series didn't need these libraries so it never had these > kind of problems building fortran. :-) I think previous consensus has been that "regressions" against g77 aren't really regressions for release purposes. We removed one language and added a new one, they just happen to both be called FORTRAN ;-) Paul
Re: AVR byte swap optimization
> Ideally, this macro would expand to three mov instructions and a ret. > Is there anything I can do to help GCC along here? I'm using GCC 4.1.0 > with -O2. > > I won't bother to show bswap_32 here, which produces a real disaster! > Think 47 instructions, for what should be 6. Use gcc head, __builtin_bswap and make sure the AVR backend implements the bswap rtl patterns. Future versions of gcc may also be able to recognise these idioms without using the builtin, but AFAIK that's not been implemented yet. Paul
Re: what about a compiler probe?
> when given the -fcompiler-probe flag, it should get an a string > option with it. If this string is a (Unix) file path it indicate a > Unix socket or FIFO; if it starts with a vertical pipe bar | it > starts the command and communicate with it thru pipes. Typically the > command is some client application (either a GTK graphical > interface, or an Emacs, or perhaps a FastCGI) which communicates > with GCC thru a textual protocol to be defined and documented. > > The textual protcol should permit to examine, but not change, the > compilation state. For a lenghtly static analysis, it could be used to > show the properties the compiler currently know about a given > (compiled) source point. Sounds like something a decent debugger and a small about of scripting should already be able to do. Paul
Re: backporting arm eabi to 4.0
On Wednesday 22 November 2006 16:33, Rafael Espíndola wrote: > I am working on a ARM backend for LLVM. The problemis that llvm-gcc is > currently based on gcc 4.0 and I would like to use the new EABI. > > I have started to back port the ABI from 4.1 to 4.0. The first attempt > was to just copy the gcc/config/arm directory and try to fix build > errors. This proved hard because the new files depend on new > infrastructure. > > What I am trying right now is to build a list of patches that are in > the 4.1 branch but not in the 4.0. Then I will try to selectively move > then to 4.0. > > Does someone has a better idea or some suggestions on how to do this? I thought Chris was working on updating LLVM to gcc head. Paul
Re: Announce: MPFR 2.2.1 is released
> This all may just be a shakedown problem with MPFR, and maybe it will > stabilize shortly. But it's disturbing that after one undistributed > version became a requirement, we then very shortly stepped up to a new > undistributed version. I think it should be obvious that if we > require an external library which is not in the tree, we should not be > at the bleeding edge of that library. I thought we were going from an unreleased version to the subsequent release. Paul
Re: Packing of structure fields and whole structs
On Tuesday 05 December 2006 22:40, Phil Endecott wrote:
> Dear GCC Experts,
>
> I am trying to understand the subtleties of __attribute__((packed)). I
> have some code that works on x86, where unaligned accesses work, but
> fails on ARM where they do not.
>
> As far as I can see, if I declare a struct with the packed attribute
> applied to the whole struct, like this:
>
> struct test {
>int a;
>int b;
> } __attribute__((packed));
>
> and then use it like this:
>
> {
>char c;
>struct test t;
> }
>
> Then t will be packed next to c, and t.a and t.b will be unaligned.
> This is not what I want!
The compiler did exactly what you told it to. Don't use
__attribute__((packed)), or also specify a larger
alignment__attribute__((aligned(N))).
You can't reliably take the address of a member of a packed structure (gcc
doesn't have unaligned pointers).
Paul
Re: Question on BOOT_CFLAGS vs. CFLAGS
On Friday 15 December 2006 01:37, Josh Conner wrote: > All - > > When I configure with --disable-bootstrap and build with: > > CFLAGS="-g -O0" > > The resultant compiler is built with the specified options. However, if > I --enable-bootstrap, when I build with the same CFLAGS, these options > are not used to build the final compiler. I can get past this by using > BOOT_CFLAGS="-g -O0", but that seems a bit inconsistent. > > My question is: Is this behaving as designed or would it be reasonable > to file a bug and/or supply a patch to change the behavior so that > CFLAGS are respected whether bootstrapping is enabled or not? It is working as documented: http://gcc.gnu.org/onlinedocs/gccint/Makefile.html http://gcc.gnu.org/install/build.html Paul
Re: Question on BOOT_CFLAGS vs. CFLAGS
On Friday 15 December 2006 09:02, Paolo Bonzini wrote: > >> http://gcc.gnu.org/onlinedocs/gccint/Makefile.html > >> http://gcc.gnu.org/install/build.html > > > > I read that, could you please quote the part that documents the current > > behavior. > > If you wish to use non-default GCC flags when compiling the stage2 and > stage3 compilers, set BOOT_CFLAGS on the command line when doing `make'. > Non-default optimization flags are less well tested here than the > default of `-g -O2', but should still work. > > > Let me offer a counter quote: > > The counter quote is obviously wrong, thanks for the report. I think Mike's quote is only really misleading if taken out of context. The paragraph Paolo quoted immediately follows the text that Mike quoted. Paul
Re: Char shifts promoted to int. Why?
On Monday 18 December 2006 01:15, Paul Schlie wrote:
> Chris Lattner wrote:
> > On Dec 17, 2006, at 12:40 PM, Rask Engelmann Lamberts wrote:
> >> I seem unable to get a QImode shift instruction from this code:
> >>
> >> unsigned char x;
> >>
> >> void qishifttest2 (unsigned int c)
> >> {
> >>x <<= c;
> >> }
> >>
> >> should have been generated. Also, notice the redundant zero extension.
> >> Why are we not generating a QImode shift instruction?
> >
> > Consider when c = 16. With the (required) integer promotion, the result
> > is defined (the result is zero). If converted to QImode, the shift would
> > be undefined, because the (dynamic) shift amount would be larger than the
> > data type.
>
> ??? A left shift >= the precision of its shifted unsigned operand can only
> logically result in a value of 0 regardless of its potential promotion.
Shifting >= the size of the value being shifted can and do give nonzero
results on common hardware. Typically hardware will truncate the shift count.
eg. x << 8 implemented with a QImode shift will give x, not 0.
> Although integer promotion as specified by C may technically be performed
> lazily as a function of the implicit target precision required for a given
> operation, GCC tends to initially promote everything and then attempt to
> determine if an operation's precision may be subsequently lowered after
> having already lost critical knowledge of its originally specified
> operand's precision.
No. You're confusing some language you just invented with C.
The operand of the shift operator is of type unsigned int.
"x <<= c" is exactly the same as "((int)x) << c"
It doesn't matter whether the promotion is explicit or implicit, the semantics
are the same.
Paul
Re: Char shifts promoted to int. Why?
On Monday 18 December 2006 17:53, Robert Dewar wrote: > Chris Lattner wrote: > > C99 says: > > > > The integer promotions are performed on each of the operands. The > > type of the result is > > that of the promoted left operand. If the value of the right operand > > is negative or is > > greater than or equal to the width of the promoted left operand, the > > behavior is undefined. > > > > Thus, it is undefined. > > So the suggested transformation is indeed valid, which is what I > thought, but some seem to be contesting this, though I don't see > on what grounds. Note that the shift value restriction is based on the *promoted* type. Shifting an 8-bit value by >=8 is undefined. However in this case we're shifting a 32-bit value, because the left operand has been promoted. The fact that the variable written i the source happens to be a char is irelevant. Paul
Re: GCC optimizes integer overflow: bug or feature?
> Compiler can optimize it any way it wants, > as long as result is the same as unoptimized one. We have an option for that. It's called -O0. Pretty much all optimization will change the behavior of your program. The important distinction is whether that difference is observable in valid programs. The whole point of langage standards is that they define what constitutes a valid program. By your definition all writes to vairables must translate into a write to memory (for "correct" behavior in multithreaded applications and with signal handlers). This implies all variables are effectively volatile. You can argue that signed overflow is an extension that it's worth supporting by default. Other people (eg. those interested in autovectorization) will argue that it provides useful optimization opportunities. I don't know which of these is better, but either what it's a lot different to saying "never change the behavior of any program. Paul
Re: GCC optimizes integer overflow: bug or feature?
On Tuesday 19 December 2006 22:39, Denis Vlasenko wrote: > On Tuesday 19 December 2006 22:46, Paul Brook wrote: > > > Compiler can optimize it any way it wants, > > > as long as result is the same as unoptimized one. > > > > We have an option for that. It's called -O0. > > > > Pretty much all optimization will change the behavior of your program. > > Even x*2 -> x+x? Or unsigned x/8 -> x>>3 ? > > I am perfectly happy with registers too. Not nesessarily with same size, > even. (Just proprerly autoextend signed values a-la AMD64). > > Do not put words in my mouth. I said nothing about volatility > and multithreading. My point exactly. You said you wanted results "the same as unoptimized". That was an unqualified statement, so the only reasonably assumption is that you meant the results should be the same in all cases, for all code. And yes, in extreme circumstances these transformations could be considered unsafe. Particularly if one form requires a libcall. As an even more extreme case it's theoretically possible to break some cryptographic algorithms by observing the power consumption variations as the CPU miltiplier unit is powered up to do the multiply. If what you really meant was "don't break my code", you're going to have to be a lot more specific about exactly what additional guarantees you require. Paul
Re: GCC optimizes integer overflow: bug or feature?
> > Actually they will with multi threaded program, since you can have a case > > where it works and now it is broken because one thread has speed up so > > much it writes to a variable which had a copy on another thread's stack. > > Why isn't that just a buggy program with wilful disregard for the use of > correct synchronisation techniques? As opposed to a buggy program with wilful disregard for signed overflow semantics? ;-) Paul
Re: GCC optimizes integer overflow: bug or feature?
On Thursday 21 December 2006 02:38, Gabriel Dos Reis wrote: > Paul Brook <[EMAIL PROTECTED]> writes: > | > Compiler can optimize it any way it wants, > | > as long as result is the same as unoptimized one. > | > | We have an option for that. It's called -O0. > | > | Pretty much all optimization will change the behavior of your program. > | The important distinction is whether that difference is observable in > | valid programs. The whole point of langage standards is that they define > | what constitutes a valid program. > > The problem is that what constitutes a valid program tends to differ > from what constitutes a useful program found in the wild. The > question for GCC is how to accomodate for the useful uses without > getting far away from both conformance and non-conformance. I never said any different. If fact you'll notice that later in the same email (which you have cut) I said pretty much the same thing. The post I was replying to wasn't suggesting that we should support specific cases of nonconforming code, it was saying that we shouldn't change the behavior of *any* code. Paul
Re: GCC optimizes integer overflow: bug or feature?
On Friday 22 December 2006 00:58, Denis Vlasenko wrote:
> On Tuesday 19 December 2006 23:39, Denis Vlasenko wrote:
> > There are a lot of 100.00% safe optimizations which gcc
> > can do. Value range propagation for bitwise operations, for one
>
> Or this, absolutely typical C code. i386 arch can compare
> 16 bits at a time here (luckily, no alighment worries on this arch):
>
> int f(char *p)
> {
> if (p[0] == 1 && p[1] == 2) return 1;
> return 0;
> }
Definitely not 100% safe. p may point to memory that is sensitive to the
access width and/or number of accesses. (ie. memory mapped IO).
Paul
Re: GCC optimizes integer overflow: bug or feature?
On Friday 22 December 2006 02:06, Robert Dewar wrote:
> Paul Brook wrote:
> > On Friday 22 December 2006 00:58, Denis Vlasenko wrote:
> >> On Tuesday 19 December 2006 23:39, Denis Vlasenko wrote:
> >>> There are a lot of 100.00% safe optimizations which gcc
> >>> can do. Value range propagation for bitwise operations, for one
> >>
> >> Or this, absolutely typical C code. i386 arch can compare
> >> 16 bits at a time here (luckily, no alighment worries on this arch):
> >>
> >> int f(char *p)
> >> {
> >> if (p[0] == 1 && p[1] == 2) return 1;
> >> return 0;
> >> }
> >
> > Definitely not 100% safe. p may point to memory that is sensitive to the
> > access width and/or number of accesses. (ie. memory mapped IO).
>
> A program that depends on this is plain wrong. There is no guarantee
> that memory references are as they appear in the program. For a
> non-volatile variable, any such optimization is valid. For instance
> if the flow can be used to prove that p[0] is already 1, then there
> is no need to repeat the read.
Who says the optimisation is valid? The language standard?
The example was given as something that's 100% safe to optimize. I'm
disagreeing with that assertion. The use I describe isn't that unlikely if
the code was written by someone with poor knowledge of C.
My point is that it's not that hard to invent plausible code that "breaks"
when pretty much any transformation is applied. We have to decide how close
to the standard we want to fly.
"Optimization should never change the behavior of any program accepted by the
compiler" is not a useful constraint for an optimizing compiler. If program
behavior includes the ability to debug the program, then I'd go as far as
saying this should be the definition of -O0.
"Optimization should never change the behavior of a valid program" is useful
definition because it forces you to define what constitutes a valid program.
There's actually a much better reason why the transformation is not safe.
Consider a data structure where a byte of 1 indicates the end of the object.
Under normal circumstances short-circuiting of the && operator prevents
anything bad happening. If you merge the two accesses you've just read past
the end of the object and all kinds of bad things may happen (eg. a
segfault).
Paul
P.S. I think I'm repeating myself now, so this is the last time I intend to
comment on this thread.
Re: dump after RTL expand
On Thursday 11 January 2007 19:27, Steven Bosscher wrote: > On 1/11/07, Andrija Radicevic <[EMAIL PROTECTED]> wrote: > > Hi, > > how could I find out from which patterns, in the md file, the 00.expand > > file was generated (i.e. to map the patterns in the expand file with the > > ones in the .md file)? Is there a compiler option/switch which would tell > > the compiler mark the patterns in the expand file with the insns names > > from the md file? > > There isn't. > > You would have to walk over the insn and make recog assign them an insn > code. That still wouldn't tell you what names were used to generate them. It's common to have a named expander that generates other (possibly anonymous insns). Paul
Re: GCC 4.1.2 RC1
On Tuesday 30 January 2007 11:44, Robert Schwebel wrote: > On Mon, Jan 29, 2007 at 07:06:36PM -0800, Mark Mitchell wrote: > > If you do encounter problems, please file a Bugzilla PR, and add me to > > the CC: list for the issue. Please do not send me reports without first > > filing a PR, as I am unable to keep track of all the issues if they are > > not in the database. > > It looks like http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28675 is fixed > in 4.2, because in our autobuild runs we don't see the ICE any more. > However, the bugzilla entry doesn't mention a fix for the problem. Paul, > have you done something in 4.2 which might be backported to 4.1? I never managed to fix it, so I expect it's still latent. I've added my analysis to the PR. Paul
Re: GCC 4.1.2 RC1
On Wednesday 31 January 2007 01:26, Mark Mitchell wrote: > Robert Schwebel wrote: > > What about PR28516, would it be acceptable for 4.1.2? > > There are two issues: > > (1) it's not marked as a 4.1 regression, let alone a regression from > 4.1.x. Did this test case work with older versions of GCC? 4.1 is the first FSF release to support arm-linux-gnueabi (the bug only effects eabi targets). The bug is preset in 4.0, but apparently noone other than glibc uses nested functions with -fexceptions. Paul
Re: Seeking advice on front ends
> My options code generations are more or less: > > 1) Code an interpreter > > 2) Build the parse tree in GCC's native format and let GCC generate > the code > > 3) Generate annotated C and call GCC on that. 3b) Generate ISO C. Compile with $(CC). 4) Convert your internal (parse) trees into GENERIC (aka GCC "native") trees as a separate pass. This is how Java, Ada and Fortran work. I strongly recommend (4) rather than (2). Whether you choose (1), (3) or (4) is a decision you need to make based on how much you care about the quality of generated code, and how much time+effort you're willing to invest. Paul
Re: sizeof struct { short x } on arm gcc-3.2.1
> My (embedded) development system is gcc-3.2.1 arm-elf. I don't really
> understand its value for sizeof(struct { short x }).
> sizeof s_sh 4
> sizeof short 2
This is a feature of the ARM ABI you are using. All structures are word
aligned (which implies being word sized).
Paul
Re: Floating point insn dependency - GCC 4.1.1
> > 1. Is there a way to check for dependency b/w this two instructions. > > 2. Any existing backend that has this type of design. > > gcc currently does a relatively crummy job of handling this type of > VLIW architecture. You can describe the dependencies in the > scheduler, but the scheduler won't insert any required nops for you. > The usual approach is walk through the insn chain in the MD reorg pass > and insert nops at that time. For example, look at mips_reorg in > config/mips/mips.c. I've also done it in FINAL_PRESCAN_INSN. Given you only have limited dual-issue, could the delay slot mechanisms be used for this? Paul
Re: gcc and gmp/mpfr - order of build
On Monday 05 March 2007 22:00, Andreas Schwab wrote: > "Kate Minola" <[EMAIL PROTECTED]> writes: > > Option A. Use the bootstrap compiler to first build gmp and mpfr, > > then build gcc. > > > > Option B. Build gcc without gmp and mpfr. Then use it to > > build gmp and mpfr. Now rebuild gcc using gmp and mpfr. > > > > Are there other options? > > Option C: unpack gmp and mpfr sources in the gcc toplevel and bootstrap > all of gcc, gmp, mpfr together. Option D: Use a cross compiler. Paul
Re: Adding a new gcc dir
> Which means using C90, which means no mixed declarations and code, no > C++ comments, etc. Is there any way to compile at least, my files with > c99 constructs? > Or all gcc code should be built like this?? This is a feature. gcc can be bootstrapped using an arbitrary c90 compiler. The warning options you mentioned help to enforce this. Paul
Re: Adding a new gcc dir
On Wednesday 07 March 2007 14:30, [EMAIL PROTECTED] wrote: > Is it time to offer "second-strap" level of compilation? Ie allow C99 to > bootstrap the creation of a basic GCC compiler, then allow a second compile > using the basic GCC compiler to get the full compiler. Maybe, but I consider rejecting mixed code/declarations to be a feature :-) C++ comments are handy for quick debugging hacks, but I'm not sure they add any real value to production code. Paul
Re: Detemining the size of int_fast8_t etc. in the frontend
On Wednesday 07 March 2007 19:21, Tobias Burnus wrote: > gfortran provides via ISO C Bindings access to the C types int, float > etc. It also provides access to int_fast8_t, int_fast16_t, etc. of > stdint.h. > > Using "#include " with e.g. sizeof(int_fast8_t) does not work > with cross compilations. (It actually fails already for -m32 on x86-64.) > On the other hand, "struct gcc_target" does not seem to provide this > information. > > What is the proper way to obtain this information? I suspect the answer is that there currently isn't one. gcc uses the stdint.h provided by the target C library. This may not be available when building the compiler. Paul
Re: Quick FUNCTION_MODE doco query
> @defmac FUNCTION_MODE
> An alias for the machine mode used for memory references to functions
> being called, in @code{call} RTL expressions. On most CISC machines,
> where an instruction can begin at any byte address, this should be
> @code{QImode}; on RISC machines, where all instructions are word-sized
> and aligned, this should be a mode with the same size and alignment as
> the machine instruction words - @code{SImode} for 32-bit processors, or
> perhaps @code{HImode} for such machines as the ARM cpu in Thumb mode,
> which uses 16-bit instructions.
> @end defmac
I think the last sentence just adds more confusion than value. Maybe:
[...]. On most RISC machines, where all instructions have fixed sized and
alignment, this should be a mode with the same size and alignment as the
machine instruction words - Typically @code{SImode} or @code{HImode}.
Paul
Re: Address of variables in the bss/text segments of a shared library
On Wednesday 14 March 2007 00:36, Scott Brooks wrote: > When I use &__bss_start, &_end, in a shared library I get the addresses of > the __bss_start and _end of the main application that has loaded the > library. > > I would like to get the address of the bss/text segments of the shared > library itself. This is the wrong place to ask this question. This list is for the development of gcc. You probably want dl_iterate_phdr. Paul
Re: Building without bootstrapping
> How can I get the build scripts to use the precompiled gcc throughout > the build process ? Short answer is you can't. The newly build gcc is always used to build the target libraries[1]. Paul [1] Except when building a Canadian cross, in which case you're expected to have a build->target cross compiler available. Bad Things will probably happen if this doesn't match the compiler being built.
Re: GCC priorities [Was Re: We're out of tree codes; now what?]
> Exactly. I'm viewing the mission statement as the moral equivalent of a > constitution -- the highest guidelines that you fall back on when > everything else fails. Your first paragraph above indicates that you view > it similarly. But it's currently so vague that I don't imagine it's much > use... it's like a legal constitution that says "be nice to everybody". The problem is that I don't think writing a detailed "mission statement" is actually going to help anything. It's either going to be gcc contributors writing down what they're doing anyway, or something invented by the SC or FSF. I the latter case nothing's going to change because neither the SC nor the FSF have any practical means of compelling contributors to work on a particular feature. It's been said before that Mark (the GCC release manager) has no real power to make anything actually happen. All he can do is delay the release and hope things get better. > Maybe I'm wrong, but to return to the original topic, I don't expect > to see compile-time performance improve significantly in any future > release. I'm not aware of anyone putting serious effort into improving compile-time performance, so you may well be right. Paul
Re: Information regarding -fPIC support for Interix gcc
On Thursday 22 March 2007 20:20, Mayank Kumar wrote: > I work for Microsoft SFU(services for unix) group and I am currently > investigating this fPIC issue for gcc 3.3 which is available with sfu 3.5. gcc3.3 is really quite old, and hasn't been maintained for quite some time. You're unlikely to get a particularly useful response from this list (or any volunteer gcc developers) unless you're working with current gcc. Of course there are organisations who will provide you with commercial support for older gcc releases. That's a separate issue though. Paul
Re: We're out of tree codes; now what?
On Thursday 22 March 2007 23:24, Richard Kenner wrote: > > 1. We can go to 9-bit codes. They're slower, independent of checking. > > Maybe we can make bitfields go faster, and get some of that back. > > I think it worth understanding why this is. One or even two instructions > should be lost in the noise on a modern machine when they are always > accompanied by a load. If nothing else you've got bigger code (increased icache pressure). Paul
Re: A sibcall is also a leaf?!?
> This logic works fine - except when gcc tells me that this sibcall > function is a leaf, despite the fact that it calls out to another function > that probably clobbers the call_used regs. A leaf function is one that doesn't make any function calls. Technically speaking, a sibcall isn't really a function call, it's "returning" to somewhere other than the caller. For most purposes it's as if foo4's caller made the function call, not foo4. As you say, the correct solution is to disallow sibcalls on isr routines. Paul
Re: arm-elf-gcc shared flat support
> I am working on Shared flat file support for uClinux (No MMU ARM ).The > gcc version > I am using is 2.95 and 3.4.0.Theory of operation is similar to that You really need to be using the latest gcc (ie. svn trunk, aka 4.3) before we can help you. gcc also has a uclinux target. You should be using that rather than the generic ELF one. > implemented for m68k.One of the major requirement is to call functions > is to be called as > > compiler output*** > > ldr r3, .L4 > mov lr,pc > ldrpc[sl,r3] > > .L4: > .word foo(GOT) > > ** > > as opposed to > bl foo(PLT) > > where sl holds the address of GOT.(binfmt_flat loader ensures that > before the program start) Why on earth do you need to do this? Can't you get the linker to generate PLT sequences like we do for normal shared libraries? Paul
Re: how to convince someone about migrating from gcc-2.95 to gcc-3.x
On Sunday 01 April 2007 12:01, Dave Korn wrote: > On 01 April 2007 07:08, ganesh subramonian wrote: > > Hi > > I work in a company where we have been using gcc-2.95.4 (based cross > > compiler) for compiling our code. Most of the code is written in c++ > > and makes extensive use of the stl libraries. We would not be changing > > our operating system or processor architecture (so portability is not > > a very good reason to give). There seems to be a lot of changes since > > gcc-2.95 as a result of which we get a large number of errors when > > trying to compile the code with gcc-3.x. > > Yes, this is known. The C++ language standard was still changing in the > 2.95->3.x timescale, and GCC moved a lot closer to strict conformance. See > > http://gcc.gnu.org/gcc-3.4/changes.html#cplusplus > > You may find that using a 3.3 series compiler requires a good deal less > rewriting than a 3.4 series compiler; which version did you try? If you're already switching compilers, moving to an already obsolete release (3.3) seems a strange choice. At this point I'd recommend skipping 3.x altogether and going straight to gcc4.1/4.2. Many of the improvements in c++ code generation were as a result of tree-ssa, you only get with 4.x. Paul
Re: bugzilla admin request
On Saturday 07 April 2007 15:28, Dave Korn wrote: > Hi there, > > I'm actively working on a patch for enhancement request PR14331, which is > still currently in 'NEW' state. Would some kindly admin like to assign it > to me? Didn't you get bugzilla super-powers with your write after approval account? Paul
Re: Toolchain for Maverick Crunch FPU
On Thursday 12 April 2007 14:02, Richard Earnshaw wrote: > On Thu, 2007-04-12 at 14:16 +0300, Kai Ruottu wrote: > > Things seem to be that the '-mcpu=ep9312 -mhard-float' combination will > > crash the GCC build in both gcc-4.1.2 and gcc-4.2.0-20070316 prerelease > > like : > > -mhard-float doesn't do what you think it does... > > I think you should be using: > > -mcpu=ep9312 -mfpu=maverick -mfloat-abi=softfp > > However, this isn't a combination that I test, so your mileage may > vary... :-) I suspect you'll find the maverick FPU code is somewhat bitrotten. To expand on what Richard said above, -mhard-float is an alias for -mfloat-abi=hard. -mfloat-abi= determines where/when coprocessor instructions are used: soft=never, softfp=only within a function, hard=always (this changes the ABI). Not all combinations are implemented. -mfpu= tells gcc which FPU model to use. It does not by itself enable generation of coprocessor instructions. I'll admit that the meaning of these options isn't particularly intuitive. You may also find that with older toolchains/targets the compiler and assembler might not be consistent in what setting they use. Recent EABI based toolchains have solved this problem using .fpu and .arch directives in the assembly file. Paul
Re: [RFA] C++ language compatibility in sources [was RE: Add missing casts in gengtype-lex]
> However, bundling them all up into big patches would probably run over the > size limit for "small patches that don't require paperwork". The size limit for non-copyrightable changes is accumulative. ie. it applies the same whether changes are submitted one by one or all at once. Paul
Re: [RFA] C++ language compatibility in sources [was RE: Add missing casts in gengtype-lex]
On Thursday 12 April 2007 16:35, Dave Korn wrote: > On 12 April 2007 16:31, Paul Brook wrote: > >> However, bundling them all up into big patches would probably run over > >> the size limit for "small patches that don't require paperwork". > > > > The size limit for non-copyrightable changes is accumulative. ie. it > > applies the same whether changes are submitted one by one or all at once. > > > :) Over what period is it cumulative? Does that mean that if you submit > an 8 line patch, that twenty years later you can't submit a 3 line patch > without paperwork? I think the 12 lines is a guideline rather than a legal definition, but in principle this would require a copyright assignment. By my reading copyright for written work expires 70 years after the author's death. IANAL. Paul
Re: A question on gimplifier
On Saturday 14 April 2007 20:32, H. J. Lu wrote: > On Sat, Apr 14, 2007 at 12:23:24PM -0700, Andrew Pinski wrote: > > On 4/14/07, H. J. Lu <[EMAIL PROTECTED]> wrote: > > >__builtin_ia32_vec_set_v2di is > > > > > >v2di __builtin_ia32_vec_set_v2di (v2di, long long, const int) > > > > v2di and m128i are the same type except for may_alias which only > > matters when taking its address. > > It sounds right. I guess we get lucky that ix86_expand_vector_set As Dan said, RTL expansion and patterns have nothing to do with the dumps you quoted. The tree dumps you quoted were before and after gimplification, which is a completely unrelated process. Paul
Re: GCC -On optimization passes: flag and doc issues
> No, the issue is that the -Os option is *documented* to *only* include > those optimizations that are known to not increase the code size. Where exactly is the documented? My documentation says It enables "optimisations that do not *typically* increase code size" (emphasis mine). Many optimizations (including inlining) are controlled by heuristics, which by their very nature give the "wrong" decision sometimes. The trick is to get the best overall settings, or the best settings for a particular target. Paul
Re: Segfault on OpenMP program
On Wednesday 18 April 2007 00:19, FX Coudert wrote: > Someone reported on bug on a trivial statically-linked Fortran progam > with OpenMP and a I/O operation. I can reproduce the segfault, which > happens at: >... > Andrew suggested on bugzilla that this might be a GLIBC issue (I use > glibc-2.4 from redhat), with "pthreads not linking in correctly". > Does this ring a bell? Can someone confirm that it's not a GCC issue > (or that it is)? Details can be found in PR 31604. The answer to any question involving glibc and static linking is generally "don't do that". I've seen pthread related problems with static linking, though that was related to nss dlopening a shared library from a static application. Paul
Re: Builtins-vs-libcalls-vs-optimised-away-vs-still-emitting-an-undefined-symbol-reference
> > .file "" > > foo.global _ffs > > Is this really a reference? It just looks like a declaration. A > typical ELF assembler will not generate an undefined symbol merely > because it sees a .global pseudo-op. I think gas 2.17 counts as a "typical ELF assembler". It does create undefined symbols in response to a .global pseudo-op. There was a patch to the c++ frontend recently to avoid a similar problem with EH personality routines. Paul
Re: Builtins-vs-libcalls-vs-optimised-away-vs-still-emitting-an-undefined-symbol-reference
> > There was a patch to the c++ frontend recently to avoid a similar problem > > with EH personality routines. > > Couldn't see what you're referring to in cp/ChangeLog straight away, have > you got a pointer/rough date/search term I can use? Ah, it wasn't actually the c++ forntend: 2007-03-19 Mark Mitchell <[EMAIL PROTECTED]> * except.c (output_function_exception_table): Do not reference the EH personality routine for functions that do not require an exception table. Paul
Re: [arm] possible bug in G++ 3.4.x
> [Paul]: > Is this problem present also in CSL-3.4.x branch? That depends which target you are using. It Richard's analysis is correct this is an ABI limitation rather than a compiler problem. The "old" arm-none-elf and arm-linux targets still use SJLJ exceptions. They will probably never be "fixed" as this would involve an ABI change. The newer eabi based arm-none-eabi and arm-linux-gnueabi targets use unwinding tables. They should not have this problem. Paul
Re: [arm] possible bug in G++ 3.4.x
On Tuesday 01 March 2005 15:29, Petko Manolov wrote: > On Tue, 1 Mar 2005, Paul Brook wrote: > > The "old" arm-none-elf and arm-linux targets still use SJLJ exceptions. > > They will probably never be "fixed" as this would involve an ABI change. > > Didn't understand that. How is all non scratch FP registers save at the > prologue related to the exceptions? Because SJLJ exception handling is implemented using __builtin_setjmp/__builtin_longjmp. These do not save/restore FP register state. If an exception is thrown the FP state will be that at the throwing location. Thus the prologue must save all call-saved registers if there is a possibility that an exception will be caught. Paul
Re: Fortran libs.
On Wednesday 02 March 2005 02:37, Marcin Dalecki wrote: > After trying to build the fortran compiler I'm convinced that at a cut > down version of the multi precision libraries it requires should be > included > in to the compiler tree. The reasons are as follows: > > 1. They should be there for reference in bug checking. > 2. This would make installation on systems which don't fall in to the > category of > JBLD (Joe Users Bloated Linux Distro) much easier. > 3. Stuff not required for the proper operation of the compiler could be > taken out. > It's actually just a tinny subset of the library, which the compiler > truly required. I'm not sure I believe that. IIRC we [gfortran] use a good proportion of the functionality provided by mpfr. If we don't, we probably should... > 4. It would see just to be consequent in face of a copy of the zip > library./ > 5. It would make it easier to guarantee that the source code setup > choices between what the > fortran compiler expects and how the library was build match. The difficulties of convincing the gmp configuration to do what gcc wants is one of the reasons why it hasn't been integrated yet. At least one person has tried and failed. > 6. Since there are multiple releases of the libraries in question this > would just reduce > the combinatorial complexity of the maintainance issues. You forgot to attach the patch implementing all the above. I agree that we want to include the libraries. However putting a modified version of a third party library in the gcc tree is a bad idea. If possible we should include the upstream version unchanged. We [I] don't want to have to maintain a separate copy when upstream authors already do that much better. If changes are required these should be incorporated by pushing the changes to upstream packages and resyncing, not by maintaining them locally. Paul
Re: request for timings - makedepend
> (a) the numbers reported by the "time" command, real3m52.604s user3m15.490s sys 0m29.550s > (b) what sort of machine this is and how old hp-pa 712/80. At least 7 years only, probably more. This machine takes many hours to bootstrap gcc. > (c) whether or not you would be willing to trade that much additional > delay in an edit-compile-debug cycle for not having to write > dependencies manually anymore. Yes. Paul
Re: Questions about trampolines
> - Are trampolines used for anything else but nested functions > in C? I believe they are used by Ada. <...> > My personal uninformed opinion is that trampolines cause more trouble > than they are worth. Ada, Fortran and Pascal all require nested functions. Paul
Re: gcc 3.4.3 bug C++/inlines/thumb
On Saturday 19 March 2005 07:51, Carl van_Schaik wrote: > I'm running into a bug with gcc 3.4.3: > > I've got syscall code for user-land to our kernel that trashes r14/lr. > The code is inlined, and works find in ARM mode. When compiling in thumb, > gcc does not preserve lr. With an older gcc 3.3.3, the code was not > inlined, but generated correctly. This has been fixed in later versions by this patch: http://gcc.gnu.org/ml/gcc-patches/2004-05/msg01739.html Paul
Re: AVR indirect_jump addresses limited to 16 bits
On Sunday 20 March 2005 01:58, Giovanni Bajo wrote:
> Paul Schlie <[EMAIL PROTECTED]> wrote:
> > - Sorry, I'm confused; can you give me an example of legal C
> > expression specifying an indirect jump to an arbitrary location
> > within a function?
>
> It is possible in GNU C at least:
>
> int foo(int dest)
> {
>__label__ l1, l2, l3;
>void *lb[] = { &&l1, &&l2, &&l3 };
>int x = 0;
>
>goto *lb[dest];
>
> l1:
>x += 1;
> l2:
>x += 1;
> l3:
>x += 1;
>return x;
> }
>
> I would not design a backend so that such a feature is deemed to be
> impossible to support.
Don't we know which labels are targets of indirect jumps?
So the proposed restriction now becomes: functions *and targets of indirect
jumps* must be aligned to an N word boundary. I'd guess that the latter are
sufficiently rare that this is still an acceptable restriction.
Paul
Re: Input and print statements for Front End?
On Wednesday 06 April 2005 13:00, Harry Goulding wrote: > Hi All, > > I'm developing a front end for a simple programming language as part of a > project. > > I have looked through the GCC Internals Manual, the Toy front end language > and Treelang. > > I can't seem to find any info regarding an input or print statement, so i > can read integers(my language only deals with integers) from the stdio and > return integer results to stdio. Interfacing with the OS is the resposibility of your language runtime library, not the compiler itself.. You might want to look at how the fortran intrinsic functions an IO routines are handled. Basically the language define IO constructs are turned into a sequence of function calls. Paul
Re: ARM EABI Exception Handling
On Thursday 07 April 2005 17:46, Josh Conner wrote: > Can anyone tell me if there are plans to incorporate the ARM EABI > exception handling (a la CSL) into the mainline gcc ARM port? Yes. It's on our (CodeSourcery's) list of things to do. Paul
Re: Inline round for IA64
On Thursday 07 April 2005 18:54, Steve Kargl wrote: > On Thu, Apr 07, 2005 at 01:41:21PM -0400, Geert Bosch wrote: > > On Apr 7, 2005, at 13:27, Steve Kargl wrote: > > >Try -fdump-parse-tree. You've given more digits in y than > > >its precision. This is permitted by the standard. It appears > > >the gfortran frontend is taking y = 0.49 and the closest > > >representable nubmer is y = 0.5. > > > > So, why does the test y < 0.5 yield true then? > > I missed that part of the output. The exceeding > long string of digits caught my attention. Can > you submit a PR? The problem, I believe, is in > gfc_simplify_nint Unlikely, although that may also be buggy. fc_simplify_* only applies to compile time costants. You probably want build_round_expr in trans-intrinsic.c Paul
Re: Stack and Function parameters alignment
On Friday 15 April 2005 13:33, Petar Penchev wrote: > Hello All, > The CPU ,I am porting GCC to , has PUSH instruction for half-word (byte) > and PUSH instruction for word as well. > GCC is using them well, until I was told to add a command-line option > which allows GCC to align on word. > It has been done, however, there samoe problems. GCC generates following > code: > > PUSH AL ; AL is 8-bit reister > INC S ; increment stack pointer > > This is correct code, but it is longer than > > PUSH A ; where A is 16 bit register<...> Obviously this only works on little-endian targets. <...> > [(set (mem:QI (post_inc (reg:HI S_HREG))) > (match_operand:QI 0 "general_operand" "b"))] >"!TARGET_STACK_BYTE_ALLIGN" > [ > (set (match_dup 1) > (match_dup 0) > ) > (set (mem:HI (post_inc (reg:HI S_HREG))) > (match_dup 1) > ) > ] >" >operands[1] = gen_rtx(REG, HImode, A_HREG); >" > ) A post_inc increments by the size of the memory access. A define_split is supposed to replace one insn by multiple insns that do the same thing. You're replacing a byte increment with a word increment. You could try adding a define_peephole2 that turns push al; inc S into push a. Paul
Re: Processor-specific code
On Friday 15 April 2005 18:43, Vincent Lefevre wrote: > On 2005-04-14 10:35:06 -0700, Richard Henderson wrote: > > All that said, C99 has to control just about anything you > > could want about the fpu. > > It is not possible to change the rounding precision with . That's because it's an x86/m68k specific implementation detail and the compiler should be setting it for you. gcc doesn't do this because noone cares enough to implement it. Paul
Re: How to -Werror in a fortran testcase?
On Saturday 16 April 2005 19:32, Richard Guenther wrote: > Hi! > > gfortran does not support -Werror it seems. It should, this is a bug. > What do I need to put in dg-options to make a testcase fail, if there is > any warning? Doesn't dejagnu do this anyway? Ie. any unexpected errors or warnings will cause the test to fail. Paul
Re: [gomp] OpenMP IL design notes
On Wednesday 04 May 2005 13:15, Biagio Lucini wrote: > On Tuesday 03 May 2005 21.16, Diego Novillo wrote: > > On Tue, May 03, 2005 at 11:05:05PM +0200, Lars Segerlund wrote: > > > we have to extend the gfortran internal representation also > > > > Yes, initially most of the effort will be in C/C++ since that's > > the only parser we have so far. > > Is there any obstruction in principle to have the so-called sentinel > directive (!$OMP) recognised by the gfortran parser? I have no objections. It'd be nice to have OpenMP support, but it's not currently a high priority for me. > Talking with Lars, I > have understood that at the moment some misbehaviour of the front-end > prevents it, but I don't quite understand what the problem is. Can anyone > shed some light? Basically the fortran parser does trial-and-error pattern matching, and can end up parsing a single comment many times. Paul
Re: [gomp] OpenMP IL design notes
On Wednesday 04 May 2005 16:40, Biagio Lucini wrote: > On Wednesday 04 May 2005 13.34, Paul Brook wrote: > > On Wednesday 04 May 2005 13:15, Biagio Lucini wrote > > > > > I have understood that at the moment some misbehaviour of the > > > front-end prevents it, but I don't quite understand what the problem > > > is. Can anyone shed some light? > > > > Basically the fortran parser does trial-and-error pattern matching, and > > can end up parsing a single comment many times. > > Is this a permanent feature or something that can be removed? The reason > why I am asking is that I would like to experiment with this front-end a > little bit. It's more of an implementation wart than a feature. I don't think anyone's particularly attached to our current parser. If it needs significant changes to support OpenMP then I've no real objections, as long as it still works :-) Paul
Re: Use $(VARRAY_H) in dependencies?
On Monday 09 May 2005 02:26, Matt Kraai wrote: > Howdy, > > The rules for c-objc-common.o, loop-unroll.o, and tree-inline.o > include $(VARRAY_H), which is never defined, in their dependency > lists. The rest of the targets that depend on varray.h include > varray.h in their dependency list. > > varray.h includes machmode.h, system.h, coretypes.h, and tm.h, so > Makefile.in should define and use VARRAY_H, right? Already one step ahead of you :-) 2005-05-07 Paul Brook <[EMAIL PROTECTED]> * Makefile.in: Fix dependencies. (GCOV_IO_H, VARRAY_H): Set.
Re: Use $(VARRAY_H) in dependencies?
On Monday 09 May 2005 03:55, Matt Kraai wrote: > On Sun, May 08, 2005 at 07:31:38PM -0700, Matt Kraai wrote: > > On Mon, May 09, 2005 at 03:03:23AM +0100, Paul Brook wrote: > > > On Monday 09 May 2005 02:26, Matt Kraai wrote: > > > > Howdy, > > > > > > > > The rules for c-objc-common.o, loop-unroll.o, and tree-inline.o > > > > include $(VARRAY_H), which is never defined, in their dependency > > > > lists. The rest of the targets that depend on varray.h include > > > > varray.h in their dependency list. > > > > > > > > varray.h includes machmode.h, system.h, coretypes.h, and tm.h, so > > > > Makefile.in should define and use VARRAY_H, right? > > > > > > Already one step ahead of you :-) > > > > > > 2005-05-07 Paul Brook <[EMAIL PROTECTED]> > > > > > > * Makefile.in: Fix dependencies. > > > (GCOV_IO_H, VARRAY_H): Set. > > > > Great. > > The dependencies for the rules for build/genautomata.o, > build/varray.o, and gtype-desc.o still include varray.h instead of > $(VARRAY_H). Is this on purpose? If so, why? That's a oversight. My dependency checking script obviously doesn't check those entries. Paul
Re: GCC 4.1: Buildable on GHz machines only?
On Tuesday 17 May 2005 20:27, Marcin Dalecki wrote: > On 2005-05-17, at 11:29, Richard Earnshaw wrote: > > On Tue, 2005-05-17 at 01:59, Steven Bosscher wrote: > >> No, I just don't build gfortran as a cross. There are many reasons > >> why this is a bad idea anyway. > > > > Such as? > > The dependence on external packages which don't cross compile well > for example. What external dependencies? gfortran does not require any target libraries other than the standard C library. It does require gmp/mpfr on the host, but in most cases the host is native, and they are dead easy to cross compile anyway. Paul
Re: libgcc_s.so.1 exception handling behaviour depending on glibc version
On Wednesday 18 May 2005 21:33, Mike Hearn wrote: > On Wed, 18 May 2005 10:05:34 -0700, Dan Kegel wrote: > > No hacks needed; you just have to embrace reality. > > The reality is that 95% of computers run Windows which is very good at > supporting developers who distribute binaries in this way. On Linux > there's all kinds of gotchas you just Have To Know which is silly and > unproductive - worse, people only find out about this stuff _after_ they > get burned by it. Rubbish. You've obviously never tried to install two third party windows applications that require two different revisions of msvcrt.dll, or even worse two random versions of an OCX control. In my experience most windows applications work because they're either statically linked, or ship with a copy of every single library they need. Paul
Re: 'jules' locking libstdc++-v3 for > 15 minutes!
On Friday 20 May 2005 16:05, Paolo Carlini wrote: > Hi, > > I have been waiting for > 15 minutes for 'jules' to unlock the library: > how is this even possible? Are there operations taking *so* much time? Tagging a branch. See previous discussions about moving to Subversion. I believe this is currently blocked on arrival of new hardware for gcc.gnu.org. > Is there something I can do in such cases? You've just got to wait until it finishes. Paul
Re: GCC and Floating-Point (A proposal)
On Thursday 26 May 2005 14:25, Scott Robert Ladd wrote: > Scott Robert Ladd <[EMAIL PROTECTED]> wrote: > >>May I be so bold as to suggest that -funsafe-math-optimizations be > >>reduced in scope to perform exactly what it's name implies: > >>transformations that may slightly alter the meanding of code. Then move > >>the use of hardware intrinsics to a new -fhardware-math switch. > > Richard Guenther wrote: > > I think the other options implied by -ffast-math apart from > > -funsafe-math-optimizations should (and do?) enable the use of > > hardware intrinsics already. It's only that some of the optimzations > > guarded by -funsafe-math-optimizations could be applied in general. > > A good start may be to enumerate the transformations done on a > > Wiki page and list the flags it is guarded with. > > Unless I've missed something obvious, -funsafe-math-optimizations alone > enables most hardware floating-point intrinsics -- on x86_64 and x86, at > least --. For example, consider a simple line of code that takes the > sine of a constant: I thought the x86 sin/cos intrinsics were unsafe. ie. they don't gave accurate results in all cases. Paul
Re: What is wrong with Bugzilla? [Was: Re: GCC and Floating-Point]
> Lets try to get a copy of gcc. Firstly I see something in the top-left > marked "releases". I click on it. It doesn't mention 4.0, Fair point. This needs fixing. > and despite reasonable attempts I see no sign of code. Huh? The first paragraph on that page is "Source code for GCC releases may be downloaded from our " The following paragraph clearly states that this is source code, and link to the page with binaries on. It even says "Important:". Furthermore the title of that section is "Download" I don't see how you could possibly have missed this. Paul
Re: Ada is broken in a clean directory
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". Paul
Re: GCC 4.0.1 RC3
On Sunday 03 July 2005 19:21, 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. arm-none-elf results are ok. No new regression from 4.0.0. http://gcc.gnu.org/ml/gcc-testresults/2005-07/msg00254.html Paul
Re: Overflow in Fortran (was: Where does the C standard describe overflow of signed integers?)
On Monday 11 July 2005 15:58, Nicholas Nethercote wrote: > Also, does anyone know what the required behaviour for Fortran integers is > on overflow? Section 7.1.7 "Evaluation of operation" "The evaluation of any numeric operation whose result is not defined by the arithmetic used by the processor[1] is prohibited" Section 13.7.1 "Models for integer and real data" The model set for integer i is defined by: [sign + magnitude] ie. overflow is not defined, and we can do whatever the hell we want. Paul [1] In this context "processor" means language processor, ie. a combination the compiler, OS and target hardware.
Re: Function Inlining for FORTRAN
On Wednesday 20 July 2005 15:35, Canqun Yang wrote:
> Hi, all
>
> Function inlining for FORTRAN programs always fails.
Not entirely true. Inlining of contained procedures works fine (or it did last
time I checked). This should include inlining of siblings within a module.
> If no one engages in it, I will give a try. Would you please give me
> some clues?
The problem is that each top level program unit (PU)[1] is compiled
separately. Each PU has it's own "external" decls for all function calls,
even if the function happens to be in the same function. Thus each PU is an
isolated self-contained tree structure, and the callgraph doesn't know the
definition and declaration are actually the same thing.
Basically what you need to do is parse the whole file, then start generating
code.
Unfortunately this isn't simple (or it would have been fixed already!).
Unlike C Fortran doesn't have file-level scope. It makes absolutely no
difference whether two procedures are in the same file, or in different
files. You get all the problems that multifile IPA in C experiences within a
single Fortran file.
The biggest problem is type consistency and aliasing. Consider the following
example:
subroutine a(p)
type t
integer :: t1
end type
type(t) :: p
p%t1 = 42
end subroutine
subroutine b
type u
integer :: u1
end type
type (u) :: q
call a(q)
print * q%u1
end subroutine
Here you have two different derived types which are actually the same derived
types. To make unit-at-a-time work (ie. inlining) you need to either
(a) Replace all occurrences of one type with the other
(b) Tell the compiler that the two types alias, and fixup the types with
explicit casts at any interfaces.
Ideally we'd do (a), but I don't think doing that is practical, and might not
even be possible. I think it would require fairly major hacking of the whole
frontend.
Which leaves (b).
Currently the high-level flow is something like:
- Parse and resolve the PU. This is basically everything before
gfc_generate_code.
- Call gfc_generate_code (or gfc_generate_module_code) to generate code for
that PU.
- Throw away the PU.
- Repeat for each function.
To implement (b) this needs to be changed to:
- Do everything up until gfc_generate{,_module}_code as normal.
- Save the results somewhere and repeat for each PU.
- Identify calls for procedures for which we have definitions, and link them
together somehow. It 's probably worth maintaining some sort of global symbol
table and building these associations incrementally during resolution.
- Generate global DECLs for all PU. Something similar to
gfc_create_function_decl. Probably also generate global DECLs for external
routines.
- Generate common blocks. This may simplify the existing code because we have
all definitions before we start generating DECLs.
- Generate code for each PU. This is more-or-less the same as the current code
except function calls may need explicit typecasts to accommodate type
mismatches described above.
- Tweak aliasing information so this type mismatching doesn't generate bad
code.
I believe Steven Bosscher had a go at implementing this, but never got it to
work properly.
Paul
[1] A top level Program Unit is a file-level subroutine, function, program or
module. If a PU has contained procedures these procedures and the parent
procedure constitute a single PU.
Re: Function inlining for FORTRAN
On Wednesday 20 July 2005 16:52, Joost VandeVondele wrote: > Hi, > > I don't think Paul's example is completely correct, I've created PR22571 > with some more info. Ah, this makes thing somewhat simpler. For some reason I though my example was legal. I think this makes it possible to implement my option (a). Ie. use the same type for all derived types that are "the same". This basically means where we create global function DECLs we also want to create global type declarations for derived types, and the type munging of function arguments becomes a no-op. Some trickey may still be needed for modules, but that's a slightly different issue. Paul
Re: Function Inlining for FORTRAN
> > The biggest problem is type consistency and aliasing. Consider the > > following > > I have several FORTRAN 77 programs. After inlining the small functions in > them by hand, they made a great performance improvements. So I need a trial > implementation of function inlining to verify the effectiveness of it. > > Now, my question is: If we just take the FORTRAN 77 syntax into account (no > derived types, no complex aliasing), may it be simpler to implement > function inlining for FORTRAN 77. Maybe, but gfortran is a fortran 95 compiler so this is not an acceptable solution. Paul
Re: Inserting a call statement
On Wednesday 27 July 2005 17:33, drizzle drizzle wrote:
> Hi
> I am trying to insert a function call "foo" inside the tree list.
>
>
> Inside this particular loop
> for (bsi = bsi_start (bb); !bsi_end_p (bsi); bsi_next (&bsi))
> {
>
> //if a particular condition is satisfied I do the following
>
> tree id = get_identifier ("foo");
> tree t = build_function_type_list (void_type_node,NULL_TREE);
> tree decl = build_decl (FUNCTION_DECL, id, t);
> tree call = build_function_call_expr (decl, NULL);
>bsi_insert_before(&bsi,call,BSI_CHAIN_END); // I have tried
> BSI_NEW_STMT
>
>
> }
>
>
> Although the node is created properly, an assertion in
> tree-flow-inline.h fails. Can someone help me identify the issue here.
> i will appreciate that
You don't appear to be recording the FUNCTION_DECL anywhere, which probably
means cgraph doesn't know about it.
Paul
Re: Ada character types : tree code and DW_AT_encoding
> A possible way to solve this problem is to add a single-bit flag to > INTEGER_TYPE nodes that indicates whether this is actually a character > type. Then dwarf2out.c could just check the flag to determine what > debug info to emit. It looks like we have a number of flag bits that > aren't being used in type nodes. This is much better than trying to do > string matches against type names to determine what is a character type. We already have TYPE_STRING_FLAG used on array types. Maybe it would it make sense to use that? Paul
Re: DCE eliminating valid statement for ACATS c34007p
> But secondly, why make that restriction at all? Suppose I have a function > to which a language semantics requires passing by reference. Now suppose > the operand is "a + b". Why not just make an ADDR_EXPR of the PLUS_EXPR? > > Sure, the front end *could* make a temporary, but the gimplifier has all > the logic already to do that, so why shouldn't it? > > The whole point of the gimplifier is to avoid making too many restrictions > on what are valid trees: it's GIMPLE where we want to make those > restrictions. It seems very duplicative to me to say that the process of > creating temporaries for certain expressable trees is the job of the front > end and for others is the job of the gimplifier? Why not just be > consistent and say it's the gimplifier's job to do all of them? But only where the semantics are well defined. I can think of several different possible semantics for talking the address of arbitrary things. Consider "foo(&(a+b), &(a+b))" Is it ok to pass the same address for both arguments? Should the location pointed to be modifiable or readonly? IMHO it's best to make things like this explicit. That way there's no disagreement over which language defined semantics we should be using. Paul
Re: DCE eliminating valid statement for ACATS c34007p
> But only where the semantics are well defined. I can think of several > different possible semantics for talking the address of arbitrary > things. > > The counter-argument is that it can used when the semantics need *not* be > well-defined, in other words, where you're saying you don't care. We've seen many times before, often with the ADA frontend, that "don't care" is often not what the language frontend really wants. Different people have different ideas about exactly which subset of semantics are required, and which are allowed to be changed. > IMHO it's best to make things like this explicit. That way there's no > disagreement over which language defined semantics we should be using. > > What about case like taking an ADDR_EXPR of a COMPONENT_REF where the > field is a bitfield? Trying to over-specify things can get quite complex > as well. That's my point. We shouldn't be trying to support this sort of language specific weirdness in generic code. Unless you have bit-addressable memory/pointers and arbitrary bit-sized types, taking the address of a bitfield makes no sense. It's up to the frontend to transform it into something sane. Paul
Re: a question about floating point register
On Friday 09 September 2005 02:51, Eric Fisher wrote: > Hello, > > Can anyone give me some suggestions about floating point implemention. > My new target doesn't have floating point register. But must I implement > the floating point operantion? Libgcc always fails on _floatdifi.o. But how > can I implement them? See e.g. gcc/config/mips/t-mips Paul
Re: lib2funcs and fpbit both rely on each other
On Thursday 15 September 2005 10:59, Eric Fisher wrote: > Hello, > > When building Libgcc with new porting gcc, _floatdidf.o failed for > undefined symbol > _floatsidf. I've been told that _floatsidf is in fpbit.c as > _si_to_df.o. Then I modified the libgcc.mk and firstly build fpbit. > But _pack_df.o failed for undefined symbol > _ashldi3.o which is in libgcc2.c. It seems that they are rely on both > each other. Sounds like your assembler is broken. Building libgcc shouldn't require linking anything, so you should never get undefined symbols when building libgcc.a. Paul
Re: GCC 4.0.2 RC1 Available
On Wednesday 14 September 2005 16:13, Mark Mitchell wrote: > GCC 4.0.2 RC1 is now available from FTP mirrors of gcc.gnu.org arm-none-elf results look good: http://gcc.gnu.org/ml/gcc-testresults/2005-09/msg00780.html Paul
Re: GCC 4.0.2 RC2
> GCC 4.0.2 RC2 is now available here Sill ok on arm-none-elf: http://gcc.gnu.org/ml/gcc-testresults/2005-09/msg00938.html Paul
Re: No effect of -fshort-enums..is it a bug
On Thursday 22 September 2005 19:31, Daniel Jacobowitz wrote: > On Thu, Sep 22, 2005 at 12:50:39PM -0400, Robert Dewar wrote: > > of course, but the behavior of a compiler with a special implementation > > dependent switch is not specified by the standard! Switches can do any > > amount of violence to the standard you like, the only requirement is > > that there be a defined set of switches which gives standard defined > > semantics. > > Except that the point I've been trying to make for the last day is that > -fshort-enums does no damage to the standard. At least for C99. It's also worth noting that -fshort-enums is the default on some targets, as required by the platform ABI. Paul
Re: Insn for direct increment of memory?
On Saturday 24 September 2005 23:35, Greg McGary wrote: > I'm working with a machine that has a memory-increment insn. It's a > network-processor performance hack that allows no-latency accumulation > of statistical counters. The insn sends the increment and address to > the memory controller which does the add, avoiding the usual > long-latency read-increment-write cycle. I would like to persuade GCC > to emit this insn. Maybe it could be done in the combiner? Do any > GCC ports have this feature? It should just work if you have the appropriate movsi pattern/alternative. m68k has an memory-increment instruction (aka add :-). Paul
Re: Insn for direct increment of memory?
On Saturday 24 September 2005 23:52, Paul Brook wrote: > On Saturday 24 September 2005 23:35, Greg McGary wrote: > > I'm working with a machine that has a memory-increment insn. It's a > > network-processor performance hack that allows no-latency accumulation > > of statistical counters. The insn sends the increment and address to > > the memory controller which does the add, avoiding the usual > > long-latency read-increment-write cycle. I would like to persuade GCC > > to emit this insn. Maybe it could be done in the combiner? Do any > > GCC ports have this feature? > > It should just work if you have the appropriate movsi pattern/alternative. I mean addsi3 of course. Paul
Re: Updating a subversion directory?
On Tuesday 18 October 2005 18:44, Steve Kargl wrote: > So, I finally get a copy of mainline, yesterday. As user > [EMAIL PROTECTED], I did > > cd ~/gcc > svn co svn+ssh://[EMAIL PROTECTED]/svn/gcc/trunk > > Now, I want to update this to the latest sources. The wiki > says "svn update" works exactly like "cvs update". Well, > this does not appear to be the case. > > cd trunk > svn update > Enter passphrase for key '/mnt1/sgk/.ssh/id_rsa': > At revision 105364. > > Inspecton of gcc/fortran/ChangeLog shows that it > has not been updated, which can be verified via It's working as expected. The svn repository isn't 'live' yet, just just a snapshot for a week or so ago. Paul
Re: Linking of object files from different compilers for ARM
On Friday 14 October 2005 07:49, Yaroslav Karulin wrote: >Hello! > >I have two files: foo.c and main.c. foo.c is compiled with RVTC 2.2 > compiler. main.c is compiled with gcc compiler (configured with > --target=arm-elf). I cannot link them together using gcc linker. >But it's possible to link files if I use CodeSourcery version of gcc. > CodeSourcery guys writes that they have added full EABI support and hope > to submit it to the gcc 4.1. >So, the question is what's the difference between CodeSourcery's > version of gcc and FSF version? And is EABI support really submitted to > the gcc 4.1? The CodeSourcery releases are made off csl-arm-branch in CVS. I think all the EABI changes are now in 4.1. You need to configure for the arm-eabi target, not arm-elf. Note that theres no such thing as the "gcc linker". You probably mean GNU binutils/ld. Paul
Re: Subversion and firewalls question
On Tuesday 18 October 2005 23:34, Ian Lance Taylor wrote: > Steve Ellcey <[EMAIL PROTECTED]> writes: > > Anyone have advice on how to get subversion working through a corporate > > firewall. > > In case it helps, any connection to port 443 on > sshproxy.sourceware.org is forwarded to port 22 on > sourceware.org/gcc.gnu.org. This can help making SSH connections to > gcc.gnu.org through a firewall, if your firewall permits outgoing > connections to port 443 (which is https). This combined with corkscrew (http://www.agroman.net/corkscrew) should be sufficient to get through any firewall via a http[s] proxy. Paul
Re: A couple more subversion notes
On Thursday 20 October 2005 18:34, Richard Kenner wrote: > Ideally, once this discussion is over, some kind subversion expert > will update the wiki to contain the answers to the questions raised on this > thread. > > Ideally once this discussion is over, the information will be in real > documentation, not just the wiki ... There already IS real documentation, and it's very good. http://svnbook.red-bean.com/ The online help provided by "svn help" is also very good as a quick reference. Paul
Re: Is the test svn repository working fine?
> >paolo:~/test-svn> svn co svn+ssh://[EMAIL PROTECTED]/svn/gcc/trunk > >Enter passphrase for RSA key '[EMAIL PROTECTED]': > >Enter passphrase for RSA key '[EMAIL PROTECTED]': > > This is *totally* crazy: if I enter the password *3* times, then it works! > > If someone is curious and wants more debug info to figure out how this > could even be possible, just let me know... See previous threads about how svn makes multiple connections to the server, each requiring authorization. Paul
Re: Is the test svn repository working fine?
On Friday 21 October 2005 15:59, Paolo Carlini wrote: > Paul Brook wrote: > >See previous threads about how svn makes multiple connections to the > > server, each requiring authorization. > > Argh! I glanced briefly over those threads... > > While you are at it, are you willing to summarize the solution for this > annoyance and/or point me to the relevant subthread? Use ssh-agent(1) and/or ssh connection caching http://gcc.gnu.org/wiki/SSH%20connection%20caching Paul
Re: Is the test svn repository working fine?
> >See previous threads about how svn makes multiple connections to the > > server, each requiring authorization. > > I guess it is the SSH connection caching thing?!? I tought it was for > performance not also for finger saving... ;) I think it's configurable via the ControlMaster option. The default is to allow secondary connections without asking for a password. Paul
Re: Vectorizing HIRLAM 4: complicated access patterns examined.
> When compiling for 64bit, there is an extra cast: > In the 64bit case however, the vectorizer dumps show that the > access-function returned for the index to array b is much more > compilcated > - the dataref analyzer doesn't seem to be able to extract the > evolution/step in this case, and concludes that the access is > non-consecutive: > ... > > Ah yes, this was a well-known issue in the days long before vectorization > ... > > In 1997, Richard Henderson hacked g77 to generate 64-bit array indices > on 64-bit machines to prevent these casts, which inhibited all sorts > of run-of-the-mill induction variable analysis ... > > This is probably quite invasive. I thought we'd also fixed this in gfortran. Array indices should be 64-bit (aka gfc_array_index_type) on 64-bit targets. I guess you could also try -fdefault-integer-8, though that might break/pessimize other things. Paul
