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: [PATCH][RFC] Another approach to fixing "bad" inlining


On 10 July 2007 16:01, Richard Guenther wrote:

> On Tue, 10 Jul 2007, Dave Korn wrote:
> 
>> On 10 July 2007 15:23, Richard Guenther wrote:
>> 
>> 
>>   Excuse me for butting-in on what is a side-issue, but ...
>> 
>>> where this is undefined at runtime only, so we may not issue an error.
>> 
>>> Now we will happily inline, but simply leave y uninitialized (which
>>> should be valid, as the code is undefined at runtime).
>> 
>> ... what is "undefined at runtime only"?  I couldn't find a definition for
>> this distinction between different kinds of undefined behaviour, and the
>> note at n2794/3.18.2 suggests there's no reason not to issue an error.
>> 
>>   Or is this part of the great linguistics debate about 'may' vs. 'can'?
>> :-) 
> 
> I was basing my knowledge on
> 
> http://gcc.gnu.org/ml/gcc-patches/2004-10/msg00772.html
> 
> so "undefined at runtime only" just means we may not issue an error.
 

  Ah, so I think I would be correct in reading your earlier post as:

" [ ... ] where this is undefined, but we don't find out until runtime, so we
may not (in the sense of 'we are not able to', not in the sense of 'we are
forbidden from') issue an error (because we don't know that we should) [ ...
]"

... yes?  (Just asking for clarity's sake.)


    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....


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