https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116130

--- Comment #8 from rguenther at suse dot de <rguenther at suse dot de> ---
On Mon, 29 Jul 2024, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116130
> 
> --- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
> Seems we actually implement it that way already, or at least sometimes.
> build_conditional_expr has
>   /* Quickly detect the usual case where op1 and op2 have the same type
>      after promotion.  */
>   if (TYPE_MAIN_VARIANT (type1) == TYPE_MAIN_VARIANT (type2))
>     {
>       if (type1 == type2)
>         result_type = type1;
>       else
>         result_type = TYPE_MAIN_VARIANT (type1);
>     }
> which would do the wrong thing and
>   else if (code1 == POINTER_TYPE && code2 == POINTER_TYPE)
>     {
> ...
>       if (comp_target_types (colon_loc, type1, type2))
>         result_type = common_pointer_type (type1, type2);
> which would merge them.
> All I want to say is that there are big chances of this breaking real-world
> code if somebody decides to add the new standard attributes to decls.

IMO this asks for metadata on each (standard) attribute whether it
merges conservatively by union or by intersection since there are
two classes of attributes.

And then there's things like [[gnu::warn_unused_result]] where
it's not at all clear what is "conservative" (drop valid diagnostics
or introduce broken ones?).

Possibly a program with ?: on types with differing attributes should
be ill-formed and instead allow

  ?[[...]]x:[[...]]y

to fixup?  Is there a way to "drop" an attribute, like cast it
away? [[no-...]] or [[!...]]?

Reply via email to