------- Comment #6 from manu at gcc dot gnu dot org 2008-08-27 11:03 -------
(In reply to comment #5)
> (In reply to comment #4)
> > error: 'operator new' takes type 'size_t' ('long unsigned int') as first
> > parameter
>
> I don't understand why you get this error
>
Because I am using a 64bit target and you are using a 32bit to generate the .ii
file. I can reproduce the testcase fine now.
This is a two-fold bug:
* Printing guard$13936$owner is no-no. We rather not print anything and miss a
warning than print something like that. Not sure how to detect that this is not
a user-variable. It is not marked as compiler-generated.
* I don't know if the throw is explicit or compiler-generated (the dumps are a
bit useless).
# BLOCK 4, starting at line 0
# PRED: 2 (ab,eh,exec)
<L2>:
save_filt.157D.15292_7 = [filter_expr] <<<filter object>>>;
save_eptr.156D.15293_8 = [exc_ptr_expr] <<<exception object>>>;
[/opt/ACE_wrappers/ace/Guard_T.inl : 24] D.15294_9 =
guard$D15120$owner_D.15311_16(D);
[/opt/ACE_wrappers/ace/Guard_T.inl : 24] if (D.15294_9 == -1)
goto <bb 6>;
else
goto <bb 5>;
# SUCC: 6 [48.8%] (true,exec) 5 [51.2%] (false,exec)
If it is compiler-generated, we should never warn.
The enclosing function is defined as:
long unsigned int CircularBuffer<MUTEX>::write() [with MUTEX =
ACE_Thread_Mutex] (struct CircularBufferD.14893 * const thisD.14900)
Eh tree:
1 cleanup
3 must_not_throw tree_label:<L3>
2 cleanup tree_label:<L2>
The must_not_throw is not an indication that this function doesn't throw?
Perhaps we should just never warn about anything within EH BB, since they are
not properly marked as compiler-generated by the front-end and the middle-end
has problems dealing with them. That would fix a few bugs.
--
manu at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|0000-00-00 00:00:00 |2008-08-27 11:03:18
date| |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36833
