[Bug c/31870] Failure to diagnose taking address of register variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31870 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |FIXED --- Comment #6 from Marek Polacek mpolacek at gcc dot gnu.org --- Fixed in r204544 - that is in 4.9/5. Not backportable to 4.8.
[Bug c/31870] Failure to diagnose taking address of register variable
--- Comment #1 from bangerth at dealii dot org 2007-05-09 16:16 --- Uh, can you elaborate? We get the warning you want if we have int d (void) { register int a[2]; return a; } instead. In your case, i.e. return a,1, we return 1, but we still need evaluate the expression a. I assume that you mean that this implies that we have to do the array-to-pointer decay operation. However, for that case, C99's clause 6.3.2.1/3 says that that's possible for register storage class arrays but that the result is undefined. The prohibition in 6.5.3.2/1 against register objects only holds for the application of the address-of operator . Both these clauses are referenced also from footnote 100 on page 98. W. -- bangerth at dealii dot org changed: What|Removed |Added CC||bangerth at dealii dot org Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31870
[Bug c/31870] Failure to diagnose taking address of register variable
--- Comment #2 from neil at daikokuya dot co dot uk 2007-05-09 23:39 --- Subject: Re: Failure to diagnose taking address of register variable bangerth at dealii dot org wrote:- Uh, can you elaborate? We get the warning you want if we have int d (void) { register int a[2]; return a; } instead. In your case, i.e. return a,1, we return 1, but we still need evaluate the expression a. I assume that you mean that this implies that we have to do the array-to-pointer decay operation. However, Yes, it has to be done. for that case, C99's clause 6.3.2.1/3 says that that's possible for register storage class arrays but that the result is undefined. Right. GCC seems to want to diagnose this undefined behaviour; it does in all other circumstances. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31870
[Bug c/31870] Failure to diagnose taking address of register variable
--- Comment #3 from bangerth at math dot tamu dot edu 2007-05-09 23:46 --- Subject: Re: Failure to diagnose taking address of register variable for that case, C99's clause 6.3.2.1/3 says that that's possible for register storage class arrays but that the result is undefined. Right. GCC seems to want to diagnose this undefined behaviour; it does in all other circumstances. It probably wouldn't hurt if it were diagnosed, but since the result of the expression is thrown away anyway, there probably isn't much hurm done in the current state either. I agree that we might want to warn, but I wouldn't consider it very high priority. W. - Wolfgang Bangerthemail:[EMAIL PROTECTED] www: http://www.math.tamu.edu/~bangerth/ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31870
[Bug c/31870] Failure to diagnose taking address of register variable
-- bangerth at dealii dot org changed: What|Removed |Added Status|WAITING |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-05-09 23:47:26 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31870
[Bug c/31870] Failure to diagnose taking address of register variable
--- Comment #4 from neil at gcc dot gnu dot org 2007-05-10 00:00 --- Agreed it's minor; I think I flagged the PR that way. I'm not sure but I suspect it indicates that the pointer decay is not happening. If so and you were using GCC to do source code analysis, you would have an incorrect type in the expression tree. Which may not be a big deal. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31870
[Bug c/31870] Failure to diagnose taking address of register variable
--- Comment #5 from bangerth at dealii dot org 2007-05-10 03:52 --- (In reply to comment #4) I'm not sure but I suspect it indicates that the pointer decay is not happening. Or that the warning is only emitted if something is actually done with the result. I don't know, someone else may check this. W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31870