Thanks! I understand what you mean, then can I think that if the
function here is not an external function, but a function visible to
the compiler and the function doesn't modify `a`, then these two
blocks can be merged?
Marc Glisse 于2023年9月27日周三 12:51写道：
>
> On Wed, 27 Sep 2023, Hanke Zhang via
On Wed, 27 Sep 2023, Hanke Zhang via Gcc wrote:
Hi, I have recently been working on merging if-else statement blocks,
and I found a rather bizarre phenomenon that I would like to ask
about.
A rough explanation is that for two consecutive if-else blocks, if
their if statements are exactly the sam
* Arsen Arsenović via Gcc:
> Sam James via Gcc writes:
>
>> Florian Weimer via Gcc writes:
>>
>>> My understanding of the consensus goes as follows:
>>>
>>> * We want to make some changes in this area for GCC 14.
>>> * We should do the same thing that Clang does: default to the relevant
>>> -W
Hi, I have recently been working on merging if-else statement blocks,
and I found a rather bizarre phenomenon that I would like to ask
about.
A rough explanation is that for two consecutive if-else blocks, if
their if statements are exactly the same, they should be merged, like
the following progra
Hi!
Four things:
On 2023-09-10T23:25:06+0200, Jan Hubicka via Gcc wrote:
>> On 2023-09-07T19:00:49-0400, James Hu via Gcc wrote:
>> > I noticed that adding incremental LTO was a GSoC project that was not
>> > claimed this cycle (
>> > https://summerofcode.withgoogle.com/programs/2023/organizati
Sam James via Gcc writes:
> Florian Weimer via Gcc writes:
>
>> My understanding of the consensus goes as follows:
>>
>> * We want to make some changes in this area for GCC 14.
>> * We should do the same thing that Clang does: default to the relevant
>> -Werror= options.
>> * Unlike regular w
Jeff Law via Gcc writes:
> On 9/26/23 02:28, Florian Weimer via Gcc wrote:
>> My understanding of the consensus goes as follows:
>> * We want to make some changes in this area for GCC 14.
>> * We should do the same thing that Clang does: default to the relevant
>>-Werror= options.
>> * Unli
Florian Weimer via Gcc writes:
> My understanding of the consensus goes as follows:
>
> * We want to make some changes in this area for GCC 14.
> * We should do the same thing that Clang does: default to the relevant
> -Werror= options.
> * Unlike regular warnings, these warnings-as-errors sh
On 9/26/23 09:30, Richard Biener via Gcc wrote:
On Mon, Sep 25, 2023 at 5:17 PM Sylvain Noiry via Gcc wrote:
As I said at the end of the presentation, we have written a paper which
explains
our implementation in details. You can find it on the wiki page of the
Cauldron
(https://gcc.gnu.org/w
On Mon, 25 Sep 2023, Sylvain Noiry via Gcc wrote:
> --> Idea: Add an attribute to the Tree complex type which specify pure real /
> pure
> imaginary / full complex ?
If you start from the implementation approach of lowering imaginary type
operations in the front end, a flag on a REAL_TYPE wou
* Jeff Law:
>> I think the open issues are:
>> * Do we want to implement something else beside implicit-int and
>>implicit-function-declaration? (Candidates are int-conversion and
>>incompatible-pointer-types, and the void vs non-void part of
>>return-type, maybe others as previously
On 9/26/23 02:28, Florian Weimer via Gcc wrote:
My understanding of the consensus goes as follows:
* We want to make some changes in this area for GCC 14.
* We should do the same thing that Clang does: default to the relevant
-Werror= options.
* Unlike regular warnings, these warnings-as-e
* Jakub Jelinek:
> On Tue, Sep 26, 2023 at 10:28:34AM +0200, Florian Weimer via Gcc wrote:
>> My understanding of the consensus goes as follows:
>>
>> * We want to make some changes in this area for GCC 14.
>> * We should do the same thing that Clang does: default to the relevant
>> -Werror= op
On Tue, Sep 26, 2023 at 08:29:16AM +, Tamar Christina via Gcc wrote:
> Hi,
>
> I tried to find you two on Sunday but couldn't locate you. Thanks for the
> presentation!
Yes, sadly we could not attend on Sunday because we wanted to be back
for Monday.
> > >
> > > We had very interesting disc
On Tue, Sep 26, 2023 at 09:28:08AM +, Tamar Christina wrote:
> > -Original Message-
> > From: Gcc On Behalf
> > Of Paul Iannetta via Gcc
> > Sent: Tuesday, September 26, 2023 9:54 AM
> > To: Richard Biener
> > Cc: Sylvain Noiry ; gcc@gcc.gnu.org;
> > sylvain.no...@hotmail.fr
> > Subje
> -Original Message-
> From: Gcc On Behalf
> Of Paul Iannetta via Gcc
> Sent: Tuesday, September 26, 2023 9:54 AM
> To: Richard Biener
> Cc: Sylvain Noiry ; gcc@gcc.gnu.org;
> sylvain.no...@hotmail.fr
> Subject: Re: Complex numbers support: discussions summary
>
> On Tue, Sep 26, 2023 at
On Tue, Sep 26, 2023 at 10:28:34AM +0200, Florian Weimer via Gcc wrote:
> My understanding of the consensus goes as follows:
>
> * We want to make some changes in this area for GCC 14.
> * We should do the same thing that Clang does: default to the relevant
> -Werror= options.
I think it doesn'
On Tue, Sep 26, 2023 at 09:30:21AM +0200, Richard Biener via Gcc wrote:
> On Mon, Sep 25, 2023 at 5:17 PM Sylvain Noiry via Gcc wrote:
> >
> > Hi,
> >
> > We had very interesting discussions during our presentation with Paul on
> > the
> > support of complex numbers in gcc at the Cauldron.
> >
> >
Hi,
I tried to find you two on Sunday but couldn't locate you. Thanks for the
presentation!
> >
> > We had very interesting discussions during our presentation with Paul
> > on the support of complex numbers in gcc at the Cauldron.
> >
> > Thank you all for your participation !
> >
> > Here is a
My understanding of the consensus goes as follows:
* We want to make some changes in this area for GCC 14.
* We should do the same thing that Clang does: default to the relevant
-Werror= options.
* Unlike regular warnings, these warnings-as-errors should also apply
to system headers.
* At leas
On Mon, Sep 25, 2023 at 5:17 PM Sylvain Noiry via Gcc wrote:
>
> Hi,
>
> We had very interesting discussions during our presentation with Paul on
> the
> support of complex numbers in gcc at the Cauldron.
>
> Thank you all for your participation !
>
> Here is a small summary from our viewpoint:
>
21 matches
Mail list logo
