[patch java]: Intialize va_list_type_node to avoid segfault for x86_64 targets in respect for alignment

[patch java]: Intialize va_list_type_node to avoid segfault for x86_64 targets in respect for alignment

[Kai Tietz]

[-- Attachment #1: Type: text/plain, Size: 419 bytes --]

Hello,

we noticed that java doesn't initialize in decl.c
(java_init_decl_processing) the va_list_type_node. This leads to
issues in some architectures for wrong checks and/or ICE (as for
x86_64 one in i386.c (ix86_local_alignment)).

ChangeLog

2011-01-07  Kai Tietz

        * decl.c (java_init_decl_processing): Setup va_list_type_node.

Tested for i686-pc-cygwin and x86_64-w64-mingw32. Ok for apply?

Regards,
Kai

[-- Attachment #2: java_va_list.txt --]
[-- Type: text/plain, Size: 952 bytes --]

Index: gcc/gcc/java/decl.c
===================================================================
--- gcc.orig/gcc/java/decl.c	2010-12-15 14:28:00.000000000 +0100
+++ gcc/gcc/java/decl.c	2011-01-07 12:28:26.951395700 +0100
@@ -1154,6 +1154,19 @@ java_init_decl_processing (void)
     = add_builtin_function ("_Jv_remJ", t,
 			    0, NOT_BUILT_IN, NULL, NULL_TREE);
 
+  /* Initialize va_list_type_node.  */
+  t = targetm.build_builtin_va_list ();
+
+  /* Many back-ends define record types without setting TYPE_NAME.
+     If we copied the record type here, we'd keep the original
+     record type without a name.  This breaks name mangling.  So,
+     don't copy record types and let c_common_nodes_and_builtins()
+     declare the type to be __builtin_va_list.  */
+  if (TREE_CODE (t) != RECORD_TYPE)
+    t = build_variant_type_copy (t);
+
+  va_list_type_node = t;
+
   initialize_builtins ();
 
   soft_fmod_node = built_in_decls[BUILT_IN_FMOD];

Re: [patch java]: Intialize va_list_type_node to avoid segfault for x86_64 targets in respect for alignment

[Andrew Haley]

On 01/07/2011 11:42 AM, Kai Tietz wrote:
> Hello,
>
> we noticed that java doesn't initialize in decl.c
> (java_init_decl_processing) the va_list_type_node. This leads to
> issues in some architectures for wrong checks and/or ICE (as for
> x86_64 one in i386.c (ix86_local_alignment)).
>
> ChangeLog
>
> 2011-01-07  Kai Tietz
>
>          * decl.c (java_init_decl_processing): Setup va_list_type_node.
>
> Tested for i686-pc-cygwin and x86_64-w64-mingw32. Ok for apply?

Sure.

Andrew.

Re: [patch java]: Intialize va_list_type_node to avoid segfault for x86_64 targets in respect for alignment

[Kai Tietz]

2011/1/7 Andrew Haley <aph@redhat.com>:
> On 01/07/2011 11:42 AM, Kai Tietz wrote:
>>
>> Hello,
>>
>> we noticed that java doesn't initialize in decl.c
>> (java_init_decl_processing) the va_list_type_node. This leads to
>> issues in some architectures for wrong checks and/or ICE (as for
>> x86_64 one in i386.c (ix86_local_alignment)).
>>
>> ChangeLog
>>
>> 2011-01-07  Kai Tietz
>>
>>         * decl.c (java_init_decl_processing): Setup va_list_type_node.
>>
>> Tested for i686-pc-cygwin and x86_64-w64-mingw32. Ok for apply?
>
> Sure.
>
> Andrew.
>

Ok, applied to trunk at revision 168569. Is this patch ok for 4.5 branch, too?

Regards,
Kai

Re: [patch java]: Intialize va_list_type_node to avoid segfault for x86_64 targets in respect for alignment

[H.J. Lu]

On Fri, Jan 7, 2011 at 5:51 AM, Kai Tietz <ktietz70@googlemail.com> wrote:
> 2011/1/7 Andrew Haley <aph@redhat.com>:
>> On 01/07/2011 11:42 AM, Kai Tietz wrote:
>>>
>>> Hello,
>>>
>>> we noticed that java doesn't initialize in decl.c
>>> (java_init_decl_processing) the va_list_type_node. This leads to
>>> issues in some architectures for wrong checks and/or ICE (as for
>>> x86_64 one in i386.c (ix86_local_alignment)).
>>>
>>> ChangeLog
>>>
>>> 2011-01-07  Kai Tietz
>>>
>>>         * decl.c (java_init_decl_processing): Setup va_list_type_node.
>>>
>>> Tested for i686-pc-cygwin and x86_64-w64-mingw32. Ok for apply?
>>
>> Sure.
>>
>> Andrew.
>>
>
> Ok, applied to trunk at revision 168569. Is this patch ok for 4.5 branch, too?
>
>

This caused:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47215



-- 
H.J.

Re: [patch java]: Intialize va_list_type_node to avoid segfault for x86_64 targets in respect for alignment

[Kai Tietz]

2011/1/7 H.J. Lu <hjl.tools@gmail.com>:
> On Fri, Jan 7, 2011 at 5:51 AM, Kai Tietz <ktietz70@googlemail.com> wrote:
>> 2011/1/7 Andrew Haley <aph@redhat.com>:
>>> On 01/07/2011 11:42 AM, Kai Tietz wrote:
>>>>
>>>> Hello,
>>>>
>>>> we noticed that java doesn't initialize in decl.c
>>>> (java_init_decl_processing) the va_list_type_node. This leads to
>>>> issues in some architectures for wrong checks and/or ICE (as for
>>>> x86_64 one in i386.c (ix86_local_alignment)).
>>>>
>>>> ChangeLog
>>>>
>>>> 2011-01-07  Kai Tietz
>>>>
>>>>         * decl.c (java_init_decl_processing): Setup va_list_type_node.
>>>>
>>>> Tested for i686-pc-cygwin and x86_64-w64-mingw32. Ok for apply?
>>>
>>> Sure.
>>>
>>> Andrew.
>>>
>>
>> Ok, applied to trunk at revision 168569. Is this patch ok for 4.5 branch, too?
>>
>>
>
> This caused:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47215
>
>
>
> --
> H.J.
>

Hmm, I see that java doesn't initialize unsigned_type_node. HJ does it
solve the issue if you add 'unsigned_type_node = make_unsigned_type
(INT_TYPE_SIZE);' before the target hook in java/decl.c 't =
targetm.build_builtin_va_list ();' is called?

Regards,
Kai

Re: [patch java]: Intialize va_list_type_node to avoid segfault for x86_64 targets in respect for alignment

[H.J. Lu]

On Fri, Jan 7, 2011 at 11:20 AM, Kai Tietz <ktietz70@googlemail.com> wrote:
> 2011/1/7 H.J. Lu <hjl.tools@gmail.com>:
>> On Fri, Jan 7, 2011 at 5:51 AM, Kai Tietz <ktietz70@googlemail.com> wrote:
>>> 2011/1/7 Andrew Haley <aph@redhat.com>:
>>>> On 01/07/2011 11:42 AM, Kai Tietz wrote:
>>>>>
>>>>> Hello,
>>>>>
>>>>> we noticed that java doesn't initialize in decl.c
>>>>> (java_init_decl_processing) the va_list_type_node. This leads to
>>>>> issues in some architectures for wrong checks and/or ICE (as for
>>>>> x86_64 one in i386.c (ix86_local_alignment)).
>>>>>
>>>>> ChangeLog
>>>>>
>>>>> 2011-01-07  Kai Tietz
>>>>>
>>>>>         * decl.c (java_init_decl_processing): Setup va_list_type_node.
>>>>>
>>>>> Tested for i686-pc-cygwin and x86_64-w64-mingw32. Ok for apply?
>>>>
>>>> Sure.
>>>>
>>>> Andrew.
>>>>
>>>
>>> Ok, applied to trunk at revision 168569. Is this patch ok for 4.5 branch, too?
>>>
>>>
>>
>> This caused:
>>
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47215
>>
>>
>>
>> --
>> H.J.
>>
>
> Hmm, I see that java doesn't initialize unsigned_type_node. HJ does it
> solve the issue if you add 'unsigned_type_node = make_unsigned_type
> (INT_TYPE_SIZE);' before the target hook in java/decl.c 't =
> targetm.build_builtin_va_list ();' is called?
>

Please send me a proper patch.

Thanks.

-- 
H.J.

Re: [patch java]: Intialize va_list_type_node to avoid segfault for x86_64 targets in respect for alignment

[Kai Tietz]

2011/1/7 H.J. Lu <hjl.tools@gmail.com>:
> On Fri, Jan 7, 2011 at 11:20 AM, Kai Tietz <ktietz70@googlemail.com> wrote:
>> 2011/1/7 H.J. Lu <hjl.tools@gmail.com>:
>>> On Fri, Jan 7, 2011 at 5:51 AM, Kai Tietz <ktietz70@googlemail.com> wrote:
>>>> 2011/1/7 Andrew Haley <aph@redhat.com>:
>>>>> On 01/07/2011 11:42 AM, Kai Tietz wrote:
>>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> we noticed that java doesn't initialize in decl.c
>>>>>> (java_init_decl_processing) the va_list_type_node. This leads to
>>>>>> issues in some architectures for wrong checks and/or ICE (as for
>>>>>> x86_64 one in i386.c (ix86_local_alignment)).
>>>>>>
>>>>>> ChangeLog
>>>>>>
>>>>>> 2011-01-07  Kai Tietz
>>>>>>
>>>>>>         * decl.c (java_init_decl_processing): Setup va_list_type_node.
>>>>>>
>>>>>> Tested for i686-pc-cygwin and x86_64-w64-mingw32. Ok for apply?
>>>>>
>>>>> Sure.
>>>>>
>>>>> Andrew.
>>>>>
>>>>
>>>> Ok, applied to trunk at revision 168569. Is this patch ok for 4.5 branch, too?
>>>>
>>>>
>>>
>>> This caused:
>>>
>>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47215
>>>
>>>
>>>
>>> --
>>> H.J.
>>>
>>
>> Hmm, I see that java doesn't initialize unsigned_type_node. HJ does it
>> solve the issue if you add 'unsigned_type_node = make_unsigned_type
>> (INT_TYPE_SIZE);' before the target hook in java/decl.c 't =
>> targetm.build_builtin_va_list ();' is called?
>>
>
> Please send me a proper patch.
>
> Thanks.
>
> --
> H.J.
>

Ok, please try this patch. I am just about to do a build for 4.6 on
gcc14 of gcc's cfarm.

Regards,


Index: decl.c
===================================================================
--- decl.c      (revision 168580)
+++ decl.c      (working copy)
@@ -1153,8 +1153,8 @@
   soft_lrem_node
     = add_builtin_function ("_Jv_remJ", t,
                            0, NOT_BUILT_IN, NULL, NULL_TREE);
-
   /* Initialize va_list_type_node.  */
+  unsigned_type_node = make_unsigned_type (INT_TYPE_SIZE);
   t = targetm.build_builtin_va_list ();

   /* Many back-ends define record types without setting TYPE_NAME.

Re: [patch java]: Intialize va_list_type_node to avoid segfault for x86_64 targets in respect for alignment

[Dave Korn]

On 07/01/2011 19:36, Kai Tietz wrote:

> Index: decl.c
> ===================================================================
> --- decl.c      (revision 168580)
> +++ decl.c      (working copy)
> @@ -1153,8 +1153,8 @@
>    soft_lrem_node
>      = add_builtin_function ("_Jv_remJ", t,
>                             0, NOT_BUILT_IN, NULL, NULL_TREE);
> -
>    /* Initialize va_list_type_node.  */
> +  unsigned_type_node = make_unsigned_type (INT_TYPE_SIZE);
>    t = targetm.build_builtin_va_list ();
> 
>    /* Many back-ends define record types without setting TYPE_NAME.


  I think this should go somewhat further up, along with all the other
xxxx_type_nodes around the start of java_init_decl_processing().

    cheers,
      DaveK

Re: [patch java]: Intialize va_list_type_node to avoid segfault for x86_64 targets in respect for alignment

[Kai Tietz]

2011/1/7 Dave Korn <dave.korn.cygwin@gmail.com>:
> On 07/01/2011 19:36, Kai Tietz wrote:
>
>> Index: decl.c
>> ===================================================================
>> --- decl.c      (revision 168580)
>> +++ decl.c      (working copy)
>> @@ -1153,8 +1153,8 @@
>>    soft_lrem_node
>>      = add_builtin_function ("_Jv_remJ", t,
>>                             0, NOT_BUILT_IN, NULL, NULL_TREE);
>> -
>>    /* Initialize va_list_type_node.  */
>> +  unsigned_type_node = make_unsigned_type (INT_TYPE_SIZE);
>>    t = targetm.build_builtin_va_list ();
>>
>>    /* Many back-ends define record types without setting TYPE_NAME.
>
>
>  I think this should go somewhat further up, along with all the other
> xxxx_type_nodes around the start of java_init_decl_processing().
>
>    cheers,
>      DaveK
>

Well, not sure here. The other type_node language ones AFAICS, but
that one is just related to x86_64 ABI's record structure generation.
Btw the other unsigned_type_nodes (like short_... etc) aren't
necessary here.

My multilib bootstrap on linux x86_64 for this patch passed. I got no
segmentation fault on libjava.
So is patch ok for apply? Or should I move the unsigned_type_node
initialization more up?

Regards,
Kai

Re: [patch java]: Intialize va_list_type_node to avoid segfault for x86_64 targets in respect for alignment

[H.J. Lu]

On Fri, Jan 7, 2011 at 12:39 PM, Kai Tietz <ktietz70@googlemail.com> wrote:
> 2011/1/7 Dave Korn <dave.korn.cygwin@gmail.com>:
>> On 07/01/2011 19:36, Kai Tietz wrote:
>>
>>> Index: decl.c
>>> ===================================================================
>>> --- decl.c      (revision 168580)
>>> +++ decl.c      (working copy)
>>> @@ -1153,8 +1153,8 @@
>>>    soft_lrem_node
>>>      = add_builtin_function ("_Jv_remJ", t,
>>>                             0, NOT_BUILT_IN, NULL, NULL_TREE);
>>> -
>>>    /* Initialize va_list_type_node.  */
>>> +  unsigned_type_node = make_unsigned_type (INT_TYPE_SIZE);
>>>    t = targetm.build_builtin_va_list ();
>>>
>>>    /* Many back-ends define record types without setting TYPE_NAME.
>>
>>
>>  I think this should go somewhat further up, along with all the other
>> xxxx_type_nodes around the start of java_init_decl_processing().
>>
>>    cheers,
>>      DaveK
>>
>
> Well, not sure here. The other type_node language ones AFAICS, but
> that one is just related to x86_64 ABI's record structure generation.
> Btw the other unsigned_type_nodes (like short_... etc) aren't
> necessary here.
>
> My multilib bootstrap on linux x86_64 for this patch passed. I got no
> segmentation fault on libjava.
> So is patch ok for apply? Or should I move the unsigned_type_node
> initialization more up?
>

Let's fix the bootstrap now.

Thanks.

-- 
H.J.

Re: [patch java]: Intialize va_list_type_node to avoid segfault for x86_64 targets in respect for alignment

[Tom Tromey]

>>>>> "Kai" == Kai Tietz <ktietz70@googlemail.com> writes:

Kai> My multilib bootstrap on linux x86_64 for this patch passed. I got no
Kai> segmentation fault on libjava.
Kai> So is patch ok for apply? Or should I move the unsigned_type_node
Kai> initialization more up?

This is ok as-is.

thanks,
Tom

Re: [patch java]: Intialize va_list_type_node to avoid segfault for x86_64 targets in respect for alignment

[Kai Tietz]

2011/1/7 Tom Tromey <tromey@redhat.com>:
>>>>>> "Kai" == Kai Tietz <ktietz70@googlemail.com> writes:
>
> Kai> My multilib bootstrap on linux x86_64 for this patch passed. I got no
> Kai> segmentation fault on libjava.
> Kai> So is patch ok for apply? Or should I move the unsigned_type_node
> Kai> initialization more up?
>
> This is ok as-is.
>
> thanks,
> Tom
>

Thanks, applied at revision 168585.

Regards,
Kai

Re: [patch java]: Intialize va_list_type_node to avoid segfault for x86_64 targets in respect for alignment

[Andreas Schwab]

Kai Tietz <ktietz70@googlemail.com> writes:

> Index: gcc/gcc/java/decl.c
> ===================================================================
> --- gcc.orig/gcc/java/decl.c	2010-12-15 14:28:00.000000000 +0100
> +++ gcc/gcc/java/decl.c	2011-01-07 12:28:26.951395700 +0100
> @@ -1154,6 +1154,19 @@ java_init_decl_processing (void)
>      = add_builtin_function ("_Jv_remJ", t,
>  			    0, NOT_BUILT_IN, NULL, NULL_TREE);
>  
> +  /* Initialize va_list_type_node.  */
> +  t = targetm.build_builtin_va_list ();

That doesn't work.

Program received signal SIGSEGV, Segmentation fault.
place_field (rli=0x10c8c590, field=0xf7eb15a0) at ../../gcc/stor-layout.c:1132
1132      else if (TREE_CODE (type) == ERROR_MARK)
(gdb) bt
#0  place_field (rli=0x10c8c590, field=0xf7eb15a0)
    at ../../gcc/stor-layout.c:1132
#1  0x103e1398 in layout_type (type=0xf7eb1540) at ../../gcc/stor-layout.c:2095
#2  layout_type (type=0xf7eb1540) at ../../gcc/stor-layout.c:1849
#3  0x105ee484 in rs6000_build_builtin_va_list ()
    at ../../gcc/config/rs6000/rs6000.c:9435
#4  rs6000_build_builtin_va_list () at ../../gcc/config/rs6000/rs6000.c:9390
#5  0x100a8668 in java_init_decl_processing () at ../../gcc/java/decl.c:1158
#6  0x100bea78 in java_init () at ../../gcc/java/lang.c:324
#7  0x103eb9c4 in lang_dependent_init (argc=1, argv=0xffffe204)
    at ../../gcc/toplev.c:1738
#8  do_compile (argc=1, argv=0xffffe204) at ../../gcc/toplev.c:1873
#9  toplev_main (argc=1, argv=0xffffe204) at ../../gcc/toplev.c:1937
#10 0x1008d310 in main (argc=<value optimized out>, argv=<value optimized out>)
    at ../../gcc/main.c:36

Andreas.

-- 
Andreas Schwab, schwab@redhat.com
GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84  5EC7 45C6 250E 6F00 984E
"And now for something completely different."

Re: [patch java]: Intialize va_list_type_node to avoid segfault for x86_64 targets in respect for alignment

[Kai Tietz]

2011/1/11 Andreas Schwab <schwab@redhat.com>:
> Kai Tietz <ktietz70@googlemail.com> writes:
>
>> Index: gcc/gcc/java/decl.c
>> ===================================================================
>> --- gcc.orig/gcc/java/decl.c  2010-12-15 14:28:00.000000000 +0100
>> +++ gcc/gcc/java/decl.c       2011-01-07 12:28:26.951395700 +0100
>> @@ -1154,6 +1154,19 @@ java_init_decl_processing (void)
>>      = add_builtin_function ("_Jv_remJ", t,
>>                           0, NOT_BUILT_IN, NULL, NULL_TREE);
>>
>> +  /* Initialize va_list_type_node.  */
>> +  t = targetm.build_builtin_va_list ();
>
> That doesn't work.
>
> Program received signal SIGSEGV, Segmentation fault.
> place_field (rli=0x10c8c590, field=0xf7eb15a0) at ../../gcc/stor-layout.c:1132
> 1132      else if (TREE_CODE (type) == ERROR_MARK)
> (gdb) bt
> #0  place_field (rli=0x10c8c590, field=0xf7eb15a0)
>    at ../../gcc/stor-layout.c:1132
> #1  0x103e1398 in layout_type (type=0xf7eb1540) at ../../gcc/stor-layout.c:2095
> #2  layout_type (type=0xf7eb1540) at ../../gcc/stor-layout.c:1849
> #3  0x105ee484 in rs6000_build_builtin_va_list ()
>    at ../../gcc/config/rs6000/rs6000.c:9435
> #4  rs6000_build_builtin_va_list () at ../../gcc/config/rs6000/rs6000.c:9390
> #5  0x100a8668 in java_init_decl_processing () at ../../gcc/java/decl.c:1158
> #6  0x100bea78 in java_init () at ../../gcc/java/lang.c:324
> #7  0x103eb9c4 in lang_dependent_init (argc=1, argv=0xffffe204)
>    at ../../gcc/toplev.c:1738
> #8  do_compile (argc=1, argv=0xffffe204) at ../../gcc/toplev.c:1873
> #9  toplev_main (argc=1, argv=0xffffe204) at ../../gcc/toplev.c:1937
> #10 0x1008d310 in main (argc=<value optimized out>, argv=<value optimized out>)
>    at ../../gcc/main.c:36
>
> Andreas.
>
> --
> Andreas Schwab, schwab@redhat.com
> GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84  5EC7 45C6 250E 6F00 984E
> "And now for something completely different."
>

Ok, there is another target using for va_list_type_node record another
unitialized type-node ... Let me see ...

Re: [patch java]: Intialize va_list_type_node to avoid segfault for x86_64 targets in respect for alignment

[Kai Tietz]

2011/1/11 Kai Tietz <ktietz70@googlemail.com>:
> 2011/1/11 Andreas Schwab <schwab@redhat.com>:
>> Kai Tietz <ktietz70@googlemail.com> writes:
>>
>>> Index: gcc/gcc/java/decl.c
>>> ===================================================================
>>> --- gcc.orig/gcc/java/decl.c  2010-12-15 14:28:00.000000000 +0100
>>> +++ gcc/gcc/java/decl.c       2011-01-07 12:28:26.951395700 +0100
>>> @@ -1154,6 +1154,19 @@ java_init_decl_processing (void)
>>>      = add_builtin_function ("_Jv_remJ", t,
>>>                           0, NOT_BUILT_IN, NULL, NULL_TREE);
>>>
>>> +  /* Initialize va_list_type_node.  */
>>> +  t = targetm.build_builtin_va_list ();
>>
>> That doesn't work.
>>
>> Program received signal SIGSEGV, Segmentation fault.
>> place_field (rli=0x10c8c590, field=0xf7eb15a0) at ../../gcc/stor-layout.c:1132
>> 1132      else if (TREE_CODE (type) == ERROR_MARK)
>> (gdb) bt
>> #0  place_field (rli=0x10c8c590, field=0xf7eb15a0)
>>    at ../../gcc/stor-layout.c:1132
>> #1  0x103e1398 in layout_type (type=0xf7eb1540) at ../../gcc/stor-layout.c:2095
>> #2  layout_type (type=0xf7eb1540) at ../../gcc/stor-layout.c:1849
>> #3  0x105ee484 in rs6000_build_builtin_va_list ()
>>    at ../../gcc/config/rs6000/rs6000.c:9435
>> #4  rs6000_build_builtin_va_list () at ../../gcc/config/rs6000/rs6000.c:9390
>> #5  0x100a8668 in java_init_decl_processing () at ../../gcc/java/decl.c:1158
>> #6  0x100bea78 in java_init () at ../../gcc/java/lang.c:324
>> #7  0x103eb9c4 in lang_dependent_init (argc=1, argv=0xffffe204)
>>    at ../../gcc/toplev.c:1738
>> #8  do_compile (argc=1, argv=0xffffe204) at ../../gcc/toplev.c:1873
>> #9  toplev_main (argc=1, argv=0xffffe204) at ../../gcc/toplev.c:1937
>> #10 0x1008d310 in main (argc=<value optimized out>, argv=<value optimized out>)
>>    at ../../gcc/main.c:36
>>
>> Andreas.
>>
>> --
>> Andreas Schwab, schwab@redhat.com
>> GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84  5EC7 45C6 250E 6F00 984E
>> "And now for something completely different."
>>
>
> Ok, there is another target using for va_list_type_node record another
> unitialized type-node ... Let me see ...
>

Yes, rs9000 uses here unsigned_char_type_node, which isn't intialized by java.

Following patch should solve your issue:

Index: decl.c
===================================================================
--- decl.c      (revision 168662)
+++ decl.c      (working copy)
@@ -1154,6 +1154,7 @@
     = add_builtin_function ("_Jv_remJ", t,
                            0, NOT_BUILT_IN, NULL, NULL_TREE);
   /* Initialize va_list_type_node.  */
+  unsigned_char_type_node = make_unsigned_type (CHAR_TYPE_SIZE);
   unsigned_type_node = make_unsigned_type (INT_TYPE_SIZE);
   long_integer_type_node = make_signed_type (LONG_TYPE_SIZE);

Ok for apply, if it solves the issue?

Regards,
Kai

Re: [patch java]: Intialize va_list_type_node to avoid segfault for x86_64 targets in respect for alignment

[Andreas Schwab]

Kai Tietz <ktietz70@googlemail.com> writes:

> Following patch should solve your issue:

It doesn't.

Andreas.

-- 
Andreas Schwab, schwab@redhat.com
GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84  5EC7 45C6 250E 6F00 984E
"And now for something completely different."

Re: [patch java]: Intialize va_list_type_node to avoid segfault for x86_64 targets in respect for alignment

[Kai Tietz]

2011/1/11 Andreas Schwab <schwab@redhat.com>:
> Kai Tietz <ktietz70@googlemail.com> writes:
>
>> Following patch should solve your issue:
>
> It doesn't.
>
> Andreas.
>
> --
> Andreas Schwab, schwab@redhat.com
> GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84  5EC7 45C6 250E 6F00 984E
> "And now for something completely different."
>

Yes, it uses also the unsigned_short_type_node ...

Here a bunch of missing type-node initializers. Could you please test again?

Thanks in advance,
Kai

Index: decl.c
===================================================================
--- decl.c      (revision 168662)
+++ decl.c      (working copy)
@@ -1154,8 +1154,14 @@
     = add_builtin_function ("_Jv_remJ", t,
                            0, NOT_BUILT_IN, NULL, NULL_TREE);
   /* Initialize va_list_type_node.  */
+  unsigned_char_type_node = make_unsigned_type (CHAR_TYPE_SIZE);
+  short_integer_type_node = make_signed_type (SHORT_TYPE_SIZE);
+  short_unsigned_type_node = make_unsigned_type (SHORT_TYPE_SIZE);
   unsigned_type_node = make_unsigned_type (INT_TYPE_SIZE);
   long_integer_type_node = make_signed_type (LONG_TYPE_SIZE);
+  long_unsigned_type_node = make_unsigned_type (LONG_TYPE_SIZE);
+  long_long_integer_type_node = make_signed_type (LONG_LONG_TYPE_SIZE);
+  long_long_unsigned_type_node = make_unsigned_type (LONG_LONG_TYPE_SIZE);

   t = targetm.build_builtin_va_list ();

Re: [patch java]: Intialize va_list_type_node to avoid segfault for x86_64 targets in respect for alignment

[Andreas Schwab]

Kai Tietz <ktietz70@googlemail.com> writes:

> Here a bunch of missing type-node initializers. Could you please test again?

What about TYPE_STRING_FLAG?  What about char_type_node?  What about all
the other standard types created by build_common_tree_nodes?

Andreas.

-- 
Andreas Schwab, schwab@redhat.com
GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84  5EC7 45C6 250E 6F00 984E
"And now for something completely different."

Re: [patch java]: Intialize va_list_type_node to avoid segfault for x86_64 targets in respect for alignment

[Richard Guenther]

On Tue, Jan 11, 2011 at 5:09 PM, Andreas Schwab <schwab@redhat.com> wrote:
> Kai Tietz <ktietz70@googlemail.com> writes:
>
>> Here a bunch of missing type-node initializers. Could you please test again?
>
> What about TYPE_STRING_FLAG?  What about char_type_node?  What about all
> the other standard types created by build_common_tree_nodes?

Java should really be fixed to call build_common_tree_nodes instead
of replicating parts of it.

Richard.

> Andreas.
>
> --
> Andreas Schwab, schwab@redhat.com
> GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84  5EC7 45C6 250E 6F00 984E
> "And now for something completely different."
>

Re: [patch java]: Intialize va_list_type_node to avoid segfault for x86_64 targets in respect for alignment

[Kai Tietz]

2011/1/11 Richard Guenther <richard.guenther@gmail.com>:
> On Tue, Jan 11, 2011 at 5:09 PM, Andreas Schwab <schwab@redhat.com> wrote:
>> Kai Tietz <ktietz70@googlemail.com> writes:
>>
>>> Here a bunch of missing type-node initializers. Could you please test again?
>>
>> What about TYPE_STRING_FLAG?  What about char_type_node?  What about all
>> the other standard types created by build_common_tree_nodes?
>
> Java should really be fixed to call build_common_tree_nodes instead
> of replicating parts of it.

Yes, would be obviously the best. Nevertheless nothing for stage 4 (as
I talked to Tom on IRC already).

Andreas, did this patch fixed rs6000 java bootstrap for you?

Regards,
Kai

Re: [patch java]: Intialize va_list_type_node to avoid segfault for x86_64 targets in respect for alignment

[Andreas Schwab]

Kai Tietz <ktietz70@googlemail.com> writes:

> Andreas, did this patch fixed rs6000 java bootstrap for you?

The discrepancies with TYPE_STRING_FLAG and char_type_node remain.  I
don't know what kind of hidden effect that will have.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: [patch java]: Intialize va_list_type_node to avoid segfault for x86_64 targets in respect for alignment

[Kai Tietz]

2011/1/11 Andreas Schwab <schwab@linux-m68k.org>:
> Kai Tietz <ktietz70@googlemail.com> writes:
>
>> Andreas, did this patch fixed rs6000 java bootstrap for you?
>
> The discrepancies with TYPE_STRING_FLAG and char_type_node remain.  I
> don't know what kind of hidden effect that will have.
>
> Andreas.

I don't know if there are side-effects, or not. I just know that this
type wasn't set before, so it seems not to be used before. Otherwise
we would have seen a crash in java bootstrap before.
Maybe java maintainers could clarify this.

Regards,
Kai


-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| (")_(") him gain world domination

Re: [patch java]: Intialize va_list_type_node to avoid segfault for x86_64 targets in respect for alignment

[Andreas Schwab]

Kai Tietz <ktietz70@googlemail.com> writes:

> 2011/1/11 Andreas Schwab <schwab@linux-m68k.org>:
>> Kai Tietz <ktietz70@googlemail.com> writes:
>>
>>> Andreas, did this patch fixed rs6000 java bootstrap for you?
>>
>> The discrepancies with TYPE_STRING_FLAG and char_type_node remain.  I
>> don't know what kind of hidden effect that will have.
>>
>> Andreas.
>
> I don't know if there are side-effects, or not. I just know that this
> type wasn't set before, so it seems not to be used before.

But it is used now, so care must be taken.  Especially the different
char_type_node is worrying.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: [patch java]: Intialize va_list_type_node to avoid segfault for x86_64 targets in respect for alignment

[Richard Guenther]

On Tue, Jan 11, 2011 at 9:38 PM, Andreas Schwab <schwab@linux-m68k.org> wrote:
> Kai Tietz <ktietz70@googlemail.com> writes:
>
>> 2011/1/11 Andreas Schwab <schwab@linux-m68k.org>:
>>> Kai Tietz <ktietz70@googlemail.com> writes:
>>>
>>>> Andreas, did this patch fixed rs6000 java bootstrap for you?
>>>
>>> The discrepancies with TYPE_STRING_FLAG and char_type_node remain.  I
>>> don't know what kind of hidden effect that will have.
>>>
>>> Andreas.
>>
>> I don't know if there are side-effects, or not. I just know that this
>> type wasn't set before, so it seems not to be used before.
>
> But it is used now, so care must be taken.  Especially the different
> char_type_node is worrying.

Indeed.  Please either revert the full series or work towards
using build_common_tree_nodes.

Richard.

> Andreas.
>
> --
> Andreas Schwab, schwab@linux-m68k.org
> GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
> "And now for something completely different."
>

Re: [patch java]: Intialize va_list_type_node to avoid segfault for x86_64 targets in respect for alignment

[Kai Tietz]

[-- Attachment #1: Type: text/plain, Size: 1969 bytes --]

2011/1/12 Richard Guenther <richard.guenther@gmail.com>:
> On Tue, Jan 11, 2011 at 9:38 PM, Andreas Schwab <schwab@linux-m68k.org> wrote:
>> Kai Tietz <ktietz70@googlemail.com> writes:
>>
>>> 2011/1/11 Andreas Schwab <schwab@linux-m68k.org>:
>>>> Kai Tietz <ktietz70@googlemail.com> writes:
>>>>
>>>>> Andreas, did this patch fixed rs6000 java bootstrap for you?
>>>>
>>>> The discrepancies with TYPE_STRING_FLAG and char_type_node remain.  I
>>>> don't know what kind of hidden effect that will have.
>>>>
>>>> Andreas.
>>>
>>> I don't know if there are side-effects, or not. I just know that this
>>> type wasn't set before, so it seems not to be used before.
>>
>> But it is used now, so care must be taken.  Especially the different
>> char_type_node is worrying.
>
> Indeed.  Please either revert the full series or work towards
> using build_common_tree_nodes.
>
> Richard.
>
>> Andreas.

Well, as described in bug-report this missing va_list_type_node in
java's decl.c is a regression from 1999. I attaced a patch, which is
reverting it, but it is  a paper-patch. That char_type_node is used
within va_list_type_node of java's decl.c, shouldn't lead here to any
issues, as java FE didn't used that types before (as otherwise there
would be ICEs without that patch already), and now those types are
used just in va_list_type_node construction. The va_list types are
just used in comparison by some backends. Java doesn't operate with
va_list_type_node and you can't specify them within this language
AFAICS.


2011-01-16  Kai Tietz

	PR bootstrap/47215
	* decl.c (java_init_decl_processing): Remove
	va_list_type_node related type initializations.

2011-01-16  Kai Tietz

	PR bootstrap/47215
	* config/i386/i386.c (ix86_local_alignment): Handle
	case for va_list_type_node is nil.
	(ix86_canonical_va_list_type): Likewise.

Tested for x86_64-pc-linux-gnu and x86_64-w64-mingw32. Ok for apply?

Regards,
Kai

[-- Attachment #2: pr47215.txt --]
[-- Type: text/plain, Size: 2083 bytes --]

Index: gcc/gcc/config/i386/i386.c
===================================================================
--- gcc.orig/gcc/config/i386/i386.c	2011-01-09 14:50:57.000000000 +0100
+++ gcc/gcc/config/i386/i386.c	2011-01-16 09:53:42.379793400 +0100
@@ -22931,8 +22931,9 @@ ix86_local_alignment (tree exp, enum mac
       && TARGET_SSE)
     {
       if (AGGREGATE_TYPE_P (type)
-	   && (TYPE_MAIN_VARIANT (type)
-	       != TYPE_MAIN_VARIANT (va_list_type_node))
+	   && (va_list_type_node == NULL_TREE
+	       || (TYPE_MAIN_VARIANT (type)
+		   != TYPE_MAIN_VARIANT (va_list_type_node)))
 	   && TYPE_SIZE (type)
 	   && TREE_CODE (TYPE_SIZE (type)) == INTEGER_CST
 	   && (TREE_INT_CST_LOW (TYPE_SIZE (type)) >= 16
@@ -33682,7 +33683,7 @@ ix86_canonical_va_list_type (tree type)
   else if (POINTER_TYPE_P (type) && TREE_CODE (TREE_TYPE (type)) == ARRAY_TYPE)
     type = TREE_TYPE (type);
 
-  if (TARGET_64BIT)
+  if (TARGET_64BIT && va_list_type_node != NULL_TREE)
     {
       wtype = va_list_type_node;
 	  gcc_assert (wtype != NULL_TREE);
Index: gcc/gcc/java/decl.c
===================================================================
--- gcc.orig/gcc/java/decl.c	2011-01-11 20:36:15.000000000 +0100
+++ gcc/gcc/java/decl.c	2011-01-16 09:46:13.187101100 +0100
@@ -1153,21 +1153,6 @@ java_init_decl_processing (void)
   soft_lrem_node
     = add_builtin_function ("_Jv_remJ", t,
 			    0, NOT_BUILT_IN, NULL, NULL_TREE);
-  /* Initialize va_list_type_node.  */
-  unsigned_type_node = make_unsigned_type (INT_TYPE_SIZE);
-  long_integer_type_node = make_signed_type (LONG_TYPE_SIZE);
-
-  t = targetm.build_builtin_va_list ();
-
-  /* Many back-ends define record types without setting TYPE_NAME.
-     If we copied the record type here, we'd keep the original
-     record type without a name.  This breaks name mangling.  So,
-     don't copy record types and let c_common_nodes_and_builtins()
-     declare the type to be __builtin_va_list.  */
-  if (TREE_CODE (t) != RECORD_TYPE)
-    t = build_variant_type_copy (t);
-
-  va_list_type_node = t;
 
   initialize_builtins ();
 

Re: [patch java]: Intialize va_list_type_node to avoid segfault for x86_64 targets in respect for alignment

[Tom Tromey]

>>>>> "Richard" == Richard Guenther <richard.guenther@gmail.com> writes:

Richard> Indeed.  Please either revert the full series or work towards
Richard> using build_common_tree_nodes.

It seems to me that his current patches remove some crashes.
Presumably they can't affect correctness since those nodes are never
used or generated by the java front end in the first place.
So, I think reverting them is too strong.

I agree that java probably should use the common tree-building
infrastructure.  ISTR looking at this once though and deciding it was
hard.

Tom

Re: [patch java]: Intialize va_list_type_node to avoid segfault for x86_64 targets in respect for alignment

[Tom Tromey]

>>>>> "Kai" == Kai Tietz <ktietz70@googlemail.com> writes:

Kai> Java doesn't operate with va_list_type_node and you can't specify
Kai> them within this language AFAICS.

That is correct.

Tom

Re: [patch java]: Intialize va_list_type_node to avoid segfault for x86_64 targets in respect for alignment

[Jakub Jelinek]

On Mon, Jan 17, 2011 at 07:28:13AM -0700, Tom Tromey wrote:
> >>>>> "Richard" == Richard Guenther <richard.guenther@gmail.com> writes:
> 
> Richard> Indeed.  Please either revert the full series or work towards
> Richard> using build_common_tree_nodes.
> 
> It seems to me that his current patches remove some crashes.
> Presumably they can't affect correctness since those nodes are never
> used or generated by the java front end in the first place.
> So, I think reverting them is too strong.

The crashes were just on i?86 AFAIK, and only because the backend (IMHO
incorrectly) assumed va_list_type_node is always non-NULL.  I think
languages that don't have va_list type nor support va_* macros shouldn't be
forced to create such type.

> I agree that java probably should use the common tree-building
> infrastructure.  ISTR looking at this once though and deciding it was
> hard.

I'd say that is clearly stage1 material though, not stage4.
The patch caused so many regressions that IMHO at least for stage4 reverting
it is the only sane approach.

	Jakub

Re: [patch java]: Intialize va_list_type_node to avoid segfault for x86_64 targets in respect for alignment

[Jakub Jelinek]

Hi!

I'd prefer if we go with this patch, at least for 4.6.  For 4.7 somebody can
do something about the type initialization unification, but that is IMHO
stage1 material, not stage4.  This is a P1 bootstrap failure on several
targets AFAIK.

Uros/Richard, could you please review the i386.c changes?  I think Kai
can just revert his own recent changes without any kind of acking.

I believe other targets use va_list_type_node just in va_start expansion,
va_arg gimplification and vaarg setup in ... functions, but all those
should never happen in Java which doesn't have them.

On Sun, Jan 16, 2011 at 10:21:50AM +0100, Kai Tietz wrote:
> Well, as described in bug-report this missing va_list_type_node in
> java's decl.c is a regression from 1999. I attaced a patch, which is
> reverting it, but it is  a paper-patch. That char_type_node is used
> within va_list_type_node of java's decl.c, shouldn't lead here to any
> issues, as java FE didn't used that types before (as otherwise there
> would be ICEs without that patch already), and now those types are
> used just in va_list_type_node construction. The va_list types are
> just used in comparison by some backends. Java doesn't operate with
> va_list_type_node and you can't specify them within this language
> AFAICS.
> 
> 
> 2011-01-16  Kai Tietz
> 
> 	PR bootstrap/47215
> 	* decl.c (java_init_decl_processing): Remove
> 	va_list_type_node related type initializations.
> 
> 2011-01-16  Kai Tietz
> 
> 	PR bootstrap/47215
> 	* config/i386/i386.c (ix86_local_alignment): Handle
> 	case for va_list_type_node is nil.
> 	(ix86_canonical_va_list_type): Likewise.
> 
> Tested for x86_64-pc-linux-gnu and x86_64-w64-mingw32. Ok for apply?
> 
> Regards,
> Kai

> Index: gcc/gcc/config/i386/i386.c
> ===================================================================
> --- gcc.orig/gcc/config/i386/i386.c	2011-01-09 14:50:57.000000000 +0100
> +++ gcc/gcc/config/i386/i386.c	2011-01-16 09:53:42.379793400 +0100
> @@ -22931,8 +22931,9 @@ ix86_local_alignment (tree exp, enum mac
>        && TARGET_SSE)
>      {
>        if (AGGREGATE_TYPE_P (type)
> -	   && (TYPE_MAIN_VARIANT (type)
> -	       != TYPE_MAIN_VARIANT (va_list_type_node))
> +	   && (va_list_type_node == NULL_TREE
> +	       || (TYPE_MAIN_VARIANT (type)
> +		   != TYPE_MAIN_VARIANT (va_list_type_node)))
>  	   && TYPE_SIZE (type)
>  	   && TREE_CODE (TYPE_SIZE (type)) == INTEGER_CST
>  	   && (TREE_INT_CST_LOW (TYPE_SIZE (type)) >= 16
> @@ -33682,7 +33683,7 @@ ix86_canonical_va_list_type (tree type)
>    else if (POINTER_TYPE_P (type) && TREE_CODE (TREE_TYPE (type)) == ARRAY_TYPE)
>      type = TREE_TYPE (type);
>  
> -  if (TARGET_64BIT)
> +  if (TARGET_64BIT && va_list_type_node != NULL_TREE)
>      {
>        wtype = va_list_type_node;
>  	  gcc_assert (wtype != NULL_TREE);
> Index: gcc/gcc/java/decl.c
> ===================================================================
> --- gcc.orig/gcc/java/decl.c	2011-01-11 20:36:15.000000000 +0100
> +++ gcc/gcc/java/decl.c	2011-01-16 09:46:13.187101100 +0100
> @@ -1153,21 +1153,6 @@ java_init_decl_processing (void)
>    soft_lrem_node
>      = add_builtin_function ("_Jv_remJ", t,
>  			    0, NOT_BUILT_IN, NULL, NULL_TREE);
> -  /* Initialize va_list_type_node.  */
> -  unsigned_type_node = make_unsigned_type (INT_TYPE_SIZE);
> -  long_integer_type_node = make_signed_type (LONG_TYPE_SIZE);
> -
> -  t = targetm.build_builtin_va_list ();
> -
> -  /* Many back-ends define record types without setting TYPE_NAME.
> -     If we copied the record type here, we'd keep the original
> -     record type without a name.  This breaks name mangling.  So,
> -     don't copy record types and let c_common_nodes_and_builtins()
> -     declare the type to be __builtin_va_list.  */
> -  if (TREE_CODE (t) != RECORD_TYPE)
> -    t = build_variant_type_copy (t);
> -
> -  va_list_type_node = t;
>  
>    initialize_builtins ();
>  


	Jakub

Re: [patch java]: Intialize va_list_type_node to avoid segfault for x86_64 targets in respect for alignment

[Richard Henderson]

>> 2011-01-16  Kai Tietz
>>
>> 	PR bootstrap/47215
>> 	* config/i386/i386.c (ix86_local_alignment): Handle
>> 	case for va_list_type_node is nil.
>> 	(ix86_canonical_va_list_type): Likewise.

Ok.


r~

Re: [patch java]: Intialize va_list_type_node to avoid segfault for x86_64 targets in respect for alignment

[Kai Tietz]

2011/1/21 Richard Henderson <rth@redhat.com>:
>>> 2011-01-16  Kai Tietz
>>>
>>>      PR bootstrap/47215
>>>      * config/i386/i386.c (ix86_local_alignment): Handle
>>>      case for va_list_type_node is nil.
>>>      (ix86_canonical_va_list_type): Likewise.
>
> Ok.
>
>
> r~
>

Applied at revision 169080.

Kai