8:21 p.m.
[ Discussion redirected to xemacs-beta. ]
Zajcev Evgeny <zevlg(a)yandex.ru> wrote:
As you can see function CPTR1 just does nothing, even without
optimisation flags, gcc optimized this function to just return. So no
Gcc 3.4.2 is hideously broken if it's doing crud like that.
--
Darryl Okahata
darrylo(a)soco.agilent.com
DISCLAIMER: this message is the author's personal opinion and does not
constitute the support, opinion, or policy of Agilent Technologies, or
of the little green men that have been following him all day.
11:14 p.m.
New subject: [CORE (21.4)] "clever" compilers sometimes opt away too much.
Darryl Okahata <darrylo(a)soco.agilent.com> writes:
[ Discussion redirected to xemacs-beta. ]
Zajcev Evgeny <zevlg(a)yandex.ru> wrote:
> As you can see function CPTR1 just does nothing, even without
> optimisation flags, gcc optimized this function to just return. So no
Gcc 3.4.2 is hideously broken if it's doing crud like that.
Yes, but what we have is what we have. Here is my investigations:
---- file m.c ----
void
cptr1(void *ptr, unsigned int len)
{
if (len > 1)
/* If we can, try to avoid problems with super-optimizing compilers
that might decide that memcmp (ptr, ptr, len) can be optimized
away since its result is always 1. */
memcmp (ptr, (char *) ptr + 1, len - 1);
else
memcmp (ptr, ptr, len);
}
void
cptr2(void *ptr, unsigned int len)
{
while (len-- > 0) {
char a = ((char*)ptr)[len];
if (a == '1')
/* pass */;
}
}
int
main()
{
void *ptr = (void*)10;
cptr1(ptr, 10);
printf("cptr1\n");
cptr2(ptr, 10);
printf("cptr2\n");
return 0;
}
---- m.c ends here ---
[0][~]$ gcc342 -o m m.c
[0][~]$ ./m
cptr1
zsh: segmentation fault (core dumped) ./m
[139][~]$ gcc342 -O -o m m.c
[0][~]$ ./m
cptr1
cptr2
[0][~]$ gcc295 -o m m.c
[0][~]$ ./m
zsh: segmentation fault (core dumped) ./m
[139][~]$ gcc295 -O -o m m.c
[0][~]$ ./m
cptr1
cptr2
[0][~]$
CPTR1 works only with gcc295 without any optimisation flags. CPTR2
works on gcc295 and gcc342 without optimisation flags.
So even CPTR2 is does not cheats gcc optimisations fully, finally i
was able to get good results with next CPTR2:
void
cptr2(void *ptr, unsigned int len)
{
while (len-- > 0) {
char a = ((char*)ptr)[len];
if (a == '1')
((char*)ptr)[len] = a;
}
}
[0][~]$ gcc342 -o m m.c
[0][~]$ ./m
cptr1
zsh: segmentation fault (core dumped) ./m
[139][~]$ gcc342 -O -o m m.c
[0][~]$ ./m
cptr1
zsh: segmentation fault (core dumped) ./m
[139][~]$ gcc342 -O3 -o m m.c
[0][~]$ ./m
cptr1
zsh: segmentation fault (core dumped) ./m
[139][~]$ gcc295 -o m m.c
[0][~]$ ./m
zsh: segmentation fault (core dumped) ./m
[139][~]$ gcc295 -O -o m m.c
[0][~]$ ./m
cptr1
zsh: segmentation fault (core dumped) ./m
[139][~]$ gcc295 -O3 -o m m.c
[0][~]$ ./m
cptr1
zsh: segmentation fault (core dumped) ./m
[139][~]$
As you see new CPTR2 does the job with both gcc342 and gcc 295 and
any optimisation flags.
Thanks!
--
lg
11:32 p.m.
New subject: [CORE (21.4)] "clever" compilers sometimes opt away too much.
Zajcev Evgeny <zevlg(a)yandex.ru> writes:
[snip]
void
cptr2(void *ptr, unsigned int len)
{
while (len-- > 0) {
char a = ((char*)ptr)[len];
if (a == '1')
((char*)ptr)[len] = a;
}
}
Oh, my bad. I realized that this will not work for XEmacs, only after
sending mail. PTR may lay in read only segment and writing to it will
eventually lead to SIGBUS.
So here is another variant:
void
cptr2(void *ptr, unsigned int len)
{
static char dummy_char;
while (len-- > 0)
dummy_char = ((char*)ptr)[len];
}
Checked with gcc295 and gcc342, works with and without optimisation
flags.
--
lg
11:21 p.m.
New subject: [CORE (21.4)] "clever" compilers sometimes opt away too much.
Darryl> [ Discussion redirected to xemacs-beta. ]
Redirected from where? I have no context for this discussion. I don't know
what CPTR1 is and a quick find/grep doesn't locate it in the 21.4.15 source
(the only source on my currently Internet-unaware laptop), but if it does
nothing I see no reason the optimizer couldn't eliminate it.
--
Skip Montanaro
skip(a)mojam.com
http://www.mojam.com/
12:51 a.m.
New subject: [CORE (21.4)] "clever" compilers sometimes opt away too much.
Skip Montanaro <skip(a)pobox.com> writes:
Darryl> [ Discussion redirected to xemacs-beta. ]
Redirected from where? I have no context for this discussion.
The origin of this thread can be found at
http://thread.gmane.org/gmane.emacs.xemacs.patches/5361
Jon
1:08 a.m.
New subject: [CORE (21.4)] "clever" compilers sometimes opt away too much.
Skip Montanaro <skip(a)pobox.com> wrote:
Darryl> [ Discussion redirected to xemacs-beta. ]
Redirected from where? I have no context for this discussion. I don't know
what CPTR1 is and a quick find/grep doesn't locate it in the 21.4.15 source
Sorry. It was originally being discussed in xemacs-patches. The
function, "cptr1()", is part of a simple compiler test case, and is not
part of the XEmacs sources. Original message appended.
--
Darryl Okahata
darrylo(a)soco.agilent.com
DISCLAIMER: this message is the author's personal opinion and does not
constitute the support, opinion, or policy of Agilent Technologies, or
of the little green men that have been following him all day.
Date: Wed, 12 Jan 2005 23:02:15 +0300
To: Vin Shelton <acs(a)xemacs.org>
cc: XEmacs patches <xemacs-patches(a)xemacs.org>
From: Zajcev Evgeny <zevlg(a)yandex.ru>
Subject: Re: [CORE (21.4)] "clever" compilers sometimes opt away too much.
Vin Shelton <acs(a)xemacs.org> writes:
> Steve Youngs <steve(a)sxemacs.org> writes:
>
>> Sorry, haven't checked 21.5, but I'd imagine this is needed there
>> too.
>>
>> 21.4 patch:
>> ChangeLog files diff command: cvs -q diff -U 0
>> Files affected: src/ChangeLog
>> Source files diff command: cvs -q diff -uN
>> Files affected: src/emacs.c
>>
>> Index: src/ChangeLog
>> ===================================================================
>> RCS file: /pack/xemacscvs/XEmacs/xemacs/src/ChangeLog,v
>> retrieving revision 1.290.2.83
>> diff -u -U0 -r1.290.2.83 ChangeLog
>> --- src/ChangeLog 11 Jan 2005 02:02:11 -0000 1.290.2.83
>> +++ src/ChangeLog 12 Jan 2005 01:11:36 -0000
>> ＠＠ -0,0 +1,7 ＠＠
>> +2005-01-12 Steve Youngs <steve(a)sxemacs.org>
>> +
>> + From Evgeny Zajcev <lg(a)sxemacs.org>:
>> +
>> + * emacs.c (debug_can_access_memory): Fix problem of "clever"
>> + compilers being over-zealous in their optimising.
>> +
>> Index: src/emacs.c
>> ===================================================================
>> RCS file: /pack/xemacscvs/XEmacs/xemacs/src/emacs.c,v
>> retrieving revision 1.97.2.8
>> diff -u -u -r1.97.2.8 emacs.c
>> --- src/emacs.c 13 Jun 2004 20:19:39 -0000 1.97.2.8
>> +++ src/emacs.c 12 Jan 2005 01:10:26 -0000
>> ＠＠ -535,15 +535,13 ＠＠
>> old_sigsegv =
>> (SIGTYPE (*) (int)) signal (SIGSEGV, debug_memory_error);
>>
>> - if (len > 1)
>> - /* If we can, try to avoid problems with super-optimizing compilers
>> - that might decide that memcmp (ptr, ptr, len) can be optimized
>> - away since its result is always 1. */
>> - memcmp (ptr, (char *) ptr + 1, len - 1);
>> - else
>> - memcmp (ptr, ptr, len);
>> - }
>> - else
>> + /* Examine memory pool at PTR */
>> + while (len-- > 0) {
>> + char a = ((char*)ptr)[len];
>> + if (a == '1')
>> + /* pass */;
>> + }
>> + } else
>> retval = 0;
>> signal (SIGBUS, old_sigbus);
>> signal (SIGSEGV, old_sigsegv);
>>
>
> Do you have a test case?
Consider two functions:
---- file m.c ----
void
cptr1(void *ptr, unsigned int len)
{
if (len > 1)
/* If we can, try to avoid problems with super-optimizing compi
lers
that might decide that memcmp (ptr, ptr, len) can be optimiz
ed
away since its result is always 1. */
memcmp (ptr, (char *) ptr + 1, len - 1);
else
memcmp (ptr, ptr, len);
}
void
cptr2(void *ptr, unsigned int len)
{
while (len-- > 0) {
char a = ((char*)ptr)[len];
if (a == '1')
/* pass */;
}
}
---- end of m.c ----
compile it with gcc 3.4.2 for example
$ gcc -c m.c
$ objdump -D m.o
...
00000000 <cptr1>:
0: 55 push %ebp
1: 89 e5 mov %esp,%ebp
3: c9 leave
4: c3 ret
5: 8d 76 00 lea 0x0(%esi),%esi
00000008 <cptr2>:
8: 55 push %ebp
9: 89 e5 mov %esp,%ebp
b: 83 ec 04 sub $0x4,%esp
e: 8d 45 0c lea 0xc(%ebp),%eax
11: ff 08 decl (%eax)
13: 83 7d 0c ff cmpl $0xffffffff,0xc(%ebp)
17: 74 0d je 26 <cptr2+0x1e>
19: 8b 45 0c mov 0xc(%ebp),%eax
1c: 03 45 08 add 0x8(%ebp),%eax
1f: 8a 00 mov (%eax),%al
21: 88 45 ff mov %al,0xffffffff(%ebp)
24: eb e8 jmp e <cptr2+0x6>
26: c9 leave
27: c3 ret
...
As you can see function CPTR1 just does nothing, even without
optimisation flags, gcc optimized this function to just return. So no
actual reading accessity checking performed. CPTR2 does not have such
problem.
Thanks!
--
lg
7253
days inactive
7254
days old
5 comments
4 participants
participants (4)
-
Darryl Okahata -
Jon Ericson -
Skip Montanaro -
Zajcev Evgeny