> Am 07.07.2024 um 17:14 schrieb Jakub Jelinek :
>
> On Sun, Jul 07, 2024 at 09:02:57AM +0200, Richard Biener wrote:
>> I see. I was wondering because PCH includes are not resolved. That said,
>> it sounds like #embed is sadly defined on The preprocessor side rather
>> than in the language w
On Sun, Jul 07, 2024 at 09:02:57AM +0200, Richard Biener wrote:
> I see. I was wondering because PCH includes are not resolved. That said,
> it sounds like #embed is sadly defined on The preprocessor side rather
> than in the language where it would have been easy to constrain uses to
> those tha
> Am 06.07.2024 um 16:56 schrieb Jakub Jelinek :
>
> On Sat, Jul 06, 2024 at 02:45:45PM +0200, Richard Biener wrote:
>>> Anyway, thoughts on this before I spend too much time on it?
>>
>> Why do we have an "element type"? Would
>>
>> int a[] = {
>> #embed "cc1plus"
>> };
>>
>> be valid?
>
On Sat, Jul 06, 2024 at 02:45:45PM +0200, Richard Biener wrote:
> > Anyway, thoughts on this before I spend too much time on it?
>
> Why do we have an "element type"? Would
>
> int a[] = {
> #embed "cc1plus"
> };
>
> be valid?
Yes, that is valid.
The way #embed is defined for C is that it is e
On Fri, 5 Jul 2024, Jakub Jelinek wrote:
> Hi!
>
> Just to show what I'm working on on top of the already posted #embed
> patches.
> Working on the C FE only for now, the patch emits CPP_EMBED tokens
> when preprocessing C (but still with the important simplification that
> CPP_EMBED token is alw
Hi!
Just to show what I'm working on on top of the already posted #embed
patches.
Working on the C FE only for now, the patch emits CPP_EMBED tokens
when preprocessing C (but still with the important simplification that
CPP_EMBED token is always preceded by {CPP_NUMBER,CPP_EMBED} CPP_COMMA
and fol
