[Bug middle-end/41992] ICE on invalid dereferencing of void *

2017-07-18 Thread ygribov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41992

Yury Gribov  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||ygribov at gcc dot gnu.org
 Resolution|--- |FIXED
   Target Milestone|--- |4.7.0

--- Comment #5 from Yury Gribov  ---
Fixed.

[Bug middle-end/41992] ICE on invalid dereferencing of void *

2017-07-10 Thread tetra2005 at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41992

Yuri Gribov  changed:

   What|Removed |Added

 CC||tetra2005 at gmail dot com

--- Comment #4 from Yuri Gribov  ---
Fixed long ago, most probly in r172298. Could someone close?

[Bug middle-end/41992] ICE on invalid dereferencing of void *

2009-11-11 Thread mikulas at artax dot karlin dot mff dot cuni dot cz


--- Comment #3 from mikulas at artax dot karlin dot mff dot cuni dot cz  
2009-11-11 21:06 ---
You can dereference void * in asm arguments --- i.e.
void *p; ... asm volatile (prefetch %0::m(*p));

gcc warns in this case about the dereference and maybe it shouldn't (but it's
trivial to supress the warning with a cast to char *).

If you change m constraint to mr, you get an ICE.


-- 


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



[Bug middle-end/41992] ICE on invalid dereferencing of void *

2009-11-09 Thread rguenth at gcc dot gnu dot org


--- Comment #1 from rguenth at gcc dot gnu dot org  2009-11-09 10:16 ---
Which is because the gimplifier thinks this is an error for the frontend to
pass through:

Breakpoint 1, fancy_abort (
file=0x10b1ab8 /space/rguenther/src/svn/trunk/gcc/gimplify.c, line=7173, 
function=0x10b2ca4 gimplify_expr)
at /space/rguenther/src/svn/trunk/gcc/diagnostic.c:728
728   internal_error (in %s, at %s:%d, function, trim_filename (file),
line);
(gdb) up
#1  0x007fa0a5 in gimplify_expr (expr_p=0x76f07a48, 
pre_p=0x7fffced8, post_p=0x7fffc558, 
gimple_test_f=0x7b9486 is_gimple_asm_val, fallback=1)
at /space/rguenther/src/svn/trunk/gcc/gimplify.c:7173
7173  gcc_assert (!VOID_TYPE_P (TREE_TYPE (*expr_p)));
(gdb) 
#2  0x007e9450 in gimplify_asm_expr (expr_p=0x77ede980, 
pre_p=0x7fffced8, post_p=0x7fffc558)
at /space/rguenther/src/svn/trunk/gcc/gimplify.c:4896
4896  tret = gimplify_expr (TREE_VALUE (link), pre_p, post_p,

the C standard doesn't claim dereferencing a void pointer is invalid, so
the gimplifier should deal with this.

Before tree-ssa we ICEd with

t5.c:3: internal compiler error: in int_mode_for_mode, at stor-layout.c:289
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.

or with 2.95 with

t5.c:3: Internal compiler error in `emit_move_insn_1', at expr.c:2835

so, not a regression.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||ice-on-invalid-code
   Last reconfirmed|-00-00 00:00:00 |2009-11-09 10:16:57
   date||


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



[Bug middle-end/41992] ICE on invalid dereferencing of void *

2009-11-09 Thread joseph at codesourcery dot com


--- Comment #2 from joseph at codesourcery dot com  2009-11-09 13:16 ---
Subject: Re:  ICE on invalid dereferencing of void *

On Mon, 9 Nov 2009, rguenth at gcc dot gnu dot org wrote:

 the C standard doesn't claim dereferencing a void pointer is invalid, so
 the gimplifier should deal with this.

It's not invalid in general, but if the value gets used (NB conditional 
expressions involving such dereferences, whose values don't get used, are 
OK; DR 106) then it is invalid and there should be an error; void value 
not ignored as it ought to be is used in some places.  Though I note that 
if you change the dereference in the present testcase to use the return 
value of a function returning void, the resulting error using result of 
function returning 'void' comes from the gimplifier and not the front 
end, so making the gimplifier deal with this case as well would at least 
be consistent.


-- 


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