Re: Apple, iPhone, and GPLv3 troubles
1) This is offtopic. Yeah, but I want to bring this up because I can tell it is affecting GCC development. From http://gcc.gnu.org/ml/gcc/2008-02/msg00523.html: If someone steps forward, are you allowed to follow the patches list We can't read the patches nor gcc list. and give feedback and/or approve patches for new contributors? I assume this is possible since you helped out with objc++ review for me just recently. Only because I was cced on it. From http://gcc.gnu.org/ml/gcc/2008-02/msg00516.html: Are current Darwin maintainers working on fixing anything in the FSF sources? Currently no. The transition to GPL v3 is problematic for us in the short/mid term. :-( Longer term, we'll see how it goes. 2) You didn't say what the problem is. I certainly can't figure it out from the links you posted. Basically, what happened is that Apple created a Tivoized device called the iPhone, and Apple uses GCC (which is now under GPLv3) and Mac OS X on it. Unfortunately, the iPhone is incompatible with GPLv3, if you want more see the link I mentioned.
Re: Apple, iPhone, and GPLv3 troubles
Off-topic, but I feel this is important, since Apple contributed to gcc, and it is licensed under GPLv3 now. The license of GCC does not matter, unless the iPhone includes a copy of GCC's binaries for a recent-enough version. In which case, of course, Apple would be violating the GPLv3 and you should tell the FSF. [offtopic parts rot13'd] V fgvyy ubcr vg pna or fbyirq Jung fubhyq or fbyirq? Npghnyyl, jung pbhyq or fbyirq? OGJ, gur TCYi2 unf abar bs gur pynhfrf gung pnhfr gur gebhoyr Nccyr vf snpvat jvgu gur TCYi3 naq gur vCubar, fb vg vf BX. Fbzr znl guvax gung gur TCYi3 vf gur bar gung vf BX... Naljnl, va pnfr lbh jrera'g njner, vg'f abg whfg gur TCYi3 gung vf nssrpgrq. Orpnhfr bs gur AQN gurl fubiry qbja lbhe guebng jura lbh qbjaybnq gur FQX, Nccyr rssrpgviryl qrpvqrq gb ybpx nal xvaq bs bcra fbhepr fbsgjner (abg whfg serr fbsgjner) bhg bs gur vCubar. Ab ovt qrny, gung zrnaf gung V jba'g jevgr cebtenzf sbe gur vCubar V qba'g bja. Paolo
Re: Apple, iPhone, and GPLv3 troubles
Yuhong Bao wrote: and Apple uses GCC (which is now under GPLv3) and Mac OS X on it. Unfortunately, the iPhone is incompatible with GPLv3, if you want more see the link I mentioned. Apple does not use a GPLv3 version of GCC. All GPL sources used in the iPhone, are, as far as I know, available at http://www.opensource.apple.com/darwinsource/iPhone2.1/ (perhaps also other locations at http://www.opensource.apple.com/darwinsource). If there are sources that you feel are missing, filing a bug at http://bugreporter.apple.com is probably your best bet. And, yes, I feel bad for replying to the list on this when it has already been stated that it is off-topic. Peter -- Peter O'Gorman http://pogma.com
Re: Adding to G++: Adding a warning on throwing unspecified exceptions.
Thanks for all the links. I knew there were people wanting this but I didn't quite get how big an issue it was. Brain Dessent wrote: You're essentially trusting that all exception specifiers for every function in the program and *all* library code are always present and always correct which is a huge leap of faith that I don't think is supported by reality. I agree that it won't be very useful initially due to lots of third party code like boost neither defining nor adhering exception restrictions 100% of the time (STL may be guilty also). However, this is a catch 22. Why not provide the mechanism for verifying exception specifications so that these libraries can, in future, become fully compliant? It won't take much work, especially when you can get a warning telling you exactly what you need to change, and the only thing you need to do 99% of the time is add throw() clauses to definitions and declarations. I bet you could get boost STL compliant within a week even if they had 0 throw() clauses to begin with. Brain Dessent wrote: The general consensus is that doing this at compile time cannot give you anything useful, because the compiler can only see one compilation unit at a time and so the only thing it can know of all the downstream functions that are in other CUs is what is provided in the exception specifiers of the prototypes. So, once the other CUs adhere to their prototype exception specifiers, this becomes OK. I definately intend all of my own CUs to adhere. Also, you rely on CUs doing what they say in all other means (eg not modifying const-passed references), why not rely on their exception specifiers as long as they say you can. And if only some (ie your own) CUs adhere, that's by no means worse than none adhering (as long as you are aware that some don't). You should certainly look at EDoc++, mentioned in the above threads. http://edoc.sourceforge.net/ This is definitely interesting, however our goals are a bit different. EDoc++ is about checking that there is no chance a thrown that actually exists in code can propogate to somewhere where it will terminate the app due to being unhandled. It's not about enforcing code requirements. For example, foo() throw() can call bar() throw(zug) as long as it doesn't actually throw a zug, or call anything that does. I would like an environment where the above example is considered poor practice. One thing I read there that concerned me was when it was said that some compilers do pessimizations such as not inlining functions with throw clauses or placing try/catch blocks around calls to these. I hope that these compilers aren't mainstream. Also, I don't think that consideration of current bad implementations should factor into the decision. If people decide to use exception specifications more these compilers will either get fixed or become slower. So overall: - Lots of people request it (for good reasons or bad). Even bad reasons mean there's an advantage from providing this as an option, ie showing that it doesn't do what they want. - Nobody has yet shown me any fundamental problems with implementing this, apart from my typedefs of function pointers not being allowed exception specifications which, while annoying, can be avoided. - It helps code comply with what it says (if you read the throw() clause in what seems to be its spirit: as an indication of what may be thrown). - It's fully optional, and off by default. - The only real issue is that it will complain about third party code that doesn't yet comply. But by this same token this helps third party code become compliant if the authors desire it to be. There's also the possibility of adding a modification that could ignore calls to functions declared inside a whitelist of headers like vector to further reduce this. - GCC probably doesn't do the above pessimizations (I guess I'll have to look into this). Where's the downside?
Re: Adding to G++: Adding a warning on throwing unspecified exceptions.
I agree that it won't be very useful initially due to lots of third party code like boost neither defining nor adhering exception restrictions 100% of the time (STL may be guilty also). However, this is a catch 22. Why not provide the mechanism for verifying exception specifications so that these libraries can, in future, become fully compliant? It won't take much work, especially when you can get a warning telling you exactly what you need to change, and the only thing you need to do 99% of the time is add throw() clauses to definitions and declarations. I bet you could get boost STL compliant within a week even if they had 0 throw() clauses to begin with. One of the problems i see with this is generic template classes like the STL containers. The author of the template class or container can't know what types of exceptions will be thrown from them, so you must define them as being able to throw all exceptions (which is how they are currently). Then if those containers are used all over the place then you are back to square one. Personally i am starting to see that usage of the exception specifier in C++ is almost useless (I find them a bit more useful with EDoc++ but i still only use them very rarely). I initially thought the same way as you are now, but in the end decided it was necessary to construct a complete list of exceptions that can be thrown before then applying such rules. This is what EDoc++ does. It first calculates all possible exceptions, then it performs all sorts of analysis to enforce things like exception specifiers (and much more). After developing EDoc++, i have also realized how pervasive exceptions can be in C++ code, which works against the sorts of checks that can be done within a single translation unit. I had to go to lengths to provide a suppressions system for EDoc++, simply because almost all code can throw all sorts of exceptions i had never heard of before. A developer generally is not interested in exceptions like: __gnu_cxx::recursive_init. But after writing EDoc++ i found exceptions like this turn up all over the place, though they should not occur in normal operation... With all this said though. If your purpose is to learn more about GCC internals, then i think it would be a good project to undertake to achieve that. You may have to do so though, with the understanding that the maintainers may not choose to accept your patch into the official GCC release. I don't know if they would or not, as i am not a GCC maintainer but it would be worth getting clarification before doing the task. On a slight side note, there is a feature i have been postponing from EDoc++ until the distant future. It is to provide meta-data or code markup which can be used to enforce certain restrictions on code being used. This is primarily of use for defining a contract when writing template code that wants to define a certain exception guarantee. For example, i assume you are familiar with the various guarantees that have been described in literature about exceptions in C++ (if not then it is worth looking up. It sure opened my eyes to writing safer and better code in the presence of exceptions). To make some generic container satisfy the strong guarantee will require certain restrictions on the type used to instantiate the template. A good example of this is that the destructor for the type must not throw an exception. For a given generic implementation, there may be additional restrictions as well. If these restrictions are not met, then the container will no longer meet the strong guarantee. I wish to define a method of marking up source code such that those requirements are described inline in the code of the template implementation such that someone who instantiates the template with a particular type can then run EDoc++ over their code and be warned when that particular instantiation may break the requirements. Anyhow, this is a preliminary idea and i just don't have the time now to look at implementing it. It will likely require changes to the C++ parser and front end to insert extra nodes into the tree for this markup. I am also not sure if others would accept such a modification into the official GCC release unless it was generic enough to be used for other purposes (maybe such as providing optimization hints for certain segments of code or other forms of markup). Thanks, Brendon.
Re: char* problems
I have no gcc 4.1.2 at hand. but I just had a try with gcc-4.1.0 and gcc-4.2.0 which compiled a simple testcase with no errors or warnings. additionally, I had a try with some other compiler than gcc to compile it. a warning issued. I think it's possibly too strict of gcc raising a error on sch case. any options that you added when compiling? 2008/9/15 Douglas Gemignani [EMAIL PROTECTED]: Dear friends, I have serious issues when compiling using gcc 4.1.2, everytime i try to pass a unsigned char* to a function that receives char*, i got errors, it also happens when passing const char* to char* or unsigned char* functions. This is really annoying and the code is a working one in other system, i would like to foce the compilation, i already tryed to use the following flags: -fno-const-strings -Wwrite-strings -funsigned-char but none of them worked. Is there something that i can tell to gcc, other than making casts all over the code? Thanks []s Douglas -- Best wishes! Yours, Lijuan Hai _ _ (_)(_) (,,) =()= ((__)\ _|L\___/
Apple-employed maintainers (was Re: Apple, iPhone, and GPLv3 troubles)
Peter O'Gorman wrote: Yuhong Bao wrote: and Apple uses GCC (which is now under GPLv3) and Mac OS X on it. Unfortunately, the iPhone is incompatible with GPLv3, if you want more see the link I mentioned. Apple does not use a GPLv3 version of GCC. Ah, actually I think I now see the OP's point. Apple is scared of the GPLv3 because the iPhone might violate it, so they are not contributing to anything that falls under the GPLv3. It is indeed in-topic. There are four Darwin maintainers listed in MAINTAINERS: darwin port Dale Johannesen [EMAIL PROTECTED] darwin port Mike Stump [EMAIL PROTECTED] darwin port Eric Christopher[EMAIL PROTECTED] darwin port Stan Shebs [EMAIL PROTECTED] and three of them are not allowed to read the GCC patches mailing list. They might do something if CCed, but not necessarily so. Same for Objective-C/C++: objective-c/c++ Mike Stump [EMAIL PROTECTED] objective-c/c++ Stan Shebs [EMAIL PROTECTED] Now I wonder: 1) does it make sense to keep a maintainer category that is known to be inactive? 2) who should then get maintainership of darwin? note that there are some patches for darwin like this one: http://article.gmane.org/gmane.comp.gcc.patches/172498 It's sad, but I think that there is need for the SC to take action on this. Paolo
Re: Adding to G++: Adding a warning on throwing unspecified exceptions.
Brendon Costa said:
The author of the template class or container can't know
what types of exceptions will be thrown from them, so you must define
them as being able to throw all exceptions (which is how they are
currently).
Ouch, you have a point. But couldn't you put this round the other way.
Place the onus on the user of the template to comply with the
exception guarantees inside the template. Unfortunately that would
likely cause problems with some existing code.
I'm trying to think whether this would actually prevent well-designed
future code. All I can really come up with so far is copying a vector
of vectors and having bad_alloc thrown during a copy constructor
partway through, but I think bad_alloc should be allowed. Other
things, such as constructing a vector of N thread objects that can
throw on failed thread creation, might be better off undergoing a
redesign.
In other words, would you gain more from a tight exception
specification than you'd lose by not being able to do this?
Another thought that could be a workaround: Is it possible to do
anything like this?
===
template typename E
int foo() throw(E) {}
===
IE using a template parameter to specify what can be thrown. (Esp with
a C++0X variadic).
Sorry I won't be near a compiler to test this for many an hour, if I
test it and can get it working I'll reply.
Re: Apple-employed maintainers (was Re: Apple, iPhone, and GPLv3 troubles)
On Wed, Sep 24, 2008 at 11:47:18AM +0200, Paolo Bonzini wrote: Peter O'Gorman wrote: Yuhong Bao wrote: and Apple uses GCC (which is now under GPLv3) and Mac OS X on it. Unfortunately, the iPhone is incompatible with GPLv3, if you want more see the link I mentioned. Apple does not use a GPLv3 version of GCC. Ah, actually I think I now see the OP's point. Apple is scared of the GPLv3 because the iPhone might violate it, so they are not contributing to anything that falls under the GPLv3. It is indeed in-topic. There are four Darwin maintainers listed in MAINTAINERS: darwin port Dale Johannesen [EMAIL PROTECTED] darwin port Mike Stump [EMAIL PROTECTED] darwin port Eric Christopher[EMAIL PROTECTED] darwin port Stan Shebs [EMAIL PROTECTED] and three of them are not allowed to read the GCC patches mailing list. They might do something if CCed, but not necessarily so. Same for Objective-C/C++: objective-c/c++ Mike Stump [EMAIL PROTECTED] objective-c/c++ Stan Shebs [EMAIL PROTECTED] Now I wonder: 1) does it make sense to keep a maintainer category that is known to be inactive? 2) who should then get maintainership of darwin? note that there are some patches for darwin like this one: http://article.gmane.org/gmane.comp.gcc.patches/172498 It's sad, but I think that there is need for the SC to take action on this. Paolo Well at least that explains their total inactivity in the last year. Is Dale the one still allowed to read the gcc-patches mailing list? I recall that he posted in the last year that he would be more active in gcc (but I can't find that message at the moment). I had attributed the fact that they were not active to the emphasis on llvm at Apple. However if GPLv3 is such a huge issue at Apple, it does make one wonder if llvm will ever see a gcc front-end newer than the current 4.2 one. Jack
Re: Apple, iPhone, and GPLv3 troubles
Yuhong Bao [EMAIL PROTECTED] writes: 1) This is offtopic. Yeah, but I want to bring this up because I can tell it is affecting GCC development. From http://gcc.gnu.org/ml/gcc/2008-02/msg00523.html: If someone steps forward, are you allowed to follow the patches list We can't read the patches nor gcc list. and give feedback and/or approve patches for new contributors? I assume this is possible since you helped out with objc++ review for me just recently. Only because I was cced on it. From http://gcc.gnu.org/ml/gcc/2008-02/msg00516.html: Are current Darwin maintainers working on fixing anything in the FSF sources? Currently no. The transition to GPL v3 is problematic for us in the short/mid term. :-( Longer term, we'll see how it goes. Apple's dislike of GPLv3 is a problem for gcc, yes. However, Apple is moving to a new free compiler, LLVM, so they have little incentive to fix the problem. My understanding of Apple's current position is that they won't take any action until they see the final version of the gcc runtime license. gcc's runtime libraries have not yet been updated to GPLv3, because the FSF has not yet settled on the final version of the appropriate license to use for those libraries (yes, this has taken a ridiculously long time, largely because the FSF is trying to get the plugin license right at the same time). Until the runtime library licenses have been updated, there is little point in discussing Apple's future contributions to gcc. Since Apple is moving to a new compiler, it is likely that Apple will have negligible future contributions to gcc in any case, though some individuals employed by Apple may be able to once again contribute on their own time. 2) You didn't say what the problem is. I certainly can't figure it out from the links you posted. Basically, what happened is that Apple created a Tivoized device called the iPhone, and Apple uses GCC (which is now under GPLv3) and Mac OS X on it. Unfortunately, the iPhone is incompatible with GPLv3, if you want more see the link I mentioned. Using gcc to compile your code does not impose any licensing requirements on that code. Many people use gcc to create proprietary software. This is understood and is in fact desirable. This is not a problem to be solved. Morevoer, as Peter pointed out, GPLv3 is a total red herring here, since Apple has very carefully avoided any use of it. Not that gcc being under GPLv3 makes any difference whatsoever, as the iPhone would still be permitted regardless. Ian
Re: Apple-employed maintainers (was Re: Apple, iPhone, and GPLv3 troubles)
Well at least that explains their total inactivity in the last year. Is Dale the one still allowed to read the gcc-patches mailing list? No, that would be Stan just because he's not at Apple. It must be said also that Mike Stump accepted to review/discuss Darwin/ObjC patches that he was CCed on, but most people don't know that they need to do so. As a side note, Mike also wrote this last February: The SC knows of the issue Still, after six months it would be nice to have a clearer idea of what will happen with respect to Darwin/ObjC, especially since the previous statement (which I suppose was as clear as Mike could do) was buried under an unrelated thread. Paolo
Re: Apple-employed maintainers (was Re: Apple, iPhone, and GPLv3 troubles)
Paolo Bonzini [EMAIL PROTECTED] writes: Ah, actually I think I now see the OP's point. Apple is scared of the GPLv3 because the iPhone might violate it, so they are not contributing to anything that falls under the GPLv3. ... 1) does it make sense to keep a maintainer category that is known to be inactive? 2) who should then get maintainership of darwin? note that there are some patches for darwin like this one: http://article.gmane.org/gmane.comp.gcc.patches/172498 It's sad, but I think that there is need for the SC to take action on this. I personally don't think there is any need to remove them as maintainers until the FSF finally produces the GPLv3 version of the runtime library license. At that point Apple will be out of excuses, and will have to finally decide in or out on future gcc developmnt. It's worth noting that in a larger sense, Apple is simply not interested in contributing to gcc. If they were interested, they would contribute. They (for some version of they) are using GPLv3 as a tactic to get out of the gcc game while blaming it on us. They have not raised any actual substantial issue with the GPLv3, which is not surprising, since the GPLv3 does not impose any additional requirements on them beyond GPLv2. However, the gcc community can't call them on that until the runtime library license is complete, as its absence is indeed a valid objection. Jack Howarth [EMAIL PROTECTED] writes: However if GPLv3 is such a huge issue at Apple, it does make one wonder if llvm will ever see a gcc front-end newer than the current 4.2 one. The LLVM folks are writing a new frontend anyhow. In the future they presumably plan to stop using the gcc frontend. gcc's code is so tangled anyhow, it's not like using the gcc frontend somehow makes LLVM compile code the same way gcc does. Ian
Re: Apple-employed maintainers (was Re: Apple, iPhone, and GPLv3 troubles)
However if GPLv3 is such a huge issue at Apple, it does make one wonder if llvm will ever see a gcc front-end newer than the current 4.2 one. The LLVM folks are writing a new frontend anyhow. In the future they presumably plan to stop using the gcc frontend. gcc's code is so tangled anyhow, it's not like using the gcc frontend somehow makes LLVM compile code the same way gcc does. I'm quite interested in porting llvm-gcc to gcc head, in order to get better Ada support. Apple isn't planning Ada support in their new compiler (clang) as far as I know :) Duncan. PS: I have no connection with Apple.
Runtime library license, was Re: Apple-employed maintainers (was Re: Apple, iPhone, and GPLv3 troubles)
Ian Lance Taylor wrote:
Paolo Bonzini [EMAIL PROTECTED] writes:
It's sad, but I think that there is need for the SC to take action on this.
I personally don't think there is any need to remove them as
maintainers until the FSF finally produces the GPLv3 version of the
runtime library license. At that point Apple will be out of excuses,
and will have to finally decide in or out on future gcc development.
I am probably not alone to be extremely interested in understanding more
clearly what is happening on the runtime library license side,
especially with relation to plugins.
The recent thread http://gcc.gnu.org/ml/gcc/2008-09/msg00292.html
Defining a common plugin machinery is particularly concerned with this
issue (of runtime library license). I'm guessing that since Diego
Novillo asked something, he was expecting/dreaming/knowing? about some
evolution on this.
Is it top secret information only available to some few members of the
Steering Committee, or is some information sharable on this list? Just
knowing that indeed a runtime library license will be finalized before
Christmas (ie in 2008) and that GPL-ed plugins will be somehow blessed
by the SC (or is it the FSF) will be a big relief.
Is something happening on runtime library license, or is there some
unexpected issue which affects existing branches experimenting plugins
(e.g. MELT)?
The only thing I know about runtime library license is the stuff I heard
and read at the june 2008 GCC summit, and I am guessing that a lot of
things happened since. IIRC, I remember having heard in june 2008 that
we have only months, not years, to wait (I did not understood exactly
for what, but it was runtime licence related).
In particular, if dlopen-ing GPL-ed (and even FSF copyright-ed) code is
still a taboo in GCC, I would be glad to be informed...
[I'm writing in some proposals, to get money to work on GCC, that
plugins are indeed appearing in GCC; I hope that I am not entirely wrong]
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basileatstarynkevitchdotnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: Runtime library license, was Re: Apple-employed maintainers (was Re: Apple, iPhone, and GPLv3 troubles)
Basile STARYNKEVITCH [EMAIL PROTECTED] writes: Is it top secret information only available to some few members of the Steering Committee, or is some information sharable on this list? Just knowing that indeed a runtime library license will be finalized before Christmas (ie in 2008) and that GPL-ed plugins will be somehow blessed by the SC (or is it the FSF) will be a big relief. I have no additional information. I just want to make the point that these issues involve lawyers, and they involve RMS, and it's not a major priority for any of them. It takes time. It's frustrating. But it is most likely not the case that secret negotiations are happening. It is far more likely that nothing is happening at all. There is a simple technique which anybody is free to use to make this happen much faster: make a large donation to the SFLC and/or the FSF, contingent on this issue being finished. In the absence of that, it will happen in the time that people have available to work on it. Ian
Mainline bootstrap failure on powerpc64-darwin, but looks generic
I'm just not having any luck bootstrapping this thing ... http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37639
Re: Apple-employed maintainers (was Re: Apple, iPhone, and GPLv3 troubles)
On Wed, Sep 24, 2008 at 04:33:35PM +0200, Paolo Bonzini wrote: Well at least that explains their total inactivity in the last year. Is Dale the one still allowed to read the gcc-patches mailing list? No, that would be Stan just because he's not at Apple. It must be said also that Mike Stump accepted to review/discuss Darwin/ObjC patches that he was CCed on, but most people don't know that they need to do so. As a side note, Mike also wrote this last February: The SC knows of the issue Still, after six months it would be nice to have a clearer idea of what will happen with respect to Darwin/ObjC, especially since the previous statement (which I suppose was as clear as Mike could do) was buried under an unrelated thread. Paolo Do we know if Apple still intends to update the ObjC in FSF gcc to v2.0? Jack
Re: Runtime library license, was Re: Apple-employed maintainers (was Re: Apple, iPhone, and GPLv3 troubles)
On Wed, Sep 24, 2008 at 11:26 AM, Ian Lance Taylor [EMAIL PROTECTED] wrote: Basile STARYNKEVITCH [EMAIL PROTECTED] writes: Is it top secret information only available to some few members of the Steering Committee, or is some information sharable on this list? Just knowing that indeed a runtime library license will be finalized before Christmas (ie in 2008) and that GPL-ed plugins will be somehow blessed by the SC (or is it the FSF) will be a big relief. I have no additional information. I just want to make the point that these issues involve lawyers, and they involve RMS, and it's not a major priority for any of them. It takes time. It's frustrating. But it is most likely not the case that secret negotiations are happening. It is far more likely that nothing is happening at all. There is a simple technique which anybody is free to use to make this happen much faster: make a large donation to the SFLC and/or the FSF, contingent on this issue being finished. In the absence of that, it will happen in the time that people have available to work on it. How large is large?
Re: Apple-employed maintainers (was Re: Apple, iPhone, and GPLv3 troubles)
On Sep 24, 2008, at 8:51 AM, Jack Howarth wrote: The SC knows of the issue Still, after six months it would be nice to have a clearer idea of what will happen with respect to Darwin/ObjC, especially since the previous statement (which I suppose was as clear as Mike could do) was buried under an unrelated thread. Paolo Do we know if Apple still intends to update the ObjC in FSF gcc to v2.0? Jack We don't have any short-term plans to do so. However, all the code for ObjC 2.0 and even the new C Blocks feature is available in the llvm-gcc repository. One potential issue is that while Apple has a blanket copyright assignment with the FSF, I don't know whether code in the llvm-gcc repo is auto-assigned to the FSF. -Chris
Re: Apple, iPhone, and GPLv3 troubles
On Sep 24, 2008, at 7:06 AM, Ian Lance Taylor wrote: fix the problem. My understanding of Apple's current position is that they won't take any action until they see the final version of the gcc runtime license. Basically, what happened is that Apple created a Tivoized device called the iPhone, and Apple uses GCC (which is now under GPLv3) and Mac OS X on it. Unfortunately, the iPhone is incompatible with GPLv3, if you want more see the link I mentioned. Using gcc to compile your code does not impose any licensing requirements on that code. I'm not speaking for Apple here, and I am not a lawyer. However, the last draft of the runtime library exception clause (which is quite old by now) imposed licensing restrictions on the executables generated by GCC (due to linked runtime libraries) if you did certain things to the compiler. I'm personally very eager to see the final wording, because the draft I saw (again, which is old and has certainly changed) was extremely aggressive. -Chris
Re: Apple-employed maintainers (was Re: Apple, iPhone, and GPLv3 troubles)
On Sep 24, 2008, at 8:02 AM, Duncan Sands wrote: However if GPLv3 is such a huge issue at Apple, it does make one wonder if llvm will ever see a gcc front-end newer than the current 4.2 one. The LLVM folks are writing a new frontend anyhow. In the future they presumably plan to stop using the gcc frontend. gcc's code is so tangled anyhow, it's not like using the gcc frontend somehow makes LLVM compile code the same way gcc does. I'm quite interested in porting llvm-gcc to gcc head, in order to get better Ada support. As Duncan says here, Apple and the LLVM Project really are separable entities. As a developer on the LLVM Project, I'd love to see a new version of llvm-gcc based on ToT GCC. I'm not sure how technically feasible it is, but it would be even better for future versions of llvm-gcc to be based on the new GCC plugin model. -Chris
Re: Apple, iPhone, and GPLv3 troubles
On Sep 24, 2008, at 10:01 AM, Chris Lattner wrote: requirements on that code. I'm not speaking for Apple here, and I am not a lawyer. However, the last draft of the runtime library exception clause (which is quite old by now) I'm sorry, to be clear, I meant the last draft *that I saw* (which is quite old... -Chris
Re: Apple, iPhone, and GPLv3 troubles
On Wed, Sep 24, 2008 at 10:05:37AM -0700, Chris Lattner wrote: On Sep 24, 2008, at 10:01 AM, Chris Lattner wrote: requirements on that code. I'm not speaking for Apple here, and I am not a lawyer. However, the last draft of the runtime library exception clause (which is quite old by now) I'm sorry, to be clear, I meant the last draft *that I saw* (which is quite old... While I'm not eager to continue this thread, the draft you saw was rejected by pretty much everyone (in particular, the SC pushed back hard) and has been replaced by much narrower language, so I hope that no one panics based on your message.
Re: Runtime library license, was Re: Apple-employed maintainers (was Re: Apple, iPhone, and GPLv3 troubles)
NightStrike [EMAIL PROTECTED] writes: There is a simple technique which anybody is free to use to make this happen much faster: make a large donation to the SFLC and/or the FSF, contingent on this issue being finished. In the absence of that, it will happen in the time that people have available to work on it. How large is large? More than you want to pay personally. Think: enough to hire another staff member to work on it. To be clear, I'm not saying it won't get done. It will get done. But it is in effect like any other volunteer job. Our position with regard to the people who need to do the work is like a gcc user's position with regard to us. Ian
Re: Apple, iPhone, and GPLv3 troubles
Chris Lattner [EMAIL PROTECTED] writes: On Sep 24, 2008, at 7:06 AM, Ian Lance Taylor wrote: fix the problem. My understanding of Apple's current position is that they won't take any action until they see the final version of the gcc runtime license. Basically, what happened is that Apple created a Tivoized device called the iPhone, and Apple uses GCC (which is now under GPLv3) and Mac OS X on it. Unfortunately, the iPhone is incompatible with GPLv3, if you want more see the link I mentioned. Using gcc to compile your code does not impose any licensing requirements on that code. I'm not speaking for Apple here, and I am not a lawyer. However, the last draft of the runtime library exception clause (which is quite old by now) imposed licensing restrictions on the executables generated by GCC (due to linked runtime libraries) if you did certain things to the compiler. I'm personally very eager to see the final wording, because the draft I saw (again, which is old and has certainly changed) was extremely aggressive. I do not know what draft you saw, but I don't think I ever saw it, unless we disagree on the meaning of extremely aggressive. In the general sense, you are most likely correct: if you modify gcc by adding GPL-incompatible software used to generate code, it is likely that you will not be granted any exception to the GPL when using the runtime library. In other words, if you 1) add an optimization pass to gcc using the (hypothetical) plugin architecture, and 2) that optimization pass is not licensed under a GPL-compatible license, and 3) you generate object code using that optimization pass, and 4) you link that generated object code with the gcc runtime library (e.g., libgcc or libstdc++-v3), then you will not be permitted to distribute the resulting executable except under the terms of the GPL. This does not of course affect LLVM, which is not under a GPL-incompatible license. This is intended to be a mechanism to use the runtime libraries as a hook to prevent people from distributing GPL-incompatible plugins for gcc. This message is not intended to describe the final version of the runtime library license, which does not exist. Nor does it represent the official position of the gcc steering committee, the FSF, the SFLC, or, for that matter, Google. This describes my personal understanding of the intent of the current drafting process. Ian
Re: Apple, iPhone, and GPLv3 troubles
Chris Lattner [EMAIL PROTECTED] writes: I'm not speaking for Apple here, and I am not a lawyer. However, the last draft of the runtime library exception clause (which is quite old by now) imposed licensing restrictions on the executables generated by GCC (due to linked runtime libraries) if you did certain things to the compiler. I'm personally very eager to see the final wording, because the draft I saw (again, which is old and has certainly changed) was extremely aggressive. On Wed, Sep 24, 2008 at 10:50:13AM -0700, Ian Lance Taylor wrote: I do not know what draft you saw, but I don't think I ever saw it, unless we disagree on the meaning of extremely aggressive. There was a first version that had some problems, forbidding things that weren't intended to be forbidden and with muddy language making the scope of the GCC exception unclear. But this was never intentional.
Re: Apple, iPhone, and GPLv3 troubles
On Sep 24, 2008, at 10:50 AM, Ian Lance Taylor wrote: I'm not speaking for Apple here, and I am not a lawyer. However, the last draft of the runtime library exception clause (which is quite old by now) imposed licensing restrictions on the executables generated by GCC (due to linked runtime libraries) if you did certain things to the compiler. I'm personally very eager to see the final wording, because the draft I saw (again, which is old and has certainly changed) was extremely aggressive. I do not know what draft you saw, but I don't think I ever saw it, unless we disagree on the meaning of extremely aggressive. In the general sense, you are most likely correct: if you modify gcc by adding GPL-incompatible software used to generate code, it is likely that you will not be granted any exception to the GPL when using the runtime library. In other words, if you 1) add an optimization pass to gcc using the (hypothetical) plugin architecture, and 2) that optimization pass is not licensed under a GPL-compatible license, and 3) you generate object code using that optimization pass, and 4) you link that generated object code with the gcc runtime library (e.g., libgcc or libstdc++-v3), then you will not be permitted to distribute the resulting executable except under the terms of the GPL. Again, speaking for myself as an individual: This was many months ago, and I did not retain a copy of the draft. In any case, it doesn't really matter because the draft probably has changed. However, the intent of pieces of the exception clause was pretty much what you said above. This does not of course affect LLVM, which is not under a GPL-incompatible license. Right. However, the wording I saw was much broader than just the plugin model. It was vague and poorly worded, and you could interpret it as saying that use of a non-GPL assembler or linker was also not allowed to build or link the libraries. My personal feeling on the matter is that it seems very strange to talk about *compiler plugins* in the license for *runtime libraries*. Considering that there are already widely available alternative libraries (e.g. the apache stdc++ library and many others) it seems potentially damaging to the GCC community to try to address the plugin issue this way. In any case, this thread should probably be killed, as we won't know until the FSF publishes the final proposed wording what the end result will be. I am (personally) looking forward to this, and I (personally) wish that the FSF was a lot more transparent on this issue, for the sake of the GCC community. -Chris
Re: Apple, iPhone, and GPLv3 troubles
On Wed, Sep 24, 2008 at 11:11:41AM -0700, Chris Lattner wrote: Right. However, the wording I saw was much broader than just the plugin model. It was vague and poorly worded, and you could interpret it as saying that use of a non-GPL assembler or linker was also not allowed to build or link the libraries. That's the version that was dumped, exactly for the reasons you state.
Re: Apple, iPhone, and GPLv3 troubles
On Wed, Sep 24, 2008 at 11:22 AM, Joe Buck [EMAIL PROTECTED] wrote: On Wed, Sep 24, 2008 at 11:11:41AM -0700, Chris Lattner wrote: Right. However, the wording I saw was much broader than just the plugin model. It was vague and poorly worded, and you could interpret it as saying that use of a non-GPL assembler or linker was also not allowed to build or link the libraries. That's the version that was dumped, exactly for the reasons you state. Excellent. I'm glad to hear that since I had also seen it and thought that it was unacceptable in general (speaking for myself). Anyhow, I hope to see all of this resolved at some point. -eric
Re: Runtime library license, was Re: Apple-employed maintainers (was Re: Apple, iPhone, and GPLv3 troubles)
Ian Lance Taylor wrote:
NightStrike [EMAIL PROTECTED] writes:
There is a simple technique which anybody is free to use to make this
happen much faster: make a large donation to the SFLC and/or the FSF,
contingent on this issue being finished. In the absence of that, it
will happen in the time that people have available to work on it.
How large is large?
More than you want to pay personally. Think: enough to hire another
staff member to work on it.
To be clear, I'm not saying it won't get done. It will get done. But
it is in effect like any other volunteer job. Our position with
regard to the people who need to do the work is like a gcc user's
position with regard to us.
I fully understand that position, but it triggers another question: what
company (or kind of companies) would want GCC plugins to happen really fast?
Is there any big coorporation, already contributing to GCC, which needs
plugin quickly? I cannot name any.
My feeling is that plugin will become progressively extremely useful to
*new* companies, which are not yet working within GCC. This mostly is
the case because in my perception plugins will open new use of GCC, like
illustrated by the replacing sed grep by gcc papers from Mozilla
folks (Tarek et al.). My intuition is that plugins will mostly enhance
all the non-code-generation activities in GCC.
Big hardware companies (those traditionally investing in GCC, like
Intel, AMD, Apple, ...) probably do not need plugins (except if they
wanted to provide *proprietary* plugins, which I believe the next
runtime license will try to prohibit), they can and do contribute to GCC
inside.
Big software or services companies (IBM, Google) probably also don't
need plugins (except to enhance GCC with a plugin that they use only in
house and do not intend to distribute, but for that use an inhouse
patched GCC is enough).
So I cannot guess a company willing to invest big bucks on the runtime
license issue, but I am probably wrong (and not naive enough to believe
that companies will discuss their GCC related strategies motivations
here, publicly, on this list).
Regards
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basileatstarynkevitchdotnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: Apple, iPhone, and GPLv3 troubles
On Sep 24, 2008, at 11:22 AM, Joe Buck wrote: On Wed, Sep 24, 2008 at 11:11:41AM -0700, Chris Lattner wrote: Right. However, the wording I saw was much broader than just the plugin model. It was vague and poorly worded, and you could interpret it as saying that use of a non-GPL assembler or linker was also not allowed to build or link the libraries. That's the version that was dumped, exactly for the reasons you state. I look forward to seeing the updated version - someday. -Chris
Re: Apple, iPhone, and GPLv3 troubles
On Wed, Sep 24, 2008 at 4:06 PM, Ian Lance Taylor [EMAIL PROTECTED] wrote: Apple's dislike of GPLv3 is a problem for gcc, yes. Well, excuse me for being a-political, but I don't see this problem. The relationship between GCC and Apple has never been really good AFAIK, but that hasn't hampered either to be quite successful. And w.r.t. GCC development - I don't know where/how the money flows, but at least the publicly the contributions from Apple to the FSF GCC are pretty marginal. Gr. Steven
Re: Apple, iPhone, and GPLv3 troubles
Steven Bosscher wrote: On Wed, Sep 24, 2008 at 4:06 PM, Ian Lance Taylor [EMAIL PROTECTED] wrote: Apple's dislike of GPLv3 is a problem for gcc, yes. Well, excuse me for being a-political, but I don't see this problem. The relationship between GCC and Apple has never been really good AFAIK, but that hasn't hampered either to be quite successful. I agree with you, but if you don't look at GCC as a whole -- but rather at the small intersection represented by FSF GCC on Darwin -- it *has* hampered it. Apple GCC is basically a fork nowadays, and it is often impossible to compile Leopard application using FSF GCC (in turn because of the lack of Objective-C 2.0 support). Sometimes I wonder why Darwin is still part of FSF GCC, just like it is not supported in binutils or gdb... I guess just for the sake of GCC developers that are working on a Mac. Even outside *-*-darwin*, what caused the development of two separate Objective-C runtimes, the one in FSF GCC being a big chainball for the removal of dead code from the compiler? Note that basically all Objective-C code in existence either does not care about the runtime, or has support for both runtimes; so it would not be a problem to deprecate libobjc if Apple contributed their own implementation. (There is now a third runtime, named Étoilé). Paolo ps: of course, there is no offense intended for poor Mike who's CCed in this thread.
Re: C/C++ FEs: Do we really need three char_type_nodes?
Joe Buck wrote: On Tue, Sep 23, 2008 at 05:51:23PM -0400, Jason Merrill wrote: Mark Mitchell wrote: Is that desirable? Type-based alias analysis should be able to take advantage of the difference between them; a char ** and a signed char ** cannot point at the same thing, for example. They can. In C++, a char* (or unsigned char*) can alias anything, and any signed/unsigned type can alias the other signage. Right, but a char** points to a char*, and a signed char** points to a signed char*. The aliasing exception for char pointers doesn't cover this case the way it does for the one star case. Oops, I was overlooking the second *. Jason
RE: Apple, iPhone, and GPLv3 troubles
BTW, one of the reason I posted this was that I wanted to privately talk about the politics behind this issue with someone internal to Apple, and forward some of that to RMS and the FSF. Can this be done or is the politics all under NDA? Because this issue isn't just limited to GCC, it is locking Apple out of an entire body of FOSS code. Yuhong bao Date: Wed, 24 Sep 2008 21:14:42 +0200 From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] CC: [EMAIL PROTECTED]; [EMAIL PROTECTED]; gcc@gcc.gnu.org; [EMAIL PROTECTED] Subject: Re: Apple, iPhone, and GPLv3 troubles Steven Bosscher wrote: On Wed, Sep 24, 2008 at 4:06 PM, Ian Lance Taylor wrote: Apple's dislike of GPLv3 is a problem for gcc, yes. Well, excuse me for being a-political, but I don't see this problem. The relationship between GCC and Apple has never been really good AFAIK, but that hasn't hampered either to be quite successful. I agree with you, but if you don't look at GCC as a whole -- but rather at the small intersection represented by FSF GCC on Darwin -- it *has* hampered it. Apple GCC is basically a fork nowadays, and it is often impossible to compile Leopard application using FSF GCC (in turn because of the lack of Objective-C 2.0 support). Sometimes I wonder why Darwin is still part of FSF GCC, just like it is not supported in binutils or gdb... I guess just for the sake of GCC developers that are working on a Mac. Even outside *-*-darwin*, what caused the development of two separate Objective-C runtimes, the one in FSF GCC being a big chainball for the removal of dead code from the compiler? Note that basically all Objective-C code in existence either does not care about the runtime, or has support for both runtimes; so it would not be a problem to deprecate libobjc if Apple contributed their own implementation. (There is now a third runtime, named Étoilé). Paolo ps: of course, there is no offense intended for poor Mike who's CCed in this thread. _
Re: char* problems
On Wed, Sep 24, 2008 at 2:47 AM, Lijuan Hai [EMAIL PROTECTED] wrote: I have no gcc 4.1.2 at hand. but I just had a try with gcc-4.1.0 and gcc-4.2.0 which compiled a simple testcase with no errors or warnings. additionally, I had a try with some other compiler than gcc to compile it. a warning issued. I think it's possibly too strict of gcc raising a error on sch case. any options that you added when compiling? Well lets put it this way, this is invalid code as char, signed char, and unsigned char are three distant types so the pointers to each of them are not compatible which means you need an explicit cast. The C++ compiler errors out by default, you can change the error to a warning with -fpermissive. While the C front-end warns by default, you can change the warning to an error with -pedantic-errors. Thanks, Andrew Pinski
Re: Apple, iPhone, and GPLv3 troubles
Yuhong Bao [EMAIL PROTECTED] writes: BTW, one of the reason I posted this was that I wanted to privately talk about the politics behind this issue with someone internal to Apple, and forward some of that to RMS and the FSF. Can this be done or is the politics all under NDA? Well, good luck. The people you need to talk to, with respect to Apple and GPLv3, are not reading this mailing list. We've already talked to some of them, and the situation as I understand it is what I already outlined, with the obvious proviso that I do not work at Apple. A couple of people from Apple have now commented on this thread; go ahead and mail them directly. Ian
Re: Apple, iPhone, and GPLv3 troubles
Chris Lattner [EMAIL PROTECTED] writes: My personal feeling on the matter is that it seems very strange to talk about *compiler plugins* in the license for *runtime libraries*. Considering that there are already widely available alternative libraries (e.g. the apache stdc++ library and many others) it seems potentially damaging to the GCC community to try to address the plugin issue this way. Here's the problem: the FSF doesn't really want to permit plugins. Many members of the gcc community, including myself, think they are very important. The FSF doesn't want plugins because they are concerned that people will start distributing proprietary plugins to gcc. I personally think this is a fear from twenty years ago which shows a lack of understanding of today's compiler market, but, that said, the FSF wants to cover themselves for the future as well. So, how do we permit plugins while prohibiting proprietary plugins, and how do we do it while staying within the bounds of copyright law which is the basis of the GPL? It's not an easy problem to solve. Using the runtime library license to solve it is a nice little bit of legal jujitsu. Presumably we could go ahead and use a simple runtime library license, similar to the existing one, which doesn't address the plugin issue. But we still want plugins, and then how do we get them? Separating the problems doesn't make them easier to solve. You are clearly right that the runtime license is potentially damaging to the GCC community. However, it's not like the people working on this are stupid, and it's not like they are going to force it on everybody without accepting comments. So I think it's premature to worry overly much about this. The FSF has not yet made a major licensing mistake. Ian
Re: Apple, iPhone, and GPLv3 troubles
On Sep 24, 2008, at 12:57 PM, Ian Lance Taylor wrote: Chris Lattner [EMAIL PROTECTED] writes: My personal feeling on the matter is that it seems very strange to talk about *compiler plugins* in the license for *runtime libraries*. Considering that there are already widely available alternative libraries (e.g. the apache stdc++ library and many others) it seems potentially damaging to the GCC community to try to address the plugin issue this way. Here's the problem: the FSF doesn't really want to permit plugins. So, how do we permit plugins while prohibiting proprietary plugins, and how do we do it while staying within the bounds of copyright law which is the basis of the GPL? Does the obvious answer work?: add it to the license that covers the code in question. Specifically, I think that it would be much more reasonable to add plugin wording to the license that covers the GCC compiler code itself. This means that you couldn't use *GCC* if you did something the FSF found objectionable, closing an easy work-around. -Chris
gcc-4.2-20080924 is now available
Snapshot gcc-4.2-20080924 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20080924/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.2 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_2-branch revision 140646 You'll find: gcc-4.2-20080924.tar.bz2 Complete GCC (includes all of below) gcc-core-4.2-20080924.tar.bz2 C front end and core compiler gcc-ada-4.2-20080924.tar.bz2 Ada front end and runtime gcc-fortran-4.2-20080924.tar.bz2 Fortran front end and runtime gcc-g++-4.2-20080924.tar.bz2 C++ front end and runtime gcc-java-4.2-20080924.tar.bz2 Java front end and runtime gcc-objc-4.2-20080924.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.2-20080924.tar.bz2The GCC testsuite Diffs from 4.2-20080917 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.2 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: Adding to G++: Adding a warning on throwing unspecified exceptions.
Simon Hill wrote: Brendon Costa said: The author of the template class or container can't know what types of exceptions will be thrown from them, so you must define them as being able to throw all exceptions (which is how they are currently). Ouch, you have a point. But couldn't you put this round the other way. Place the onus on the user of the template to comply with the exception guarantees inside the template. Unfortunately that would likely cause problems with some existing code. ... In other words, would you gain more from a tight exception specification than you'd lose by not being able to do this? You as an author of a new template class could define it the other way. The issue here is that doing so restricts usage of the generic component. In specific cases this may be desirable, but not for generic components like STL containers or those in boost. For generic components you want to make them as useful as possible. Even if at the time of writing the container you do not foresee that throwing any type of exception is a good idea, users may come up with some way of using it that you just never thought about. I.e. I think the general philosophy is to define only what restrictions are necessary to implement the template, not necessarily what we think constitute good uses of the template at the time we created it. Brendon.
[Bug c++/37553] [4.3/4.4 Regression] ICE in build_c_cast
--- Comment #3 from doug dot gregor at gmail dot com 2008-09-24 06:01 --- Patch here: http://gcc.gnu.org/ml/gcc-patches/2008-09/msg01667.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37553
[Bug fortran/37634] New: Fix libgfortran compiling to support GCC_NO_EXECUTABLES
See: http://gcc.gnu.org/ml/fortran/2008-09/msg00380.html and following emails. The configure script does link tests which cause some kinds of cross compilations to fail. Solution (cf. email thread, see above link): a) Approved patch in the link above b) Remove AC_LIBTOOL_DLOPEN which does not seem to be used c) Add an if-block around the AC_CHECK_FUNCS d) Check what else is needed, e.g. AC_CHECK_LIB -- Summary: Fix libgfortran compiling to support GCC_NO_EXECUTABLES Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: build Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37634
[Bug fortran/37626] ICE for automatic deallocation of character result variable
--- Comment #3 from burnus at gcc dot gnu dot org 2008-09-24 07:02 --- Subject: Bug 37626 Author: burnus Date: Wed Sep 24 07:01:18 2008 New Revision: 140624 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140624 Log: 2008-09-24 Tobias Burnus [EMAIL PROTECTED] PR fortran/37626 * trans-array.c (gfc_trans_deferred_array): Don't auto-deallocate result variables. 2008-09-24 Tobias Burnus [EMAIL PROTECTED] PR fortran/37626 * gfortran.dg/allocatable_function_4.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/allocatable_function_4.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-array.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37626
[Bug testsuite/37623] builtin-math-4 tests fail
--- Comment #4 from tim dot vanholder at anubex dot com 2008-09-24 07:03 --- Then perhaps either configure should reject the too-old version, or the testcase should detect this situation and either skip the tests in question and/or report that MPFR is too old. The situation as it stands is not very helpful. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37623
[Bug testsuite/37623] builtin-math-4 tests fail
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2008-09-24 07:18 --- Then perhaps either configure should reject the too-old version, or the testcase should detect this situation and either skip the tests in question and/or report that MPFR is too old. The situation as it stands is not very helpful. See the comment at the beginning of the testcase. Moreover, configure should have reported that the version of MPFR is not optimal. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37623
[Bug fortran/37583] ICE insert_bbt(): Duplicate key for self-calling ENTRY subprogram
--- Comment #9 from pault at gcc dot gnu dot org 2008-09-24 08:05 --- Fixed on trunk and 4.3 Thanks for the report Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37583
[Bug fortran/37583] ICE insert_bbt(): Duplicate key for self-calling ENTRY subprogram
--- Comment #10 from pault at gcc dot gnu dot org 2008-09-24 08:05 --- Subject: Bug 37583 Author: pault Date: Wed Sep 24 08:04:26 2008 New Revision: 140626 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140626 Log: 2008-09-24 Paul Thomas [EMAIL PROTECTED] PR fortran/37583 * decl.c (scalarize_intrinsic_call): Both subroutines and functions can give a true for get_proc_mame's last argument so remove the gfc_current_ns-proc_name-attr.function. resolve.c (resolve_actual_arglist): Add check for recursion by reference to procedure as actual argument. 2008-09-24 Paul Thomas [EMAIL PROTECTED] PR fortran/37583 * gfortran.dg/entry_18.f90: New test. Added: branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/entry_18.f90 Modified: branches/gcc-4_3-branch/gcc/fortran/ChangeLog branches/gcc-4_3-branch/gcc/fortran/decl.c branches/gcc-4_3-branch/gcc/fortran/resolve.c branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37583
[Bug fortran/36700] [4.3/4.4 Regression] ICE on calling a function
--- Comment #6 from pault at gcc dot gnu dot org 2008-09-24 08:14 --- Fixed on trunk and 4.3 Thanks for the report Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36700
[Bug fortran/35945] Complex module-based overloading fails
--- Comment #3 from pault at gcc dot gnu dot org 2008-09-24 08:14 --- Subject: Bug 35945 Author: pault Date: Wed Sep 24 08:12:47 2008 New Revision: 140627 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140627 Log: 2008-09-24 Paul Thomas [EMAIL PROTECTED] PR fortran/35945 * resolve.c (resolve_fl_variable_derived): Remove derived type comparison for use associated derived types. Host association of a derived type will not arise if there is a local derived type whose use name is the same. PR fortran/36700 * match.c (gfc_match_call): Use the existing symbol even if it is a function. 2008-09-24 Paul Thomas [EMAIL PROTECTED] PR fortran/35945 * gfortran.dg/host_assoc_types_2.f90: New test. PR fortran/36700 * gfortran.dg/host_assoc_call_2.f90: New test. Added: branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/host_assoc_call_2.f90 branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/host_assoc_types_2.f90 Modified: branches/gcc-4_3-branch/gcc/fortran/ChangeLog branches/gcc-4_3-branch/gcc/fortran/match.c branches/gcc-4_3-branch/gcc/fortran/resolve.c branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35945
[Bug fortran/36700] [4.3/4.4 Regression] ICE on calling a function
--- Comment #7 from pault at gcc dot gnu dot org 2008-09-24 08:14 --- Subject: Bug 36700 Author: pault Date: Wed Sep 24 08:12:47 2008 New Revision: 140627 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140627 Log: 2008-09-24 Paul Thomas [EMAIL PROTECTED] PR fortran/35945 * resolve.c (resolve_fl_variable_derived): Remove derived type comparison for use associated derived types. Host association of a derived type will not arise if there is a local derived type whose use name is the same. PR fortran/36700 * match.c (gfc_match_call): Use the existing symbol even if it is a function. 2008-09-24 Paul Thomas [EMAIL PROTECTED] PR fortran/35945 * gfortran.dg/host_assoc_types_2.f90: New test. PR fortran/36700 * gfortran.dg/host_assoc_call_2.f90: New test. Added: branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/host_assoc_call_2.f90 branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/host_assoc_types_2.f90 Modified: branches/gcc-4_3-branch/gcc/fortran/ChangeLog branches/gcc-4_3-branch/gcc/fortran/match.c branches/gcc-4_3-branch/gcc/fortran/resolve.c branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36700
[Bug fortran/35945] Complex module-based overloading fails
--- Comment #4 from pault at gcc dot gnu dot org 2008-09-24 08:14 --- Fixed on trunk and 4.3 Thanks for the report Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35945
[Bug fortran/37635] New: Fortran 2008: Support LEADZ / TRAILZ
Requested by Richard Townsend at http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/1e4130b9720e4f2a LEADZ and TRAILZ are rather common vendor extensions, e.g. supported by the Intel compiler (it also allows for logical arguments). LEADZ (I) Description. Number of leading zero bits. Argument. I shall be of type integer. Result Value. If all of the bits of I are zero, the result value is BIT SIZE (I). [...] TRAILZ (I) Description. Number of trailing zero bits. Argument. I shall be of type integer. The implementation should be relatively easy using the following built-ins, however, one presumably needs a special case for ZERO. BUILT_IN_CLZ* These functions return the number of leading 0-bits in a, starting at the most significant bit position. If a is zero, the result is undefined. and BUILT_IN_CTZ* These functions return the number of trailing 0-bits in a, starting at the least significant bit position. If a is zero, the result is undefined. (Description copied from http://gcc.gnu.org/onlinedocs/gccint/Integer-library-routines.html) For compile-time simplification, MPFR does not seem to provide a ready-to-use function; if one cooks up something oneself, one needs to check endian issues (though there might be none). -- Summary: Fortran 2008: Support LEADZ / TRAILZ Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37635
[Bug fortran/36700] [4.3/4.4 Regression] ICE on calling a function
--- Comment #8 from pault at gcc dot gnu dot org 2008-09-24 08:28 --- Subject: Bug 36700 Author: pault Date: Wed Sep 24 08:27:27 2008 New Revision: 140628 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140628 Log: 2008-09-24 Paul Thomas [EMAIL PROTECTED] PR fortran/36700 * gfortran.dg/host_assoc_call_2.f90: Correct typo. Modified: branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/host_assoc_call_2.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36700
[Bug libstdc++/25191] exception_defines.h #defines try/catch
--- Comment #56 from l dot lunak at suse dot cz 2008-09-24 08:50 ---
(In reply to comment #55)
It seems reasonable to me for try { X } catch... to mean X when
-fno-exceptions. We don't need to error except on throw.
It seems unreasonable to me that gcc would silently modify code's behaviour,
just like it would be unreasonable that -pedantic would silently change 'long
long i = 2LL 34;' to 'long i = 0;'. With today's complex build systems it is
not that difficult to get -fno-exceptions without noticing and then get code
that works differently than intended (and I'm not making this up, I had such a
real case).
If people really want code with exception handling to work with both
-fexception states, then they need to write the code with that in mind and then
they can as well just use __try/__catch macros the way libstdc++ does now, just
without breaking the code for the rest of people who can run into trouble if
the compiler/libraries try to outguess them.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191
[Bug middle-end/37601] [4.4 Regression] gcc-4.4-20080919 ada build failure
--- Comment #3 from gcc at spatium dot org 2008-09-24 09:37 --- Subject: Re: [4.4 Regression] gcc-4.4-20080919 ada build failure pinskia at gcc dot gnu dot org wrote 767 bytes: Can you try this again? same thing with latest trunk. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37601
[Bug middle-end/37170] [4.4 Regression]: gcc.dg/weak/weak-1.c
--- Comment #84 from aldot at gcc dot gnu dot org 2008-09-24 09:51 ---
The fix doesn't seem to work for me on arm:
$ cat pr-weak.c
/* tell the compiler that the count isn't in the small data section if the arch
* has one (eg: FRV)
*/
extern const unsigned long kallsyms_num_syms
__attribute__((weak, section(.rodata)));
int main(void) {
return !!kallsyms_num_syms;
}
$ /there.arm/usr/bin/arm-linux-uclibcgnueabi-gcc -Os -S -o - pr-weak.c -v
Using built-in specs.
Target: arm-linux-uclibcgnueabi
Configured with: /srcs/toolchain_build_arm_nofpu/gcc-4.4.0/configure
--prefix=/usr --build=i386-pc-linux-gnu --host=i386-pc-linux-gnu
--target=arm-linux-uclibcgnueabi --enable-languages=c,fortran
--with-sysroot=/there.arm
--with-build-time-tools=/there.arm/usr/arm-linux-uclibcgnueabi/bin
--disable-__cxa_atexit --enable-target-optspace --with-gnu-ld --enable-shared
--with-gmp=/srcs/toolchain_build_arm_nofpu/gmp
--with-mpfr=/srcs/toolchain_build_arm_nofpu/mpfr --disable-nls --enable-threads
--disable-multilib --with-float=soft --with-abi=aapcs-linux --disable-libssp
--disable-libssp --disable-libmudflap --disable-libgomp
--enable-decimal-float=no
Thread model: posix
gcc version 4.4.0 20080923 (experimental) [trunk revision 140602] (GCC)
COLLECT_GCC_OPTIONS='-Os' '-S' '-o' '-' '-v' '-mfloat-abi=soft'
'-mabi=aapcs-linux'
/there.arm/usr/bin/../libexec/gcc/arm-linux-uclibcgnueabi/4.4.0/cc1 -quiet -v
-iprefix /there.arm/usr/bin/../lib/gcc/arm-linux-uclibcgnueabi/4.4.0/ pr-weak.c
-quiet -dumpbase pr-weak.c -mfloat-abi=soft -mabi=aapcs-linux -auxbase-strip -
-Os -version -o -
ignoring nonexistent directory
/there.arm/usr/bin/../lib/gcc/arm-linux-uclibcgnueabi/4.4.0/../../../../arm-linux-uclibcgnueabi/include
ignoring nonexistent directory /there.arm/usr/local/include
ignoring duplicate directory
/there.arm/usr/bin/../lib/gcc/../../lib/gcc/arm-linux-uclibcgnueabi/4.4.0/include
ignoring duplicate directory
/there.arm/usr/bin/../lib/gcc/../../lib/gcc/arm-linux-uclibcgnueabi/4.4.0/include-fixed
ignoring nonexistent directory
/there.arm/usr/bin/../lib/gcc/../../lib/gcc/arm-linux-uclibcgnueabi/4.4.0/../../../../arm-linux-uclibcgnueabi/include
#include ... search starts here:
#include ... search starts here:
/there.arm/usr/bin/../lib/gcc/arm-linux-uclibcgnueabi/4.4.0/include
/there.arm/usr/bin/../lib/gcc/arm-linux-uclibcgnueabi/4.4.0/include-fixed
/there.arm/usr/include
End of search list.
GNU C (GCC) version 4.4.0 20080923 (experimental) [trunk revision 140602]
(arm-linux-uclibcgnueabi)
compiled by GNU C version 4.3.2, GMP version 4.2.2, MPFR version 2.3.1.
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 071bc0f306e6057c8a651fee23ec8dfa
.cpu arm10tdmi
.fpu softvfp
.eabi_attribute 20, 1
.eabi_attribute 21, 1
.eabi_attribute 23, 3
.eabi_attribute 24, 1
.eabi_attribute 25, 1
.eabi_attribute 26, 2
.eabi_attribute 30, 4
.eabi_attribute 18, 4
.file pr-weak.c
.text
.align 2
.global main
.type main, %function
main:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
ldr r3, .L3
ldr r0, [r3, #0]
subsr0, r0, #0
movne r0, #1
bx lr
.L4:
.align 2
.L3:
.word kallsyms_num_syms
.size main, .-main
.ident GCC: (GNU) 4.4.0 20080923 (experimental) [trunk revision
140602]
.section.note.GNU-stack,,%progbits
COMPILER_PATH=/there.arm/usr/bin/../libexec/gcc/arm-linux-uclibcgnueabi/4.4.0/:/there.arm/usr/bin/../libexec/gcc/:/there.arm/usr/bin/../lib/gcc/arm-linux-uclibcgnueabi/4.4.0/../../../../arm-linux-uclibcgnueabi/bin/
LIBRARY_PATH=/there.arm/usr/bin/../lib/gcc/arm-linux-uclibcgnueabi/4.4.0/:/there.arm/usr/bin/../lib/gcc/:/there.arm/usr/bin/../lib/gcc/arm-linux-uclibcgnueabi/4.4.0/../../../../arm-linux-uclibcgnueabi/lib/:/there.arm/lib/:/there.arm/usr/lib/
COLLECT_GCC_OPTIONS='-Os' '-S' '-o' '-' '-v' '-mfloat-abi=soft'
'-mabi=aapcs-linux'
works with 4.3.2 configured in the same way.
--
aldot at gcc dot gnu dot org changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37170
[Bug fortran/35723] Can't use run-time array element in character declaration
-- domob at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |domob at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2008-03-28 19:40:15 |2008-09-24 09:59:41 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35723
[Bug libgcj/37636] New: [4.4 regression] java tools are unable to find resource files
seen with 20080923 from the trunk, try running any of the tools:
$ /usr/lib/gcc-snapshot/bin/gjar -help
Exception in thread main java.lang.ExceptionInInitializerError
at java.lang.Class.initializeClass(natClass.cc:792)
at gnu.classpath.tools.common.Messages.getString(Messages.java:60)
at
gnu.classpath.tools.common.ClasspathToolParser.getVersionString(ClasspathToolParser.java:65)
at
gnu.classpath.tools.common.ClasspathToolParser.init(ClasspathToolParser.java:81)
at
gnu.classpath.tools.common.ClasspathToolParser.init(ClasspathToolParser.java:76)
at gnu.classpath.tools.jar.Main$JarParser.init(Main.java:151)
at gnu.classpath.tools.jar.Main.initializeParser(Main.java:177)
at gnu.classpath.tools.jar.Main.run(Main.java:268)
at gnu.classpath.tools.jar.Main.main(Main.java:284)
Caused by: java.util.MissingResourceException: Bundle
gnu.classpath.tools.common.Messages not found for locale en_US by classloader
gnu.gcj.runtime.SystemClassLoader{urls=[file:./],
parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=null}}
at java.util.ResourceBundle.getBundle(ResourceBundle.java:410)
at java.util.ResourceBundle.getBundle(ResourceBundle.java:231)
at gnu.classpath.tools.common.Messages.clinit(Messages.java:50)
at java.lang.Class.initializeClass(natClass.cc:780)
...8 more
--
Summary: [4.4 regression] java tools are unable to find resource
files
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: doko at ubuntu dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37636
[Bug middle-end/37637] New: Build fails with reserved constraints
The build of the Debian gcc-snapshot package, version 20080923, fails to build with this output from some sort of constraints check. This constraints are arch specific. build/genpreds -h ../../src/gcc/config/s390/s390.md tmp-preds.h ../../src/gcc/config/s390/constraints.md:122: constraint letter 'G' is reserved for const_double constraints ../../src/gcc/config/s390/constraints.md:129: constraint letter 'I' is reserved for const_int constraints ../../src/gcc/config/s390/constraints.md:135: constraint letter 'J' is reserved for const_int constraints ../../src/gcc/config/s390/constraints.md:141: constraint letter 'K' is reserved for const_int constraints ../../src/gcc/config/s390/constraints.md:147: constraint letter 'L' is reserved for const_int constraints ../../src/gcc/config/s390/constraints.md:157: constraint letter 'M' is reserved for const_int constraints ../../src/gcc/config/s390/constraints.md:163: constraint letter 'P' is reserved for const_int constraints ../../src/gcc/config/s390/constraints.md:197: constraint names beginning with 'N' (NxQS0) are reserved for const_int constraints ../../src/gcc/config/s390/constraints.md:203: constraint names beginning with 'N' (NxQD0) are reserved for const_int constraints ../../src/gcc/config/s390/constraints.md:209: constraint names beginning with 'N' (N3HD0) are reserved for const_int constraints ../../src/gcc/config/s390/constraints.md:215: constraint names beginning with 'N' (N2HD0) are reserved for const_int constraints ../../src/gcc/config/s390/constraints.md:221: constraint names beginning with 'N' (N1SD0) are reserved for const_int constraints ../../src/gcc/config/s390/constraints.md:227: constraint names beginning with 'N' (N1HS0) are reserved for const_int constraints ../../src/gcc/config/s390/constraints.md:233: constraint names beginning with 'N' (N1HD0) are reserved for const_int constraints ../../src/gcc/config/s390/constraints.md:239: constraint names beginning with 'N' (N0SD0) are reserved for const_int constraints ../../src/gcc/config/s390/constraints.md:245: constraint names beginning with 'N' (N0HS0) are reserved for const_int constraints ../../src/gcc/config/s390/constraints.md:251: constraint names beginning with 'N' (N0HD0) are reserved for const_int constraints ../../src/gcc/config/s390/constraints.md:257: constraint names beginning with 'N' (NxQDF) are reserved for const_int constraints ../../src/gcc/config/s390/constraints.md:263: constraint names beginning with 'N' (N1SDF) are reserved for const_int constraints ../../src/gcc/config/s390/constraints.md:269: constraint names beginning with 'N' (N0SDF) are reserved for const_int constraints ../../src/gcc/config/s390/constraints.md:275: constraint names beginning with 'N' (N3HDF) are reserved for const_int constraints ../../src/gcc/config/s390/constraints.md:281: constraint names beginning with 'N' (N2HDF) are reserved for const_int constraints ../../src/gcc/config/s390/constraints.md:287: constraint names beginning with 'N' (N1HDF) are reserved for const_int constraints ../../src/gcc/config/s390/constraints.md:293: constraint names beginning with 'N' (N0HDF) are reserved for const_int constraints ../../src/gcc/config/s390/constraints.md:299: constraint names beginning with 'N' (N0HSF) are reserved for const_int constraints ../../src/gcc/config/s390/constraints.md:305: constraint names beginning with 'N' (N1HSF) are reserved for const_int constraints ../../src/gcc/config/s390/constraints.md:311: constraint names beginning with 'N' (NxQSF) are reserved for const_int constraints ../../src/gcc/config/s390/constraints.md:317: constraint names beginning with 'N' (NxQHF) are reserved for const_int constraints ../../src/gcc/config/s390/constraints.md:323: constraint names beginning with 'N' (NxQH0) are reserved for const_int constraints ../../src/gcc/config/s390/constraints.md:336: constraint names beginning with 'O' (Os) are reserved for const_int constraints ../../src/gcc/config/s390/constraints.md:345: constraint names beginning with 'O' (Op) are reserved for const_int constraints ../../src/gcc/config/s390/constraints.md:354: constraint names beginning with 'O' (On) are reserved for const_int constraints -- Summary: Build fails with reserved constraints Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: waldi at debian dot org GCC target triplet: s390-*-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37637
[Bug libstdc++/25191] exception_defines.h #defines try/catch
--- Comment #57 from mark at codesourcery dot com 2008-09-24 13:03 ---
Subject: Re: exception_defines.h #defines try/catch
jason at gcc dot gnu dot org wrote:
--- Comment #55 from jason at gcc dot gnu dot org 2008-09-23 20:43
---
It seems reasonable to me for try { X } catch... to mean X when
-fno-exceptions. We don't need to error except on throw.
We have to be careful, in some cases. For example:
extern int f();
template typename T
struct S {
static int i;
};
template typename T
int ST::i = f();
int main() {
try {
return 0;
} catch (...) {
return Sint::i;
}
}
This program, IIRC, is guaranteed to call f, as a side-effect of the
presence of the catch-clause? Of course, the C++ FE could still process
the catch clause; my only point is that we cannot literally just throw
away the catch clause.
I don't objection to -fno-exceptions silently discarding catch clauses,
as long as we avoid the kind of problem above.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191
[Bug fortran/37638] New: ICE in update_arglist_pass
Current version of gfortran dies with an ICE on the attached invalid code. - log --- [EMAIL PROTECTED] F03]$ gfortran -v -c foo-ext.f03 Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../gcc/configure --prefix=/usr/local/gnutest --with-mpfr=/usr/local/mpfr --with-gmp=/usr/local/gmp --enable-languages=c,c++,fortran Thread model: posix gcc version 4.4.0 20080923 (experimental) (GCC) COLLECT_GCC_OPTIONS='-v' '-c' '-mtune=generic' /usr/local/gnutest/libexec/gcc/x86_64-unknown-linux-gnu/4.4.0/f951 foo-ext.f03 -quiet -dumpbase foo-ext.f03 -mtune=generic -auxbase foo-ext -version -fintrinsic-modules-path /usr/local/gnutest/lib/gcc/x86_64-unknown-linux-gnu/4.4.0/finclude -o /tmp/cc5PDDfU.s GNU Fortran (GCC) version 4.4.0 20080923 (experimental) (x86_64-unknown-linux-gnu) compiled by GNU C version 4.4.0 20080923 (experimental), GMP version 4.2.2, MPFR version 2.3.0. GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 foo-ext.f03:10.13: procedure, pass(a) :: makenull 1 Error: Procedure 'makenull' with PASS(a) at (1) has no argument 'a' f951: internal compiler error: in update_arglist_pass, at fortran/resolve.c:4380 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. -- Summary: ICE in update_arglist_pass Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sfilippone at uniroma2 dot it GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37638
[Bug c++/37540] [4.4 regression] ICE on __decltype of method call in function template
--- Comment #4 from dgregor at gcc dot gnu dot org 2008-09-24 13:51 --- We need to look at CALL_EXPR_FN's type because the decltype of a call retrieves the return type of the the function called, which may be a REFERENCE_TYPE. The type of the expression will have stripped away that reference. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37540
[Bug fortran/37638] ICE in update_arglist_pass
--- Comment #1 from sfilippone at uniroma2 dot it 2008-09-24 13:51 --- Created an attachment (id=16400) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16400action=view) test case ICE-on-invalid -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37638
[Bug target/37629] auto-import of constant data results in a crash at runtime
--- Comment #2 from jkolb at wsi dot com 2008-09-24 14:07 --- Binutils 2.19.50 Yes I have. The linker switch does not help. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37629
[Bug fortran/37638] ICE in update_arglist_pass
--- Comment #2 from domob at gcc dot gnu dot org 2008-09-24 14:39 --- Thanks for the report Salvatore, I'll take this one on. It seems the new F2003 features are starting to getting used, from the bug-noise :D -- domob at gcc dot gnu dot org changed: What|Removed |Added CC||domob at gcc dot gnu dot org AssignedTo|unassigned at gcc dot gnu |domob at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-09-24 14:39:00 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37638
[Bug fortran/37638] ICE in update_arglist_pass
--- Comment #3 from sfilippone at uniroma2 dot it 2008-09-24 14:50 --- (In reply to comment #2) Thanks for the report Salvatore, I'll take this one on. It seems the new F2003 features are starting to getting used, from the bug-noise :D Unfortunately these features are not going to be very useful until CLASS() is implemented; indeed, the code is invalid, but if you change pass(a) into pass(m) it would still be invalid because the makenull procedure should be written with a CLASS() and not a TYPE() argument. In fact, if you comment the second contained subroutine the ICE goes away. As soon as CLASS() is in you (and PaulT) may expect a lot more noise :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37638
[Bug target/37629] auto-import of constant data results in a crash at runtime
--- Comment #3 from brian at dessent dot net 2008-09-24 15:24 --- Subject: Re: auto-import of constant data results in a crash at runtime So, is the segment containing the reference to ff_log2_tab writable? This still sounds like a linker issue not a compiler issue. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37629
[Bug bootstrap/37639] New: Bootstrap fails with may be used uninitialized warning in c-parser.c
-- Summary: Bootstrap fails with may be used uninitialized warning in c-parser.c Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: lucier at math dot purdue dot edu GCC build triplet: powerpc64-apple-darwin9.5.0 GCC host triplet: powerpc64-apple-darwin9.5.0 GCC target triplet: powerpc64-apple-darwin9.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37639
[Bug bootstrap/37639] Bootstrap fails with may be used uninitialized warning in c-parser.c
--- Comment #1 from lucier at math dot purdue dot edu 2008-09-24 15:34
---
Created an attachment (id=16401)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16401action=view)
macro-expanded source of c-parser.c
Sorry for hitting return instead of tab in the initial report ...
Configured and bootstrapped with
[descartes:objdirs/mainline/gcc] lucier% cat
../../../mainline/build-and-check-gcc-64
#!/bin/tcsh
/bin/rm -rf *; ../../mainline/configure CC='/usr/bin/gcc-4.0 -mcpu=970 -m64'
--build=powerpc64-apple-darwin9.5.0 --host=powerpc64-apple-darwin9.5.0
--target=powerpc64-apple-darwin9.5.0 --with-gmp-include=/sw/include/
--with-gmp-lib=/sw/lib/ppc64 --with-mpfr-include=/sw/include/
--with-mpfr-lib=/sw/lib/ppc64 --prefix=/pkgs/gcc-4.4.0-64
--with-libiconv-prefix=/usr --with-system-zlib; make -j 4 bootstrap
BOOT_LDFLAGS='-Wl,-search_paths_first' build.log (make install) (make
-k -j 8 check RUNTESTFLAGS=--target_board 'unix{-mcpu=970/-m64}'
check.log ; make mail-report.log)
Error is
[descartes:objdirs/mainline/gcc] lucier%
/Users/lucier/programs/gcc/objdirs/mainline/./prev-gcc/xgcc
-B/Users/lucier/programs/gcc/objdirs/mainline/./prev-gcc/
-B/pkgs/gcc-4.4.0-64/powerpc64-apple-darwin9.5.0/bin/ -c -g -O2 -DIN_GCC -W
-Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual
-Wold-style-definition -Wc++-compat -Wmissing-format-attribute -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common
-DHAVE_CONFIG_H -I. -I. -I../../../mainline/gcc -I../../../mainline/gcc/.
-I../../../mainline/gcc/../include -I./../intl
-I../../../mainline/gcc/../libcpp/include -I/sw/include/ -I/sw/include/
-I../../../mainline/gcc/../libdecnumber
-I../../../mainline/gcc/../libdecnumber/dpd -I../libdecnumber
../../../mainline/gcc/c-parser.c -o c-parser.o -save-temps
cc1: warnings being treated as errors
../../../mainline/gcc/c-parser.c: In function 'c_parser_binary_expression':
../../../mainline/gcc/c-parser.c:4579: error: 'binary_loc' may be used
uninitialized in this function
../../../mainline/gcc/c-parser.c:4579: note: 'binary_loc' was declared here
preprocessed source included as an attachment
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37639
[Bug target/37629] auto-import of constant data results in a crash at runtime
--- Comment #4 from jkolb at wsi dot com 2008-09-24 15:35 --- I'm not sure, I don't have access to that machine right now. Kai Tietz (from the mingw-w64 project) thought it might be the linker as well. How do I hand the bug off to the linker folks? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37629
[Bug fortran/37635] Fortran 2008: Support LEADZ / TRAILZ
--- Comment #1 from kargl at gcc dot gnu dot org 2008-09-24 16:19 --- (In reply to comment #0) For compile-time simplification, MPFR does not seem to provide a ready-to-use function; if one cooks up something oneself, one needs to check endian issues (though there might be none). I think you mean GMP because we're concerned with INTEGER types. See mpz_scan0 and mpz_scan1. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37635
[Bug regression/37640] New: Misuse of __sync_lock_test_and_set causes ICE
A gcc build from today (gcc version 4.4.0 20080924) gets an ICE on PowerPC when
building this (admittedly broken) code:
# gcc -m64 -O2 -c test.c
struct foo {
int a;
char lock;
};
struct foo *foo;
void testcase()
{
__sync_lock_test_and_set((foo-lock), 0);
}
It compiles if building 32bit. Even so, I wonder if gcc should warn when the
variable is incompatible with __sync_* builtins.
--
Summary: Misuse of __sync_lock_test_and_set causes ICE
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: regression
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: anton at samba dot org
GCC target triplet: powerpc-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37640
[Bug rtl-optimization/26479] suboptimal register allocation for return register
--- Comment #5 from hp at gcc dot gnu dot org 2008-09-24 16:49 --- (In reply to comment #4) I think this was fixed for 4.3.0: HP, can you try this again on cris? At 140627, the problem is still there on the 4.3 branch for CRIS. I'll attach a diff of the generated assembly of -O2 compared to -O2 -fno-if-conversion. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26479
[Bug rtl-optimization/26479] suboptimal register allocation for return register
--- Comment #6 from hp at gcc dot gnu dot org 2008-09-24 16:51 --- Created an attachment (id=16402) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16402action=view) Diff of asembly of -O2 vs -O2 -fno-if-conversion at r.140627 See previous comment. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26479
[Bug rtl-optimization/26479] suboptimal register allocation for return register
--- Comment #7 from hp at gcc dot gnu dot org 2008-09-24 16:57 --- I guess I should turn the code in the description into a testcase in gcc.dg so target maintainers can add their xfailed scan-assembler-not and we'd see xpasses if/when this is magically fixed... (After the IRA adjustments for CRIS!) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26479
[Bug ada/37641] New: FILE_WRITE_PROPERTIES is deprecated
adaint.c uses a macro for mingw called FILE_WRITE_PROPERTIES. This has long since been deprecated, and is instead replaced with FILE_WRITE_EA. Both macros are defined to the same value (0x0010), but one does not exist in current versions (such as mingw-w64, the 64-bit port). I recommend updating to the new macro. The below is a patch that should work: === --- ../../../gcc/gcc/ada/adaint.c (revision 140599) +++ ../../../gcc/gcc/ada/adaint.c (working copy) @@ -1923,7 +1923,7 @@ __gnat_set_OWNER_ACL (wname, DENY_ACCESS, FILE_WRITE_DATA | FILE_APPEND_DATA | - FILE_WRITE_PROPERTIES | FILE_WRITE_ATTRIBUTES); + FILE_WRITE_EA | FILE_WRITE_ATTRIBUTES); SetFileAttributes (wname, GetFileAttributes (wname) | FILE_ATTRIBUTE_READONLY); #elif ! defined (__vxworks) ! defined(__nucleus__) -- Summary: FILE_WRITE_PROPERTIES is deprecated Product: gcc Version: unknown Status: UNCONFIRMED Severity: trivial Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: nightstrike at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37641
[Bug c/37642] New: GCC applies signed strict-overflow rules to unsigned short type
I'll submit a testcase that apparently demonstrates that gcc is trying to apply signed strict overflow rules to an unsigned short type, at least on 32 bit machines when short is 16 bit. Here is the output: arm-elf-gcc -O2 -W -Wall -Wstrict-overflow=5 -c testcase.c testcase.c: In function incr_counter: testcase.c:13: warning: assuming signed overflow does not occur when assuming that (X + c) X is always false this is from gcc 4.3.1; my native build also has the same semantics, and I've tested with 4.2.4 also. The thing is that the type is unsigned (even if it is smaller than the target machine register), so that it can overflow and it can be detected (costly perhaps, but can). -- Summary: GCC applies signed strict-overflow rules to unsigned short type Product: gcc Version: 4.2.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: alexandre dot nunes at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37642
[Bug c/37642] GCC applies signed strict-overflow rules to unsigned short type
--- Comment #1 from alexandre dot nunes at gmail dot com 2008-09-24 17:29 --- Created an attachment (id=16403) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16403action=view) This is the first testcase. compile with gcc -O2 -W -Wall -Wstrict-overflow=5 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37642
[Bug ada/37641] FILE_WRITE_PROPERTIES is deprecated
--- Comment #1 from ktietz at gcc dot gnu dot org 2008-09-24 17:32 --- FILE_WRITE_PROPERTIES is deprecated and even the documentation is removed from msdn. So I agree that FILE_WRITE_EA should be used instead. -- ktietz at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ktietz at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-09-24 17:32:21 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37641
[Bug inline-asm/37621] Missing documentation for x86 inline assembler modifiers
--- Comment #2 from dlenski at gmail dot com 2008-09-24 17:43 --- Hi Andrew, It seems to me that these modifiers are quite necessary for flexible x86 assembly. What is the point of the q and Q constraints if there's no way to specifically refer to the 16-bit or 8-bit components of the selected register? And are you sure there built-in functions to invoke the rol/ror/xhcg instructions? I don't see any in the 4.3 docs. Dan -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37621
[Bug c/37642] GCC applies signed strict-overflow rules to unsigned short type
--- Comment #2 from pinskia at gmail dot com 2008-09-24 17:44 --- Subject: Re: New: GCC applies signed strict-overflow rules to unsigned short type When doing addition unsigned short is promoted to an signed int. So this is not a bug. That is unsigned short + 1 is a signed int since 1 is a signed int. Sent from my iPhone On Sep 24, 2008, at 10:29 AM, alexandre dot nunes at gmail dot com [EMAIL PROTECTED] wrote: I'll submit a testcase that apparently demonstrates that gcc is trying to apply signed strict overflow rules to an unsigned short type, at least on 32 bit machines when short is 16 bit. Here is the output: arm-elf-gcc -O2 -W -Wall -Wstrict-overflow=5 -c testcase.c testcase.c: In function âincr_counterâ: testcase.c:13: warning: assuming signed overflow does not occur when assuming that (X + c) X is always false this is from gcc 4.3.1; my native build also has the same semantics, and I've tested with 4.2.4 also. The thing is that the type is unsigned (even if it is smaller than the target machine register), so that it can overflow and it can be detected (costly perhaps, but can). -- Summary: GCC applies signed strict-overflow rules to unsigned short type Product: gcc Version: 4.2.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: alexandre dot nunes at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37642 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37642
[Bug libstdc++/25191] exception_defines.h #defines try/catch
--- Comment #58 from jason at redhat dot com 2008-09-24 19:21 ---
Subject: Re: exception_defines.h #defines try/catch
l dot lunak at suse dot cz wrote:
--- Comment #56 from l dot lunak at suse dot cz 2008-09-24 08:50 ---
(In reply to comment #55)
It seems reasonable to me for try { X } catch... to mean X when
-fno-exceptions. We don't need to error except on throw.
It seems unreasonable to me that gcc would silently modify code's behaviour,
The change I was talking about doesn't modify behavior. If there are no
exceptions, catch blocks will never be executed, so we can optimize them
away in the presence of -fno-exceptions.
This program, IIRC, is guaranteed to call f, as a side-effect of the
presence of the catch-clause? Of course, the C++ FE could still process
the catch clause; my only point is that we cannot literally just throw
away the catch clause.
True, it would be more like { X } if (0) ...
Jason
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191
[Bug fortran/37643] New: fortran doesn't build on 4.4.0 for vax
When cross-compiling for vax--netbsdelf, fortran doesn't build. I have a NetBSD/vax 4.99.72 install symlinked, and am using binutils 2.19.50.20080923. gcc sources are subversion rev 140638. It gets to here and stops: libtool: compile: /usr/src/gcc/vax/./gcc/xgcc -B/usr/src/gcc/vax/./gcc/ -B/usr/local/vax--netbsdelf/bin/ -B/usr/local/vax--netbsdelf/lib/ -isystem /usr/local/vax--netbsdelf/include -isystem /usr/local/vax--netbsdelf/sys-include -DHAVE_CONFIG_H -I. -I../../../libgfortran -I. -iquote../../../libgfortran/io -I../../../libgfortran/../gcc -I../../../libgfortran/../gcc/config -I../.././gcc -D_GNU_SOURCE -std=gnu99 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wextra -Wwrite-strings -fcx-fortran-rules -g -O2 -MT c99_functions.lo -MD -MP -MF .deps/c99_functions.Tpo -c ../../../libgfortran/intrinsics/c99_functions.c -o c99_functions.o ../../../libgfortran/intrinsics/c99_functions.c:539: warning: no previous prototype for 'roundl' ../../../libgfortran/intrinsics/c99_functions.c:640: warning: no previous prototype for 'lroundl' ../../../libgfortran/intrinsics/c99_functions.c:667: warning: no previous prototype for 'llroundl' ../../../libgfortran/intrinsics/c99_functions.c:679: warning: no previous prototype for 'log10l' ../../../libgfortran/intrinsics/c99_functions.c:717: warning: no previous prototype for 'floorl' ../../../libgfortran/intrinsics/c99_functions.c:743: warning: no previous prototype for 'fmodl' ../../../libgfortran/intrinsics/c99_functions.c: In function 'tgamma': ../../../libgfortran/intrinsics/c99_functions.c:1455: warning: floating constant truncated to zero ../../../libgfortran/intrinsics/c99_functions.c:1457: warning: target format does not support infinity /var/tmp//ccY9ySD8.s: Assembler messages: /var/tmp//ccY9ySD8.s:712: Fatal error: Junk at end of expression QNaN Closer examination reveals that the line the assembler is choking on is: movd $0d+QNaN,%r1 Fortran did build in the past on 4.4.0; I have a version dated 2008.04.10. -- Summary: fortran doesn't build on 4.4.0 for vax Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hbent at cs dot oberlin dot edu GCC build triplet: i386-unknown-netbsdelf4.99.72 GCC host triplet: i386-unknown-netbsdelf4.99.72 GCC target triplet: vax--netbsdelf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37643
[Bug target/37640] Misuse of __sync_lock_test_and_set causes ICE
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-09-24 19:55 --- How is this broken code? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|regression |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37640
[Bug target/37640] Misuse of __sync_lock_test_and_set causes ICE
--- Comment #2 from anton at samba dot org 2008-09-24 20:07 --- After reading the gcc documentation I guess it is valid, and the 32bit lwarx/stwcx will overlap but not change surrounding memory. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37640
[Bug target/37640] Misuse of __sync_lock_test_and_set causes ICE
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-09-24 20:16 --- Something like this fixes the issue: Index: config/rs6000/rs6000.c === --- config/rs6000/rs6000.c (revision 140638) +++ config/rs6000/rs6000.c (working copy) @@ -14082,7 +14082,8 @@ rs6000_expand_compare_and_swapqhi (rtx d HOST_WIDE_INT imask = GET_MODE_MASK (mode); /* Shift amount for subword relative to aligned word. */ - addrSI = force_reg (SImode, gen_lowpart_common (SImode, XEXP (mem, 0))); + addrSI = force_reg (GET_MODE (XEXP (mem, 0)), XEXP (mem, 0)); + addrSI = force_reg (SImode, gen_lowpart_common (SImode, addrSI)); shift = gen_reg_rtx (SImode); emit_insn (gen_rlwinm (shift, addrSI, GEN_INT (3), GEN_INT (shift_mask))); --- CUT --- gen_lowpart_common does not work on non regs so force the addition to memory first and then get the lowerpart. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Summary|__sync_lock_test_and_set|Misuse of |causes ICE |__sync_lock_test_and_set ||causes ICE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37640
[Bug c++/36461] [c++0x] Exception throws don't use rvalue reference constructors
--- Comment #4 from dgregor at gcc dot gnu dot org 2008-09-24 20:20 ---
GCC is doing the right thing here. In this constructor:
Thing2(Thing2 o) : Thing(o) { }
the parameter o is treated as an lvalue, because it has a name. Using
std::move(o) to treat it as an rvalue.
Similarly, there are no automatically generated move constructors or
move-assignment operators, so if you leave Thing2() empty, you'll just get the
copy constructor and therefore do a copy.
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36461
[Bug middle-end/37601] [4.4 Regression] gcc-4.4-20080919 ada build failure
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-09-24 20:36 --- What happens if you don't use profiledbootstrap but instead bootstrap? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37601
[Bug c/37642] GCC applies signed strict-overflow rules to unsigned short type
--- Comment #3 from alexandre dot nunes at gmail dot com 2008-09-24 20:42 --- (In reply to comment #2) Subject: Re: New: GCC applies signed strict-overflow rules to unsigned short type When doing addition unsigned short is promoted to an signed int. So this is not a bug. That is unsigned short + 1 is a signed int since 1 is a signed int. Sent from my iPhone Hah, living and learning. That actually makes sense, thanks, I'll refine the test. -- alexandre dot nunes at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37642
[Bug bootstrap/37304] [4.4 Regression]: in-tree-binutils gcc configure tests fail because of unexpanded $(objdir)
--- Comment #5 from hp at gcc dot gnu dot org 2008-09-24 21:10 --- (In reply to comment #4) FWIW, this happens inside libtool configure tests, so I guess it is harmless inside gcc/. Do you see this in other directories' configure outputs, too, No. and if yes, can you post a little more context (esp. the 5 or so lines following what you posted would have been interesting)? I'll attach the corresponding *native* x64-64 build of r139963, where the behavior is visible for each stage. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37304
[Bug bootstrap/37304] [4.4 Regression]: in-tree-binutils gcc configure tests fail because of unexpanded $(objdir)
--- Comment #6 from hp at gcc dot gnu dot org 2008-09-24 21:15 --- Created an attachment (id=16404) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16404action=view) bzip2:ed native x64-64-linux build_log The build_log from GeoffK's contrib/regression/btest-gcc.sh) of trunk r139963 of a x86_64-unknown-linux-gnu test with in-tree binutils. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37304
[Bug fortran/37635] Fortran 2008: Support LEADZ / TRAILZ
--- Comment #2 from steven at gcc dot gnu dot org 2008-09-24 22:28 --- I'll see this weekend if I can take care of this. -- steven at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |steven at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-09-24 22:28:12 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37635
[Bug inline-asm/37621] Missing documentation for x86 inline assembler modifiers
--- Comment #3 from n dot pipenbrinck at cubic dot org 2008-09-24 22:41 --- ROL/ROR on the native integer size is not supported via intrinsics, but the compiler will fold two shifts into a rotate. If I want to manipulate only the lower 16 bit of an 32 bit integer (e.g. issue a rolw) assembly is the only way it's currently possible. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37621
[Bug fortran/37644] New: compiler Segmentation fault
Open MP directives in conjunction with LAM MPI calls is causing compiler to fail: (bash) niwot.pts/3% export LAMHF77=/z/stoch/home/rlnaff/usr/local/bin/gfortran4.3.2 (bash) niwot.pts/3% mpif77 -g -fopenmp -c reorder_parent.f90 reorder_parent.f90:470: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. (bash) niwot.pts/3% mpif77 -v -save-temps -g -fopenmp -c reorder_parent.f90 Using built-in specs. Target: i686-pc-linux-gnu Configured with: /z/stoch/home/rlnaff/gcc_source/gcc-4.3.2//configure --prefix=/z/stoch/home/rlnaff/usr/local --program-suffix=4.3.2 -with-local-prefix=/z/stoch/home/rlnaff/usr/local --with-gnu-as --with-gnu-ld --enable-threads --with-cpu-32=cpu --enable-languages=all --with-gmp --with-mpfr Thread model: posix gcc version 4.3.2 (GCC) COLLECT_GCC_OPTIONS='-I/usr/local/include' '-pthread' '-v' '-save-temps' '-g' '-fopenmp' '-c' '-mtune=generic' '-pthread' /a/stoch/home/rlnaff/usr/local/bin/../libexec/gcc/i686-pc-linux-gnu/4.3.2/f951 reorder_parent.f90 -quiet -dumpbase reorder_parent.f90 -mtune=generic -auxbase reorder_parent -g -version -fopenmp -I/usr/local/include -fintrinsic-modules-path /a/stoch/home/rlnaff/usr/local/bin/../lib/gcc/i686-pc-linux-gnu/4.3.2/finclude -o reorder_parent.s GNU F95 (GCC) version 4.3.2 (i686-pc-linux-gnu) compiled by GNU C version 4.3.2, GMP version 4.2.2, MPFR version 2.3.1. GGC heuristics: --param ggc-min-expand=99 --param ggc-min-heapsize=129368 reorder_parent.f90:470: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. -- Summary: compiler Segmentation fault Product: gcc Version: 4.3.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rlnaff at usgs dot gov GCC build triplet: see description below GCC host triplet: see description below GCC target triplet: see description below http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37644
[Bug libgcj/37636] [4.4 regression] java tools are unable to find resource files
--- Comment #1 from gnu_andrew at member dot fsf dot org 2008-09-25 01:47 --- I'm not sure when 4.3 branched, but David Daney's locale patch (switching from gcj's locales to Classpath's) might have had an effect (2008-03-04). It's the only locale change I can see from this year. The current 4.3 branch does still work fine. The missing resources are in libjava/classpath/tools/resource. None of them are locale-specific. ResourceBundle is used as-is from Classpath without being overridden or amended. It may be a classloader issue. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37636
[Bug rtl-optimization/36758] [4.3/4.4 Regression] addition moved out of the loop when used with an argument
--- Comment #12 from pinskia at gcc dot gnu dot org 2008-09-25 02:52 --- This happens also for x86_64. on the trunk: L2: movq%rbx, %rdi call_f0 testl %eax, %eax jne L2 4.0.1: L3: leaq-4(%rbp), %rdi call_f0 testl %eax, %eax jne L3 --- CUT --- With the fwrprop patch which I am working on and disabling move loop invariants, we get back: L2: leaq-4(%rbp), %rdi call_f0 testl %eax, %eax jne L2 -- CUT --- move-loop-invariants still moves this out of the loop though. So to answer Richard's question about this being a target issue, since it is also happens on x86_64 and move loop invariants does not take into account the cost of the move instruction, I am going to say this is a move loop invariant issue (after I fix the fwprop one). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added GCC target triplet|powerpc*-*-*|powerpc*-*-*, x86_64 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36758
[Bug libgcj/37636] [4.4 regression] java tools are unable to find resource files
--- Comment #2 from gnu_andrew at member dot fsf dot org 2008-09-25 03:20 --- Interestingly: $ /home/andrew/build/gcj/bin/gcj --version gcj (GCC) 4.4.0 20080913 (experimental) [gcj/classpath-098-merge-branch revision 140651] $ /home/andrew/build/gcj/bin/gjar --version jar (GNU Classpath) 0.98-pre $ /home/andrew/build/gcj/bin/gjar --help Usage: jar -ctxui [OPTIONS] jar-file [-C DIR FILE] FILE... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37636
[Bug target/37121] g++ create global symbol for inline function, which make link failed with multiple defination
--- Comment #1 from drangon dot mail at gmail dot com 2008-09-25 04:45 --- Created an attachment (id=16405) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16405action=view) output of gcc -E -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37121
[Bug target/37121] g++ create global symbol for inline function, which make link failed with multiple defination
--- Comment #2 from drangon dot mail at gmail dot com 2008-09-25 04:47 --- Created an attachment (id=16406) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16406action=view) output of nm, the object is build by gcc -O0 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37121
