Ada and the TREE_COMPLEXITY field on struct tree_exp
Hello, Ada is the last user of the tree_exp-complexity field. Removing this field should reduce GCC's memory usage by about 5% on a 64 bit host. Could an Ada maintainer see if it possible to remove the use of this field? I would think it shouldn't be too hard -- TREE_COMPLEXITY is used only inside ada/decl.c. But I haven't been able to figure out myself yet how to avoid using TREE_COMPLEXITY there... Thanks, Gr. Steven
Re: CSE not combining equivalent expressions.
On Thu, 2007-01-18 at 12:44 +0530, pranav bhandarkar wrote: On 1/17/07, Mircea Namolaru [EMAIL PROTECTED] wrote: Thanks. Another question I have is that, in this case, will the following http://gcc.gnu.org/wiki/Sign_Extension_Removal help in removal of the sign / zero extension ? First, it seems to me that in your case: (1) a = a | 1 /* a |= 1 */ (2) a = a | 1 /* a |= 1 */ the expressions a | 1 in (1) and (2) are different as the a is not the same. So there is nothing to do for CSE. If the architecture has an instruction that does both the store and the zero extension, the zero extension instructions become redundant. The sign extension algorithm is supposed to catch such cases, but I suspect that in this simple case the regular combine is enough. Mircea Thanks for the info. I went through the documentation provided by you in see.c, which I must add is very comprehensive indeed, and realised that we need an instruction that does a zero extend before a store so that that the extension instructions become redundant and can be removed. I haven't followed this thread that closely, but it seems to me this could be done in the propagation engine. Basically we keep track of the known zero, sign bit copies and known nonzero bits for SSA names, then propagate them in the obvious ways. Basically replicating a lot of what combine cse do in this area, but at the tree level. It's something I've always wanted to see implemented, but never bothered to do... jeff
Re: CSE not combining equivalent expressions.
On Thursday 18 January 2007 09:31, Jeffrey Law wrote: I haven't followed this thread that closely, but it seems to me this could be done in the propagation engine. Basically we keep track of the known zero, sign bit copies and known nonzero bits for SSA names, then propagate them in the obvious ways. Basically replicating a lot of what combine cse do in this area, but at the tree level. It's something I've always wanted to see implemented, but never bothered to do... I had this implemented at one point (2 years ago??) and I could not show any real benefit. There were almost no opportunities for this kind of optimization in GCC itself or in some benchmarks I looked at. There appear to be more bit operations in RTL, so perhaps it is a better idea to implement a known-bits propagation pass for RTL, with the new dataflow engine. Gr. Steven
Re: CSE not combining equivalent expressions.
On Thu, 2007-01-18 at 09:41 +0100, Steven Bosscher wrote: There appear to be more bit operations in RTL, so perhaps it is a better idea to implement a known-bits propagation pass for RTL, with the new dataflow engine. If that's the case then most of the opportunities are appearing due to lowering of the IL which would make a lot of sense for detecting useless sign/zero extensions. I'm not immediately aware of too many cases where lowering the IL is going to expose new opportunities to track and optimize nonzero/zero bits stuff. Jeff
gcc compile time support for assumptions
I'd like to know if gcc has implemented some generic way to help
optimizer job by allowing programmers to specify assumptions (or
constraints).
This is somewhat different from assertions: suppose we have this simple
code:
#include assert.h
int p(int a) {
assert(a 0);
return a = 0;
}
Compiling with #undef NDEBUG the code generated has a test for a's sign,
a branch for failed assertion and a branch to unconditionally return 0.
Compiling with #define NDEBUG the code generated has a test for a's sign
and the congruent return of 0 and 1.
Neither of this two compilations give the maximum optimization feasible.
If exists a way to write:
int p(int a) {
assume(a 0);
return a = 0;
}
this would be compiled with #define NDEBUG as if the assume was an
assert, but with #undef NDEBUG as an unconditional return 0.
In this way we'll get the maximum optimization.
This is a very simple example, but I guess that everyone get the many
possibilities that these gives.
Just to give another examples and to link this to a current thread:
assume(x != INT_MIN || y != -1);
return x % y;
Can be safely compiled with current inexact code also on ppc, i386, x86-64.
Of course the infrastructure is already present in current gcc optimizer
implementation, what I like to know is if there is some way to access it
from compiled code (by example using specific builtin_).
Re: Miscompilation of remainder expressions
Ian Lance Taylor writes: Robert Dewar [EMAIL PROTECTED] writes: Ian Lance Taylor wrote: We do want to generate a trap for x / 0, of course. Really? Is this really defined to generate a trap in C? I would be surprised if so ... As far as I know, but I think it would be a surprising change for x / 0 to silently continue executing. But perhaps not a very important one. Java depends for correct execution on some divisions by zero (in libgcc) generating traps. For example, here's one in __udivmoddi4: if (d0 == 0) d0 = 1 / d0;/* Divide intentionally by zero. */ Andrew.
Re: Miscompilation of remainder expressions
On Thu, 18 Jan 2007, Andrew Haley wrote: | Robert Dewar writes: | Joe Buck wrote: | | (off topic!) | |On Wed, Jan 17, 2007 at 06:40:21PM -0500, Robert Dewar wrote: |H .. I wish some of the more important bugs in gcc received |the attention that this very unimportant issue is receiving :-) | |I guess the difference is that lots of people can understand |this issue. | |Yes, this phenomenon has been given a name, by Parkinson of Parkinson's |law fame: bike shed. | | Actually I don't think Parkinson uses this term. He states a similar | principle as: | | * THE LAW OF TRIVIALITY: The time spent on any item of a committee's | agenda will be in inverse proportion to the sum of money involved. | | Mm, but although the problem being dicussed here is trivial, some of | the proposed solutions aren't. As the saying goes, the cure is worse | than the disease. I would say that is a bit extreme. I don't think we're going to implement any of the solutions without giving people options to disable the correct instruction generation when they don't care about it. -- Gaby
C Parser
Hi all, I was quite surprised to see that the C Parser was manually implemented and you didn't use any parser generator. I would be curious regarding this decision. I would think the development of a C parser would be an almost unsurmountable task and not very logic given the parser generators in existence today. Can someone comment this? (which issues led to this decision?) Regards, -- Paulo Jorge Matos - pocm at soton.ac.uk http://www.personal.soton.ac.uk/pocm PhD Student @ ECS University of Southampton, UK
Re: Ada and the TREE_COMPLEXITY field on struct tree_exp
Ada is the last user of the tree_exp-complexity field. Removing this field should reduce GCC's memory usage by about 5% on a 64 bit host. Could an Ada maintainer see if it possible to remove the use of this field? I would think it shouldn't be too hard -- TREE_COMPLEXITY is used only inside ada/decl.c. But I haven't been able to figure out myself yet how to avoid using TREE_COMPLEXITY there... It's just being used as a cache to avoid recomputing a value. My suggestion would be to replace it with a hash table. It'll tend to keep nodes around a little more than usual, but that should be a tiny cost.
Re: CSE not combining equivalent expressions.
Basically we keep track of the known zero, sign bit copies and known nonzero bits for SSA names, then propagate them in the obvious ways. Basically replicating a lot of what combine cse do in this area, but at the tree level. It's something I've always wanted to see implemented, but never bothered to do... Likewise!
Where the languages meet...
Hello all, After reading the internals of gcc wikibooks some questions come up. So, gcc has front end for C, C++, java, fortran, etc.. All these languages have a frontend which parse into AST and then GIMPLE which is converted to RTX and then assembly. Now, my guess is that GIMPLE is the _common_ ground for all languages. No matter which language, all will go through GIMPLE, so if I wished to implement some language analysis / optimizations, I should do it in GIMPLE to be able to implement in one go the optimization for all languages, right? Is there any formal syntax/semantics for GIMPLE? Or the SIMPLE paper is the only thing with this stuff? Any reference to the differences between GIMPLE and SIMPLE? Regards, -- Paulo Jorge Matos - pocm at soton.ac.uk http://www.personal.soton.ac.uk/pocm PhD Student @ ECS University of Southampton, UK
Re: Ada and the TREE_COMPLEXITY field on struct tree_exp
On 1/18/07, Richard Kenner [EMAIL PROTECTED] wrote: Ada is the last user of the tree_exp-complexity field. Removing this field should reduce GCC's memory usage by about 5% on a 64 bit host. Could an Ada maintainer see if it possible to remove the use of this field? I would think it shouldn't be too hard -- TREE_COMPLEXITY is used only inside ada/decl.c. But I haven't been able to figure out myself yet how to avoid using TREE_COMPLEXITY there... It's just being used as a cache to avoid recomputing a value. My suggestion would be to replace it with a hash table. It'll tend to keep nodes around a little more than usual, but that should be a tiny cost. I had thought of a hash table, too, but I couldn't figure out where to initialize and free it (i.e. where it is a live table, so to speak). For example, I don't know if this table would be required after gimplification, and I also don't even know how GNAT translates its own representation to GIMPLE (whole translation unit at once? function at a time?). Gr. Steven
Re: C Parser
On 1/18/07, Paulo J. Matos [EMAIL PROTECTED] wrote: Hi all, I was quite surprised to see that the C Parser was manually implemented and you didn't use any parser generator. I would be curious regarding this decision. I would think the development of a C parser would be an almost unsurmountable task and not very logic given the parser generators in existence today. Can someone comment this? (which issues led to this decision?) Regards, -- Paulo Jorge Matos - pocm at soton.ac.uk http://www.personal.soton.ac.uk/pocm PhD Student @ ECS University of Southampton, UK You can find some information about the benefits of the hand-written parser on the Wiki page for it - http://gcc.gnu.org/wiki/New_C_Parser. Hopefully you'll be able to find answers to some/all of your questions from either that page, or from the discussion of the posted patches. Cheers, Lee.
Re: Ada and the TREE_COMPLEXITY field on struct tree_exp
I had thought of a hash table, too, but I couldn't figure out where to initialize and free it (i.e. where it is a live table, so to speak). For example, I don't know if this table would be required after gimplification, and I also don't even know how GNAT translates its own representation to GIMPLE (whole translation unit at once? function at a time?). It's fairly conventional in that part. But that's not relevant here. This is used for transmitting location information on FIELD_DECLs back to the front end. Most records in Ada are defined at GCC's global level, so there's little point in doing anything other than a hash table that's initialized early on (e.g., in the routine gigi) and never freed. Also, the current code just saves the result for EXPR_P nodes since only those have TREE_COMPLEXITY, but if you're switching to a hash table, it's probably best just to record *all* results in it. No point in getting too sophisticated here: this is just a small hack to avoid pathalogical compile-time behavior when compiling certain very complex record types.
Re: CSE not combining equivalent expressions.
On 1/18/07, Richard Kenner [EMAIL PROTECTED] wrote:
I'm not immediately aware of too many cases where lowering the IL is
going to expose new opportunities to track and optimize nonzero/zero
bits stuff.
Bitfield are the big one. If you have both bitfield and logical operations,
you can often merge the logical operations with those used to retrieve
and/or store the field.
Things such as
x.y |= 1;
where Y is a bitfield and X non-BLKmode would be a large sequence of logical
operations that can all be replaced by a single OR insn at the RTL level
but presents no optimization opportunities at the tree level.
I have found another case where a zero / sign extend is inhibiting optimization
extern char b;
extern char c;
int main()
{
b = 1;
b = 1;
b = 1;
c = b;
return 0;
}
Here again a zero extend gets generated after every 'ashift' whereas
we are interested only in the lower order 8 bits. However when i try
the same thing with int instead of char i.e. there is no need for
extension then the operations get converted into b=3 instead of 3
instructions.
regards,
Pranav
Re: Miscompilation of remainder expressions
Andrew Haley wrote: Mm, but although the problem being dicussed here is trivial, some of the proposed solutions aren't. As the saying goes, the cure is worse than the disease. Indeed! Well whenever you have umpteen people all trying to solve a simple problem, things always get out of hand, and fixing a bug is definitely a case where too many cooks Andrew.
Re: Miscompilation of remainder expressions
Gabriel Dos Reis wrote: I would say that is a bit extreme. I don't think we're going to implement any of the solutions without giving people options to disable the correct instruction generation when they don't care about it. I would hesitate a bit about options in this general class of generate-wrong-code-i-don't-care I think such options should only be in place if you can really show a substantial effect. Point in case, GNAT put in a truly horrible overflow detection circuit very early on, that works by doing everything in double precision and range checking the results. This seemed so very inefficient that we made overflow checks off by default and provided an option (-gnato) to turn them on. But in practice, most large applications find that -gnato is not noticeably expensive, and probably at the very least it should have been made the default. P.S. it would seem that -ftrapv would be just what Ada needs, but our local gcc folks claim that -ftrapv is completely broken and unusable :-(
Re: gcc compile time support for assumptions
Abramo Bagnara [EMAIL PROTECTED] writes: I'd like to know if gcc has implemented some generic way to help optimizer job by allowing programmers to specify assumptions (or constraints). The answer is no, there is nothing quite like you describe. But I think it would be a good idea. Ian
Re: C Parser
Paulo J. Matos [EMAIL PROTECTED] writes: I was quite surprised to see that the C Parser was manually implemented and you didn't use any parser generator. I would be curious regarding this decision. I would think the development of a C parser would be an almost unsurmountable task and not very logic given the parser generators in existence today. For a long time gcc used bison to generate the parser. Joseph Myers rewrote it into a recursive descent parser a couple of years ago. I'm sure Joseph could explain the reasons better, but some of the problems with the bison parser were 1) it's hard to generate good error messages at the right places; 2) C is not LALR(1) (at least, not in a natural sense) because of the declaration syntax; 3) it made it a lot easier to add OpenMP support. http://gcc.gnu.org/ml/gcc-patches/2004-10/msg01969.html Ian
Re: gcc compile time support for assumptions
Ian Lance Taylor writes: Abramo Bagnara [EMAIL PROTECTED] writes: I'd like to know if gcc has implemented some generic way to help optimizer job by allowing programmers to specify assumptions (or constraints). The answer is no, there is nothing quite like you describe. But I think it would be a good idea. Something like this would greatly improve the code generation quality of gcj. There are a great many assertions that I could pass to VRP and the optimizers: this is invariant, this is less than that, and so on. Andrew.
Getting a tree node for a field of a variable
Hi, Please, would you suggest me any clues on how to get a tree node for a field of a variable within the AST. Let's say that somewhere I declared: MyStruct *var; What I want to do is to get a tree node of a field within var, i.e. var-field What I want actually is to modify var-field, i.e. var-field = 10; but I couldn't find any useful functions to use for doing that. Any suggestions are welcome. Thanks a lot. -- Ferad Zyulkyarov
Re: C Parser
Ian Lance Taylor wrote: I'm sure Joseph could explain the reasons better, but some of the problems with the bison parser were 1) it's hard to generate good error messages at the right places; 2) C is not LALR(1) (at least, not in a natural sense) because of the declaration syntax; 3) it made it a lot easier to add OpenMP support. For me, 1) is decisive, GNAT uses a hand written parser for that reason, and there we did a reasonably fair test, since Gerry Fisher did a really VERY good table driven parser (using much more sophisticated approaches than BISON and similar tools, that generated really quite good messages, but still not as good as what can be done by hand, where for example we take note of indentation in generating messages, e.g. consider the following very common cut-and-paste error. 1. package body p is 2.procedure p1 is 3.begin 4. null; 5.end; 6. 7.procedure p2; 8.procedure p3; 9.procedure p4 is | is should be ; 10.procedure p5; 11.procedure p6; 12. 13.procedure p2 is begin null; end; 14.procedure p3 is begin null; end; 15.procedure p4 is begin null; end; 16.procedure p5 is begin null; end; 17.procedure p6 is begin null; end; 18. end; All other Ada compilers I know would complain at the end. You can see this more clearly by indenting the above program in accordance with the way it is written: package body p is procedure p1 is begin null; end; procedure p2; procedure p3; procedure p4 is procedure p5; procedure p6; procedure p2 is begin null; end; procedure p3 is begin null; end; procedure p4 is begin null; end; procedure p5 is begin null; end; procedure p6 is begin null; end; end; What looks wrong here is the unexpected end, there is nothing wrong syntactically in a left to right scan till that point. If you give this indented version (which makes it clear that the dclarations after the is really *are* intended for procedure p4, you get 1. package body p is 2.procedure p1 is 3.begin 4. null; 5.end; 6. 7.procedure p2; 8.procedure p3; 9.procedure p4 is 10. procedure p5; 11. procedure p6; 12. 13. procedure p2 is begin null; end; 14. procedure p3 is begin null; end; 15. procedure p4 is begin null; end; 16. procedure p5 is begin null; end; 17. procedure p6 is begin null; end; 18.end; 12 missing begin for procedure p4 at line 9 end p4; expected Here is another example: 1. procedure q is 2. begin 3.x := a b; | binary operator expected 4.x := a | missing ; 5.b; 6. end;
Re: gcc compile time support for assumptions
On 18 Jan 2007 07:51:51 -0800, Ian Lance Taylor [EMAIL PROTECTED] wrote: Andrew Haley [EMAIL PROTECTED] writes: Ian Lance Taylor writes: Abramo Bagnara [EMAIL PROTECTED] writes: I'd like to know if gcc has implemented some generic way to help optimizer job by allowing programmers to specify assumptions (or constraints). The answer is no, there is nothing quite like you describe. But I think it would be a good idea. Something like this would greatly improve the code generation quality of gcj. There are a great many assertions that I could pass to VRP and the optimizers: this is invariant, this is less than that, and so on. Well, internally, we do have ASSERT_EXPR. It would probably take a little work to permit the frontends to generate it, but the optimizers should understand it. Providing a __builtin_assert () function is still one thing on my TODO, we can derive proper ASSERT_EXPRs from it in VRP even in the -DNDEBUG case. Of course if the asserts still end up in the source VRP already can derive information from the IL of the assert code. Richard.
Re: gcc compile time support for assumptions
Richard Guenther wrote: Providing a __builtin_assert () function is still one thing on my TODO, we can derive proper ASSERT_EXPRs from it in VRP even in the -DNDEBUG case. Great! Certainly could be profitably used in libstdc++. Paolo.
Re: gcc compile time support for assumptions
Paolo Carlini [EMAIL PROTECTED] writes: | Richard Guenther wrote: | | Providing a __builtin_assert () function is still one thing on my | TODO, we can | derive proper ASSERT_EXPRs from it in VRP even in the -DNDEBUG case. | | Great! Certainly could be profitably used in libstdc++. Indeed! We would just make sure that people don't think there is a relation between __builtin_assert() and assert(), and there usually are between __builtin_xxx() and xxx(). -- Gaby
Re: gcc compile time support for assumptions
On 18 Jan 2007 10:19:37 -0600, Gabriel Dos Reis [EMAIL PROTECTED] wrote: Paolo Carlini [EMAIL PROTECTED] writes: | Richard Guenther wrote: | | Providing a __builtin_assert () function is still one thing on my | TODO, we can | derive proper ASSERT_EXPRs from it in VRP even in the -DNDEBUG case. | | Great! Certainly could be profitably used in libstdc++. Indeed! We would just make sure that people don't think there is a relation between __builtin_assert() and assert(), and there usually are between __builtin_xxx() and xxx(). Ok, so better name it __builtin_assume () then. Richard.
Re: CSE not combining equivalent expressions.
On 1/18/07, Jeffrey Law [EMAIL PROTECTED] wrote: On Thu, 2007-01-18 at 12:44 +0530, pranav bhandarkar wrote: On 1/17/07, Mircea Namolaru [EMAIL PROTECTED] wrote: Thanks. Another question I have is that, in this case, will the following http://gcc.gnu.org/wiki/Sign_Extension_Removal help in removal of the sign / zero extension ? First, it seems to me that in your case: (1) a = a | 1 /* a |= 1 */ (2) a = a | 1 /* a |= 1 */ the expressions a | 1 in (1) and (2) are different as the a is not the same. So there is nothing to do for CSE. If the architecture has an instruction that does both the store and the zero extension, the zero extension instructions become redundant. The sign extension algorithm is supposed to catch such cases, but I suspect that in this simple case the regular combine is enough. Mircea Thanks for the info. I went through the documentation provided by you in see.c, which I must add is very comprehensive indeed, and realised that we need an instruction that does a zero extend before a store so that that the extension instructions become redundant and can be removed. I haven't followed this thread that closely, but it seems to me this could be done in the propagation engine. Basically we keep track of the known zero, sign bit copies and known nonzero bits for SSA names, then propagate them in the obvious ways. The obvious way is at IL lowering time. Basically replicating a lot of what combine cse do in this area, but at the tree level. It's something I've always wanted to see implemented, but never bothered to do... jeff -- Ramana Radhakrishnan
Re: Getting a tree node for a field of a variable
Ferad Zyulkyarov [EMAIL PROTECTED] writes: Please, would you suggest me any clues on how to get a tree node for a field of a variable within the AST. Look in tree.def. Given the RECORD_TYPE node, walk down TYPE_FIELDS looking for the FIELD_DECL that you want. To assign to a field use a COMPONENT_REF. Ian
Dumping gimple tree
Hello, from GENERIC and GIMPLE: A New Tree Representation for Entire Functions by Jason Merrill it says there's a flag -fdump-tree-simple to get the gimple tree (page 3). However, this doesn't exist in gcc 4.1: $ gcc -fdump-tree-simple bigger3.c cc1: error: unrecognized command line option -fdump-tree-simple Is there anything similar for gcc4.1? Regards, -- Paulo Jorge Matos - pocm at soton.ac.uk http://www.personal.soton.ac.uk/pocm PhD Student @ ECS University of Southampton, UK
Re: Dumping gimple tree
Argh, forget it! Found the answer in: http://gcc.gnu.org/onlinedocs/gcc-4.1.1/gcc/Debugging-Options.html#Debugging-Options Regards, Paulo Matos On 1/18/07, Paulo J. Matos [EMAIL PROTECTED] wrote: Hello, from GENERIC and GIMPLE: A New Tree Representation for Entire Functions by Jason Merrill it says there's a flag -fdump-tree-simple to get the gimple tree (page 3). However, this doesn't exist in gcc 4.1: $ gcc -fdump-tree-simple bigger3.c cc1: error: unrecognized command line option -fdump-tree-simple Is there anything similar for gcc4.1? Regards, -- Paulo Jorge Matos - pocm at soton.ac.uk http://www.personal.soton.ac.uk/pocm PhD Student @ ECS University of Southampton, UK -- Paulo Jorge Matos - pocm at soton.ac.uk http://www.personal.soton.ac.uk/pocm PhD Student @ ECS University of Southampton, UK
Re: Preventing warnings
I think this warning is starting to happen for valid code because of 64-bit machines. You can avoid it by using unsigned types. I think that something like this will do the trick: #define FIXNUM_OVERFLOW_P(i)\ ((unsigned long long)(i) MOST_POSITIVE_FIXNUM \ (unsigned long long)(i) MOST_NEGATIVE_FIXNUM) Thanks. I will ask people to give that a try. Is this documented as a way to avoid problems with that warning?
Re: 27% regression of gcc 4.3 performance on cpu2k6/calculix
On Tue, Jan 16, 2007 at 07:05:34PM +0300, Grigory Zagorodnev wrote: Toon Moene wrote: Calculix is a combined C/Fortran program. Did you try to compile the Fortran parts with --param max-aliased-vops=something higher than the default 50 ? Right, calculix is a combined program. Gprof says the regression is in e_c3d routine which is 1k lines of Fortran code. Various max-aliased-vops give no difference for calculix: Is that possible to extract a smaller testcase? H.J.
Re: Preventing warnings
On 18/01/07, Richard Stallman [EMAIL PROTECTED] wrote: Is this documented as a way to avoid problems with that warning? No. This is an undocumented, unnamed, unconditional warning. We are working on fixing those for GCC 4.3 :-) Cheers, Manuel.
Re: -Wconversion versus libstdc++
On 18/01/07, Gabriel Dos Reis [EMAIL PROTECTED] wrote: On Thu, 18 Jan 2007, Manuel López-Ibáñez wrote: | On 18/01/07, Gabriel Dos Reis [EMAIL PROTECTED] wrote: | On Thu, 18 Jan 2007, Manuel López-Ibáñez wrote: | | | Does that apply also to: | | | | unsigned int y = -10; | | Yes. | | | Then, why Wconversion has warned about it at least since | http://gcc.gnu.org/onlinedocs/gcc-3.0.4/gcc_3.html#SEC11 ? The description on the page there is: Warn if a prototype causes a type conversion that is different from what would happen to the same argument in the absence of a prototype. This includes conversions of fixed point to floating and vice versa, and conversions changing the width or signedness of a fixed point argument except when the same as the default promotion. Also, warn if a negative integer constant expression is implicitly converted to an unsigned type. For example, warn about the assignment x = -1 if x is unsigned. But do not warn about explicit casts like (unsigned) -1. As the PR you noted, it wasn't part of C++. You are wrong. The PR was about signed-unsigned for two variables. A warning about negative constant converted to unsigned has always existed in g++! I have it in g++ (GCC) 4.1.2 20060928 (prerelease) (Ubuntu 4.1.1-13ubuntu5). I guess it is also in GCC 4.2. And it was present in g++ before as warning: initialization of negative value `-0x1' to `unsigned int'. It was moved to Wconversion on revision 105421, before that moment, it was an unconditional warning. | And my favourite, Gabriel dos Reis willing to implement a warning for ^ Please use capital D if you must write my full name; thanks. Sure. | int-unsigned int for g++: | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26167#c3 | | :-) I hope you understand why I think the issue is not as clear to me | as it seems to be for you. You never re-evaluate based on data collected from experimenting with applications out there? Yes, I do. Actually, that is what we are doing right now... let's see if we can get the best solution. Look at the code at issue in libstdc++. What is wrong with it? As noted by Joe, such constructs are now likely common place, as they fall from STL-style view of sequences. You have to take that into account. What is wrong with it is that if the difference between the two pointers is negative you could obtain an unexpected result when this negative value is converted to unsigned. Can we detect that this cannot happen or that it doesn't matter? Is there any distinctive case where we can detect that it matters and we should warn? Assigning negative values to unsigned types is a typical security vulnerability, it doesn't matter if you do it in complement-2 arithmetic. The result is not what the programmer (who may be unaware of the unsigned type because it is hidden behind a typedef) expected. So some cases of sign-unsigned are worth warning. Can we detect those? | Finally, why libstdc++ is using Wconversion at all? Please go and read the PR submitted by Gerald. I read it and still don't get it. We know we should not warn about system headers but we do and that is a known bug. So again, why is libstdc++ using Wconversion at all? That doesn't mean that this particular part of the warning should not be disabled. It just means that I don't think that because some combination of warnings enabled explicitly by the user triggers a warning in libstdc++ headers, the warning is invalid. Try for example -Wunreachable-code. It seems a much better approach to fix the bug about warning in system headers rather than systematically trying to avoid warnings for any possible warning option in GCC. But still, it is good to know this, so we can remove the noise from Wconversion. I just don't want to cut too much for the wrong reason ;-) One use of -Wconversion is to draw attention to int x = 2.3; // warning: be careful, is this what you want? // this is a potential bug as it is value altering. That was not the case until very recently and it has never been documented. Before that, a warning for double-int was emitted without Wconversion (GCC 4.1 for example). As I said before, the warning for unsigned int i = -1; was in g++ way before this and it was the only documented thing that Wconversion did. So anyone enabling Wconversion before GCC 4.2, did it to get the negative constant-unsigned warning (or by mistake or ignorance, of course). I suggest to move int - unsigned into a separate category, out of -Wconversion, if you must keep it. We could do that. -Wconversion-sign ? We could move it also to -Wsign-comparison (enabled by -Wall) which I guess was implemented because someone found interesting to warn about comparison between signed and unsigned despite all the false positives that it produces. That won't silence the warnings in libstdc++ if you use -Wconversion-sign, though, because we have
Re: -Wconversion versus libstdc++
Manuel -- I read it and still don't get it. We know we should not warn about system headers but we do and that is a known bug. So again, why is libstdc++ using Wconversion at all? I appreciate your help with this issue, and I'm confident that we'll soon converge to a nice solution. Thanks, really. That said, frankly, I'm finding your saying, multiple times, why is libstdc++ using Wconversion at all particularly misleading, distracting and, well, annoying: libstdc++ is not using anything, by itself, certainly is not using Wconversion at .so and .a build time. The problem is that **the user of the library** may certainly compile **his own** code including libstdc++ headers passing a -Wconversion switch, or any other obscure request for warning. Then, given the bugginess of the pragma, which you correctly reminded (I just filed C++/30500 for that), warnings will be spilled from the libstdc++ headers to his face. He will be totally confused. Let's agree about that simple point and move ahead. Thanks, Paolo.
Re: -Wconversion versus libstdc++
On 18/01/07, Paolo Carlini [EMAIL PROTECTED] wrote: Manuel -- I read it and still don't get it. We know we should not warn about system headers but we do and that is a known bug. So again, why is libstdc++ using Wconversion at all? I appreciate your help with this issue, and I'm confident that we'll soon converge to a nice solution. Thanks, really. That said, frankly, I'm finding your saying, multiple times, why is libstdc++ using Wconversion at all particularly misleading, distracting and, well, annoying: libstdc++ is not using anything, by itself, certainly is not using Wconversion at .so and .a build time. The problem is that **the user of the library** may certainly compile **his own** code including libstdc++ headers passing a -Wconversion switch, or any other obscure request for warning. Then, given the bugginess of the pragma, which you correctly reminded (I just filed C++/30500 for that), warnings will be spilled from the libstdc++ headers to his face. He will be totally confused. Let's agree about that simple point and move ahead. Agreed. They may certainly turn on any warning on gcc. Like -Wunreachable-code, or -Waggregate-return. And agreed that Wconversion is too noisy. I just felt that the conversation was going in the direction of we should shut the warnings of Wconversion up because people using it will get warnings for libstdc++. And I don't think that one thing should be traded-off by the other (in any direction). I hope you can understand how annoying is that the bug has been filed just now. So we can just forget about libstdc++ and focus on who will use Wconversion and what for and what may be worth warning for what not. Although it would be great if, at the end, Wconversion were useful also for libstdc++ :-) Sorry for the repetition and being annoying, that was not my intention at all. Cheers, Manuel.
Re: -Wconversion versus libstdc++
On Thu, 18 Jan 2007, Manuel López-Ibáñez wrote: [...] | As the PR you noted, it wasn't part of C++. | | | You are wrong. the PR you noted is http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26167#c3 which you described as your favorite. The PR starts with this gcc reports the signedness probelm correctly, but g++ does not. See below for a demonstration: [...] | You never re-evaluate based on data collected from experimenting with | applications out there? | | | Yes, I do. Good. [...] | Look at the code at issue in libstdc++. What is wrong with it? | As noted by Joe, such constructs are now likely common place, as they | fall from STL-style view of sequences. You have to take that into | account. | | What is wrong with it is that if the difference between the two ^ | pointers is negative you could obtain an unexpected result when this | negative value is converted to unsigned. But, it isn't. I asked what *is* wrong with it; not what might be wrong with it in a speculative world. The fact is nothing is wrong with it. | Can we detect that this | cannot happen or that it doesn't matter? Is there any distinctive case | where we can detect that it matters and we should warn? | | Assigning negative values to unsigned types is a typical security | vulnerability, it doesn't matter if you do it in complement-2 | arithmetic. The result is not what the programmer (who may be unaware | of the unsigned type because it is hidden behind a typedef) expected. | So some cases of sign-unsigned are worth warning. Can we detect | those? | | | Finally, why libstdc++ is using Wconversion at all? | | Please go and read the PR submitted by Gerald. | | I read it and still don't get it. So, you did not get that libstdc++ was not using -Wconversion? That is troublesome. -- Gaby
Re: -Wconversion versus libstdc++
On Thu, 18 Jan 2007, Paolo Carlini wrote: | Manuel -- | | I read it and still don't get it. We know we should not warn about | system headers but we do and that is a known bug. So again, why is | libstdc++ using Wconversion at all? | | I appreciate your help with this issue, and I'm confident that we'll | soon converge to a nice solution. Thanks, really. | | That said, frankly, I'm finding your saying, multiple times, why is | libstdc++ using Wconversion at all particularly misleading, distracting | and, well, annoying: libstdc++ is not using anything, by itself, | certainly is not using Wconversion at .so and .a build time. It is troublesome that Manuel is so definitive, when in fact, he does not seem to understand the PR and its implications. | The problem | is that **the user of the library** may certainly compile **his own** | code including libstdc++ headers passing a -Wconversion switch, or any | other obscure request for warning. Then, given the bugginess of the | pragma, which you correctly reminded (I just filed C++/30500 for that), | warnings will be spilled from the libstdc++ headers to his face. He will | be totally confused. The pragma thing will be fixed; however, we will still be left with unhelful warning for what has become idiomatic because of the way C++ tends to see sequences. -- Gaby
Re: -Wconversion versus libstdc++
Gabriel Dos Reis wrote: The pragma thing will be fixed; however, we will still be left with unhelful warning for what has become idiomatic because of the way C++ tends to see sequences. In Ada, we changed things a while ago to give warnings ONLY on the extended main unit being compiled, and not on with'ed specs. This is really a similar case, though it is not quite as clear how to get this effect in C++.
Re: -Wconversion versus libstdc++
Manuel López-Ibáñez [EMAIL PROTECTED] writes: [...] | I just felt that the conversation was going in the direction of we | should shut the warnings of Wconversion up because people using it | will get warnings for libstdc++. I'm afraid you did not read the conversation carefully. -- Gaby
Re: -Wconversion versus libstdc++
On Thu, 18 Jan 2007, Robert Dewar wrote: | Gabriel Dos Reis wrote: | | The pragma thing will be fixed; however, we will still be left with | unhelful warning for what has become idiomatic because of the way C++ | tends to see sequences. | | In Ada, we changed things a while ago to give warnings ONLY on the | extended main unit being compiled, and not on with'ed specs. This | is really a similar case, though it is not quite as clear how to | get this effect in C++. Maybe we might get some opportunity with the LTO framework, when merging several translation units. -- Gaby
Re: -Wconversion versus libstdc++
On 18/01/07, Gabriel Dos Reis [EMAIL PROTECTED] wrote: On Thu, 18 Jan 2007, Manuel López-Ibáñez wrote: [...] | As the PR you noted, it wasn't part of C++. | | | You are wrong. the PR you noted is http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26167#c3 which you described as your favorite. The PR starts with this gcc reports the signedness probelm correctly, but g++ does not. See below for a demonstration: [...] Gabriel, I gave you all the information with revision numbers included. I did my homework. If you didn't believe me you could have proved me wrong just by running g++ with -Wconversion at that revision (or 4.1 or 4.2) and checking whether there was a warning for unsigned int ui = -1; or not. Moreover, in the comments of the PR, I also explained why the reporter had the wrong impression that there was a difference between C and C++ diagnostics for signed-unsigned conversions. I obviously wasted my time. Honestly, I don't want to enter in a discussion about you said this, you said that when any one can read and test what I / you said by himself/herself. I feel that I researched and wrote the above mail (and the comments on the PR) for nothing and I wasted my afternoon when I should be in bed drinking hot soup, hot milk with honey or sleeping. So I will stop here and I will wait until Joseph gives his opinion. Manuel.
Re: 27% regression of gcc 4.3 performance on cpu2k6/calculix
H. J. Lu wrote: Is that possible to extract a smaller testcase? I'm working on the small reproducer. That would take some time because of benchmark complexity. - Grigory
Re: -Wconversion versus libstdc++
On Thu, 18 Jan 2007, Manuel López-Ibáñez wrote: | On 18/01/07, Gabriel Dos Reis [EMAIL PROTECTED] wrote: | On Thu, 18 Jan 2007, Manuel López-Ibáñez wrote: | | [...] | | | As the PR you noted, it wasn't part of C++. | | | | | | You are wrong. | | the PR you noted is | | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26167#c3 | | which you described as your favorite. The PR starts with this | | gcc reports the signedness probelm correctly, but g++ does not. See | below for a demonstration: | | [...] | | | Gabriel, I gave you all the information with revision numbers | included. I did my homework. If you didn't believe me you could have | proved me wrong just by running g++ with -Wconversion at that | revision (or 4.1 or 4.2) and checking whether there was a warning for | unsigned int ui = -1; or not. I'm less in the business of assigning you're wrong, than you seem to be. And I don't mind you prove me wrong; we get a better understanding of the issue. However, fixating on proving wrong derails the discussion. In the PR, you noted: If you mean that gcc (and g++) should warn that a signed variable is passed to a function that expects an unsigned variable, then when using the -Wcoercion flag (provided by the Wcoercion project [*]), both cc1 and cc1plus report: [...] | I feel that I researched and wrote the above mail (and the comments on | the PR) for nothing and I wasted my afternoon when I should be in bed | drinking hot soup, hot milk with honey or sleeping. and I should have prepared more slides for my classes, and close more PRs for GCC-4.0.4. -- Gaby
gcc doesn't build on ppc
gcc doesn't build on powerpc-apple-darwin9: /Volumes/mrs3/net/gcc-darwinO2/./prev-gcc/xgcc -B/Volumes/mrs3/net/gcc-darwinO2/./p rev-gcc/ -B/Volumes/mrs3/Packages/gcc-061208/powerpc-apple-darwin9/bin/ -c -g -O2 -mdynamic-no-pic -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing -prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings - Wold-style-definition -Wmissing-format-attribute -Werror -fno-common -DHAVE_CONFI G_H -I. -I. -I../../gcc/gcc -I../../gcc/gcc/. -I../../gcc/gcc/../include -I./../int l -I../../gcc/gcc/../libcpp/include -I../../gcc/gcc/../libdecnumber -I../libdecnum ber\ ../../gcc/gcc/config/rs6000/rs6000.c -o rs6000.o cc1: warnings being treated as errors ../../gcc/gcc/config/rs6000/rs6000.c: In function ârs6000_emit_vector_compareâ: ../../gcc/gcc/config/rs6000/rs6000.c:11904: warning: ISO C90 forbids mixed declarat ions and code make[3]: *** [rs6000.o] Error 1 make[3]: *** Waiting for unfinished jobs rm cpp.pod gcc.pod make[2]: *** [all-stage2-gcc] Error 2 make[1]: *** [stage2-bubble] Error 2 make: *** [all] Error 2 :-(
Re: gcc doesn't build on ppc
Mike Stump writes: Mike gcc doesn't build on powerpc-apple-darwin9: Mike ../../gcc/gcc/config/rs6000/rs6000.c: In function ârs6000_emit_vector_compareâ: Mike ../../gcc/gcc/config/rs6000/rs6000.c:11904: warning: ISO C90 forbids mixed declarat Mike ions and code Is this due to Josh's patch? David
Re: Miscompilation of remainder expressions
For sure a/b is undefined In C, it is. In assembler it is perfectly well defined, i.e., it traps. But how is the trap handler supposed to know the source of a given instruction? M.
about the float lib
hi all, i meet some problem when use the ARM gcc 4.1.1 with arg -msoft-float, the gcc can't find the -lfloat. while to found the source code of float lib? Br Thomas
[Bug middle-end/28071] [4.1 regression] A file that can not be compiled in reasonable time/space
--- Comment #59 from hubicka at ucw dot cz 2007-01-18 09:51 --- Subject: Re: [4.1 regression] A file that can not be compiled in reasonable time/space Hi, just as heads up, the early inlining change made inliner to now fully inline to the function at -O2 (orignally we stopped because of inline unit growth doing just few of inlines). This enables more optimizations and reduces memory usage of all other passes except for scheduler, that increases. So we have roughly peak of 60MB GGC memory without scheduling, 360MB with scheduling, so this patch would be even more greatly appreciated ;) http://www.suse.de/~aj/SPEC/amd64/memory/pr28071-O2.rep Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28071
[Bug bootstrap/30495] New: can't compile on AIX
with both 4.1.0 and 4.1.1. at cc -g -DIN_GCC -DHAVE_CONFIG_H -DGENERATOR_FILE -o build/genattrtab \ build/genattrtab.o build/genautomata.o \ build/rtl.o build/read-rtl.o build/ggc-none.o build/min-insn-modes.o build/gensupport.o build/insn-conditions.o build/print-rtl.o build/errors.o \ build/varray.o ../build-powerpc-ibm-aix5.3.0.0/libiberty/libiberty.a -lm build/genattrtab ../../gcc/config/rs6000/rs6000.md tmp-attrtab.c I get : out of memory allocating 4072 bytes after a total of 416165366 -- Summary: can't compile on AIX Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mircea_lutic at yahoo dot com GCC build triplet: powerpc-ibm-aix5.3.0.0 GCC host triplet: powerpc-ibm-aix5.3.0.0 GCC target triplet: powerpc-ibm-aix5.3.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30495
[Bug middle-end/30494] ICE with VLA and openmp
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-01-18 10:13 ---
Confirmed, reduced testcase (I thought I had asked about this interaction
before):
int Birkhoff_with_Vol_para(int n)
{
int I;
#pragma omp for
for(I = 0; I 6; I++)
{
int v[n];
}
}
This ICEs for both the C and C++ front-ends. Considering VLA is C99, we should
support this. Also I bet you can produce a fortran code which also ICEs.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Component|c++ |middle-end
Ever Confirmed|0 |1
GCC build triplet|4.2.0 20070102 (prerelease) |
GCC host triplet|x86_64-unknown-linux-gnu|
GCC target triplet|x86_64-unknown-linux-gnu|
Keywords||openmp
Last reconfirmed|-00-00 00:00:00 |2007-01-18 10:13:33
date||
Summary|internal compiler error: in |ICE with VLA and openmp
|gimplify_expr, at |
|gimplify.c:5979 [-fopenmp] |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30494
[Bug bootstrap/30495] can't compile on AIX
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-01-18 10:18 --- From http://gcc.gnu.org/install/specific.html: out of memory bootstrap failures may indicate a problem with process resource limits (ulimit). Hard limits are configured in the /etc/security/limits system configuration file. Did you read that page and does changing the limits help? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30495
[Bug c++/30496] New: Compilation errors when compiled with optimization flags
When I compile the following code with optimization flags (O1, O2, O3, Os) I
get compilation errors. If the code is compiled without optimizations (-g, -O0)
then everything is ok.
Error.cpp :
#include libintl.h
#define _(x) gettext(x)
typedef struct
{
int code;
const char* p_str;
} ErrorStr;
static ErrorStr g_errorStrTab[] =
{
{ 1,_(Success) },
{ 2,_(Invalid error code) },
{ 3,_(Invalid argument) },
{ 4,_(Convertion error) }
};
The platform is : Debian 2.2 Potato, glibc 2.1.3
The output of gcc -v -save-temps -Os -c Error.cpp is :
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ./configure --enable-languages=c,c++
Thread model: posix
gcc version 4.1.1
/usr/local/libexec/gcc/i686-pc-linux-gnu/4.1.1/cc1plus -E -quiet -v
-D_GNU_SOURCE Error.cpp -mtune=pentiumpro -Os -fpch-preprocess -o Erro
r.ii
ignoring nonexistent directory NONE/include
ignoring nonexistent directory
/usr/local/lib/gcc/i686-pc-linux-gnu/4.1.1/../../../../i686-pc-linux-gnu/include
#include ... search starts here:
#include ... search starts here:
/usr/local/lib/gcc/i686-pc-linux-gnu/4.1.1/../../../../include/c++/4.1.1
/usr/local/lib/gcc/i686-pc-linux-gnu/4.1.1/../../../../include/c++/4.1.1/i686-pc-linux-gnu
/usr/local/lib/gcc/i686-pc-linux-gnu/4.1.1/../../../../include/c++/4.1.1/backward
/usr/local/include
/usr/local/lib/gcc/i686-pc-linux-gnu/4.1.1/include
/usr/include
End of search list.
/usr/local/libexec/gcc/i686-pc-linux-gnu/4.1.1/cc1plus -fpreprocessed Error.ii
-quiet -dumpbase Error.cpp -mtune=pentiumpro -auxbase Error
-Os -version -o Error.s
GNU C++ version 4.1.1 (i686-pc-linux-gnu)
compiled by GNU C version 4.1.1.
GGC heuristics: --param ggc-min-expand=38 --param ggc-min-heapsize=15901
Compiler executable checksum: 6b1156c38beeebd4aa05553feb32ed24
Error.cpp:13: error: statement-expressions are allowed only inside functions
Error.cpp:14: error: statement-expressions are allowed only inside functions
Error.cpp:14: error: redefinition of 'char* __result'
Error.cpp:13: error: 'char* __result' previously declared here
Error.cpp:14: error: redefinition of 'char* __translation__'
Error.cpp:13: error: 'char* __translation__' previously declared here
Error.cpp:14: error: redefinition of 'int __catalog_counter__'
Error.cpp:13: error: 'int __catalog_counter__' previously declared here
Error.cpp:15: error: statement-expressions are allowed only inside functions
Error.cpp:15: error: redefinition of 'char* __result'
Error.cpp:13: error: 'char* __result' previously declared here
Error.cpp:15: error: redefinition of 'char* __translation__'
Error.cpp:13: error: 'char* __translation__' previously declared here
Error.cpp:15: error: redefinition of 'int __catalog_counter__'
Error.cpp:13: error: 'int __catalog_counter__' previously declared here
Error.cpp:16: error: statement-expressions are allowed only inside functions
Error.cpp:16: error: redefinition of 'char* __result'
Error.cpp:13: error: 'char* __result' previously declared here
Error.cpp:16: error: redefinition of 'char* __translation__'
Error.cpp:13: error: 'char* __translation__' previously declared here
Error.cpp:16: error: redefinition of 'int __catalog_counter__'
Error.cpp:13: error: 'int __catalog_counter__' previously declared here
--
Summary: Compilation errors when compiled with optimization flags
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: csandu4096 at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30496
[Bug c++/30496] Compilation errors when compiled with optimization flags
--- Comment #1 from csandu4096 at gmail dot com 2007-01-18 10:51 --- Created an attachment (id=12916) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12916action=view) Error.ii -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30496
[Bug c++/30496] Compilation errors when compiled with optimization flags
--- Comment #2 from csandu4096 at gmail dot com 2007-01-18 10:51 --- Created an attachment (id=12917) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12917action=view) Error.s -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30496
[Bug tree-optimization/21548] [4.0 regression] Wrong warning about uninitialized variable
--- Comment #15 from gdr at gcc dot gnu dot org 2007-01-18 11:40 --- Won't fix for GCC-4.0.x -- gdr at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21548
[Bug c/21659] [4.0/4.1/4.2/4.3 Regression] [unit-at-a-time] weak declaration must precede definition error missing at = O1
--- Comment #5 from gdr at gcc dot gnu dot org 2007-01-18 11:41 --- not release critical for GCC-4.0.x -- gdr at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.0.4 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21659
[Bug target/22077] [4.0 Regression] vec_all_eq does not produce good result
--- Comment #16 from gdr at gcc dot gnu dot org 2007-01-18 11:42 --- not release critical for GCC-4.0.x -- gdr at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|4.0.4 |4.1.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22077
[Bug c++/22252] [4.0 Regression] pragma interface/implementation still break synthesized methods
--- Comment #12 from gdr at gcc dot gnu dot org 2007-01-18 11:42 --- not release critical for GCC-4.0.x -- gdr at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|4.0.4 |4.1.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22252
[Bug c/22297] [4.0/4.1/4.2/4.3 Regression] missing uninitialization warning
--- Comment #5 from gdr at gcc dot gnu dot org 2007-01-18 11:43 --- nnot release critical for GCC-4.0.x -- gdr at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.0.4 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22297
[Bug tree-optimization/22360] [4.0 Regression] upper_bound_in_type and lower_bound_in_type are buggy
--- Comment #7 from gdr at gcc dot gnu dot org 2007-01-18 11:44 --- Fixed in GCC-4.1.1 not release critcal for GCC-4.0.x -- gdr at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|4.0.4 |4.1.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22360
[Bug tree-optimization/22415] [4.0 Regression] ICE in coalesce_abnormal_edges
--- Comment #11 from gdr at gcc dot gnu dot org 2007-01-18 11:45 --- fixed in GCC-4.1.0 not release critical for GCC-4.0.x -- gdr at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|4.0.4 |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22415
[Bug c/30497] New: compiling binutils 2.17 on aix fails with gcc 4.1.1
-bash-3.00$ gcc -v Using built-in specs. Target: powerpc-ibm-aix5.3.0.0 Configured with: /data1/JM/gcc-4.1.1/configure --prefix=/usr/unic/libexec/gcc/4.1.1 --enable-languages=c,c++ --disable-nls Thread model: aix gcc version 4.1.1 -bash-3.00$ gcc -save-temps -DHAVE_CONFIG_H -I. -I.././binutils -I. -D_GNU_SOURCE -I. -I.././binutils -I../bfd -I.././binutils/../bfd \ -I.././binutils/../include -I.././binutils/../intl -I../intl -DLOCALEDIR=\/usr/unic/libexec/binutils/2.17/share/locale\ \ -Dbin_dummy_emulation=bin_aix5_emulation -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Werror -g -O2 -c readelf.c readelf.c: In function 'get_dynamic_data': readelf.c:6882: error: unrecognizable insn: (insn 190 186 191 9 readelf.c:6877 (parallel [ (set (mem:SI (plus:SI (reg:SI 29 29 [orig:123 ivtmp.1079 ] [123]) (const_int 4294967288 [0xfff8])) [0 S4 A8]) (reg:SI 3 3)) (set (reg:SI 29 29 [orig:123 ivtmp.1079 ] [123]) (plus:SI (reg:SI 29 29 [orig:123 ivtmp.1079 ] [123]) (const_int 4294967288 [0xfff8]))) ]) -1 (nil) (nil)) readelf.c:6882: internal compiler error: in extract_insn, at recog.c:2084 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. -- Summary: compiling binutils 2.17 on aix fails with gcc 4.1.1 Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: major Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jorgen dot moth at uni-c dot dk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30497
[Bug c/30497] compiling binutils 2.17 on aix fails with gcc 4.1.1
--- Comment #1 from jorgen dot moth at uni-c dot dk 2007-01-18 11:54 --- Created an attachment (id=12918) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12918action=view) readelf.i -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30497
[Bug libfortran/30498] New: Support traceback (backtrace) on errors
+++ This bug was initially created as a clone of Bug #29649 +++ Running an application I got the following error Fortran runtime error: Attempt to allocate negative amount of memory. Possible integer overflow This is not very helpful in debugging, as it gives no clue as to where in the code it occurred. It would be extremely helpful to have a way to force a backtrace produced, either explicitly via stderr (as Intel Fortran does for code compiled with -traceback), or implicitly by producing a core dump. The core dump has been implemented in bug #29649. A draft patch, containing both the now-checked in core dumping and the traceback can be found at http://gcc.gnu.org/ml/fortran/2006-11/msg00634.html That patch calls the addr2line to translate the address to the file/line number. The library used by addr2line cannot be used as it is GPL. (Cf. PR 5773 for gcj.) FX wrote in the initial PR: It was mentionned on IRC tonight that Daniel Berlin has a library that extracts line and file information from DWARF2 info. It's internal to Google, but he said he'll see if he can get it released. We'll have to get back to him in some time... -- Summary: Support traceback (backtrace) on errors Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org BugsThisDependsOn: 29649 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30498
[Bug libfortran/29649] Force core dump on runtime library errors
--- Comment #14 from burnus at gcc dot gnu dot org 2007-01-18 12:54 --- Subject: Bug 29649 Author: burnus Date: Thu Jan 18 12:54:11 2007 New Revision: 120897 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=120897 Log: 2007-01-18 Francois-Xavier Coudert [EMAIL PROTECTED] Tobias Burnus [EMAIL PROTECTED] PR libfortran/29649 * gfortran.h (gfc_option_t): Add flag_dump_core. * lang.opt: Add -fdump-core option. * invoke.texi: Document the new options. * trans-decl.c (gfc_build_builtin_function_decls): Add new options to the call to set_std. * options.c (gfc_init_options, gfc_handle_option): Set the new options. 2007-01-18 Francois-Xavier Coudert [EMAIL PROTECTED] Tobias Burnus [EMAIL PROTECTED] PR libfortran/29649 * runtime/environ.c (variable_table): New GFORTRAN_ERROR_DUMPCORE environment variable. * runtime/compile_options.c (set_std): Add new argument. * runtime/error.c (sys_exit): Move from io/unix.c. Add coredump functionality. * libgfortran.h (options_t): New dump_core and backtrace members. (sys_exit): Move prototype. * io/unix.c (sys_exit): Move to runtime/error.c. * configure.ac: Add check for getrlimit. * configure: Regenerate. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/invoke.texi trunk/gcc/fortran/lang.opt trunk/gcc/fortran/options.c trunk/gcc/fortran/trans-decl.c trunk/libgfortran/ChangeLog trunk/libgfortran/configure trunk/libgfortran/configure.ac trunk/libgfortran/io/unix.c trunk/libgfortran/libgfortran.h trunk/libgfortran/runtime/compile_options.c trunk/libgfortran/runtime/environ.c trunk/libgfortran/runtime/error.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29649
[Bug libfortran/29649] Force core dump on runtime library errors
--- Comment #15 from burnus at gcc dot gnu dot org 2007-01-18 12:56 --- Fixed in the trunk. Creating a backtrace is now PR 30498. -- burnus at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn|5773| Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29649
[Bug c/8268] no compile time array index checking
--- Comment #43 from mueller at gcc dot gnu dot org 2007-01-18 13:00 --- Subject: Bug 8268 Author: mueller Date: Thu Jan 18 13:00:33 2007 New Revision: 120898 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=120898 Log: 2007-01-18 Dirk Mueller [EMAIL PROTECTED] · Richard Guenther [EMAIL PROTECTED] · PR diagnostic/8268 · * doc/invoke.texi (Warray-bounds): Document -Warray-bounds. · * common.opt (Warray-bounds): Add new warning option. · * c-opts.c (c_common_handle_option): Define -Warray-bounds · if -Wall is given. * Makefile.in: make tree-vrp.o depend on toplev.h · * tree-vrp.c (vrp_finalize): Call check_array_refs if -Warray-bounds · is enabled. · (check_array_refs, check_array_bounds, check_array_ref): New. · * gcc.dg/Warray-bounds.c: New testcase. * gcc.dg/Warray-bounds-2.c: New testcase. * g++.dg/warn/Warray-bounds.C: New testcase. * g++.dg/warn/Warray-bounds-2.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/warn/Warray-bounds-2.C trunk/gcc/testsuite/g++.dg/warn/Warray-bounds.C trunk/gcc/testsuite/gcc.dg/Warray-bounds-2.c trunk/gcc/testsuite/gcc.dg/Warray-bounds.c Modified: trunk/gcc/ChangeLog trunk/gcc/Makefile.in trunk/gcc/c-opts.c trunk/gcc/common.opt trunk/gcc/doc/invoke.texi trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vrp.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8268
[Bug c/8268] no compile time array index checking
--- Comment #44 from mueller at gcc dot gnu dot org 2007-01-18 13:12 --- Fixed for 4.3. -- mueller at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||4.3.0 Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8268
[Bug tree-optimization/30440] internal compiler error: in find_or_generate_expression, at tree-ssa-pre.c:1472
--- Comment #11 from jasonmbechtel at gmail dot com 2007-01-18 13:48 --- I'm trying to build a more recent 4.1.2 so I can get this program compiled. Unfortunately, I am running into the same problem with the SVN checkout (as of 11pm 1/17/07, EST) and with the last two weekly snapshots (gcc-core-4.1-20070108 and gcc-core-4.1-20070115). I installed gmp and mpfr. I create a subdir of the top-level 'gcc' directory named localtarget and cd into it. I run ../configure without any special arguments and it completes without error. I run 'make bootstrap-lean' and they all die at the following: gcc -c -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute -fno-common -Wno-error -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I../../gcc -I../../gcc/build -I../../gcc/../include -I../../gcc/../libcpp/include -I../../gcc/../libdecnumber -I../libdecnumber-o build/gengtype-lex.o gengtype-lex.c gcc: gengtype-lex.c: No such file or directory gcc: no input files make[3]: *** [build/gengtype-lex.o] Error 1 make[3]: *** Waiting for unfinished jobs rm fsf-funding.pod gcov.pod gfdl.pod cpp.pod gpl.pod gcc.pod make[3]: Leaving directory `/home/jason/gcc/gcc/localtarget/gcc' make[2]: *** [all-stage1-gcc] Error 2 make[2]: Leaving directory `/home/jason/gcc/gcc/localtarget' make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory `/home/jason/gcc/gcc/localtarget' make: *** [bootstrap-lean] Error 2 Doing a regular 'make' also results in the error: gcc: gengtype-lex.c: No such file or directory Any help? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30440
[Bug fortran/30481] Accepts namelist-group object with assumed character length
--- Comment #2 from pault at gcc dot gnu dot org 2007-01-18 14:27 ---
Confirmed.
With this patch:
Index: gcc/fortran/match.c
===
*** gcc/fortran/match.c (revision 120859)
--- gcc/fortran/match.c (working copy)
*** gfc_match_namelist (void)
*** 2600,2605
--- 2600,2612
gfc_error_check ();
}
+ if (sym-ts.type == BT_CHARACTER sym-ts.cl-length == NULL)
+ {
+ gfc_error (Assumed character length '%s' in namelist '%s' at
+%C is not allowed, sym-name, group_name-name);
+ gfc_error_check ();
+ }
+
if (sym-as sym-as-type == AS_ASSUMED_SHAPE
gfc_notify_std (GFC_STD_GNU, Assumed shape array '%s' in
namelist '%s' at %C is an extension.,
you now get
pr30481.f90:3.18:
namelist /abc/ c
1
Error: Assumed character length 'c' in namelist 'abc' at (1) is not allowed
If you feel like submitting/committing, please feel free.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2007-01-18 14:27:38
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30481
[Bug c++/30499] New: gcc segfault on linux kernel 2.6.17.10
Kernel was download from www.kernel.org Compile command is fakeroot make-kpkg --initrd --append-to-version=-custom1 kernel_image kernel_headers Error is: drivers/video/cirrusfb.c: In function â#152;cirrusfb_set_par_fooâ: drivers/video/cirrusfb.c:1573: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. For Debian GNU/Linux specific bug reporting instructions, see URL:file:///usr/share/doc/gcc-4.1/README.Bugs. The bug is not reproducible, so it is likely a hardware or OS problem. make[3]: *** [drivers/video/cirrusfb.o] Error 1 make[2]: *** [drivers/video] Error 2 make[1]: *** [drivers] Error 2 make[1]: Leaving directory `/usr/src/linux-2.6.17.10' make: *** [debian/stamp-build-kernel] Error 2 -- Summary: gcc segfault on linux kernel 2.6.17.10 Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dronord at gmail dot com GCC host triplet: Linux kubuntu Edgy;gcc version is default http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30499
[Bug c++/30499] gcc segfault on linux kernel 2.6.17.10
--- Comment #1 from dronord at gmail dot com 2007-01-18 14:32 --- version of compiler not exactly -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30499
[Bug fortran/30283] [4.2 and 4.1 only] Specification expression not properly recognized in declaration
-- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-01-18 14:33:46 date|| Summary|Specification expression not|[4.2 and 4.1 only] |properly recognized in |Specification expression not |declaration |properly recognized in ||declaration http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30283
[Bug middle-end/20623] ICE: fold check: original tree changed by fold with --enable-checking=fold
--- Comment #13 from ghazi at gcc dot gnu dot org 2007-01-18 14:42 --- 4.1.x branch still has the fold checking errors with labels: http://gcc.gnu.org/ml/gcc-testresults/2007-01/msg00699.html http://gcc.gnu.org/ml/gcc-testresults/2007-01/msg00700.html -- ghazi at gcc dot gnu dot org changed: What|Removed |Added Known to fail|4.0.4 |4.0.4 4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20623
[Bug c/30475] assert(int+100 int) optimized away
--- Comment #27 from felix-gcc at fefe dot de 2007-01-18 15:20 --- Oh, so C++ code using vector gets faster, you say? Let's see... This is vector.C from http://ptrace.fefe.de/vector.C It does some assignments to a vector. It runs the loop 10 times and takes the minimum cycle counter. $ g++ -O2 -o vector vector.C $ ./vector 20724 cycles $ g++ -O2 -o vector vector.C -fwrapv $ ./vector 20724 cycles $ And AGAIN you are proven wrong by the facts. Do you have some more proof where this came from? Man, this is ridiculous. Just back out that optimization and I'll shut up. -- felix-gcc at fefe dot de changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|WONTFIX | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30475
[Bug c/30475] assert(int+100 int) optimized away
--- Comment #28 from felix-gcc at fefe dot de 2007-01-18 15:23 --- Mhh, so I wondered, how can it be that the code is exactly as fast. So I disassembled the binary. You know what? IT'S THE EXACT SAME CODE. So, my conjecture is, again: your optimization does exactly NO good whatsoever, it just breaks code that tries to defend against integer overflows. Please remove it. Now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30475
[Bug bootstrap/30495] can't compile on AIX
--- Comment #2 from mircea_lutic at yahoo dot com 2007-01-18 15:54 --- out of memory allocating 16 bytes after a total of 4161654796 bytes /etc/security/limits: default: fsize = 2097151 core = 2097151 cpu = -1 data = 262144 rss = 65536 stack = 65536 nofiles = 2000 I had someone add memory to the machine and still : build/genattrtab ../../gcc/config/rs6000/rs6000.md tmp-attrtab.c out of memory allocating 16 bytes after a total of 4161654796 bytes On a closer look that's 4161654796 =F80D-D00Ch I mean genattrtab is trying to allocate 4 gigs of mem I think this is a bit too much for anything a compiler might want to do. I suspect it's allocating storage in a loop Fortunately I found the gcc binaries for my machine (as a matter of fact I used gcc 4.1.1 to compile itself). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30495
[Bug c++/30500] New: pragma GCC system_header vs templates
I don't think we have an open PR for this well known issue so... As you can
see, in the example below, the pragma is totally ineffective with templates,
even when the involved types are non dependent.
By the way, sad to say that, but the way ICC implements the GCC pragma for
compatibility sake is, once more, better than the original: no warning from ICC
(-Wall on ICC as a switch, excellent warnings without the pragma).
paolo:~/Work more test.h
#pragma GCC system_header
int f()
{
double d = 0.0;
return d;
}
templatetypename T
int g()
{
double d = 0.0;
return d;
}
templatetypename T
T h()
{
double d = 0.0;
return d;
}
paolo:~/Work more test.cc
#include test.h
int main()
{
f();
gint();
hint();
}
paolo:~/Work g++ -c -Wconversion test.cc
test.h: In function 'int g() [with T = int]':
test.cc:6: instantiated from here
test.h:13: warning: converting to 'int' from 'double'
test.h:13: warning: conversion to 'int' from 'double' may alter its value
test.h: In function 'T h() [with T = int]':
test.cc:7: instantiated from here
test.h:20: warning: converting to 'int' from 'double'
test.h:20: warning: conversion to 'int' from 'double' may alter its value
--
Summary: pragma GCC system_header vs templates
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pcarlini at suse dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30500
[Bug ada/30501] New: GNAT BUG BOX: 16-bit target Standard.Integer
[EMAIL PROTECTED]:~/tmp/GNAT_Test$ m32c-elf-gcc -v -gnatv -gnatS -S --RTS=rts integer_test.ads Using built-in specs. Target: m32c-elf Configured with: ../gcc-4.2-20070110/configure --target=m32c-elf --prefix=/home/psch/tmp/GNAT_Test/localinst --enable-languages=c,ada --disable-nls --disable-multilib --disable-libada --disable-libssp --program-prefix=m32c-elf- Thread model: single gcc version 4.2.0 20070110 (prerelease) /home/psch/tmp/GNAT_Test/localinst/libexec/gcc/m32c-elf/4.2.0/gnat1 -quiet -dumpbase integer_test.ads -fRTS=rts -gnatv -gnatS integer_test.ads -o integer_test.s GNAT 4.2.0 20070110 (prerelease) Copyright 1992-2006, Free Software Foundation, Inc. -- Representation of package Standard -- This is not accurate Ada, since new base types cannot be -- created, but the listing shows the target dependent -- characteristics of the Standard types for this compiler package Standard is pragma Pure(Standard); type Boolean is (False, True); for Boolean'Size use 1; for Boolean use (False = 0, True = 1); type Integer is range -(2 **15) .. +(2 **15 - 1); for Integer'Size use 16; subtype Natural is Integer range 0 .. Integer'Last; subtype Positive is Integer range 1 .. Integer'Last; type Short_Short_Integer is range -(2 **7) .. +(2 **7 - 1); for Short_Short_Integer'Size use 8; type Short_Integer is range -(2 **15) .. +(2 **15 - 1); for Short_Integer'Size use 16; type Long_Integer is range -(2 **31) .. +(2 **31 - 1); for Long_Integer'Size use 32; type Long_Long_Integer is range -(2 **63) .. +(2 **63 - 1); for Long_Long_Integer'Size use 64; type Short_Float is digits 6 range -16#0._FF#E+32 .. 16#0._FF#E+32; for Short_Float'Size use 32; type Float is digits 6 range -16#0._FF#E+32 .. 16#0._FF#E+32; for Float'Size use 32; type Long_Float is digits 15 range -16#0.___F8#E+256 .. 16#0.___F8#E+256; for Long_Float'Size use 64; type Long_Long_Float is digits 15 range -16#0.___F8#E+256 .. 16#0.___F8#E+256; for Long_Long_Float'Size use 64; type Character is (...) for Character'Size use 8; -- See RM A.1(35) for details of this type type Wide_Character is (...) for Wide_Character'Size use 16; -- See RM A.1(36) for details of this type type Wide_Wide_Character is (...) for Wide_Character'Size use 32; -- See RM A.1(36) for details of this type type String is array (Positive range ) of Character; pragma Pack (String); type Wide_String is array (Positive range ) of Wide_Character; pragma Pack (Wide_String); type Wide_Wide_String is array (Positive range ) of Wide_Wide_Character; pragma Pack (Wide_Wide_String); type Duration is delta 0.1 range -((2 ** 63 - 1) * 0.1) .. +((2 ** 63 - 1) * 0.1); for Duration'Small use 0.1; Constraint_Error : exception; Program_Error: exception; Storage_Error: exception; Tasking_Error: exception; Numeric_Error: exception renames Constraint_Error; end Standard; Compiling: integer_test.ads (source file time stamp: 2007-01-18 16:23:40) +===GNAT BUG DETECTED==+ | 4.2.0 20070110 (prerelease) (m32c-unknown-elf) GCC error:| | in gnat_to_gnu, at ada/trans.c:2675 | | No source file position information available| | Please submit a bug report; see http://gcc.gnu.org/bugs.html.| | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact gcc or gnatmake command that you entered. | | Also include sources listed below in gnatchop format | | (concatenated together with no headers between files). | +==+ Please include these source files with error report Note that list may not be accurate in some cases, so please double check that the problem can still be reproduced with the set of files listed. integer_test.ads 14 lines: No errors compilation abandoned -- The bug also occures with avr-elf. -- integer_test.ads: package Integer_Test is -- type Int_Type is new Short_Short_Integer; -- OK -- type Int_Type is new Short_Integer;-- GNAT BUG BOX type Int_Type is new Integer; -- GNAT BUG BOX (M32C: same as Short_Integer) -- type Int_Type is new Long_Integer; -- OK -- type Int_Type is new Long_Long_Integer;-- OK -- type Int_Type is range -(2 **15) .. +(2 **15 - 1); -- OK (M32C: same as Integer) -- for Int_Type'Size use 16; Var : Int_Type; end Integer_Test;
[Bug target/30485] ICE in rs6000_emit_vector_compare when building with -fno-trapping-math
--- Comment #1 from jconner at gcc dot gnu dot org 2007-01-18 16:44 --- Subject: Bug 30485 Author: jconner Date: Thu Jan 18 16:44:03 2007 New Revision: 120902 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=120902 Log: 2007-01-18 Josh Conner [EMAIL PROTECTED] PR target/30485 * config/rs6000/rs6000.c (rs6000_emit_vector_compare): Add support for UNLE, UNLT, UNGE, and UNGT. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/rs6000.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30485
[Bug target/30485] ICE in rs6000_emit_vector_compare when building with -fno-trapping-math
--- Comment #2 from jconner at gcc dot gnu dot org 2007-01-18 16:45 --- Subject: Bug 30485 Author: jconner Date: Thu Jan 18 16:44:50 2007 New Revision: 120903 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=120903 Log: 2007-01-18 Josh Conner [EMAIL PROTECTED] PR target/30485 * gcc.dg/vect/vect.exp: Add support for no-trapping-math tests. * gcc.dg/vect/no-trapping-math-1: New. * gcc.dg/vect/no-trapping-math-2: New. Added: trunk/gcc/testsuite/gcc.dg/vect/no-trapping-math-1.c trunk/gcc/testsuite/gcc.dg/vect/no-trapping-math-2.c Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/vect/vect.exp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30485
[Bug c/30502] New: compiler inlines slightly invalid function without warning
Reading specs from /bin/../lib/gcc/i686-pc-linux-gnu/3.4.6/specs
Configured with: gcc/configure --enable-languages=c,c++ --disable-nls
--disable-c-mbchar --disable-multilib --with-gnu-as --with-gnu-ld
rtv.c ---
extern int putchar (int c);
static int __inline__ compute_tables_error_code ( int ots );
int main (void)
{
int err_code = putchar('z');
if (compute_tables_error_code (err_code))
return 1;
else
return 0;
}
static int __inline__ compute_tables_error_code ( int ots )
{
if ( ots )
return 0x85;
}
rtv.c ---
gcc -Wall -O2 -fno-inline -Winline rtv.c
rtv.c: In function `compute_tables_error_code':
rtv.c:18: warning: control reaches end of non-void function
rtv.c: In function `main':
rtv.c:15: warning: inlining failed in call to `compute_tables_error_code'
rtv.c:8: warning: called from here
--
Summary: compiler inlines slightly invalid function without
warning
Product: gcc
Version: 3.4.6
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: yakov at emc dot com
GCC target triplet: gcc version 3.4.6 (SuSE Linux)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30502
[Bug tree-optimization/30440] internal compiler error: in find_or_generate_expression, at tree-ssa-pre.c:1472
--- Comment #12 from pinskia at gcc dot gnu dot org 2007-01-18 17:20 --- (In reply to comment #11) Any help? Yes to compile the snapshot (and SVN) you need bision. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30440
[Bug libfortran/30007] libgfortran doesn't build for sh-elf
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-01-18 17:28
---
So, the reduced code looks like this:
extern void bar (void);
extern __typeof(bar) bar __asm__(foo);
void bar (void) { ; }
extern __typeof(bar) gee __attribute__((__alias__(foo)));
Ian Lance Taylor gave me the solution on IRC, which is: on SH, all symbol names
are preprended an underscore, but in the above code __asm__(foo) does not
prepend it for us. The macro defined for this underscore (and other such
prefixes on other targets, although I don't any in particular) is
__USER_LABEL_PREFIX__, so the final fix is:
#define stringize(x) expand_macro(x)
#define expand_macro(x) # x
extern void bar (void);
extern __typeof(bar) bar __asm__(stringize(__USER_LABEL_PREFIX__) foo);
void bar (void) { ; }
extern __typeof(bar) gee __attribute__((__alias__(foo)));
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot
|dot org |org
Status|NEW |ASSIGNED
Last reconfirmed|2007-01-05 10:10:35 |2007-01-18 17:28:42
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30007
[Bug c/30475] assert(int+100 int) optimized away
--- Comment #29 from pinskia at gcc dot gnu dot org 2007-01-18 17:36 --- Oh and I meant at, not get or []. at does bounds checking. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30475
[Bug bootstrap/30495] can't compile on AIX
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-01-18 17:44 --- I mean genattrtab is trying to allocate 4 gigs of mem No, that is how much it allocated overall, not how much is actually still in use. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30495
[Bug libfortran/22423] Warnings when building libgfortran
--- Comment #9 from fxcoudert at gcc dot gnu dot org 2007-01-18 17:45 --- Once that last warning is fixed, I'd really like libgfortran to be built with -Werror by default, at least on linux systems (it's known to issue tons of warnings on some non-C99 systems, so we can't make it the default unconditionaly). -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-10-01 07:43:53 |2007-01-18 17:45:32 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22423
[Bug libfortran/30007] libgfortran doesn't build for sh-elf
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-01-18 17:52 ---
__USER_LABEL_PREFIX__ should be a string already.
so you just need:
extern void bar (void);
extern __typeof(bar) bar __asm__(__USER_LABEL_PREFIX__ foo);
void bar (void) { ; }
extern __typeof(bar) gee __attribute__((__alias__(foo)));
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30007
[Bug libfortran/30498] Support traceback (backtrace) on errors
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-01-18 17:59 --- (In reply to comment #0) It was mentionned on IRC tonight that Daniel Berlin has a library that extracts line and file information from DWARF2 info. It's internal to Google, but he said he'll see if he can get it released. We'll have to get back to him in some time... I since spoke to him again, and we'd better go ahead with our current plan. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-01-18 17:59:49 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30498
[Bug c/30502] compiler inlines slightly invalid function without warning
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-01-18 18:00 --- I think you mean the following options: -O2 -Wall -Winline and with 4.0.0 and above I get: t.c:9: warning: control may reach end of non-void function 'compute_tables_error_code' being inlined or: t.c: In function 'compute_tables_error_code': t.c:19: warning: control reaches end of non-void function PS this is not really invalid code, just undefined code. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30502
[Bug c/29521] Confusing warning for return with expression in function returning void
--- Comment #2 from patchapp at dberlin dot org 2007-01-18 18:05 --- Subject: Bug number PR 29521 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-01/msg01533.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29521
[Bug c++/30499] gcc segfault on linux kernel 2.6.17.10
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-01-18 18:06 --- Can you rerun the command which is failing and add -save-temps and then attach the resulting .i file if the segfault appears? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30499
[Bug c++/17854] Accept statement expressions at top level
--- Comment #8 from pinskia at gcc dot gnu dot org 2007-01-18 18:10 --- *** Bug 30496 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||csandu4096 at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17854
[Bug middle-end/30421] incorrect warning when using firstprivate and lastprivate clauses
--- Comment #4 from jakub at gcc dot gnu dot org 2007-01-18 18:23 --- Testing a fix. -- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-01-18 18:23:03 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30421
[Bug c/30503] New: ICE using phase 2 bootstrap output cc1 on tree.c
Using the phase 2 cc1 on tree.c results in a segmentation error. Phase 1 cc1 does not result in segmentation faults. This is on main at patchlevel 12900. Command: /var/tmp/gcc_r43/gcc.build.lnx14/gcc/xgcc -v -save-temps -B/var/tmp/gcc_r43/gcc.build.lnx14/gcc/ -B/usr/i686-pc-linux-gnu/bin/ -c -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wmissing-format-attribute-DHAVE_CONFIG_H -I. -I. -I../../gcc-4.3.0/gcc -I../../gcc-4.3.0/gcc/. -I../../gcc-4.3.0/gcc/../include -I../../gcc-4.3.0/gcc/../libcpp/include -I../../gcc-4.3.0/gcc/../libdecnumber -I../libdecnumber../../gcc-4.3.0/gcc/tree.c -o tree.o Output: Reading specs from /var/tmp/gcc_r43/gcc.build.lnx14/gcc/specs Target: i686-pc-linux-gnu Configured with: ../gcc-4.3.0/configure --prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc-bin/4.3.0 --includedir=/usr/lib/gcc/i686-pc-linux-gnu/4.3.0/include --datadir=/usr/share/gcc-data/i686-pc-linux-gnu/4.3.0 --mandir=/usr/share/gcc-data/i686-pc-linux-gnu/4.3.0/man --infodir=/usr/share/gcc-data/i686-pc-linux-gnu/4.3.0/info --with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/4.3.0/include/g++-v4 --enable-version-specific-runtime-libs --disable-nls --disable-checking --disable-werror --disable-multilib --disable-libgcj --disable-dssi --disable-checking --enable-shared --enable-threads=posix --enable-bootstrap --enable-__cxa_atexit --enable-languages=c,c++,fortran --with-cpu=pentium2 --with-system-zlib --enable-clocale=gnu Thread model: posix gcc version 4.3.0 20070118 (experimental) /var/tmp/gcc_r43/gcc.build.lnx14/gcc/cc1 -E -quiet -v -I. -I. -I../../gcc-4.3.0/gcc -I../../gcc-4.3.0/gcc/. -I../../gcc-4.3.0/gcc/../include -I../../gcc-4.3.0/gcc/../libcpp/include -I../../gcc-4.3.0/gcc/../libdecnumber -I../libdecnumber -iprefix /var/tmp/gcc_r43/gcc.build.lnx14/gcc/../../../lib/gcc/i686-pc-linux-gnu/4.3.0/ -isystem /var/tmp/gcc_r43/gcc.build.lnx14/gcc/include -DIN_GCC -DHAVE_CONFIG_H ../../gcc-4.3.0/gcc/tree.c -mtune=pentium2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wmissing-format-attribute -O2 -fpch-preprocess -o tree.i ignoring nonexistent directory /var/tmp/gcc_r43/gcc.build.lnx14/gcc/../../../lib/gcc/i686-pc-linux-gnu/4.3.0/include ignoring nonexistent directory /var/tmp/gcc_r43/gcc.build.lnx14/gcc/../../../lib/gcc/i686-pc-linux-gnu/4.3.0/../../../../i686-pc-linux-gnu/include ignoring nonexistent directory /var/tmp/gcc_r43/gcc.build.lnx14/gcc/../../../lib/gcc//lib/gcc/i686-pc-linux-gnu/4.3.0/include ignoring nonexistent directory /var/tmp/gcc_r43/gcc.build.lnx14/gcc/../../../lib/gcc//lib/gcc/i686-pc-linux-gnu/4.3.0/../../../../i686-pc-linux-gnu/include ignoring duplicate directory . ignoring duplicate directory ../../gcc-4.3.0/gcc/. #include ... search starts here: #include ... search starts here: . ../../gcc-4.3.0/gcc ../../gcc-4.3.0/gcc/../include ../../gcc-4.3.0/gcc/../libcpp/include ../../gcc-4.3.0/gcc/../libdecnumber ../libdecnumber /var/tmp/gcc_r43/gcc.build.lnx14/gcc/include /usr/local/include /usr/include End of search list. /var/tmp/gcc_r43/gcc.build.lnx14/gcc/cc1 -fpreprocessed tree.i -quiet -dumpbase tree.c -mtune=pentium2 -auxbase-strip tree.o -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wmissing-format-attribute -version -o tree.s GNU C version 4.3.0 20070118 (experimental) (i686-pc-linux-gnu) compiled by GNU C version 4.3.0 20070118 (experimental). GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 43ce5038e422d0a4c380c402a468014e ../../gcc-4.3.0/gcc/tree.c: In function 'int_cst_hash_hash': ../../gcc-4.3.0/gcc/tree.c:8131: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. -- Summary: ICE using phase 2 bootstrap output cc1 on tree.c Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: critical Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: malitzke at metronets dot com GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30503
[Bug c/30503] ICE using phase 2 bootstrap output cc1 on tree.c
--- Comment #1 from malitzke at metronets dot com 2007-01-18 18:31 --- Created an attachment (id=12919) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12919action=view) Detailed out using different optimization levels I also have similar output using Phase 1 cc1 (also at different otimization levels). In another attachment I am submitting tree.i. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30503
[Bug c/30503] ICE using phase 2 bootstrap output cc1 on tree.c
--- Comment #2 from malitzke at metronets dot com 2007-01-18 18:38 --- Created an attachment (id=12920) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12920action=view) Standard preprocessed file This file was created using the xgcc resulting from phase 2. I have another file tree.i using the phase 1 xgcc this differs on in the includes referenced. The includes diff equal for phase 1 and 2 (spot checks only) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30503
[Bug libfortran/30007] libgfortran doesn't build for sh-elf
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2007-01-18 18:49
---
(In reply to comment #5)
__USER_LABEL_PREFIX__ should be a string already.
so you just need:
extern void bar (void);
extern __typeof(bar) bar __asm__(__USER_LABEL_PREFIX__ foo);
void bar (void) { ; }
extern __typeof(bar) gee __attribute__((__alias__(foo)));
That one gives: c.c:2: error: expected string literal before _
__USER_LABEL_PREFIX__ is a string in the compiler config macros. For user code,
the macro expands to the underscore itself.
Actually, the problem with libgfortran is that it uses __USER_LABEL_PREFIX__
already, but it uses it for both __asm__ and __attribute__((__alias__(...))),
which is wrong. I'm testing the following patch, but I should really test it on
a machine that has a non-empty __USER_LABEL_PREFIX__. Any idea?
Index: libgfortran.h
===
--- libgfortran.h (revision 120891)
+++ libgfortran.h (working copy)
@@ -126,10 +126,10 @@
# define export_proto(x) sym_rename(x, PREFIX(x))
# define export_proto_np(x)extern char swallow_semicolon
# define iexport_proto(x) internal_proto(x)
-# define iexport(x)iexport1(x, __USER_LABEL_PREFIX__, IPREFIX(x))
-# define iexport1(x,p,y) iexport2(x,p,y)
-# define iexport2(x,p,y) \
- extern __typeof(x) PREFIX(x) __attribute__((__alias__(#p #y)))
+# define iexport(x)iexport1(x, IPREFIX(x))
+# define iexport1(x,y) iexport2(x,y)
+# define iexport2(x,y) \
+ extern __typeof(x) PREFIX(x) __attribute__((__alias__(#y)))
/* ??? We're not currently building a dll, and it's wrong to add dllexport
to objects going into a static library archive. */
#elif 0 defined(HAVE_ATTRIBUTE_DLLEXPORT)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30007
[Bug c/30503] ICE using phase 2 bootstrap output cc1 on tree.c
--- Comment #3 from malitzke at metronets dot com 2007-01-18 18:52 --- Prior to patclevel 12900 (about 12880) bootstrap failed even with O1 with segment error. For those dismissive folks who either say It works for me or claim that it is the submitters harware fault I can only aver the following: The work was done on a four processor server with 3G error correcting memory andover the last three weeks similar Segmentation errors occured; I have tried different binutils and different versions of glibc. I realize GCC-main is undergoing drastic changes right now. day before yesterday cc1 (from phse 1) worked with O1 and bombed out with O2. I doubt this cand be reduced to a simple test case as it occurs when trying to optimize across procedures. Glad to cooperate further. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30503
