> On Feb 2, 2023, at 11:25 PM, Siddhesh Poyarekar <siddh...@gotplt.org> wrote:
>
> On 2023-02-02 03:33, Richard Biener wrote:
>> looking at PR77650 what seems missing there is the semantics of this
>> extension as expected/required by the glibc use. comment#5 seems
>> to suggest that for my example above its expected that
>> Y.x.data[0] aliases Y.end?! There must be a better way to write
>> the glibc code and IMHO it would be best to deprecate this extension.
>> Definitely the middle-end wouldn't consider this aliasing for
>> my example - maybe it "works" when wrapped inside a union but
>> then for sure only when the union is visible in all accesses ...
>> typedef union
>> {
>> struct __gconv_info __cd;
>> struct
>> {
>> struct __gconv_info __cd;
>> struct __gconv_step_data __data;
>> } __combined;
>> } _G_iconv_t;
>> could be written as
>> typedef union
>> {
>> struct __gconv_info __cd;
>> char __dummy[sizeof(struct __gconv_info) + sizeof(struct
>> __gconv_step_data)];
>> } _G_iconv_t;
>> in case the intent is to provide a complete type with space for
>> a single __gconv_step_data.
>
> I dug into this on the glibc end and it looks like this commit:
>
> commit 63fb8f9aa9d19f85599afe4b849b567aefd70a36
> Author: Zack Weinberg <za...@panix.com>
> Date: Mon Feb 5 14:13:41 2018 -0500
>
> Post-cleanup 2: minimize _G_config.h.
>
> ripped all of that gunk out. AFAICT there's no use of struct __gconv_info
> anywhere else in the code.
>
> I reckon it is safe to say now that glibc no longer needs this misfeature.
Thanks a lot for the info.
Looks like it’s good time to start deprecating this misfeature from GCC.
Qing
>
> Sid
