--- Comment #6 from rguenth at gcc dot gnu dot org 2009-01-19 14:07 ---
Can you attach preprocessed source of idecode.c at least? Can you track down
where in idecode.c the bug is and wrap a main () around that piece, making it
an executable testcase?
Does 4.3.[23] work? Pleas adjust t
--- Comment #7 from joel at gcc dot gnu dot org 2009-01-19 14:38 ---
Works with 4.3.2 as shipped with Fedora 10 (RPM gcc-4.3.2-7.x86_64)
--
joel at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #8 from joel at gcc dot gnu dot org 2009-01-19 14:45 ---
$ gcc --version
gcc (GCC) 4.4.0 20090116 (experimental) [trunk revision 143442]
broken still. Test script
=
rm -rf b-gdb && mkdir b-gdb && cd b-gdb && \
/home/joel/gcc-
--- Comment #9 from joel at gcc dot gnu dot org 2009-01-19 14:51 ---
Created an attachment (id=17144)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17144&action=view)
PSIM test executable that produces assertion
PowerPC PSIM executable used by previous test script.
--
http://
--- Comment #10 from joel at gcc dot gnu dot org 2009-01-19 14:54 ---
Created an attachment (id=17145)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17145&action=view)
preprocessed idecode.c
Preprocessed version of idecode.i using this gcc version on Fedora 10:
4.4.0 20090116 (ex
--- Comment #11 from joel at gcc dot gnu dot org 2009-01-19 15:00 ---
(In reply to comment #6)
> Can you attach preprocessed source of idecode.c at least? Can you track down
> where in idecode.c the bug is and wrap a main () around that piece, making it
> an executable testcase?
psim i
--- Comment #12 from hjl dot tools at gmail dot com 2009-01-19 19:01
---
How can I reproduce it on Linux/x86-64, assuming I know nothing
about rtems and sim?
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--
--- Comment #13 from joel at gcc dot gnu dot org 2009-01-19 19:09 ---
Created an attachment (id=17147)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17147&action=view)
script to run psim
script to run psim to reproduce bug. Specifying the device tree is painful.
--
http://gc
--- Comment #14 from joel at gcc dot gnu dot org 2009-01-19 19:15 ---
(In reply to comment #12)
> How can I reproduce it on Linux/x86-64, assuming I know nothing
> about rtems and sim?
>
You don't have to know much of anything. It should be reproducible with
powerpc-elf but this is t
--- Comment #15 from hjl dot tools at gmail dot com 2009-01-19 21:38
---
Revision 142516 gave:
[...@gnu-28 pr38587]$ ./psim-4.10 ./powerpc-psim-ticker.ralf
events.c:329: assertion failed - !events->processing
[...@gnu-28 pr38587]$
Revision 142517 gave:
[...@gnu-34 pr38587]$ ./psim-
--- Comment #16 from joel at gcc dot gnu dot org 2009-01-19 22:20 ---
(In reply to comment #15)
> Revision 142516 gave:
>
> [...@gnu-28 pr38587]$ ./psim-4.10 ./powerpc-psim-ticker.ralf
> events.c:329: assertion failed - !events->processing
That sounds like the previous psim miscompiled
--- Comment #17 from hjl dot tools at gmail dot com 2009-01-19 23:29
---
*** Bug 38387 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38587
--- Comment #18 from hjl dot tools at gmail dot com 2009-01-19 23:35
---
(In reply to comment #11)
> (In reply to comment #6)
> > Can you attach preprocessed source of idecode.c at least? Can you track
> > down
> > where in idecode.c the bug is and wrap a main () around that piece, ma
--- Comment #19 from hjl dot tools at gmail dot com 2009-01-19 23:41
---
Revert revision revision 139996 doesn't solve the problem.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #20 from hjl dot tools at gmail dot com 2009-01-20 02:00
---
The problem may something to do with
setjmp
...
while (1)
{
foo (); // foo calls longjmp and foo is inlined.
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38587
--- Comment #21 from hjl dot tools at gmail dot com 2009-01-20 05:00
---
(In reply to comment #20)
> The problem may something to do with
>
> setjmp
> ...
> while (1)
> {
> foo (); // foo calls longjmp and foo is inlined.
> }
>
The problem is
if (setjmp (buf))
{
/* Res
--- Comment #22 from rguenth at gcc dot gnu dot org 2009-01-20 09:13
---
>From tree-inline.c:
case BUILT_IN_LONGJMP:
/* We can't inline functions that call __builtin_longjmp at
all. The non-local goto machinery really requires the
de
--- Comment #23 from hjl dot tools at gmail dot com 2009-01-20 14:24
---
(In reply to comment #22)
> From tree-inline.c:
>
> case BUILT_IN_LONGJMP:
> /* We can't inline functions that call __builtin_longjmp at
>all. The non-local goto machinery re
--- Comment #24 from rguenther at suse dot de 2009-01-20 15:01 ---
Subject: Re: [4.4 Regression] psim miscompiled #2
On Tue, 20 Jan 2009, hjl dot tools at gmail dot com wrote:
> --- Comment #23 from hjl dot tools at gmail dot com 2009-01-20 14:24
> ---
> (In reply to comment
--- Comment #25 from hjl dot tools at gmail dot com 2009-01-20 15:08
---
(In reply to comment #24)
> Subject: Re: [4.4 Regression] psim miscompiled #2
>
> On Tue, 20 Jan 2009, hjl dot tools at gmail dot com wrote:
>
> > --- Comment #23 from hjl dot tools at gmail dot com 2009-01
--- Comment #26 from rguenth at gcc dot gnu dot org 2009-01-20 15:29
---
Well, ISTR something about local variables need to be marked volatile if you
use setjmp/longjmp. Is psim really in compliance with what the standard says
here? See 7.13.2.1/3 "..., except that the values of objec
--- Comment #27 from hjl dot tools at gmail dot com 2009-01-20 15:49
---
(In reply to comment #26)
> Well, ISTR something about local variables need to be marked volatile if you
> use setjmp/longjmp. Is psim really in compliance with what the standard says
> here? See 7.13.2.1/3 "...,
--- Comment #28 from joel at gcc dot gnu dot org 2009-01-20 15:55 ---
I am starting a test sweep with this patch applied.
I will report back when the testing is done.
Thanks.
--joel
(In reply to comment #27)
> (In reply to comment #26)
> > Well, ISTR something about local variables
--- Comment #29 from schwab at suse dot de 2009-01-20 16:30 ---
(In reply to comment #27)
> This patch for sim:
> Index: sim/ppc/gen-idecode.c
> ===
> RCS file: /cvs/src/src/sim/ppc/gen-idecode.c,v
> retrieving revision 1.4
--- Comment #30 from hjl dot tools at gmail dot com 2009-01-20 16:36
---
(In reply to comment #28)
> I am starting a test sweep with this patch applied.
>
> I will report back when the testing is done.
>
I am not sure if those volatile are really needed. I am trying
to create a testc
--- Comment #31 from hjl dot tools at gmail dot com 2009-01-20 21:17
---
Created an attachment (id=17154)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17154&action=view)
A testcase
Revision 143498 gave:
[...@gnu-34 ppc]$ /export/gnu/import/rrs/143498/usr/bin/gcc -S bar.c -O2; e
--- Comment #32 from pinskia at gcc dot gnu dot org 2009-01-20 21:19
---
PR 38660 might the same issue too. It is an issue with longjmp and setjmp.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38587
--- Comment #33 from hjl dot tools at gmail dot com 2009-01-21 02:14
---
For
psim_set_halt_and_restart(system, &halt, ((void *)0));
if (_setjmp (halt))
return;
last_cpu = psim_last_cpu(system);
psim_set_halt_and_restart(system, &halt, &restart);
if (_setjmp (restart)) {
--- Comment #34 from vmakarov at redhat dot com 2009-01-21 03:15 ---
C standard guarantees that automatic variable only with volatile will be
restored after longjmp. Gcc puts volatiles on stack and don't use pseudos for
them. So they will be never shared on stack.
I think the code (its
--- Comment #35 from hjl dot tools at gmail dot com 2009-01-21 03:27
---
(In reply to comment #34)
> C standard guarantees that automatic variable only with volatile will be
> restored after longjmp. Gcc puts volatiles on stack and don't use pseudos for
> them. So they will be never sh
--- Comment #36 from pinskia at gcc dot gnu dot org 2009-01-21 03:28
---
(In reply to comment #35)
> (In reply to comment #34)
> > C standard guarantees that automatic variable only with volatile will be
> > restored after longjmp. Gcc puts volatiles on stack and don't use pseudos
> >
--- Comment #37 from pinskia at gcc dot gnu dot org 2009-01-21 03:35
---
To be more explict:
6.9.1/9:
Each parameter has automatic storage duration.
7.13.2.1/3:
All accessible objects have values, and all other components of the abstract
machine209)
have state, as of the time the longj
--- Comment #38 from schwab at suse dot de 2009-01-21 09:16 ---
(In reply to comment #35)
> "system", which is a function argument, is trashed here.
But it's not modified between setjmp and longjmp, so its value must be
preserved.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3858
--- Comment #39 from vmakarov at redhat dot com 2009-01-21 15:39 ---
Yes, right. I should have read the standard itself (not gcc manual which
states "ISO C says that automatic variables that are not declared `volatile'
have undefined values after a `longjmp'"). That is good that Andrew
--- Comment #40 from hjl dot tools at gmail dot com 2009-01-21 20:03
---
*** Bug 38660 has been marked as a duplicate of this bug. ***
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
-
35 matches
Mail list logo
