.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc2eran at tromer dot org
GCC build triplet: 4.1.1
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29626
--- Additional Comments From gcc2eran at tromer dot org 2005-07-08 09:18
---
(In reply to comment #13)
> In the C99 standard, 6.5.4 Cast Operators, Footnote 85 "A cast does not
> yield an lvalue. Thus, a cast to a qualified type has the same effect
> as a cast to t
--- Additional Comments From gcc2eran at tromer dot org 2005-07-06 18:42
---
Correction of typo in comment 9: the related PR referenced is PR 22278.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21568
--- Additional Comments From gcc2eran at tromer dot org 2005-07-03 12:12
---
To make it easier to evaluate my claim, here are all messages in the thread
linked from comment 1 that seemingly contradicy comment 9:
Nathan Sidwell: http://gcc.gnu.org/ml/gcc/2005-05/msg00085.html
Dale
--- Additional Comments From gcc2eran at tromer dot org 2005-07-03 06:59
---
(In reply to comment #34)
OK, that was just a demonstration of of the problem you pointed out in comments
9 and 12 and example (a) of comment 16. In this case, your analysis ("be
conservative") and
--- Additional Comments From gcc2eran at tromer dot org 2005-07-03 06:50
---
> Did you read what was writting in comment #1 and #4?
Carefully. Similarly to Paul Schlie in comment 5, I don't agree. My reasoning
follows.
> Because at this point avail is known not to volati
--- Additional Comments From gcc2eran at tromer dot org 2005-07-03 05:09
---
(In reply to comment #32)
> | I meant that we were mostly concerned about what the standard says about the
> | effect of casting (say) int* into volatile int*, but the other directly is
> | simply
--- Additional Comments From gcc2eran at tromer dot org 2005-07-03 04:55
---
Why was this bug closed? The testcases in comment 5 do *not* pass.
Here's the first testcase, fixed to compile cleanly:
int avail;
int main() {
volatile int **outside = (volatil
--- Additional Comments From gcc2eran at tromer dot org 2005-07-03 04:14
---
(In reply to comment #30)
> | OK. Then the volatile-stripping direction can be handled arbitrarily.
>
> I do not understand that comment.
I meant that we were mostly concerned about what the stan
--- Additional Comments From gcc2eran at tromer dot org 2005-07-03 02:30
---
(In reply to comment #25)
> If when the compiler sees "const T* p", it assumes that *p is
> effectively const, then it would miscompile
>
>int foo(int* p, const int* q) {
>
--- Additional Comments From gcc2eran at tromer dot org 2005-07-03 01:46
---
(In reply to comment #24)
Thanks!
None of the quotes and references in comment 23 changed in N1124.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22278
--- Additional Comments From gcc2eran at tromer dot org 2005-07-03 01:19
---
(In reply to comment #22)
> | int foo;
> | *(volatile int*) (&foo);
>
> It was included in my previous message.
Then it's still eluding me, since your foo (the "object"
--- Additional Comments From gcc2eran at tromer dot org 2005-07-02 23:30
---
(In reply to comment #17)
> Furthermore, the fundamental issue is whether this
>
>*(volatile int*) (int*) (&foo);
>
> (or equivalent) where foo has been defined volatile int
--- Additional Comments From gcc2eran at tromer dot org 2005-07-02 22:07
---
Prior versions of gcc did "respect" casts to pointer-to-volatile and did not
optimize away the access. I've seen a lot of code that relies on that, and which
would thus be broken by gcc 4.x (
14 matches
Mail list logo
