--- Comment #9 from ubizjak at gmail dot com 2007-07-04 14:11 ---
(In reply to comment #1)
Most likely -pg is changing the alignment of the stack which is incorrect. Oh
-pg code is emitted by the target specific code so this is a target issue.
Hm, on x86_64 pg inserts:
fprintf
--- Comment #10 from ubizjak at gmail dot com 2007-07-04 14:16 ---
(In reply to comment #9)
So, it loads %r11 and calls mcount. The only thing that can go wrong is, that
some value in %r11 gets rewritten.
Not even that because x86_64 is a NO_PROFILE_COUNTERS by default.
--
--- Comment #11 from ubizjak at gmail dot com 2007-07-04 14:26 ---
Hm...
--cut here--
// just a stupid testcase, don't bother with source
long long test(long long a, long long b)
{
return a / b;
}
--cut here--
cc1 -O2:
test:
.LFB2:
movq%rdi, %rdx
movq%rdi,
--- Comment #12 from jv244 at cam dot ac dot uk 2007-07-04 14:51 ---
(In reply to comment #11)
Just a wild guess, could this depend on PR32450? Could you check if there is
an
access to stack after leave insn?
Hi Uros,
thanks for looking into this, but I'm afraid I don't really
--- Comment #13 from jv244 at cam dot ac dot uk 2007-07-04 18:51 ---
just checked that current trunk (Wed Jul 4 17:21:37 UTC 2007 (revision
126328)) still exhibits the same problem. I don't see the same problem on an
opteron, only on a core2 (both using -march=native), so it could be
--- Comment #14 from jv244 at cam dot ac dot uk 2007-07-04 19:02 ---
Created an attachment (id=13847)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13847action=view)
bad assembly
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32450
--- Comment #15 from jv244 at cam dot ac dot uk 2007-07-04 19:03 ---
Created an attachment (id=13848)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13848action=view)
good assembly
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32450
--- Comment #16 from jv244 at cam dot ac dot uk 2007-07-04 19:09 ---
I've added the assembly as obtained from
1044 gfortran -O2 -pg -S cp_log_handling.f90
1045 mv cp_log_handling.s g.s
1046 gfortran -O2 -pg -march=native -S cp_log_handling.f90
1047 mv cp_log_handling.s b.s
--- Comment #17 from jv244 at cam dot ac dot uk 2007-07-04 19:17 ---
actually, in gdb, I find that the variable is not corrupted:
(gdb) bt
#0 0x0089dc94 in __message_passing_MOD_mp_stop ()
#1 0x0050ed2e in __cp_log_handling_MOD_cp_add_default_logger ()
#2
--- Comment #18 from ubizjak at gmail dot com 2007-07-04 19:58 ---
(In reply to comment #12)
thanks for looking into this, but I'm afraid I don't really understand what
you're asking for. Also the PR mentioned in the above comment is a circular
reference.
Sorry for the confusion,
On 4 Jul 2007 19:17:22 -, jv244 at cam dot ac dot uk
[EMAIL PROTECTED] wrote:
b.s:
.LCFI15:
cmpl$9, __cp_log_handling_MOD_stack_pointer(%rip)
callmcount
movq%rdi, %rbx
jle .L21
This is obviosuly wrong as the call will most likely clobber the
--- Comment #19 from pinskia at gmail dot com 2007-07-04 20:07 ---
Subject: Re: -pg seemingly causes miscompilation
On 4 Jul 2007 19:17:22 -, jv244 at cam dot ac dot uk
[EMAIL PROTECTED] wrote:
b.s:
.LCFI15:
cmpl$9, __cp_log_handling_MOD_stack_pointer(%rip)
--- Comment #20 from ubizjak at gmail dot com 2007-07-04 20:10 ---
(In reply to comment #17)
(the variable should be 0), but it looks like the assembly might be wrong:
b.s:
(1)cmpl$9, __cp_log_handling_MOD_stack_pointer(%rip)
callmcount
movq%rdi,
--- Comment #21 from jv244 at cam dot ac dot uk 2007-07-05 05:01 ---
This is a small testcase (that aborts if miscompiled):
cat test.f90
MODULE cp_log_handling
INTEGER, PRIVATE:: stack_pointer=0
INTEGER, PARAMETER, PRIVATE :: max_stack_pointer=10
CONTAINS
SUBROUTINE
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-06-27 08:58
---
(In reply to comment #3)
basically, you need -O2 and -march=native to trigger the bug
I can't reproduce that, what is your processor exactly? (ie what is native
for you)
--
fxcoudert at gcc dot gnu dot org
--- Comment #5 from jv244 at cam dot ac dot uk 2007-06-27 10:34 ---
(In reply to comment #4)
(In reply to comment #3)
basically, you need -O2 and -march=native to trigger the bug
I can't reproduce that, what is your processor exactly? (ie what is native
for you)
... here is a
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-06-27 11:25 ---
... here is a suggestion for the gcc crew ... what about having gfortran -v
When you invoke gfortran with -v march=native and with a source file, it will
show the values. This is the recommended way of showing
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2007-06-27 11:38
---
(In reply to comment #6)
When you invoke gfortran with -v march=native and with a source file, it will
show the values. This is the recommended way of showing how you involved
gcc/gfortran anyways.
Yes, that
--- Comment #8 from jv244 at cam dot ac dot uk 2007-06-27 12:15 ---
(In reply to comment #7)
(In reply to comment #6)
When you invoke gfortran with -v march=native and with a source file, it
will
right.. that shows:
gfortran --verbose -O2 -march=native -pg all.f90
Driving:
When you invoke gfortran with -v march=native and with a source file, it will
show the values. This is the recommended way of showing how you involved
gcc/gfortran anyways.
I get:
f951: error: unrecognized command line option -march=native
with
[karma] bug/timing% gfc -v -march=native -O3
On 6/27/07, Dominique Dhumieres [EMAIL PROTECTED] wrote:
When you invoke gfortran with -v march=native and with a source file, it will
show the values. This is the recommended way of showing how you involved
gcc/gfortran anyways.
I get:
f951: error: unrecognized command line option
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-21 09:07 ---
Most likely -pg is changing the alignment of the stack which is incorrect. Oh
-pg code is emitted by the target specific code so this is a target issue.
--
pinskia at gcc dot gnu dot org changed:
--- Comment #2 from jv244 at cam dot ac dot uk 2007-06-21 10:16 ---
(In reply to comment #1)
Most likely -pg is changing the alignment of the stack which is incorrect. Oh
-pg code is emitted by the target specific code so this is a target issue.
Is there an easy way for me to
--- Comment #3 from jv244 at cam dot ac dot uk 2007-06-21 14:28 ---
this is the list of options I have tested, the comment indicates if this yields
a failure or not, basically, you need -O2 and -march=native to trigger the bug
using '-O1 -march=native -pg' or '-O2 -pg' are not
24 matches
Mail list logo
