> "Jakub" == Jakub Jelinek writes:
Jakub> 2013-05-04 Jakub Jelinek
Jakub> PR libgcj/57074
Jakub> * class.c (emit_symbol_table): Use array type of the
Jakub> right size for the_syms_decl and its DECL_INITIAL, instead
Jakub> of symbols_array_type. Set TREE_TYPE (the_syms_decl) to it.
Ja
I'd really like to see this in, so that powerpc doesn't silently
generate wrong code. Bootstrapped and regression tested
powerpc64-linux, with Jakub's java fixes applied.
* varasm.c (output_object_block): Use .org for each item in
section anchor block rather than padding.
Index:
On Sat, May 04, 2013 at 12:31:31PM +0200, Eric Botcazou wrote:
> > Good to hear. I wasn't sure whether the sizes were even supposed to
> > agree. Assuming Jakub's second patch fixes java for us (testing now),
> > that just leaves gcc.c-torture/execute/20010924-1.c which fails to
> > size a3 and a
On Sat, May 04, 2013 at 09:20:24AM +0200, Jakub Jelinek wrote:
> 2013-05-04 Jakub Jelinek
>
> PR libgcj/57074
> * class.c (emit_symbol_table): Use array type of the
> right size for the_syms_decl and its DECL_INITIAL, instead
> of symbols_array_type. Set TREE_TYPE (the_
> Good to hear. I wasn't sure whether the sizes were even supposed to
> agree. Assuming Jakub's second patch fixes java for us (testing now),
> that just leaves gcc.c-torture/execute/20010924-1.c which fails to
> size a3 and a4 properly. Both of these vars have DECL_SIZE_UNIT of 1.
>
> struct {
On Sat, May 04, 2013 at 10:34:52AM +0200, Eric Botcazou wrote:
> > I believe the real problem here is in place_block_symbol() and
> > output_object_block(). If DECL_INITIAL is given for an array, then
> > shouldn't we be taking the size from the initializer?
>
> This means that the size of the ar
> I believe the real problem here is in place_block_symbol() and
> output_object_block(). If DECL_INITIAL is given for an array, then
> shouldn't we be taking the size from the initializer?
This means that the size of the array and the size of the initializer don't
agree, right? IMO this should
On Sat, May 04, 2013 at 09:33:34AM +0930, Alan Modra wrote:
> On Fri, May 03, 2013 at 07:10:15PM +0200, Jakub Jelinek wrote:
> > Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, but
> > not tested on powerpc32 where it actually caused runtime issues, can
> > somebody please try
I believe the real problem here is in place_block_symbol() and
output_object_block(). If DECL_INITIAL is given for an array, then
shouldn't we be taking the size from the initializer?
This patch fixes that problem, and ensures that we get an assembler
error if placement in the block changes. I'v
Here's a smaller case that shows the same problem
/home/amodra/build/gcc-current/./gcc/jc1
/home/amodra/src/gcc-current/libjava/classpath/lib/gnu/java/awt/dnd/peer/gtk/GtkDragSourceContextPeer.class
-fhash-synchronization -fuse-divide-subroutine -fuse-boehm-gc
-fnon-call-exceptions -fPIC -fkeep
On Fri, May 03, 2013 at 07:10:15PM +0200, Jakub Jelinek wrote:
> Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, but
> not tested on powerpc32 where it actually caused runtime issues, can
> somebody please try it there? Ok for trunk/4.8?
/home/amodra/build/gcc-current/./gcc/g
Hi!
As discovered by Alan Modra, the GCJ FE sometimes emits VAR_DECLs
that have smaller DECL_SIZE (and TYPE_SIZE (TREE_TYPE ())) than the
size of their initializers. I went through all build_constructor
calls in the java FE and it seems only these two spots are problematic,
they keep using arrays
12 matches
Mail list logo
