Re: Types of operands in a gimple equality operation
On Fri, Nov 10, 2017 at 3:54 PM, Andrew MacLeod wrote:
> On 11/10/2017 09:03 AM, Richard Biener wrote:
>>
>> On Fri, Nov 10, 2017 at 2:49 PM, Andrew MacLeod
>> wrote:
>>>
>>> Before I open a PR, I want to confirm my beliefs.
>>>
>>>
>>> Is it not true that both operations of a gimple operation such as == or
>>> !=
>>> must satisfy types_compatible_p (op1_type, op2_type) ? Even when one is
>>> a
>>> constant?
>>>
>>> given :
>>>
>>>_10 = _2 != 0
>>>
>>> so the generic node for the 0 needs to be a type compatible with _2?
>>>
>>> I ask because I tripped over a fortran test where that is not true. It is
>>> comparing a function pointer of some sort with a (void *)0, and the
>>> types_compatible_p check fails.
>>>
>>> I hacked the compiler to check when building a gimple assign to verify
>>> that
>>> the types are compatible. It succeeds and entire bootstrap cycle, which
>>> leads me to believe my assertion is true. For some reason I thought there
>>> was gimple verification that would catch things like this.. apparently
>>> not?
>>>
>>> Index: gimple.c
>>> ===
>>> *** gimple.c(revision 254327)
>>> --- gimple.c(working copy)
>>> *** gimple_build_assign_1 (tree lhs, enum tr
>>> *** 423,428
>>> --- 423,430
>>>{
>>> gcc_assert (num_ops > 2);
>>> gimple_assign_set_rhs2 (p, op2);
>>> + if (subcode == EQ_EXPR || subcode == NE_EXPR)
>>> + gcc_assert (types_compatible_p (TREE_TYPE (op1), TREE_TYPE (op2)));
>>>}
>>>
>>>
>>> and when I run it on this small program:
>>>
>>>interface
>>> integer function foo ()
>>> end function
>>> integer function baz ()
>>> end function
>>>end interface
>>>procedure(foo), pointer :: ptr
>>>ptr => baz
>>>if (.not.associated (ptr, baz)) call abort
>>> end
>>>
>>> I get a trap on this statement:
>>>
>>> if (.not.associated (ptr, baz)) call abort
>>>
>>> internal compiler error: in gimple_build_assign_1, at gimple.c:443
>>>
>>> The IL is comparing
>>> ptr == 0B
>>>
>>> and I see:
>>> Type op1 : 0x7fd8e312df18 -> integer(kind=4) (*) (void)
>>> Type op2 : 0x7fd8e2fa10a8 -> void *
>>>
>>> These 2 types fail the types_compatible_p test.
>>>
>>> So is this a bug like I think it is?
>>
>> Always look at tree-cfg.c:verify_gimple_*
>>
>> Quoting:
>>
>> static bool
>> verify_gimple_comparison (tree type, tree op0, tree op1, enum tree_code
>> code)
>> {
>> ...
>>/* For comparisons we do not have the operations type as the
>> effective type the comparison is carried out in. Instead
>> we require that either the first operand is trivially
>> convertible into the second, or the other way around.
>> Because we special-case pointers to void we allow
>> comparisons of pointers with the same mode as well. */
>>if (!useless_type_conversion_p (op0_type, op1_type)
>>&& !useless_type_conversion_p (op1_type, op0_type)
>>&& (!POINTER_TYPE_P (op0_type)
>>|| !POINTER_TYPE_P (op1_type)
>>|| TYPE_MODE (op0_type) != TYPE_MODE (op1_type)))
>> {
>>error ("mismatching comparison operand types");
>>debug_generic_expr (op0_type);
>>debug_generic_expr (op1_type);
>>return true;
>> }
>>
>> this is exactly because we have that "wart"
>>
>> bool
>> useless_type_conversion_p (tree outer_type, tree inner_type)
>> {
>>/* Do the following before stripping toplevel qualifiers. */
>>if (POINTER_TYPE_P (inner_type)
>>&& POINTER_TYPE_P (outer_type))
>> {
>> ...
>>/* Do not lose casts to function pointer types. */
>>if ((TREE_CODE (TREE_TYPE (outer_type)) == FUNCTION_TYPE
>> || TREE_CODE (TREE_TYPE (outer_type)) == METHOD_TYPE)
>>&& !(TREE_CODE (TREE_TYPE (inner_type)) == FUNCTION_TYPE
>> || TREE_CODE (TREE_TYPE (inner_type)) == METHOD_TYPE))
>> return false;
>> }
>>
>> which is IIRC because of targets with function descriptors (details are
>> lost
>> on me, but I remember repeatedly trying to get rid of this special case).
>>
> Huh, that bites. Im surprised we don't just make those places produce a
> cast, or just introduce an explicit cast of the (void *)0 during the
> expression building process.
I'm quite sure we could relax the above now given we have gimple_call_fntype
to preserve the original function type. But I don't remember what broke and
exactly why on those pesky fn descriptor targets. These days I only know
about IA64.
Richard.
> Of course, I'm sure its not that simple :-P Nothing ever is.
>
> OKeydoke. I'll leave it as is an allow the wart to pass my code as well for
> the moment.
>
> Thanks
> Adnrew
>
>
Re: Question about generated type for common block in fortran
Hi, On Thu, 9 Nov 2017, Bin.Cheng wrote: > So I have two questions here. > A) Is this special kind union type only generated by fortran FE for > equivalence+common? It's not special in that it isn't marked in any way. For all purposes it's a normal union type with surprising field(offset)s. I don't know if it can occur for any situations except equivalence+common. Not from the fortran frontend I believe. > B) For the special union type that has non-zero offset fields. Is it > safe to assume field A is not the last flex array: if there is field B > that offset_B >= (offset_A + length_A)? No. You can make equivalences between all kinds of objects, including non-arrays. You can also equivalence (say) an integer variable and an individual array element. Also flex arrays don't enter the picture, you can equivalize (tm) also arrays of fixed size. Ciao, Michael.
Re: Question about generated type for common block in fortran
On Mon, Nov 13, 2017 at 11:01 AM, Michael Matz wrote: > Hi, > > On Thu, 9 Nov 2017, Bin.Cheng wrote: > >> So I have two questions here. >> A) Is this special kind union type only generated by fortran FE for >> equivalence+common? > > It's not special in that it isn't marked in any way. For all purposes > it's a normal union type with surprising field(offset)s. I don't know if > it can occur for any situations except equivalence+common. Not from the > fortran frontend I believe. > >> B) For the special union type that has non-zero offset fields. Is it >> safe to assume field A is not the last flex array: if there is field B >> that offset_B >= (offset_A + length_A)? > > No. You can make equivalences between all kinds of objects, > including non-arrays. You can also equivalence (say) an integer variable > and an individual array element. Also flex arrays don't enter the > picture, you can equivalize (tm) also arrays of fixed size. Just a remark on the optimization you want to achieve. Rather than trying to fix things through max_size and friends you can also look at nonoverlapping_component_refs_of_decl_p and/or nonoverlapping_component_refs_p both of which currently punt for UNION_TYPEs. So I was thinking of a good condition to quickly decide whether UNION_TYPE fields may overlap or not (and thus to distinguish the Fortran case which then requires more elaborate processing). A simple one might be to quickly bail out if DECL_FIELD_[BIT_]OFFSET are the same. This might be a more local "fix" for the missed aliasing than trying to jump into the flex array issues. Richard. > > Ciao, > Michael.
Re: Types of operands in a gimple equality operation
On 11/13/2017 01:30 AM, Richard Biener wrote: >> Huh, that bites. Im surprised we don't just make those places produce a >> cast, or just introduce an explicit cast of the (void *)0 during the >> expression building process. > > I'm quite sure we could relax the above now given we have gimple_call_fntype > to preserve the original function type. But I don't remember what broke and > exactly why on those pesky fn descriptor targets. These days I only know > about IA64. It could well have been a PA-ism at the time. I can recall looking at some of this stuff, but none of the details. jeff
Re: Types of operands in a gimple equality operation
On Mon, Nov 13, 2017 at 9:51 AM, Jeff Law wrote: > On 11/13/2017 01:30 AM, Richard Biener wrote: > >>> Huh, that bites. Im surprised we don't just make those places produce a >>> cast, or just introduce an explicit cast of the (void *)0 during the >>> expression building process. >> >> I'm quite sure we could relax the above now given we have gimple_call_fntype >> to preserve the original function type. But I don't remember what broke and >> exactly why on those pesky fn descriptor targets. These days I only know >> about IA64. > It could well have been a PA-ism at the time. I can recall looking at > some of this stuff, but none of the details. AIX and PPC64 BE Linux also use function descriptors. - David
Re: [net-next:master 488/665] verifier.c:undefined reference to `__multi3'
On 11/11/2017 05:33 PM, Fengguang Wu wrote: CC gcc list. According to Alexei: This is a known issue with gcc 7 on mips that is "optimizing" normal 64-bit multiply into 128-bit variant. Nothing to fix on the kernel side. I filed a bug report. This is now https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82981 I found a helpful thread at https://www.linux-mips.org/archives/linux-mips/2017-08/msg00041.html that had enough info for me to reproduce and file the bug report. Jim
