--- Comment #12 from tsv at solvo dot ru 2005-11-02 22:26 ---
(In reply to comment #11)
> Subject: Bug 24178
>
> Author: rth
> Date: Wed Nov 2 18:20:07 2005
> New Revision: 106388
>
> URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106388
>
--- Comment #9 from tsv at solvo dot ru 2005-10-23 18:22 ---
(In reply to comment #8)
> (In reply to comment #7)
> > Can someone try sparc-linux, I would not doubt this could be reproduced
> > there
> > too.
>
> Actually, it can't, as I tried to explain
--- Comment #5 from tsv at solvo dot ru 2005-10-14 13:30 ---
I tried check the difference between 3.4 and 4.x. The 3.4 emit instruction that
correct passed pointer (in my case -25) and then stores value to member of
structure (p4) at correct offset (24).
In gcc 4.x the "store_fiel
--- Comment #3 from tsv at solvo dot ru 2005-10-04 05:59 ---
(In reply to comment #2)
> (In reply to comment #0)
>
> > The offset of "p5" member is 25 bytes, but compiler thinks that "p5" is
> > aligned
> > in "foo" function
>
ormal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tsv at solvo dot ru
GCC build triplet: alpha-*-linux-gnu
GCC host triplet: alpha-*-linux-gnu
GCC target triplet: alpha-*-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24178
--- Additional Comments From tsv at solvo dot ru 2005-09-28 18:07 ---
Retested in idle machine:
patch1 -O2 -mcpu=ev4 - 7 minutes
patch2 -O2 -mcpu=ev4 - 1.30 minutes
patch1 -O2 -mcpu=ev5 - 30 secs
patch2 -O2 -mcpu=ev5 - 13.6 secs
It does make a difference. :)
Thank you.
--
http
--- Additional Comments From tsv at solvo dot ru 2005-09-27 18:42 ---
Yes, I tested the reported gcc version just with your patch. After trying to
trace "synth_mult" I started to think that there should be a simplier way. :)
In my testcase the "choose_mult_variant&q
--- Additional Comments From tsv at solvo dot ru 2005-09-24 20:29 ---
It takes about 10 minutes to compile attached testcase with -O2 -mcpu=ev4 and
about 2 minutes for -O2 -mcpu=ev5 (compiled on EV45 233Mhz).
The difference is in cost of multiply op - 100 for ev4 and about 54 for ev5
--- Additional Comments From tsv at solvo dot ru 2005-09-19 19:21 ---
Created an attachment (id=9775)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9775&action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23971
P2
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tsv at solvo dot ru
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: alpha-unknown-linux-gnu
GCC host triplet: alpha-unknown-linux-gnu
GCC target triplet: alpha-unknown-linux-gnu
--- Additional Comments From tsv at solvo dot ru 2005-07-12 23:27 ---
(In reply to comment #5)
> (In reply to comment #4)
>
> Well, for this:
>
> void f(long *p) {
> *(char *) p = 0;
> }
>
> I get
>
> ldl t0,0(a0)
> andnot
--- Additional Comments From tsv at solvo dot ru 2005-07-12 23:16 ---
(In reply to comment #5)
> (In reply to comment #4)
>
> > Unfortunatelly, with switching to gcc 4.x some code started to
> > produce such exceptions (with gcc 3.4 everything was fine). Is there
>
--- Additional Comments From tsv at solvo dot ru 2005-07-12 22:48 ---
(In reply to comment #3)
> (In reply to comment #0)
>
>
> > Instead of generating the code to store a byte using unaligned load/store
> > instruction it uses aligned LDL/STL. The assembler cod
--- Additional Comments From tsv at solvo dot ru 2005-07-12 21:24 ---
Created an attachment (id=9255)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9255&action=view)
produced assembler output
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22447
--- Additional Comments From tsv at solvo dot ru 2005-07-12 21:23 ---
Created an attachment (id=9254)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9254&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22447
exceptions
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tsv at solvo dot ru
CC: gcc-bugs at gcc
--- Additional Comments From tsv at solvo dot ru 2005-05-12 08:25 ---
Your patch works a lot better than mine. Just tested and ant started to work.
Thank you very much.
--
What|Removed |Added
--- Additional Comments From tsv at solvo dot ru 2005-05-11 20:39 ---
(In reply to comment #22)
> Subject: Re: [4.0/4.1 regression] ivopts produces code that generates
"unaligned access exception"
>
>
> On May 5, 2005, at 4:03 PM, tsv at solvo dot ru wrote:
>
--- Additional Comments From tsv at solvo dot ru 2005-05-08 18:30 ---
(In reply to comment #13)
> It's the unwind info that should be changed, not the code.
> I'll do it.
Thank you very much. I just understand the code better than DWARF stuff. :)
--
http://gcc.
--- Additional Comments From tsv at solvo dot ru 2005-05-06 22:39 ---
Created an attachment (id=8832)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8832&action=view)
Fixes call frame size mismatch in ".frame" and ".eh_frame"
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21285
--- Additional Comments From tsv at solvo dot ru 2005-05-06 22:36 ---
Ok, I think I did find the problem. The unwind logic could not unwind deeper
than "ffi_closure_osf" function defined in libffi/src/alpha/osf.S (gdb showed
call stack like corrupted).
I checked number of byte
--- Additional Comments From tsv at solvo dot ru 2005-05-05 20:03 ---
(In reply to comment #20)
> (In reply to comment #19)
> > Should not be some warning to be generated?
>
> There is a warning if going directly from char * to the union pointer but
since you go
--- Additional Comments From tsv at solvo dot ru 2005-05-05 19:16 ---
I just extracted it from "dbus" package which I am testing on linux/alpha
platform. There are other packages (mozilla one of them) that started to
generate unaligned access exceptions then built by gcc 4.0.
--- Additional Comments From tsv at solvo dot ru 2005-05-05 19:07 ---
gcc version 4.0.0 20050423 (Red Hat 4.0.0-2)
Here is another test case that generates unaligned access exception:
typedef union
{
short i16;
unsigned short u16;
int
--- Additional Comments From tsv at solvo dot ru 2005-05-05 13:13 ---
I put my code into try/catch block and the exception was successfully caught.
How general EH is supposed to be called? Could it be arch specific?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21285
--- Additional Comments From tsv at solvo dot ru 2005-05-03 23:03 ---
Ok, somehow generic exception handler is missed on linux alpha. At this point I
don't undestand how and leave it for professionals.
Just check the same test on:
gij (GNU libgcj) version 3.4.3 20050227 (Red Hat
--- Additional Comments From tsv at solvo dot ru 2005-05-03 21:49 ---
So far I was able to debug to interpret.cc:3211.
It seems that unwind logic worked correctly (as far as I could understand) and
catch handler was called. The logic here didn't find exception handler and
&q
--- Additional Comments From tsv at solvo dot ru 2005-05-03 20:54 ---
How could I check that?
I ran "make check" in libffi library and it has not produced any errors.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21285
--- Additional Comments From tsv at solvo dot ru 2005-05-03 19:46 ---
Here is another stack dump from attempt of running the "ant":
exec "/usr/lib/jvm/java/bin/java" -classpath
"/usr/share/java/ant.jar:/usr/share/java/ant-launcher.jar:/usr/share/java/jaxp_parser
--- Additional Comments From tsv at solvo dot ru 2005-05-03 19:36 ---
Here it is. I tried to debug it, but it does a lot of things I have a little
knowlegde about.
(gdb) bt
#0 _Jv_Throw (value=0x20001b1b220) at ../../../libjava/exception.cc:113
#1 0x02b6c7dc in
nent: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tsv at solvo dot ru
CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu
dot org
GCC build triplet: alpha-redhat-linux
GCC host triplet: alpha-redhat-linux
GCC targe
--- Additional Comments From tsv at solvo dot ru 2005-04-19 19:57 ---
(In reply to comment #4)
> Then this is fixed for 3.4.4 and above by the following patch (which does the
same):
> 2005-04-11 Richard Henderson <[EMAIL PROTECTED]>
>
> * include/private
--- Additional Comments From tsv at solvo dot ru 2005-04-19 19:38 ---
I was able to fix the problem by applying the following patch:
--- gcc-3.4.3-20050222/boehm-gc/include/private/gcconfig.h.orig 2005-04-19
19:40:06.0 +0400
+++ gcc-3.4.3-20050222/boehm-gc/include/private
--- Additional Comments From tsv at solvo dot ru 2005-04-06 07:11 ---
No, it is UP machine. Yes - it crashes at the same place all the time.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20775
stop_func=0x203d4cc ) at ../../boehm-gc/alloc.c:365
#4 0x0204e418 in GC_init_inner () at ../../boehm-gc/misc.c:783
#5 0x0204e4c8 in GC_enable_incremental () at ../../boehm-gc/misc.c:822
#6 0x0001200051a8 in main () at ../../boehm-gc/tests/test.c:1805
(gdb)
--
S
--- Additional Comments From tsv at solvo dot ru 2005-03-30 09:43 ---
It does work for me too.
Thank you for quick fix.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20625
--- Additional Comments From tsv at solvo dot ru 2005-03-24 16:58 ---
If source code compiled without optimization - no unaligned access generated.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20625
--- Additional Comments From tsv at solvo dot ru 2005-03-24 16:57 ---
Created an attachment (id=8452)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8452&action=view)
Produced assembler file
This is generated assembler source with marked instruction (<---) that
generated
--- Additional Comments From tsv at solvo dot ru 2005-03-24 16:55 ---
Created an attachment (id=8450)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8450&action=view)
test case
This is small test case that shows the problem
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20625
ption"
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tsv at solvo dot ru
CC: gcc-bugs at gcc dot gnu dot org
40 matches
Mail list logo
