Re: gcc 4.2 more strict check for function called through a non-compatible type
Andrew Pinski wrote: On Jul 4, 2006, at 5:07 PM, Yuri Pudgorodsky wrote: Can someone make the decision to reopen PR optimization/12085? And I posted a patch to do the same in Objective-C mode as C mode :). http://gcc.gnu.org/ml/gcc-patches/2004-08/msg01013.html That indeed will fix PR for all languages (btw why it was not commited to mainline?), but in a strange way. To get back to my original point, turning particular example of possibly undefined behavior is a bad practice. With current fix we have different syntaxes with identical semantic - calling function by casted pointer - doing things in a diverse way: 1) with direct cast: (int (*)(int)) foo - warn/trap since 3.x 2) with cast through void fptr: (int (*)(int)) (int(*)()) foo - warn/trap since 4.2 current 3) with assign: int (*bar)(int) = foo - no warn, no ICE, generates proper call, does not inline 4) with union assign: ... - no warn, no ICE, generates proper call, does not inline Isn't it logical to make fix for all constructions do the same: does not inline problematic call?
Re: gcc 4.2 more strict check for function called through a non-compatible type
Ian Lance Taylor writes: Andrew Haley [EMAIL PROTECTED] writes: Ian Lance Taylor writes: Yuri Pudgorodsky [EMAIL PROTECTED] writes: Compiling openssl-0.9.8b with gcc-4.2 snapshots, I found gcc 4.2 fortifies its check for function pointer conversion and generates abort for PEM_read_X509_AUX() and similar wrappers. Personally speaking, I agree with you that the compiler should issue a warning and then go ahead and compile the call. I don't think we gain anything useful by compiling a runtime abort in this case. The spirit of C is to let the user shoot themselves in the foot if they really want to. Any contrary opinions? The answer is here: keating Because if you *do* try to inline the call, you will get an ICE. Yes, I agree that the ICE, if it still exists, would have to be fixed, but to me that seems like a separate issue. No, it isn't a separate issue. We generate an abort rather than ICEing. We could allow this iff someone fixes the ICE. But we've provided a union cast to do the work if it's *really* needed; insn't that enough? I don't think gcc should go down the path of inserting trap calls for all undefined code. That is a pretty outrageous strawman. Nobody has suggested anything like that. That is reasonable if there is nothing else that can be done. But in this case there is something easy to do: compile the function call as directed. If indeed that's easy to do, yes. But I'm pretty confident the abort wouldn't have been inserted if that were the case. If we're going to guarantee this stuff for the future, we'll have to fix the bug, make sure it's doesn't destabilize the compiler and write some test cases. If we're really serious about it we should make it a documented extension to C. I'm not exactly opposed to that, but I do wonder if it's the best use of people's time. But this is free software, and people choose their own priorities. Andrew.
Re: gcc 4.2 more strict check for function called through a non-compatible type
On Jul 5, 2006, at 2:36 AM, Yuri Pudgorodsky wrote: 1) with direct cast: (int (*)(int)) foo - warn/trap since 3.x 2) with cast through void fptr: (int (*)(int)) (int(*)()) foo - warn/trap since 4.2 current I don't see why you are invoking this undefined behavior anyways. What are you trying to do? I don't see how this can ever work really anyways even if since most targets don't pass arguments via the stack. Yes x86 will most likely work but nothing else, even x86_64 will not work as floating point is passed via the SSE registers. -- Pinski
Re: dejaGNU testsuite files for 2.95.3 20010315 (release)
Mike Stump wrote: svn ls -r40553 svn+ssh://gcc.gnu.org/svn/gcc/branches/gcc-2_95-branch/ gcc/testsuite appears to be fairly close. Don't know why the tag was messed up. This number comes from the tags/gcc-2_95_3 tag. Thx a lot Mike, This is what i get from svn repo (after importing the corresponding key from 'gcc.gnu.org (209.132.176.174)': [EMAIL PROTECTED] tmp]# LANG=C; svn ls -r40553 svn+ssh://gcc.gnu.org/svn/gcc/branches/gcc-2_95-branch/ gcc/testsuite Permission denied (publickey,gssapi-with-mic). svn: Connection closed unexpectedly Finally i tried without ssh, then i get: [EMAIL PROTECTED] tmp]# LANG=C; svn ls -r40553 svn://gcc.gnu.org/svn/gcc/branches/gcc-2_95-branch/ gcc/testsuite .cvsignore COPYING COPYING.LIB ChangeLog INSTALL/ MAINTAINERS Makefile.in README config/ config-ml.in config.guess config.if config.sub configure configure.in contrib/ etc/ gcc/ include/ install-sh libchill/ libf2c/ libiberty/ libio/ libobjc/ libstdc++/ ltconfig ltmain.sh missing mkinstalldirs move-if-change symlink-tree texinfo/ ylwrap svn: 'gcc' is not a working copy Anyway i succeded using viewcvs at gnu using the release you mentionned at: http://gcc.gnu.org/viewcvs/branches/gcc-2_95-branch/gcc/testsuite/ChangeLog?view=logpathrev=40553 And i saw after 'co' that changelog header is: Revision 30159 - (view) (download) - [select for diffs] Modified Mon Oct 25 06:59:16 1999 UTC (6 years, 8 months ago) by law File length: 111635 byte(s) Diff to previous 28721 (colored) Stamp ChangeLogs for release Sun Oct 24 23:54:10 PDT 1999 Jeff Law ([EMAIL PROTECTED]) * gcc-2.95.2 Released. ... And what im using corresponds to IIRC: http://gcc.gnu.org/viewcvs/branches/gcc-2_95_2_1-branch/gcc/testsuite/ChangeLog?view=log Wed Dec 6 22:03:04 PST 2000 Jeff Law ([EMAIL PROTECTED]) * gcc-2.95.2.1 Released. Can i assume that what im using (2.95.2.1) is the last used previously to release 2.95.3 20010315 (release)? I'm messed with this, anyway i don't understand why the 2.95.3 doesn't have a testsuite folder within. Help appreciated, TIA Jose.
Re: gcc 4.2 more strict check for function called through a non-compatible type
Andrew Haley [EMAIL PROTECTED] writes: [...] | If we're going to guarantee this stuff for the future, we'll have to | fix the bug, make sure it's doesn't destabilize the compiler and write | some test cases. If we're really serious about it we should make it a | documented extension to C. if this is not going to be documented, then it does not worth spend time on trying to fix it. In fact, if it is not going to be documented then I would suggest we leave it as is. Furthermore, I've read people suggesting that we are gratuitously broking code. That is misleading. The code was invoking undefined behaviour and, before, we did not make any explicit guarantee about the semantics. It is one thing to argue for changing gear; but, one should try to stay in honest bounds. | I'm not exactly opposed to that, but I do | wonder if it's the best use of people's time. But this is free | software, and people choose their own priorities. Yup. We just have to make sure we don't end up in a mess. -- Gaby
Re: gcc 4.2 more strict check for function called through a non-compatible type
Andrew Pinski wrote: On Jul 5, 2006, at 2:36 AM, Yuri Pudgorodsky wrote: 1) with direct cast: (int (*)(int)) foo - warn/trap since 3.x 2) with cast through void fptr: (int (*)(int)) (int(*)()) foo - warn/trap since 4.2 current I don't see why you are invoking this undefined behavior anyways. What are you trying to do? I don't see how this can ever work really anyways even if since most targets don't pass arguments via the stack. Yes x86 will most likely work but nothing else, even x86_64 will not work as floating point is passed via the SSE registers. -- Pinski As I said, that is in openssl code - they have macros casting function pointers to args with different pointer type - e.g. foo(, char * p, ) - foo(,struct bar *p, ). For some obsure reason, they prefer doing that instead of casting the calling args itself (for type safety, e.g compile-time time check of function args?)
Re: gcc 4.2 more strict check for function called through a non-compatible type
Gabriel Dos Reis wrote: Furthermore, I've read people suggesting that we are gratuitously broking code. That is misleading. The code was invoking undefined behaviour and, before, we did not make any explicit guarantee about the semantics. It is one thing to argue for changing gear; but, one should try to stay in honest bounds. | I'm not exactly opposed to that, but I do | wonder if it's the best use of people's time. But this is free | software, and people choose their own priorities. Yup. We just have to make sure we don't end up in a mess. -- Gaby What I actually trying to get attention to, is the fact the we make undefined behavior even more undefined in *some* cases while leaving others intact. Moreover the semantic of check was already changed for 4.2 to hide taht ICE further - twice-casted case as well. And current behavior does runtime-trap too much code shooting not only ICE but well-behave code too. Actually all casts of not-compatible according to standard pointers is transformed to trap, even the sane convertion like from 'const char *' to 'char *'. Suppose un future when the optimizer will become smart enough to inline assign-casted function call that ICE'll raise again. Is it reasonable to tight check again and again?
Re: gcc 4.2 more strict check for function called through a non-compatible type
Yuri Pudgorodsky [EMAIL PROTECTED] writes: | Gabriel Dos Reis wrote: | Furthermore, I've read people suggesting that we are gratuitously | broking code. That is misleading. The code was invoking undefined | behaviour and, before, we did not make any explicit guarantee about | the semantics. | It is one thing to argue for changing gear; but, one should try to | stay in honest bounds. | | | I'm not exactly opposed to that, but I do | | wonder if it's the best use of people's time. But this is free | | software, and people choose their own priorities. | | Yup. We just have to make sure we don't end up in a mess. | | -- Gaby | | | What I actually trying to get attention to, is the fact the we make | undefined behavior | even more undefined in *some* cases while leaving others intact. I believe I understand your general objection. I don't feel strongly about the current behaviour, except that if it has to change then it must be a documented extension. I don't think we can meaningfully order the space of undefined behaviour and single out some as are more undefined behaviour than others. -- Gaby
Re: gcc 4.2 more strict check for function called through a non-compatible type
I apologize for presenting something which appears to be a strawman argument. That would never be my intent. Let me restate: I don't think gcc should ever insert a trap call for undefined code. We should only insert a trap call for code which will provably trap. We're currently breaking an existing free software program which formerly worked although it relied on undefined behaviour. Therefore, I think that changing this would not be a complete waste of time. Obviously I would never ask anybody else to work on it. I personally don't agree that this needs to be a documented extension. I'm simply going on a more general rule which I tried to state above: I don't think we should insert a trap call for undefined code. Ian Exactly as I think. What do we do if compiler ICE generating code for valid C syntax with defined behavior? Fix it! Why should we go another way for valid C syntax with undefined behavior? I was really surprised going deep in that issue. Its no excuse that generated code will have platform-depend semantic, natural way is just fix the ICE and does not cover with a trap.
Re: gcc 4.2 more strict check for function called through a non-compatible type
Ian Lance Taylor writes: Andrew Haley [EMAIL PROTECTED] writes: If we're going to guarantee this stuff for the future, we'll have to fix the bug, make sure it's doesn't destabilize the compiler and write some test cases. If we're really serious about it we should make it a documented extension to C. I'm not exactly opposed to that, but I do wonder if it's the best use of people's time. But this is free software, and people choose their own priorities. We're currently breaking an existing free software program which formerly worked although it relied on undefined behaviour. I would argue that it was already broken and just worked by accident, but I suppose that's a matter of taste. Therefore, I think that changing this would not be a complete waste of time. Obviously I would never ask anybody else to work on it. I personally don't agree that this needs to be a documented extension. I'm simply going on a more general rule which I tried to state above: I don't think we should insert a trap call for undefined code. This isn't as simple as saying don't insert a trap. If we make a change for openssh to allow this undefined behaviour, then do we agree to keep it working or not? If we agree that we will, then we have to at least add some test cases and we have to add some internal documentation to gcc. If we don't agree to keep it working, then even if we fix it today it may well break in the future. I don't think we're doing the developers of openssh any favours by compiling such code. Quite the reverse, IMO. Andrew.
Re: gcc 4.2 more strict check for function called through a non-compatible type
What do we do if compiler ICE generating code for valid C syntax with defined behavior? Fix it! Why should we go another way for valid C syntax with undefined behavior? The answer is in the question, no? -- Eric Botcazou
Re: Does SIMD optimization of GCC 3.4.6 work?
This question is not appropriate for the gcc@gcc.gnu.org mailing list. It would be appropriate on the [EMAIL PROTECTED] mailing list. Thanks. [EMAIL PROTECTED] writes: I am wondering if i have used -O, -O2 or -O3, do i still benifit from flags such as -march -fmpmath -ffast-math -mmx -sse -sse2 -3dnow? Yes, although the effects will depend on your code. In particular those options will mainly affect floating point code. And you may want to use -mtune as well. I am optimizing a video codec and i see barely any performance difference whether i use just -O2 or -ffast-math -march=athlon-xp -mmmx -msse -msse2 -m3dnow -mfpmath=sse,387 -O3. I recommend approaching this as you would any performance problem: use a profiler to identify the slowest parts of your code, and see what you can do to make them faster. It may be helpful to look at the generated assembly code: compile with the --save-temps option and look at the .s file. Ian
Re: gcc 4.2 more strict check for function called through a non-compatible type
Ian Lance Taylor [EMAIL PROTECTED] writes: I personally don't agree that this needs to be a documented extension. I'm simply going on a more general rule which I tried to state above: I don't think we should insert a trap call for undefined code. I realized that I am still not stating my position very clearly. I don't think we should make any extra effort to make this code work: after all, the code is undefined. I just think 1) we should not insert a trap; 2) we should not ICE. That is, we should handle it just as we handle code like a[i++] = i++;: caveat lector. For what it's worth, I tried to recreate the ICE after removing the trap insertion, but failed. So I'm not even sure the trap insertion is fixing a real problem any more. It works at the moment simply because it treats the call through a cast as a call through a function pointer, and therefore does not inline it. The Objective C frontend does ICE on the test case which Yuri pointed out, but that ICE is independent of the code in c-typeck.c. As far as I can tell in two minutes, that's a type error in the Objective C frontend: it passes int d = (double) x; to the middle-end, and the middle-end ICEs trying to assign a double value to an int variable. Ian
Re: gcc 4.2 more strict check for function called through a non-compatible type
For what it's worth, I tried to recreate the ICE after removing the trap insertion, but failed. So I'm not even sure the trap insertion is fixing a real problem any more. It works at the moment simply because it treats the call through a cast as a call through a function pointer, and therefore does not inline it. The Objective C frontend does ICE on the test case which Yuri pointed out, but that ICE is independent of the code in c-typeck.c. As far as I can tell in two minutes, that's a type error in the Objective C frontend: it passes int d = (double) x; to the middle-end, and the middle-end ICEs trying to assign a double value to an int variable. Ian This is explained why gcc-4.2 does ICE in objc mode but gcc-4.1 successfully generates call even for problematic casts (with casting to void (*)() trick).
Re: gcc 4.2 more strict check for function called through a non-compatible type
Andrew Haley [EMAIL PROTECTED] writes: If we make a change for openssh to allow this undefined behaviour, then do we agree to keep it working or not? If we agree that we will, then we have to at least add some test cases and we have to add some internal documentation to gcc. If we don't agree to keep it working, then even if we fix it today it may well break in the future. As I tried to clarify in a separate message, I don't think we agree to keep it working. I don't think we're doing the developers of openssh any favours by compiling such code. Quite the reverse, IMO. This is, I suppose, the root of our disagreement. I believe that the people we hurt are not the developers, who presumably have enough sense to fix their code after they see the warning (if they don't, I don't care about them). The people we are hurting are the users, who discover that their existing third party code does not compile with the new compiler. Again, if we gained anything by not compiling their code, then I would be all for it. But in this case we do not gain anything. We're actually going to extra effort to break their code. To me this is related to the point I raised at the steering committee panel discussion (I know you weren't there): I think we are too casual about breaking existing working code. And, yes, the code may well break, or not work as expected in this version of the compiler or in some later version. After all, it is undefined. But we warned them it might break. That is all we need to do. We don't need to take the extra step to ensure that it definitely does break. I believe that is inappropriate. (Although I could imagine a gcc option -ftrap-on-undefined-behaviour, which some people would certainly find useful). Ian
Re: A question about TYPE_ARG_TYPES
Kazu Hirata [EMAIL PROTECTED] writes: I keep finding places in GCC sources that check whether a member of TYPE_ARG_TYPES is 0. For example, for (link = TYPE_ARG_TYPES (function_or_method_type); link TREE_VALUE (link); link = TREE_CHAIN (link)) gen_type_die (TREE_VALUE (link), context_die); Notice that TREE_VALUE (link) is part of the loop condition. Now, do we ever allow a NULL in TYPE_ARG_TYPES? If so, what does that mean? My guess is that soneone was trying to be cautious about encountering a NULL in TYPE_ARG_TYPES. (If that's the case, we should be using gcc_assert instead.) Just guessing here, but what happens with an old-style function definition in C? void f(); Ian
Re: A question about TYPE_ARG_TYPES
Ian Lance Taylor wrote:
Kazu Hirata [EMAIL PROTECTED] writes:
I keep finding places in GCC sources that check whether a member of
TYPE_ARG_TYPES is 0. For example,
for (link = TYPE_ARG_TYPES (function_or_method_type);
link TREE_VALUE (link);
link = TREE_CHAIN (link))
gen_type_die (TREE_VALUE (link), context_die);
Notice that TREE_VALUE (link) is part of the loop condition.
Now, do we ever allow a NULL in TYPE_ARG_TYPES? If so, what does that
mean? My guess is that soneone was trying to be cautious about
encountering a NULL in TYPE_ARG_TYPES. (If that's the case, we should
be using gcc_assert instead.)
Just guessing here, but what happens with an old-style function
definition in C?
We end up with null type_arg_types in some cases with old style function
definitions, yes.
I believe it also happens with varargs functions in some cases, if there
was nothing but a varargs parameter.
Like:
void foo(...)
{
}
If you look at count_num_arguments in tree-ssa-structalias, add an
assert, and bootstrap, you can find the cases pretty quickly.
--Dan
Re: A question about TYPE_ARG_TYPES
Daniel Berlin wrote: I believe it also happens with varargs functions in some cases, if there was nothing but a varargs parameter. This is the one and only case in which it should occur, but, yes, it is possible. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: A question about TYPE_ARG_TYPES
On Wed, Jul 05, 2006 at 11:49:58AM -0400, Daniel Berlin wrote: I believe it also happens with varargs functions in some cases, if there was nothing but a varargs parameter. I was recently reminded that that's not valid C. Is there any language which lets you get away with only unnamed arguments? If not, I suspect this is only for old-style definitions. -- Daniel Jacobowitz CodeSourcery
Re: A question about TYPE_ARG_TYPES
Hi Ian, I keep finding places in GCC sources that check whether a member of TYPE_ARG_TYPES is 0. For example, for (link = TYPE_ARG_TYPES (function_or_method_type); link TREE_VALUE (link); link = TREE_CHAIN (link)) gen_type_die (TREE_VALUE (link), context_die); Notice that TREE_VALUE (link) is part of the loop condition. Now, do we ever allow a NULL in TYPE_ARG_TYPES? If so, what does that mean? My guess is that soneone was trying to be cautious about encountering a NULL in TYPE_ARG_TYPES. (If that's the case, we should be using gcc_assert instead.) Just guessing here, but what happens with an old-style function definition in C? void f(); AFAIK, that gets TYPE_ARG_TYPES (...) == NULL, so we don't even get to evaluate TREE_VALUE (TYPE_ARG_TYPES (...)). On IRC, Daniel Berlin claims that there are some weird cases where TREE_VALUE (TYPE_ARG_TYPES (...)) is NULL. I'll keep putting gcc_assert to see what happens. Kazu Hirata
Re: A question about TYPE_ARG_TYPES
Kazu Hirata wrote: Hi Ian, I keep finding places in GCC sources that check whether a member of TYPE_ARG_TYPES is 0. For example, for (link = TYPE_ARG_TYPES (function_or_method_type); link TREE_VALUE (link); link = TREE_CHAIN (link)) gen_type_die (TREE_VALUE (link), context_die); Notice that TREE_VALUE (link) is part of the loop condition. Now, do we ever allow a NULL in TYPE_ARG_TYPES? If so, what does that mean? My guess is that soneone was trying to be cautious about encountering a NULL in TYPE_ARG_TYPES. (If that's the case, we should be using gcc_assert instead.) Just guessing here, but what happens with an old-style function definition in C? void f(); AFAIK, that gets TYPE_ARG_TYPES (...) == NULL, so we don't even get to evaluate TREE_VALUE (TYPE_ARG_TYPES (...)). On IRC, Daniel Berlin claims that there are some weird cases where TREE_VALUE (TYPE_ARG_TYPES (...)) is NULL. I'll keep putting gcc_assert to see what happens. That may be the difference between void f() (where TYPE_ARG_TYPES might be NULL) and void f(...) (where TREE_VALUE (TYPE_ARG_TYPES) would be NULL). The latter, as Daniel says, is not valid C, but perhaps we used to accept it. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: gcc 4.2 more strict check for function called through a non-compatible type
Ian Lance Taylor writes: Andrew Haley [EMAIL PROTECTED] writes: If we make a change for openssh to allow this undefined behaviour, then do we agree to keep it working or not? If we agree that we will, then we have to at least add some test cases and we have to add some internal documentation to gcc. If we don't agree to keep it working, then even if we fix it today it may well break in the future. As I tried to clarify in a separate message, I don't think we agree to keep it working. After reading your last message in this thread I believe we now disgree very little. If it's painless to us to remove this abort, and doing so doesn't cause an ICE, so be it. I don't think we're doing the developers of openssh any favours by compiling such code. Quite the reverse, IMO. This is, I suppose, the root of our disagreement. I believe that the people we hurt are not the developers, who presumably have enough sense to fix their code after they see the warning (if they don't, I don't care about them). The people we are hurting are the users, who discover that their existing third party code does not compile with the new compiler. Again, if we gained anything by not compiling their code, then I would be all for it. But in this case we do not gain anything. We're actually going to extra effort to break their code. I didn't realize that we were doing so; from reading the lists I was under the impression that we were generating an abort in order to avoid doing extra work. If this isn't the case, and we can simply remove that abort, let's do so. To me this is related to the point I raised at the steering committee panel discussion (I know you weren't there): I think we are too casual about breaking existing working code. Perhaps. Andrew.
Re: gcc 4.2 more strict check for function called through a non-compatible type
On Jul 5, 2006, at 8:38 AM, Ian Lance Taylor wrote: To me this is related to the point I raised at the steering committee panel discussion (I know you weren't there): I think we are too casual about breaking existing working code. What happens when a target comes along and passes different pointers types differently. Like say a floating point pointer in the FP register and an pointer to an integer in the general purpose register, wouldn't that also break the code in question? Yes this is in theory but still saying we are breaking existing working code is bogus in this case. The above reason is one of the reasons why this code is undefined because it does not make sense. Is it really working after all is the real question and I say no it can never work correctly on any target. I showed a better example where passing a fp value and the function expects it in the general purpose register. Which happens on most targets except for x86 (32bit only in fact). -- Pinski
Re: gcc 4.2 more strict check for function called through a non-compatible type
On Wed, Jul 05, 2006 at 09:11:32AM -0700, Andrew Pinski wrote: What happens when a target comes along and passes different pointers types differently. Like say a floating point pointer in the FP register and an pointer to an integer in the general purpose register, wouldn't that also break the code in question? Yes this is in theory but still saying we are breaking existing working code is bogus in this case. The above reason is one of the reasons why this code is undefined because it does not make sense. This is a flawed argument. Ian said this could would work, and we are gratuitously breaking it. Responding I can conceive of a hypothetical target where it would not be portable doesn't mean anything. If what you really meant to say was casting between a int (*)(double) and int (*) (char *), then yes, that won't work. But there's plenty of other ways to write valid code that won't work! Is it really working after all is the real question and I say no it can never work correctly on any target. Obviously untrue. I can't imagine a plausible target where int (*) (char *) and int (*) (unsigned char *) would not be compatible, for instance. -- Daniel Jacobowitz CodeSourcery
Re: gcc 4.2 more strict check for function called through a non-compatible type
Andrew Pinski [EMAIL PROTECTED] writes:
On Jul 5, 2006, at 8:38 AM, Ian Lance Taylor wrote:
To me this is related to the point I raised at the steering committee
panel discussion (I know you weren't there): I think we are too casual
about breaking existing working code.
What happens when a target comes along and passes different pointers
types
differently. Like say a floating point pointer in the FP register
and an
pointer to an integer in the general purpose register, wouldn't that
also
break the code in question? Yes this is in theory but still saying
we are
breaking existing working code is bogus in this case. The above
reason is
one of the reasons why this code is undefined because it does not
make sense.
Yes, if the existing working code in question passed a floating point
value, then it would break.
The existing code in question is, essentially,
void foo (char*)
void bar (const char* s) { ((void (*) (const char*)) foo) (s); }
This too is undefined and might break. But it is unlikely to break
because different types are passed in different register classes.
Ian
RE: gcc 4.2 more strict check for function called through a non-compatible type
On 05 July 2006 17:12, Andrew Pinski wrote: On Jul 5, 2006, at 8:38 AM, Ian Lance Taylor wrote: To me this is related to the point I raised at the steering committee panel discussion (I know you weren't there): I think we are too casual about breaking existing working code. What happens when a target comes along and passes different pointers types differently. Like say a floating point pointer in the FP register and an pointer to an integer in the general purpose register, wouldn't that also break the code in question? Yes this is in theory but still saying we are breaking existing working code is bogus in this case. The above reason is one of the reasons why this code is undefined because it does not make sense. So what? There are plenty of cases where casting the function pointer does *not* affect the calling conventions required. Your argument attempts to conflate the two cases. There is no need to break the working cases just because there are some other cases that don't work. cheers, DaveK -- Can't think of a witty .sigline today
Re: gcc 4.2 more strict check for function called through a non-compatible type
What happens when a target comes along and passes different pointers types differently. Like say a floating point pointer in the FP register and an pointer to an integer in the general purpose register, wouldn't that also break the code in question? Yes this is in theory but still saying we are breaking existing working code is bogus in this case. The above reason is one of the reasons why this code is undefined because it does not make sense. There is at least one real example of breaking existing working code - openssl. It compiles and passes tests using gcc 3.3-4.1. It compiles and tests barfs a trap using gcc-4.2. Is it really working after all is the real question and I say no it can never work correctly on any target. Didn't you want to say it can never work correctly on *all* targets? I showed a better example where passing a fp value and the function expects it in the general purpose register. Which happens on most targets except for x86 (32bit only in fact). -- Pinski I don't want to say that type-casting function pointers is a good idea. But some developers may have their own motivations and opinion. After all, C is one of hybrid type language - with high level abstractions and still allows low-level techniques. Teaching developers with a trap is a bad idea - as I already shown on that openssl example they just find another workaround. And not compiling previously working code mostly hurts joe users instead.
Re: bootstrap failed during 'make check'
Eric Botcazou wrote: make[3]: Leaving directory `/mnt/scratch/nightly/2006-07-04/i686' Comparing stages 2 and 3 warning: ./cc1-checksum.o differs warning: ./cc1plus-checksum.o differs warning: ./cc1obj-checksum.o differs Bootstrap comparison failure! Does the attached patch make any difference? No, I still get the same set of .o files that differ, and the -fdump-noaddr (See PR other/28251) peephole2 dump for cfg.c compiled with stage1 / stage2 cc1 is still the same.
Re: bootstrap failed during 'make check'
No, I still get the same set of .o files that differ, and the -fdump-noaddr (See PR other/28251) peephole2 dump for cfg.c compiled with stage1 / stage2 cc1 is still the same. Then I'm puzzled. The original patch is supposed to be essentially a nop for languages that do not use ARRAY_RANGE_REFs. With the additional patch, it is supposed to be strictly a nop for them. Have you tried to revert it? In the meantime I'm going to test on another machine. -- Eric Botcazou
Re: bootstrap failed during 'make check'
Joern Rennecke wrote: Eric Botcazou wrote: make[3]: Leaving directory `/mnt/scratch/nightly/2006-07-04/i686' Comparing stages 2 and 3 warning: ./cc1-checksum.o differs warning: ./cc1plus-checksum.o differs warning: ./cc1obj-checksum.o differs Bootstrap comparison failure! Does the attached patch make any difference? No, I still get the same set of .o files that differ, and the -fdump-noaddr (See PR other/28251) peephole2 dump for cfg.c compiled with stage1 / stage2 cc1 is still the same. Hmm, as far as I can tell, stage1 i386.c:ix86_split_ashr has been miscompiled by gcc (GCC) 3.2.3 20030502 (Red Hat Linux 3.2.3-54). config/i386/i386.c lines 12307 .. 12309 are: emit_insn ((mode == DImode ? gen_x86_shrd_1 : gen_x86_64_shrd) (low[0], high[0], GEN_INT (count))); and this has been compiled as: 0x088af608 ix86_split_ashr+486: sub$0xc,%esp 0x088af60b ix86_split_ashr+489: sub$0xc,%esp 0x088af60e ix86_split_ashr+492: pushl 0xffec(%ebp) 0x088af611 ix86_split_ashr+495: push $0x0 0x088af613 ix86_split_ashr+497: call 0x8468f42 gen_rtx_CONST_INT 0x088af618 ix86_split_ashr+502: add$0x14,%esp 0x088af61b ix86_split_ashr+505: mov$0x88969da,%edx /* gen_x86_64_shrd */ 0x088af620 ix86_split_ashr+510: sub$0x8,%esp 0x088af623 ix86_split_ashr+513: push %eax 0x088af624 ix86_split_ashr+514: pushl 0xfff0(%ebp) 0x088af627 ix86_split_ashr+517: pushl 0xfff8(%ebp) 0x088af62a ix86_split_ashr+520: call *%edx 0x088af62c ix86_split_ashr+522: add$0x14,%esp 0x088af62f ix86_split_ashr+525: push %eax 0x088af630 ix86_split_ashr+526: call 0x84710dd emit_insn 0x088af635 ix86_split_ashr+531: add$0x10,%esp I.e. we are always calling gen_x86_64_shrd no matter what the value of mode is. stepping in gdb also shows that we end up in gen_x86_64_shrd in the stage1 compiler, but in gen_x86_shrd_1 in the stage2 compiler (mode is DImode). So it seems I have to abandom the system compiler for doing bootstraps.
Re: dejaGNU testsuite files for 2.95.3 20010315 (release)
On Jul 5, 2006, at 2:26 AM, J.J.Garcia wrote: Can i assume that what im using (2.95.2.1) is the last used previously to release 2.95.3 20010315 (release)? Not really. If you were going to stake your life on it, you'd not want to do that. I doubt the stakes are that high however. Anyway, you're free to do more archeology yourself. If it is important to you, you'll be able to find the revision you want by comparing the release you have in total against what you check out, when the intersection exactly matches you can then review each such version and try and pin it down on the basis of time of when the tarball was made, or barring that, the date given in changelogs or the youngest date of any file in the tarball. This should be able to get closer. You should have asked us 6 years ago, in general, we're not going to want to help much more with something 6 years in the past.
Re: bootstrap failed during 'make check'
Joern RENNECKE writes: Joern Rennecke wrote: Eric Botcazou wrote: make[3]: Leaving directory `/mnt/scratch/nightly/2006-07-04/i686' Comparing stages 2 and 3 warning: ./cc1-checksum.o differs warning: ./cc1plus-checksum.o differs warning: ./cc1obj-checksum.o differs Bootstrap comparison failure! Does the attached patch make any difference? No, I still get the same set of .o files that differ, and the -fdump-noaddr (See PR other/28251) peephole2 dump for cfg.c compiled with stage1 / stage2 cc1 is still the same. Hmm, as far as I can tell, stage1 i386.c:ix86_split_ashr has been miscompiled by gcc (GCC) 3.2.3 20030502 (Red Hat Linux 3.2.3-54). config/i386/i386.c lines 12307 .. 12309 are: emit_insn ((mode == DImode ? gen_x86_shrd_1 : gen_x86_64_shrd) (low[0], high[0], GEN_INT (count))); and this has been compiled as: 0x088af608 ix86_split_ashr+486: sub$0xc,%esp 0x088af60b ix86_split_ashr+489: sub$0xc,%esp 0x088af60e ix86_split_ashr+492: pushl 0xffec(%ebp) 0x088af611 ix86_split_ashr+495: push $0x0 0x088af613 ix86_split_ashr+497: call 0x8468f42 gen_rtx_CONST_INT 0x088af618 ix86_split_ashr+502: add$0x14,%esp 0x088af61b ix86_split_ashr+505: mov$0x88969da,%edx /* gen_x86_64_shrd */ 0x088af620 ix86_split_ashr+510: sub$0x8,%esp 0x088af623 ix86_split_ashr+513: push %eax 0x088af624 ix86_split_ashr+514: pushl 0xfff0(%ebp) 0x088af627 ix86_split_ashr+517: pushl 0xfff8(%ebp) 0x088af62a ix86_split_ashr+520: call *%edx 0x088af62c ix86_split_ashr+522: add$0x14,%esp 0x088af62f ix86_split_ashr+525: push %eax 0x088af630 ix86_split_ashr+526: call 0x84710dd emit_insn 0x088af635 ix86_split_ashr+531: add$0x10,%esp I.e. we are always calling gen_x86_64_shrd no matter what the value of mode is. stepping in gdb also shows that we end up in gen_x86_64_shrd in the stage1 compiler, but in gen_x86_shrd_1 in the stage2 compiler (mode is DImode). So it seems I have to abandom the system compiler for doing bootstraps. Can you make a simple testcase for this? Andrew.
Re: Does SIMD optimization of GCC 3.4.6 work?
On Jul 4, 2006, at 7:43 PM, [EMAIL PROTECTED] wrote: The codec is at http://www.sourceforge.net/projects/openavs/. Currently, it requires a 3Ghz or better CPU to get a resonable framerate. I would like the codec to be useful even on 586 ( 1Ghz or so ). Any ideas? Recode slower parts in assembler or punt to video card.
Re: Does SIMD optimization of GCC 3.4.6 work?
Hi, On Wednesday 05 July 2006 19:57, Mike Stump wrote: On Jul 4, 2006, at 7:43 PM, [EMAIL PROTECTED] wrote: The codec is at http://www.sourceforge.net/projects/openavs/. Currently, it requires a 3Ghz or better CPU to get a resonable framerate. I would like the codec to be useful even on 586 ( 1Ghz or so ). Any ideas? Recode slower parts in assembler or punt to video card. Aside the general com.lang.c boilderplate (...) usually it is already a gain to rewrite inefficent algorithms with something more clever and to use gcc SIMD vector extensions. Then of course assembly is the (often) last step ,-) Yours, -- René Rebe - ExactCODE - Berlin (Europe / Germany) http://exactcode.de | http://t2-project.org | http://rene.rebe.name +49 (0)30 / 255 897 45
RE: Does SIMD optimization of GCC 3.4.6 work?
On 05 July 2006 19:11, Rene Rebe wrote: Hi, On Wednesday 05 July 2006 19:57, Mike Stump wrote: On Jul 4, 2006, at 7:43 PM, [EMAIL PROTECTED] wrote: The codec is at http://www.sourceforge.net/projects/openavs/. Currently, it requires a 3Ghz or better CPU to get a resonable framerate. I would like the codec to be useful even on 586 ( 1Ghz or so ). Any ideas? Recode slower parts in assembler or punt to video card. Aside the general com.lang.c boilderplate (...) usually it is already a gain to rewrite inefficent algorithms with something more clever and to use gcc SIMD vector extensions. I believe Lionel's real problem is likely to be that he was hoping that turning on the -mmx -sse -sse2 -3dnow options would auto-vectorise his code for him. Lionel, (IIUIC) those options just /enable/ the use of the various SIMD features; they don't adjust your code to use those features if it doesn't do so already, so apart from a fairly small speed-up on some floating point operations that can be done more efficiently in the mmx unit, you shouldn't have been expecting to see much difference in the first place. cheers, DaveK -- Can't think of a witty .sigline today
Re: GCC 4.2 Status Report (2006-06-16)
Mark Mitchell wrote: I'm not sure the number above is in and of itself terribly meaningful, in part because Volker has been filing many ICE-on-invalid-after-error-message PRs against the C++ front end. These don't really even show up for users in releases, due to the confused by earlier errors trick, so, although I've been marking these as P2, that might actually be an overly high priority. It offends my sensibilities that we crash in these cases, but it's hard to argue there's a lot of impact on users. No, I think it's a mistake to prioritize these before bugs that actually affect users. I'd knock them down to P4. Jason
Re: Does SIMD optimization of GCC 3.4.6 work?
Hi, On Wednesday 05 July 2006 20:26, Dave Korn wrote: I believe Lionel's real problem is likely to be that he was hoping that turning on the -mmx -sse -sse2 -3dnow options would auto-vectorise his code for him. Lionel, (IIUIC) those options just /enable/ the use of the various SIMD features; they don't adjust your code to use those features if it doesn't do so already, so apart from a fairly small speed-up on some floating point operations that can be done more efficiently in the mmx unit, you shouldn't have been expecting to see much difference in the first place. When you put it this way one should point him to -ftree-vectorize of GCC 4.0 and 4.1 ... Yours, -- René Rebe - ExactCODE - Berlin (Europe / Germany) http://exactcode.de | http://t2-project.org | http://rene.rebe.name +49 (0)30 / 255 897 45
Re: gcc 4.2 more strict check for function called through a non-compatible type
On Jul 4, 2006, at 5:18 PM, Andrew Pinski wrote: And I posted a patch to do the same in Objective-C mode as C mode :). http://gcc.gnu.org/ml/gcc-patches/2004-08/msg01013.html Is the reason that Objective-C was excluded been fixed? If so, while I don't like the semantics in place now, I'd rather have consistency with C/C++. :-(
Re: Ulrich Weigand appointed reload maintainer
David Edelsohn wrote: I am pleased to announce that the GCC Steering Committee has appointed Ulrich Weigand to the role of reload maintainer. Thank you! Please join me in congratulating Ulrich on his new role. Ulrich, please update your entry in the MAINTAINERS file. I've committed the following patch: ChangeLog: * MAINTAINERS (Various Maintainers): Add myself as reload maintainer. Index: MAINTAINERS === *** MAINTAINERS (revision 115206) --- MAINTAINERS (working copy) *** profile feedbackJan Hubicka [EMAIL PROTECTED] *** 207,212 --- 207,213 type-safe vectors Nathan Sidwell [EMAIL PROTECTED] alias analysisDaniel Berlin [EMAIL PROTECTED] alias analysisDiego Novillo [EMAIL PROTECTED] + reloadUlrich Weigand [EMAIL PROTECTED] Note individuals who maintain parts of the compiler need approval to check in changes outside of the parts of the compiler they maintain. Bye, Ulrich -- Dr. Ulrich Weigand Linux on zSeries Development [EMAIL PROTECTED]
Re: gcc 4.2 more strict check for function called through a non-compatible type
Mike Stump [EMAIL PROTECTED] writes: On Jul 4, 2006, at 5:18 PM, Andrew Pinski wrote: And I posted a patch to do the same in Objective-C mode as C mode :). http://gcc.gnu.org/ml/gcc-patches/2004-08/msg01013.html Is the reason that Objective-C was excluded been fixed? If so, while I don't like the semantics in place now, I'd rather have consistency with C/C++. :-( A version of Andrew's patch was checked in on 2005-05-24, by Ziemowit Laski. The languages are currently consistent. Ian
Notes from the BOF on DFP on x86/x86-64 at the GCC Summit
(Resending after update on archive link below.) A proposal was made to pick one the Decimal Floating-Point encodings from the IEEE754r draft in the x86-64 psABI a few weeks ago (see thread starting at http://www.amd64.org/lists/discuss/thrd215.html#08857). Given that any such decision can have multiple developments, many users of x86-64 were invited to discuss this proposal in the [EMAIL PROTECTED] mailing-list. Taking the opportunity that many x86-64 users were at the GCC Summit, including some already taking part in this discussion, we set up a BOF session to exchange ideas on DFP in x86-64 and even in GCC. I posted a summary at http://www.amd64.org/lists/discuss/msg09367.html. Please, feel free to correct or complement my summary. All are invited to continue this discussion at the [EMAIL PROTECTED] mailing-list (subscribe at http://www.amd64.org/mailinglists). -- ___ Evandro Menezes AMDAustin, TX
RFA: new execute testcase (Was: Re: bootstrap failed during 'make check')
Andrew Haley wrote:
So it seems I have to abandom the system compiler for doing bootstraps.
Can you make a simple testcase for this?
Andrew.
Attached.
This fails at -O0..-O2 for gcc 3.2.2 and gcc 3.2.3 on
i686-pc-linux-gnu. For gcc 3.4.3,
it still fails at -O1.
4.2.0 appears to be OK, although it might be this bug only hidden by the
tree optimizers
optimizing the test case into something that doesn't trigger the bug.
:ADDPATCH testsuite:
2006-07-05 Jorn Rennecke [EMAIL PROTECTED]
* gcc.c-torture/execute/bootfail.c: New test.
extern int ok (int);
extern void exit ();
static int gen_x86_64_shrd (int);
static int
gen_x86_64_shrd(int a __attribute__ ((__unused__)))
{
return 0;
}
extern int gen_x86_shrd_1 (int);
extern void ix86_split_ashr (int);
void
ix86_split_ashr (int mode)
{
(mode != 0
? ok
: gen_x86_64_shrd) (0);
}
int main ()
{
ix86_split_ashr (1);
return 1;
}
int
ok (int i)
{
exit (i);
}
Re: bootstrap failed during 'make check'
Hmm, as far as I can tell, stage1 i386.c:ix86_split_ashr has been miscompiled by gcc (GCC) 3.2.3 20030502 (Red Hat Linux 3.2.3-54). Thanks a bunch for sorting this out! -- Eric Botcazou
Re: gcc 4.2 more strict check for function called through a non-compatible type
Ian Lance Taylor wrote:
Mike Stump [EMAIL PROTECTED] writes:
On Jul 4, 2006, at 5:18 PM, Andrew Pinski wrote:
And I posted a patch to do the same in Objective-C mode as C mode :).
http://gcc.gnu.org/ml/gcc-patches/2004-08/msg01013.html
Is the reason that Objective-C was excluded been fixed? If so, while
I don't like the semantics in place now, I'd rather have consistency
with C/C++. :-(
A version of Andrew's patch was checked in on 2005-05-24, by Ziemowit
Laski. The languages are currently consistent.
Ian
If so, why I'm able to compile the casted pointer example with
gcc-4.2-20060701 snapshot
in objective-c mode without warning/trap inserted?
Exactly speaking, all four front-ends behave different.
[EMAIL PROTECTED] ~/tmp $ cat bbb1.c
static double foo(double arg)
{
return arg;
}
int bar(int d)
{
d = ((int (*) (int)) (void(*)())foo)(d);
return d*d;
}
[EMAIL PROTECTED] ~/tmp $ gcc -v
gcc version 4.2.0-alpha20060701 (experimental) (Gentoo 4.2.0_alpha20060701)
[EMAIL PROTECTED] ~/tmp $ gcc -O3 bbb1.c -c
bbb1.c: In function 'bar':
bbb1.c:9: warning: function called through a non-compatible type
bbb1.c:9: note: if this code is reached, the program will abort
[EMAIL PROTECTED] ~/tmp $ gcc -x c++ -O3 bbb1.c -c
[EMAIL PROTECTED] ~/tmp $ gcc -x objective-c -O3 bbb1.c -c
bbb1.c: In function 'bar':
bbb1.c:7: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://bugs.gentoo.org/ for instructions.
[EMAIL PROTECTED] ~/tmp $ gcc -x objective-c++ -O3 bbb1.c -c
bbb1.c: In function 'int bar(int)':
bbb1.c:6: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://bugs.gentoo.org/ for instructions.
Re: gcc 4.2 more strict check for function called through a non-compatible type
Ian Lance Taylor [EMAIL PROTECTED] writes: [...] | I personally don't agree that this needs to be a documented extension. | I'm simply going on a more general rule which I tried to state above: | I don't think we should insert a trap call for undefined code. If it should not a documented extension, then it will break again, and we will have this sort of discussion again. If it should not be documented, then it should stay as is. -- Gaby
Re: gcc 4.2 more strict check for function called through a non-compatible type
Ian Lance Taylor [EMAIL PROTECTED] writes: | Andrew Haley [EMAIL PROTECTED] writes: | | If we make a change for openssh to allow this undefined behaviour, | then do we agree to keep it working or not? If we agree that we will, | then we have to at least add some test cases and we have to add some | internal documentation to gcc. If we don't agree to keep it working, | then even if we fix it today it may well break in the future. | | As I tried to clarify in a separate message, I don't think we agree to | keep it working. if we should agree not to keep it working, then changing the current behaviour is pointless. -= Gaby
Re: gcc 4.2 more strict check for function called through a non-compatible type
Ian Lance Taylor wrote: I realized that I am still not stating my position very clearly. I don't think we should make any extra effort to make this code work: after all, the code is undefined. I just think 1) we should not insert a trap; 2) we should not ICE. I agree. If the inlining thing is indeed a problem (and I can see how it could be, even though you could not immediately reproduce it), then we should mark the call as uninlinable. Disabling an optimization in the face of such a cast seems more user-friendly than inserting a trap. Since we know the code is undefined, we're not pessimizing correct code, so this is not a case where to support old code we'd be holding back performance for valid code. I also agree with Gaby that we should document this as an extension. If we go to the work of putting it back in, we should ensure that it continues to work for the foreseeable future. Part of that is writing down what we've decided. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
[Bug c/27898] Compile failure with --combine and anonymous structures
-- aoliva at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |aoliva at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-07-05 06:02:55 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27898
[Bug c/27898] Compile failure with --combine and anonymous structures
--- Comment #1 from aoliva at gcc dot gnu dot org 2006-07-05 06:04 --- Created an attachment (id=11822) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11822action=view) Patch that fixes the bug This patch fixes the problem for me. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27898
[Bug other/28264] New: broken gcc/config/soft-fp build.
(...) ../../gcc/config/soft-fp/floatsisf.c:36: warning: no previous prototype for '__floatsisf' /home/users/builder/rpm/BUILD/trunk/builddir/./gcc/xgcc -B/home/users/builder/rpm/BUILD/trunk/builddir/./gcc/ -B/usr/ppc-pld-linux/bin/ -B/usr/ppc-pld-linux/lib/ -isystem /usr/ppc-pld-linux/include -isystem /usr/ppc-pld-linux/sys-include -O2 -O2 -O2 -fno-strict-aliasing -fwrapv -fsigned-char -ggdb -DIN_GCC-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -specs=ldblspecs -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I. -I../../gcc -I../../gcc/. -I../../gcc/../include -I../../gcc/../libcpp/include -I../../gcc/../libdecnumber -I../libdecnumber -fvisibility=hidden -DHIDE_EXPORTS -c ../../gcc/config/soft-fp/floatunsisf.c -o libgcc/./floatunsisf.o ../../gcc/config/soft-fp/floatunsisf.c:37: warning: no previous prototype for '__floatunsisf' ../../gcc/config/soft-fp/floatunsisf.c: In function '__floatunsisf': ../../gcc/config/soft-fp/floatunsisf.c:42: warning: comparison of unsigned expression 0 is always false /home/users/builder/rpm/BUILD/trunk/builddir/./gcc/xgcc -B/home/users/builder/rpm/BUILD/trunk/builddir/./gcc/ -B/usr/ppc-pld-linux/bin/ -B/usr/ppc-pld-linux/lib/ -isystem /usr/ppc-pld-linux/include -isystem /usr/ppc-pld-linux/sys-include -O2 -O2 -O2 -fno-strict-aliasing -fwrapv -fsigned-char -ggdb -DIN_GCC-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -specs=ldblspecs -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I. -I../../gcc -I../../gcc/. -I../../gcc/../include -I../../gcc/../libcpp/include -I../../gcc/../libdecnumber -I../libdecnumber -fvisibility=hidden -DHIDE_EXPORTS -c ../../gcc/config/soft-fp/adddf3.c -o libgcc/./adddf3.o ../../gcc/config/soft-fp/adddf3.c:36: warning: no previous prototype for '__adddf3' make[3]: *** No rule to make target `../../gcc/config/soft-fp/divdf3.c', needed by `libgcc/./divdf3.o'. Stop. -- Summary: broken gcc/config/soft-fp build. Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pluto at agmk dot net GCC build triplet: powerpc-linux GCC host triplet: powerpc-linux GCC target triplet: powerpc-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28264
[Bug tree-optimization/28218] [4.1 Regression] ICE when building Inkscape with gcc-4.1 with -O2 -ffast-math
--- Comment #5 from bonzini at gnu dot org 2006-07-05 06:20 --- Subject: Bug 28218 Author: bonzini Date: Wed Jul 5 06:20:19 2006 New Revision: 115197 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115197 Log: 2006-07-04 Paolo Bonzini [EMAIL PROTECTED] PR tree-optimization/28218 * tree-ssa-math-opts.c (execute_cse_reciprocals): Fix calls to calculate and free the dominator information. Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/tree-ssa-math-opts.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28218
[Bug other/28264] broken gcc/config/soft-fp build.
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-07-05 06:23 --- How did you configure GCC? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28264
[Bug other/28264] broken gcc/config/soft-fp build.
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-07-05 06:24 --- soft-fp is included by default on powerpc-linux and it works for everyone I know. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28264
[Bug other/28264] broken gcc/config/soft-fp build.
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-07-05 06:25 --- And config/soft-fp/divdf3.c is there for me. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28264
[Bug tree-optimization/28218] [4.1 Regression] ICE when building Inkscape with gcc-4.1 with -O2 -ffast-math
--- Comment #6 from bonzini at gnu dot org 2006-07-05 06:47 --- Subject: Bug 28218 Author: bonzini Date: Wed Jul 5 06:47:21 2006 New Revision: 115198 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115198 Log: 2006-07-04 Paolo Bonzini [EMAIL PROTECTED] PR tree-optimization/28218 * tree-ssa-math-opts.c (execute_cse_reciprocals): Fix calls to calculate and free the dominator information. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-math-opts.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28218
[Bug tree-optimization/28218] [4.1 Regression] ICE when building Inkscape with gcc-4.1 with -O2 -ffast-math
--- Comment #7 from bonzini at gnu dot org 2006-07-05 06:49 --- patch committed to 4.1 branch and mainline (where it was latent) -- bonzini at gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28218
[Bug libstdc++/28265] New: iconv-related errors while building a cross-compiler for MinGW
libstdc++-v3/include/ext/codecvt_specializations.h uses iconv_t and causes errors while building an i686-pc-linux-gnu to i686-pc-mingw32 cross-compiler. (I'm at trunk revision 115196.) Strangely however, this does not cause a build failure and is therefore not catastrophic for this target. GCC was configured as: $GCC_SRC_DIR/configure --prefix=$PREFIX \ --with-sysroot=$SYSROOT --with-build-sysroot=$SYSROOT \ --target=$TARGET --host=$HOST --build=$BUILD \ --enable-languages=c,c++,java \ --with-gnu-as --with-gnu-ld \ --disable-nls --disable-debug --disable-shared --disable-checking \ --enable-threads=win32 --disable-win32-registry --enable-sjlj-exceptions \ --enable-libgcj I will attach the part of the build log that shows this error. -- Summary: iconv-related errors while building a cross-compiler for MinGW Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rmathew at gcc dot gnu dot org GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28265
[Bug libstdc++/28265] iconv-related errors while building a cross-compiler for MinGW
--- Comment #1 from rmathew at gcc dot gnu dot org 2006-07-05 07:32 --- Created an attachment (id=11823) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11823action=view) The portion of the build log that shows the error reported in this PR. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28265
[Bug other/28264] broken gcc/config/soft-fp build.
--- Comment #4 from pluto at agmk dot net 2006-07-05 08:19 --- ohhh, now I see what's wrong. Out of Memory: Killed process 18248 (cc1). the PPC970FX box has 1GB ram + 1GB swap. i'll re-run build and try to reproduce this memory-hog. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28264
[Bug middle-end/28252] pow(x,1/3.0) should be converted to cbrt(x)
--- Comment #2 from uros at kss-loka dot si 2006-07-05 08:25 --- Created an attachment (id=11824) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11824action=view) Patch to implement pow(x,1.0/3.0) = cbrt(x) optimization I have the patch that implements the optimization ready, just waiting for the mainline to open again. Should I post it to gcc-patches anyway? 2006-07-05 Uros Bizjak [EMAIL PROTECTED] * builtins.c (fold_builtin): Fold pow(x,1.0/3.0) as cbrt(x) if flag_unsafe_math_optimizations is set. testsuite: * gcc.dg/builtins-8.c: Also check pow(x,1.0/3.0) to cbrt(x) transformation. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28252
[Bug middle-end/28252] pow(x,1/3.0) should be converted to cbrt(x)
-- uros at kss-loka dot si changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |uros at kss-loka dot si |dot org | Status|NEW |ASSIGNED Last reconfirmed|2006-07-04 22:52:33 |2006-07-05 08:26:53 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28252
[Bug tree-optimization/21883] [4.1/4.2 Regression] jump threading causing excessive code duplication
--- Comment #12 from pinskia at gcc dot gnu dot org 2006-07-05 09:04 --- As far as I can tell this has been fixed now so closing as such. Yes I did test to make sure the function calls are no longer being duplicated. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21883
[Bug target/26885] [4.1 regression] -m64 -m32 no longer creates 32-bit object
--- Comment #20 from pinskia at gcc dot gnu dot org 2006-07-05 09:05 --- Fixed on the mainline. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.1/4.2 regression] -m64 - |[4.1 regression] -m64 -m32 |m32 no longer creates 32-bit|no longer creates 32-bit |object |object http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26885
[Bug tree-optimization/8361] [4.1/4.2 regression] C++ compile-time performance regression
--- Comment #67 from pinskia at gcc dot gnu dot org 2006-07-05 09:06 --- Does anyone have new numbers for this, Richard G.'s recent memory patches have an effect on the compile time also I noticed between 7% and 10% on at least CSiBE. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8361
[Bug tree-optimization/18687] [4.0/4.1/4.2 Regression] ~50% compile time regression
--- Comment #30 from pinskia at gcc dot gnu dot org 2006-07-05 09:14 --- Can you do timings on these again on the mainline since it looks like Richard G.'s memory patches also improved compile time for C at least on the CSiBE benchmark. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18687
[Bug fortran/28005] [4.1 only] gfortran: matmul produces wrong result
--- Comment #7 from tobias dot burnus at physik dot fu-berlin dot de 2006-07-05 09:23 --- The patch did not apply to 4.1, so I will have to submit a back port. Thanks, Paul. I think this is the most serious bug in gfortran 4.1.x as it silently produces wrong results. -- tobias dot burnus at physik dot fu-berlin dot de changed: What|Removed |Added Summary|[4.1 only] gfortran: mathmul|[4.1 only] gfortran: matmul |produces wrong result |produces wrong result http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28005
[Bug tree-optimization/21596] [4.0/4.1/4.2 Regression] extra temporaries when using global register variables
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-07-05 09:27 --- It is slightly different now: leal-4(%edi), %eax movl%eax, %edi movl(%eax), %eax testl %eax, %eax But still the same issue. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2006-02-01 04:41:22 |2006-07-05 09:27:30 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21596
[Bug libfortran/23138] [mingw32] real(16) values are printed incorrectly
--- Comment #12 from fxcoudert at gcc dot gnu dot org 2006-07-05 09:45 --- (In reply to comment #9) mingw has an implementation of _IO_ldtoa() and _IO_ldtostr(), based on Stephen Moshier's ioldoubl package, that could be used. Currently, the ldtoa function is not exposed, but there is no reason why it couldn't be. Any progress on this? (for example in the newly released mingw-runtime-3.10) -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added URL|http://gcc.gnu.org/ml/gcc- | |patches/2005- | |08/msg00338.html| Keywords|patch | Last reconfirmed|2005-08-02 07:40:27 |2006-07-05 09:45:15 date|| Summary|[mingw32] real values are |[mingw32] real(16) values |printed incorrectly |are printed incorrectly http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23138
[Bug fortran/28237] print call()
--- Comment #3 from paul dot richard dot thomas at cea dot fr 2006-07-05
09:47 ---
Created an attachment (id=11825)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11825action=view)
Fix for PR28237 and the last bit of PR2320.
I have not had time to do a full regtest; just gfortran.dg/print*, which
includes the following testcase (print_fmt_5.f90):
Paul
! { dg-do compile }
! print_fmt_5.f90
! Test of fix for PR28237 and the last bit of PR2320. See
! below for the description of the problem.
!
program r
character(12) :: for = '(i5)', left = '(i', right = ')'
integer :: i, j
integer :: h(4)
= (/1h(, 1hi, 1h5, 1h)/)! { dg-warning HOLLERITH|Hollerith }
namelist /mynml/ i
i = fact ()
!
! All these are legal things to do; note however the warnings
! for extensions or obsolete features!
!
print *, fact()
print 100, fact()
print '(i5)', fact()
print mynml ! { dg-warning is an extension }
do i = 1, 5
print trim(left)//char(iachar('0') + i)//trim(right), i
end do
assign 100 to i ! { dg-warning ASSIGN statement }
print i, fact() ! { dg-warning ASSIGNED variable }
print h, fact () ! { dg-warning Non-character in FORMAT }
!
! These are not and caused a segfault in trans-io:560
!
! PR28237
print fact() ! { dg-error not an ASSIGNED variable }
! original PR23420
print precision(1.2_8) ! { dg-error type default CHARACTER }
! PR23420 points 4 and 5
print j + j ! { dg-error not an ASSIGNED variable }
! An extension of the above, encountered in writing the fix
write (*, fact())! { dg-error not an ASSIGNED variable }
100 format (i5)
contains
function fact()
integer :: fact
fact = 1
end function fact
end
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28237
[Bug target/25500] [4.0/4.1/4.2 Regression]: SSE2 vectorized code is slower on 4.x.x than previous
--- Comment #17 from pinskia at gcc dot gnu dot org 2006-07-05 09:50
---
struct FF {
__m128 d;
.
}
Mine I have a patch for this I cannot believe I found this before. The patch
has been tested a bit at least in the local tree I have been playing out with.
SRA should use element based copy that struct because it is only one element.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot
|dot org |org
Status|NEW |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25500
[Bug tree-optimization/27474] ICE: tree check: expected ssa_name, have struct_field_tag in verify_ssa, at tree-ssa.c:776
--- Comment #4 from uros at kss-loka dot si 2006-07-05 10:10 --- This still fails with current mainline gcc. -- uros at kss-loka dot si changed: What|Removed |Added Last reconfirmed|2006-05-08 07:45:56 |2006-07-05 10:10:38 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27474
[Bug tree-optimization/28162] [4.2 Regression] ICE in set_value_range, at tree-vrp.c:157
--- Comment #5 from patchapp at dberlin dot org 2006-07-05 10:45 --- Subject: Bug number PR28162 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/2006-07/msg00133.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28162
[Bug c++/26696] [4.0/4.1/4.2 Regression] ICE with statement forming unused static member function reference
--- Comment #4 from dtemirbulatov at gmail dot com 2006-07-05 10:46 --- fix we need to check first operand for FIELD_DECL before gimpilfying COMPONENT_REF this is a wrong fix, it caused some regressions -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26696
[Bug target/28158] [4.2 Regression] ICE on complex operation with -O1 -msse
--- Comment #5 from patchapp at dberlin dot org 2006-07-05 10:50 --- Subject: Bug number PR28158 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/2006-07/msg00134.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28158
[Bug c++/27084] Does not propagate memory load base through useless type conversion
--- Comment #13 from rguenth at gcc dot gnu dot org 2006-07-05 10:54 --- Subject: Bug 27084 Author: rguenth Date: Wed Jul 5 10:54:17 2006 New Revision: 115200 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115200 Log: 2006-07-05 Richard Guenther [EMAIL PROTECTED] Andrew Pinski [EMAIL PROTECTED] PR c++/27084 * cp-objcp-common.c (cxx_types_compatible_p): Ignore top level qualifiers for pointer type comparisons. * g++.dg/tree-ssa/copyprop-1.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/tree-ssa/copyprop-1.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-objcp-common.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27084
[Bug c++/27084] Does not propagate memory load base through useless type conversion
--- Comment #14 from rguenth at gcc dot gnu dot org 2006-07-05 10:58 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27084
[Bug c++/28255] [4.1/4.2 regression] ICE with initialization in template
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-07-05 11:03 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-07-05 11:03:14 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28255
[Bug c/9072] -Wconversion should be split into two distinct flags
--- Comment #14 from lopezibanez at gmail dot com 2006-07-05 11:15 --- Created an attachment (id=11826) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11826action=view) split current functionality of Wconversion in two different options This patch divides the functionality of Wconversion into two additional warning options Wtradtional-conversion and Wcoercion as part of the Wcoercion project ( http://gcc.gnu.org/wiki/Wcoercion#Background ). These are added for the sake of clarity (in order to distinguish them from the current Wconversion) and during the development phase and they are not meant to be the final form that the options will take. Bootstrapped and tested in i686-pc-linux-gnu for trunk revision 115112. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9072
[Bug c/9072] -Wconversion should be split into two distinct flags
--- Comment #15 from lopezibanez at gmail dot com 2006-07-05 11:18 --- Created an attachment (id=11827) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11827action=view) Adds a new function which detects when a real value can be exactly represented as an integer. Patch 2of3 http://gcc.gnu.org/wiki/Wcoercion#Background Adds a new function which detects when a real value can be exactly represented as an integer. This function is needed for the next patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9072
[Bug c/9072] -Wconversion should be split into two distinct flags
--- Comment #16 from lopezibanez at gmail dot com 2006-07-05 11:22 --- Created an attachment (id=11828) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11828action=view) detect implicit conversions where a value may change patch 3of3 http://gcc.gnu.org/wiki/Wcoercion#Background Detect implicit conversions where a value may change by narrowing, loss of precision or change of sign when passing arguments and in assignments. It includes testcases. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9072
[Bug c/6614] [-Wconversion] incorrect conversion warning for function taking a short
--- Comment #8 from lopezibanez at gmail dot com 2006-07-05 11:34 --- I think we may close this bug report since either: * The solution is to split the functionality of Wconversion as conceived by the Wcoercion project http://gcc.gnu.org/wiki/Wcoercion#Background. In that case, this is a duplicate of bug 9072. * The message is misleading. Maybe it should say: passing arg 1 of 'func' as short instead of 'int' due to prototype. If you agree, I can generate a patch in no time. * This is not a bug. As said in comment 5, Wconversion is meant to warn about conversions that would be different in the absence of prototypes. So we may just close the bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6614
[Bug c/6614] [-Wconversion] incorrect conversion warning for function taking a short
--- Comment #9 from rguenth at gcc dot gnu dot org 2006-07-05 11:37 --- See comment #1, this is how it is intended. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6614
[Bug fortran/24401] -fbounds-check takes too long
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2006-07-05 11:43 --- (In reply to comment #5) Can we close this? I think we can. If someone has precise input on how we can make -fbounds-check even faster, please reopen this PR with extra details. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24401
[Bug fortran/28129] gfortran -fbounds-check: Shows invalid array out of bounds error
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2006-07-05 11:50 --- I have a patch here: http://gcc.gnu.org/ml/gcc-patches/2006-07/msg00137.html -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2006- ||07/msg00137.html Keywords||patch Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28129
[Bug c++/28266] New: [4.0/4.1/4.2 regression] ICE on invalid default variable
The following invalid code snippet triggers an ICE since GCC 4.0.0:
struct A
{
int i;
A(int = X);
};
void foo()
{
A().i;
}
bug.cc:4: error: 'X' was not declared in this scope
bug.cc: In function 'void foo()':
bug.cc:9: internal compiler error: in gimple_add_tmp_var, at gimplify.c:720
Please submit a full bug report, [etc.]
--
Summary: [4.0/4.1/4.2 regression] ICE on invalid default variable
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, error-recovery, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28266
[Bug c++/28267] New: [4.0/4.1/4.2 regression] ICE on invalid default variable in operator new
The following invalid code snippet triggers a segfault since GCC 4.0.0:
struct A
{
void* operator new(__SIZE_TYPE__, int = X);
void operator delete(void*, int);
A();
};
void foo()
{
new A;
}
bug.cc:3: error: 'X' was not declared in this scope
bug.cc: In function 'void foo()':
bug.cc:11: internal compiler error: Segmentation fault
Please submit a full bug report, [etc.]
Maybe related to PR 28266.
--
Summary: [4.0/4.1/4.2 regression] ICE on invalid default variable
in operator new
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, error-recovery, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28267
[Bug middle-end/28268] New: [4.2 regression] ICE with simple vector operations
The following valid code snippet triggers an ICE on mainline:
int __attribute__((vector_size(8))) a;
void foo()
{
a += a*a;
}
bug.c: In function 'foo':
bug.c:5: internal compiler error: in fold_convert, at fold-const.c:2089
Please submit a full bug report, [etc.]
--
Summary: [4.2 regression] ICE with simple vector operations
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code, monitored
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28268
[Bug c++/28269] New: [4.2 regression] ICE on attribute for invalid template
The following invalid code snippet triggers an ICE on mainline: templateint struct A; struct __attribute__((unused)) A0; bug.cc:3: error: template argument 1 is invalid bug.cc:3: internal compiler error: tree check: expected class 'type', have 'exceptional' (error_mark) in cp_parser_elaborated_type_specifier, at cp/parser.c:10245 Please submit a full bug report, [etc.] -- Summary: [4.2 regression] ICE on attribute for invalid template Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: ice-on-invalid-code, error-recovery, monitored Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: reichelt at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28269
[Bug target/28270] New: [4.0/4.1/4.2 regression] ICE on invalid inline asm
The following invalid code snippet triggers an ICE since GCC 3.1:
void foo(long double d)
{
asm( :: a (d));
}
bug.c: In function 'foo':
bug.c:3: error: impossible register constraint in 'asm'
bug.c:4: internal compiler error: in ix86_secondary_memory_needed, at
config/i386/i386.c:16554
Please submit a full bug report, [etc.]
Maybe related to PR26655.
--
Summary: [4.0/4.1/4.2 regression] ICE on invalid inline asm
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, error-recovery, monitored
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28270
[Bug c++/28271] New: Specialization of a function is not called if compile with -03 option
The specialization of a function is not called if compile with -03 option,
the generic implementation is called insteed.
This appear only if the declaration of the specialization is in another
file.
The specialization is called if compiled with -02 or lees optimization, or
if the generic implementation is declared with the buildin noinline.
Configuration of gcc -v:
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../src/configure
--prefix=/project/spg/tools/Open-Sources/gcc/4.1.1/Linux-x86/
--enable-__cxa_atexit --enable-shared --enable-long-long --enable-threads
--enable-languages=c,c++ --with-gnu-as --with-gnu-ar --with-gnu-ld --with-gcc
Thread model: posix
gcc version 4.1.1
Three files:
header
#ifndef _TCLASS_H_
#define _TCLASS_H_
templatetypename T bool foo(T val)
{
return false;
}
#endif
scpecialization:
#include tclass.h
template bool foo(int val)
{
return true;
}
main:
#include tclass.h
int main() {
return(foo(1));
}
--
Summary: Specialization of a function is not called if compile
with -03 option
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: maxime dot fiandino at imag dot fr
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=28271
[Bug c++/28271] Specialization of a function is not called if compile with -03 option
--- Comment #1 from maxime dot fiandino at imag dot fr 2006-07-05 13:11 --- Created an attachment (id=11829) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11829action=view) The main, just call the template function foo and return the return value -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28271
[Bug c++/28271] Specialization of a function is not called if compile with -03 option
--- Comment #2 from maxime dot fiandino at imag dot fr 2006-07-05 13:12 --- Created an attachment (id=11830) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11830action=view) the specialization The specialization on int return true -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28271
[Bug c++/28271] Specialization of a function is not called if compile with -03 option
--- Comment #3 from maxime dot fiandino at imag dot fr 2006-07-05 13:12 --- Created an attachment (id=11831) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11831action=view) The header with the generic implementation The generic template function return false -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28271
[Bug c++/28271] Specialization of a function is not called if compile with -03 option
--- Comment #4 from maxime dot fiandino at imag dot fr 2006-07-05 13:14 --- Created an attachment (id=11832) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11832action=view) The makefile to test This makefile create two executable TC1 compiled with -02 which work well TC2 compiled with -O3 which don't -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28271
[Bug c++/28271] Specialization of a function is not called if compile with -03 option
--- Comment #5 from maxime dot fiandino at imag dot fr 2006-07-05 13:18 --- This bug was firstly discover under gcc3.2.3, then we test with 4.1.1 with the same results. The test case is very short. -- maxime dot fiandino at imag dot fr changed: What|Removed |Added CC||maxime dot fiandino at imag ||dot fr Known to fail||3.2.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28271
[Bug rtl-optimization/28221] [4.1 regression] ICE in add_insn_before, at emit-rtl.c:3479
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-07-05 13:36 --- With checking enabled we have obj2/gcc ./cc1plus -quiet -O2 t.ii t.ii: In static member function 'static IntType boost::random::const_modIntType, m::mult_schrage(IntType, IntType) [with IntType = int, IntType m = 2147483647]': t.ii:7335: error: too many outgoing branch edges from bb 3 t.ii:7335: internal compiler error: verify_flow_info failed Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. maybe related to PR27291. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28221
[Bug fortran/27874] Bad interaction between bounds checking, forall and derived types
-- 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 URL||http://gcc.gnu.org/ml/gcc- ||patches/2006- ||07/msg00140.html Status|NEW |ASSIGNED Keywords||patch Last reconfirmed|2006-06-02 16:39:07 |2006-07-05 13:37:13 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27874
[Bug target/27500] iWMMXT bootstrap failure with recent binutils
--- Comment #2 from s_j_newbury at yahoo dot co dot uk 2006-07-05 13:38 --- This bug is still present with binutils-2.17.50.0.2. I am still uncertain whether gcc is producing invalid code or the check in binutils is wrong. I have found this bug to be triggered while compiling gcc and even binutils-2.16.91. It also occurs when compiling ghostscript. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27500
[Bug other/28251] dumped addresses makes diffing dumps unusable
--- Comment #3 from amylaar at gcc dot gnu dot org 2006-07-05 13:42 --- Created an attachment (id=11833) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11833action=view) dump diff for mainline r115174 bootstrap failure The diff with -fdump-noaddr is indeed much more useful to track down make compare failures that either the diff with full information and the one from -fdump-unnumbered. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28251
[Bug tree-optimization/28187] [4.1/4.2 Regression] '-O2 -fwrapv' exhausts memory.
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-07-05 13:48 --- I can reproduce it on the 4.1 branch on i686, but not on trunk. Very slowly eating all of memory. Reducing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28187
