This is the mail archive of the gcc-patches@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]

Re: Some VRP improvements


On Thu, Jun 02, 2005 at 10:38:08PM +0200, Andreas Jaeger wrote:
> Diego Novillo <dnovillo@redhat.com> writes:
> 
> > On Thu, Jun 02, 2005 at 07:11:22AM +0200, Andreas Jaeger wrote:
> >> 
> >> Thanks for the large patch.  Unfortunately, it does not work for Ada,
> >> I get this error now:
> >> 
> >> aised TYPES.UNRECOVERABLE_ERROR : comperr.adb:381
> >> make[2]: *** [ada/butil.o] Error 1
> >> make[2]: *** Waiting for unfinished jobs....
> >>
> > Seems to be another instance of an FE emitting a comparison
> > between a pointer and a non-pointer.  Fortran was doing the same
> > and C is doing the same (PR 21858).
> >
> > I am *very* tempted to turn that assert into either a warning or
> > a silent ignore.  Show me val1 and val2 at that point?  Also if
> > you go 1 or 2 slots up in the backtrace, you should be able to
> > see the original predicate.
> 
> (gdb) pt val1
>
>  <modify_expr 0x2aaaaaeb3280
>     type <pointer_type 0x2aaaaadfe5b0
>         type <void_type 0x2aaaaadfe4e0 void sizes-gimplified visited VOID
>             align 8 symtab 0 alias set -1
>             pointer_to_this <pointer_type 0x2aaaaadfe5b0>>
>         public unsigned DI
>         size <integer_cst 0x2aaaaadeac00 constant invariant 64>
>         unit size <integer_cst 0x2aaaaadeac30 constant invariant 8>
>         align 64 symtab 0 alias set -1>
>     side-effects asm_written visited
>
Huh!?  We could not possibly be receiving a MODIFY_EXPR as a
value here.  Are you sure you're not getting tricked by 'pt'?  It
prints the last tree node you emitted with 'p'.  Looking at the
backtrace, you should've printed the node with address
0x2aaaab1d7b60.

>     arg 0 <ssa_name 0x2aaaab1d7b60 type <pointer_type 0x2aaaaadfe5b0>
>         visited var <var_decl 0x2aaaaaeb2680 D.869> def_stmt <modify_expr 0x2aaaaaeb3280>
>         version 70
>         ptr-info 0x2aaaaaed0b60>
>     arg 1 <call_expr 0x2aaaaaeb3190 type <pointer_type 0x2aaaaadfe5b0>
>         nothrow
>         arg 0 <addr_expr 0x2aaaaaeb1d40 type <pointer_type 0x2aaaaae8dd00>
>             constant invariant arg 0 <function_decl 0x2aaaaae050d0 __builtin_memcmp>>
>         arg 1 <tree_list 0x2aaaaaeaa4b0
>             value <addr_expr 0x2aaaaaeb1d00 type <pointer_type 0x2aaaaaeb2410>
>                 constant invariant
>                 arg 0 <string_cst 0x2aaaaae83f90 type <array_type 0x2aaaaae92410 butil__is_predefined_unit__T15b>
>                     "ada.">>
>             chain <tree_list 0x2aaaaaeaa480
>                 value <ssa_name 0x2aaaab1d7af0 type <pointer_type 0x2aaaaaeb2410>
>                     visited var <var_decl 0x2aaaaaeb25b0 D.868> def_stmt <modify_expr 0x2aaaaaeb3230>
>                     version 69
>                     ptr-info 0x2aaaaaed0b20>
>                 chain <tree_list 0x2aaaaaeaa450
>                     value <integer_cst 0x2aaaaadea570 constant invariant 4>>>>
>         /cvs/gcc/gcc/ada/butil.adb:66>
>     /cvs/gcc/gcc/ada/butil.adb:66>
> (gdb) pt val2
>  <modify_expr 0x2aaaaaeb3280
>
This is the same address.  I think you *did* get tricked by 'pt'.
I *really* dislike the .gdbinit file we emit by default in the
object directory.


Diego.


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