This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug ipa/70646] [4.9/5/6 Regression] Corrupt truncated function


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70646

--- Comment #21 from rguenther at suse dot de <rguenther at suse dot de> ---
On April 15, 2016 3:31:33 PM GMT+02:00, "hubicka at gcc dot gnu.org"
<gcc-bugzilla@gcc.gnu.org> wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70646
>
>--- Comment #16 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
>> Honza?  This seems to be somewhat fragile (redirecting things to
>unreachable
>> but _not_ changing the actual predicates in the IL).  Claiming the
>> predicate is constant true is also a bit bogus (as can be seen in
>following
>> optimization).
>
>At WPA stage inliner can not update IL, so it simply redirects to
>builtin_unreachable if predicate is FALSE and expects scalar passes to
>be
>monotonously smarter than IPA analysis. 
>
>BB3 predicate true is conservatively correct: there is no predicate to
>represent that something is not constant because we assume scalar
>optimizers to
>possibly be stronger than us and decide better.
>
>Here we manage to assume that builtin_constant_p is true and thus we
>conclude
>the following BB is unreachable:
>BB 4 predicate:(op0[ref offset: 0] not constant)                       
>       
>iftmp.0_26 = __builtin_bswap64 (_3);                                   
>      
>                freq:0.61 size:  1 time:  1
>This is because ipa-prop analyzes the values in node_name:
>
>Jump functions of caller  broken/2:                                    
>      
>callsite  broken/2 -> wwn_to_u64/1 :                                   
>    
>param 0: UNKNOWN                                                       
> 
>Aggregate passed by reference:                                         
>  offset: 0, cst: 255                                                  
>  offset: 8, cst: 255                                                  
>  offset: 16, cst: 255                                                 
>  offset: 24, cst: 255                                                 
>  offset: 32, cst: 255                                                 
>  offset: 40, cst: 255                                                 
>  offset: 48, cst: 255                                                 
>  offset: 56, cst: 255                                                 
>
>but later we fold:
>
><bb 2>:                                                                
>      
>node_name[0] = 255;                                                    
>      
>node_name[1] = 255;                                                    
>      
>node_name[2] = 255;                                                    
>      
>node_name[3] = 255;                                                    
>      
>node_name[4] = 255;                                                    
>      
>node_name[5] = 255;                                                    
>      
>node_name[6] = 255;                                                    
>      
>node_name[7] = 255;                                                    
>      
>_14 = MEM[(const u64 *)&node_name];                                    
>      
>_15 = __builtin_constant_p (_14);                                      
>      
>
>into false (which is stupid, but conservatively correct modulo the
>assumption
>about IPA passes being consistently weakter than local passes).
>
>Making IPA passes to fold builtin_constant_p call into true is
>technically
>possible, if I add builtin_true and redirect to it, but it would not be
>very
>good if the local passes can not fold above (as the wrong arm is
>taken).
>
>So can we possibly fix the local passes?You can't rely on this happening, consider -fno-foo.

So my original local hack was to not do this built-in constant stuff for
is_refp

Richard.

>Honza

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]