On 9/13/2021 7:52 AM, Martin Liška wrote:
On 8/27/21 11:05, Richard Biener wrote:
So with ignoring darktable which seems completely insane the cases
will likely continue
to work as intended if we change from the current scheme to appending
as proposed.
All right, I'm addressing the flag_com
On 8/27/21 11:05, Richard Biener wrote:
So with ignoring darktable which seems completely insane the cases
will likely continue
to work as intended if we change from the current scheme to appending
as proposed.
All right, I'm addressing the flag_complex_method in a separate sub-thread.
There's
On Fri, Aug 27, 2021 at 10:35 AM Martin Liška wrote:
>
> On 8/26/21 14:39, Martin Liška wrote:
> > I can investigate that.
>
> So there are statistics about #pragma GCC optimize and optimize attribute in
> openSUSE:Factory.
> The numbers at the line beginning represent number of functions affecte
On 8/26/21 14:39, Martin Liška wrote:
I can investigate that.
So there are statistics about #pragma GCC optimize and optimize attribute in
openSUSE:Factory.
The numbers at the line beginning represent number of functions affected by the
pragma or attribute.
Are we smarter in what we want?
Pr
On Thu, Aug 26, 2021 at 2:39 PM Martin Liška wrote:
>
> On 8/26/21 13:04, Richard Biener wrote:
> > On Tue, Aug 24, 2021 at 3:04 PM Martin Liška wrote:
> >>
> >> On 8/24/21 14:13, Richard Biener wrote:
> >>> On Thu, Jul 1, 2021 at 3:13 PM Martin Liška wrote:
>
> On 10/23/20 1:47 PM, Ma
On 8/26/21 13:04, Richard Biener wrote:
On Tue, Aug 24, 2021 at 3:04 PM Martin Liška wrote:
On 8/24/21 14:13, Richard Biener wrote:
On Thu, Jul 1, 2021 at 3:13 PM Martin Liška wrote:
On 10/23/20 1:47 PM, Martin Liška wrote:
Hey.
Hello.
I deferred the patch for GCC 12. Since the time, I
On Tue, Aug 24, 2021 at 3:04 PM Martin Liška wrote:
>
> On 8/24/21 14:13, Richard Biener wrote:
> > On Thu, Jul 1, 2021 at 3:13 PM Martin Liška wrote:
> >>
> >> On 10/23/20 1:47 PM, Martin Liška wrote:
> >>> Hey.
> >>
> >> Hello.
> >>
> >> I deferred the patch for GCC 12. Since the time, I messed
On 8/24/21 14:13, Richard Biener wrote:
On Thu, Jul 1, 2021 at 3:13 PM Martin Liška wrote:
On 10/23/20 1:47 PM, Martin Liška wrote:
Hey.
Hello.
I deferred the patch for GCC 12. Since the time, I messed up with options
I feel more familiar with the option handling. So ...
This is a follo
On Thu, Jul 1, 2021 at 3:13 PM Martin Liška wrote:
>
> On 10/23/20 1:47 PM, Martin Liška wrote:
> > Hey.
>
> Hello.
>
> I deferred the patch for GCC 12. Since the time, I messed up with options
> I feel more familiar with the option handling. So ...
>
> >
> > This is a follow-up of the discussion
PING^2
On 8/10/21 17:52, Martin Liška wrote:
PING^1
On 7/1/21 3:13 PM, Martin Liška wrote:
On 10/23/20 1:47 PM, Martin Liška wrote:
Hey.
Hello.
I deferred the patch for GCC 12. Since the time, I messed up with options
I feel more familiar with the option handling. So ...
This is a follo
PING^1
On 7/1/21 3:13 PM, Martin Liška wrote:
On 10/23/20 1:47 PM, Martin Liška wrote:
Hey.
Hello.
I deferred the patch for GCC 12. Since the time, I messed up with options
I feel more familiar with the option handling. So ...
This is a follow-up of the discussion that happened in thread
On 10/23/20 1:47 PM, Martin Liška wrote:
Hey.
Hello.
I deferred the patch for GCC 12. Since the time, I messed up with options
I feel more familiar with the option handling. So ...
This is a follow-up of the discussion that happened in thread about
no_stack_protector
attribute: https://gcc
I'm suggesting postponing this to GCC 12 as I'm planning a bigger
target/optimize attribute (pragma) overhaul.
Martin
On 12/7/20 12:03 PM, Martin Liška wrote:
PING^2
On 11/26/20 2:56 PM, Martin Liška wrote:
PING^1
On 11/9/20 11:35 AM, Martin Liška wrote:
On 11/3/20 2:34 PM, Jakub Jelinek wr
PING^2
On 11/26/20 2:56 PM, Martin Liška wrote:
PING^1
On 11/9/20 11:35 AM, Martin Liška wrote:
On 11/3/20 2:34 PM, Jakub Jelinek wrote:
On Tue, Nov 03, 2020 at 02:27:52PM +0100, Richard Biener wrote:
On Fri, Oct 23, 2020 at 1:47 PM Martin Liška wrote:
This is a follow-up of the discussion
PING^1
On 11/9/20 11:35 AM, Martin Liška wrote:
On 11/3/20 2:34 PM, Jakub Jelinek wrote:
On Tue, Nov 03, 2020 at 02:27:52PM +0100, Richard Biener wrote:
On Fri, Oct 23, 2020 at 1:47 PM Martin Liška wrote:
This is a follow-up of the discussion that happened in thread about
no_stack_protector
On 11/6/20 6:34 PM, Jeff Law wrote:
So you XNEWVEC and store the result into "merge_decoded_options". But
you free "decoded_options". Was that intentional?
Hello.
Good point here.
This seems to bring a bit more predictability, but I suspect there's
more to do here.
Yes, both should be
On 11/3/20 2:34 PM, Jakub Jelinek wrote:
On Tue, Nov 03, 2020 at 02:27:52PM +0100, Richard Biener wrote:
On Fri, Oct 23, 2020 at 1:47 PM Martin Liška wrote:
This is a follow-up of the discussion that happened in thread about
no_stack_protector
attribute: https://gcc.gnu.org/pipermail/gcc-patc
On 11/3/20 2:27 PM, Richard Biener wrote:
On Fri, Oct 23, 2020 at 1:47 PM Martin Liška wrote:
Hey.
This is a follow-up of the discussion that happened in thread about
no_stack_protector
attribute: https://gcc.gnu.org/pipermail/gcc-patches/2020-May/545916.html
The current optimize attribute
On 10/23/20 5:47 AM, Martin Liška wrote:
> Hey.
>
> This is a follow-up of the discussion that happened in thread about
> no_stack_protector
> attribute: https://gcc.gnu.org/pipermail/gcc-patches/2020-May/545916.html
>
> The current optimize attribute works in the following way:
> - 1) we take c
On Tue, Nov 3, 2020 at 2:35 PM Jakub Jelinek wrote:
>
> On Tue, Nov 03, 2020 at 02:27:52PM +0100, Richard Biener wrote:
> > On Fri, Oct 23, 2020 at 1:47 PM Martin Liška wrote:
> > > This is a follow-up of the discussion that happened in thread about
> > > no_stack_protector
> > > attribute: http
On Tue, Nov 03, 2020 at 02:27:52PM +0100, Richard Biener wrote:
> On Fri, Oct 23, 2020 at 1:47 PM Martin Liška wrote:
> > This is a follow-up of the discussion that happened in thread about
> > no_stack_protector
> > attribute: https://gcc.gnu.org/pipermail/gcc-patches/2020-May/545916.html
> >
>
On Fri, Oct 23, 2020 at 1:47 PM Martin Liška wrote:
>
> Hey.
>
> This is a follow-up of the discussion that happened in thread about
> no_stack_protector
> attribute: https://gcc.gnu.org/pipermail/gcc-patches/2020-May/545916.html
>
> The current optimize attribute works in the following way:
> -
Hey.
This is a follow-up of the discussion that happened in thread about
no_stack_protector
attribute: https://gcc.gnu.org/pipermail/gcc-patches/2020-May/545916.html
The current optimize attribute works in the following way:
- 1) we take current global_options as base
- 2) maybe_default_options
23 matches
Mail list logo