[cfe-commits] r63242 - in /cfe/trunk: Driver/RewriteObjC.cpp include/clang/AST/Decl.h include/clang/AST/Expr.h include/clang/AST/ExprCXX.h include/clang/Basic/DiagnosticSemaKinds.def lib/AST/Expr.cpp lib/AST/StmtPrinter.cpp lib/CodeGen/CGExprAgg.

[Daniel Dunbar]

Ah, I see.

If this case matters in practice, I suppose a gross but effective
scheme would be to simply write the inializer list for
[start ... end ] = foo
as
[start] = foo, [start + 1 ... end] = [start]
which CodeGen would be fine with but feels rather sleazy.

 - Daniel

On Thu, Jan 29, 2009 at 12:06 PM, Douglas Gregor <dgregor at apple.com> wrote:
>
> On Jan 29, 2009, at 11:50 AM, Daniel Dunbar wrote:
>
>> Can you clarify this? I thought that it wasn't actually a
>> miscompilation, rather a different choice in undefined behavior.
>>
>> Did I misunderstand, or is this just an area where we feel we need to
>> be compatible with gcc?
>
> The error is for something slightly different than what you're probably
> thinking about. This error refers specifically to GNU's array-range
> designators, where in GCC
>
>        int array[] = { [1 ... 99] = something_with_side_effects() };
>
> the side effects from something_with_side_effects() will happen only once.
> They actually document that this is the intended behavior in:
>
>
>  http://gcc.gnu.org/onlinedocs/gcc-4.3.2/gcc/Designated-Inits.html#Designated-Inits
>
> In our codegen, the side effect would happen 99 times. That's in violation
> of GCC's specification, so we error out rather than produce wrong code (at
> Chris's request).
>
> You're probably thinking about the multiple-initializations rule, e.g., if
> one has:
>
>        int array[] = { f1(), 2, 3, [0] = f2() };
>
> and both f1() and f2() have side effects, it is unspecified whether the side
> effects of f1() ever actually occur (see C99 6.7.8p19) or, if they do, in
> what order the side effects of f1() and f2() occur (see C99 6.7.8p23) Here,
> we warn that the later initializer overrides the former initializer [*], and
> then do the same thing that GCC does: we drop the call to f1(). Also, just
> like GCC, our side effects happen in subobject initialization order.
>
>        - Doug
>
> [*] The warning itself is meant to give more information when we think that
> the initializer being dropped has side effects, but we don't yet have the
> ability to determine whether an expression has side effects.
>
>
>> - Daniel
>>
>> On Thu, Jan 29, 2009 at 10:58 AM, Douglas Gregor <dgregor at apple.com>
>> wrote:
>>>
>>> On Jan 29, 2009, at 10:48 AM, Chris Lattner wrote:
>>>
>>>>
>>>> On Jan 29, 2009, at 8:09 AM, Douglas Gregor wrote:
>>>>
>>>>>> Very nice Doug, please make these errors though.  Some code bases
>>>>>> build with many warnings, so this can be easy to miss.  Thanks for
>>>>>> working on this!
>>>>>
>>>>>
>>>>> FWIW, follow-on patches (one still to-be-finished) get this down to
>>>>> only a very minor difference that we warn about (different behavior
>>>>> when GNU array-range designated initializers have side effects).
>>>>
>>>> I'm still not very comfortable about only warning about cases where
>>>> we miscompile the code.  The "different behavior" really is a
>>>> miscompilation in my opinion, do you agree?
>>>
>>>
>>> Yes, it's a miscompilation. I'll make this an "unsupported" error in
>>> CodeGen, so that semantic clients aren't affected.
>>>
>>>      - Doug
>>> _______________________________________________
>>> cfe-commits mailing list
>>> cfe-commits at cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>>>
>
>