On Tue, Mar 11, 2025 at 12:13:13PM +0100, Richard Biener wrote:
> On Tue, 11 Mar 2025, Jakub Jelinek wrote:
>
> > On Tue, Mar 11, 2025 at 10:18:18AM +0100, Richard Biener wrote:
> > > I think the patch as-is is more robust, but still - ugh ... I wonder
> > > whether we can instead avoid introducin
On Wed, 12 Mar 2025, Jakub Jelinek wrote:
> On Tue, Mar 11, 2025 at 12:13:13PM +0100, Richard Biener wrote:
> > On Tue, 11 Mar 2025, Jakub Jelinek wrote:
> >
> > > On Tue, Mar 11, 2025 at 10:18:18AM +0100, Richard Biener wrote:
> > > > I think the patch as-is is more robust, but still - ugh ... I
On Tue, Mar 11, 2025 at 10:18:18AM +0100, Richard Biener wrote:
> I think the patch as-is is more robust, but still - ugh ... I wonder
> whether we can instead avoid introducing the COMPLEX_EXPR at all
> at -O0?
Can we set DECL_NOT_GIMPLE_REG_P at -O0 during gimplification (where
we've already han
On Tue, 11 Mar 2025, Jakub Jelinek wrote:
> On Tue, Mar 11, 2025 at 10:18:18AM +0100, Richard Biener wrote:
> > I think the patch as-is is more robust, but still - ugh ... I wonder
> > whether we can instead avoid introducing the COMPLEX_EXPR at all
> > at -O0?
>
> Can we set DECL_NOT_GIMPLE_REG_
On Tue, 11 Mar 2025, Jakub Jelinek wrote:
> Hi!
>
> The PR119190 patch I've posted regresses the PR119120 testcase (not adding
> to testsuite, as it is fairly hard to scan for that problem).
> The issue is that for the partial setting of _Complex floating vars
> through __real__ on it first and _
Hi!
The PR119190 patch I've posted regresses the PR119120 testcase (not adding
to testsuite, as it is fairly hard to scan for that problem).
The issue is that for the partial setting of _Complex floating vars
through __real__ on it first and __imag__ later (or vice versa) and since
we forced all c
