https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65752
--- Comment #37 from Chung-Kil Hur ---
(In reply to rguent...@suse.de from comment #36)
> On Tue, 26 May 2015, gil.hur at sf dot snu.ac.kr wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65752
> >
> > --- Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65752
--- Comment #35 from Chung-Kil Hur ---
(In reply to rguent...@suse.de from comment #34)
> On Sat, 23 May 2015, gil.hur at sf dot snu.ac.kr wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65752
> >
> > --- Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65752
--- Comment #33 from Chung-Kil Hur ---
Dear Richard,
Thanks for the detailed response.
I have a suggestion for a solution of the problem, which is based on my paper
to appear at PLDI 2015.
* A Formal C Memory Model Supporting Integer-Pointer C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65752
--- Comment #29 from Chung-Kil Hur ---
Dear Richard,
This time, I think I constructed a real bug.
Please have a look and correct me if I am wrong.
=
#include
int main() {
int x = 0;
uintptr_t xp = (uintptr_t) &x;
uin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65752
--- Comment #27 from Chung-Kil Hur ---
(In reply to Chung-Kil Hur from comment #26)
> Thanks for the detailed explanations.
>
> > The C standard only guarantees that you can convert a pointer to uintptr_t
> > and back, it doesn't guarantee that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65752
--- Comment #26 from Chung-Kil Hur ---
Thanks for the detailed explanations.
> The C standard only guarantees that you can convert a pointer to uintptr_t
> and back, it doesn't guarantee that you can convert a modified uintptr_t
> back to
> a po
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65752
--- Comment #24 from Chung-Kil Hur ---
(In reply to schwab from comment #23)
> "gil.hur at sf dot snu.ac.kr" writes:
>
> > Since "hello" is not printed, I think the if-statement is the same as no-op.
> >
nt #18)
> > > > On Tue, 19 May 2015, gil.hur at sf dot snu.ac.kr wrote:
> > > >
> > > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65752
> > > > >
> > > > > --- Comment #17 from Chung-Kil Hur ---
> > > &g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65752
--- Comment #21 from Chung-Kil Hur ---
(In reply to Marek Polacek from comment #20)
> (In reply to Chung-Kil Hur from comment #19)
> > (In reply to rguent...@suse.de from comment #18)
> > > On Tue, 19 May 2015, gil.hur at sf d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65752
--- Comment #19 from Chung-Kil Hur ---
(In reply to rguent...@suse.de from comment #18)
> On Tue, 19 May 2015, gil.hur at sf dot snu.ac.kr wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65752
> >
> > --- Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65752
--- Comment #17 from Chung-Kil Hur ---
Hi Richard,
I modified the example further.
#include
int main() {
int x = 0;
uintptr_t xp = (uintptr_t) &x;
uintptr_t i, j;
for (i = 0; i < xp; i++) { }
j = i;
/* The following "if" statemen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65752
--- Comment #15 from Chung-Kil Hur ---
Hi Richard,
Thanks for the explanation.
But, what I wonder was how to justify such an optimization, rather than how it
works.
I have a better example. This might be a real bug of GCC.
#include
int main(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65752
Chung-Kil Hur changed:
What|Removed |Added
CC||gil.hur at sf dot snu.ac.kr
--- Comment
13 matches
Mail list logo
