On Mon, Sep 09, 2019 at 01:02:32PM +0200, Martin Liška wrote:
> On 9/6/19 4:56 PM, Jakub Jelinek wrote:
> > On Fri, Sep 06, 2019 at 10:48:53AM -0400, Marek Polacek wrote:
> >> On Fri, Sep 06, 2019 at 08:58:48AM +0200, Martin Liška wrote:
> >>> Ok, hopefully nobody is strongly against. I've just ret
On 9/6/19 4:56 PM, Jakub Jelinek wrote:
> On Fri, Sep 06, 2019 at 10:48:53AM -0400, Marek Polacek wrote:
>> On Fri, Sep 06, 2019 at 08:58:48AM +0200, Martin Liška wrote:
>>> Ok, hopefully nobody is strongly against. I've just retested the
>>> patch and installed it as r275450.
>>
>> --- a/gcc/c-fam
On 9/6/19 4:56 PM, Jakub Jelinek wrote:
On Fri, Sep 06, 2019 at 10:48:53AM -0400, Marek Polacek wrote:
On Fri, Sep 06, 2019 at 08:58:48AM +0200, Martin Liška wrote:
Ok, hopefully nobody is strongly against. I've just retested the
patch and installed it as r275450.
--- a/gcc/c-family/c.opt
+++
On Fri, Sep 06, 2019 at 10:48:53AM -0400, Marek Polacek wrote:
> On Fri, Sep 06, 2019 at 08:58:48AM +0200, Martin Liška wrote:
> > Ok, hopefully nobody is strongly against. I've just retested the
> > patch and installed it as r275450.
>
> --- a/gcc/c-family/c.opt
> +++ b/gcc/c-family/c.opt
> @@ -1
On Fri, Sep 06, 2019 at 08:58:48AM +0200, Martin Liška wrote:
> Ok, hopefully nobody is strongly against. I've just retested the
> patch and installed it as r275450.
--- a/gcc/c-family/c.opt
+++ b/gcc/c-family/c.opt
@@ -1763,8 +1763,8 @@ ObjC ObjC++ LTO Var(flag_replace_objc_classes)
Used in Fix-
On 9/5/19 2:51 PM, Martin Liška wrote:
> On 9/5/19 2:31 PM, Richard Biener wrote:
>> On Thu, Sep 5, 2019 at 2:06 PM Jonathan Wakely wrote:
>>>
>>> On Thu, 5 Sep 2019 at 12:21, Martin Liška wrote:
On 9/5/19 1:09 PM, Richard Biener wrote:
> So, let's just remove it now?
I'm
On 9/5/19 2:31 PM, Richard Biener wrote:
> On Thu, Sep 5, 2019 at 2:06 PM Jonathan Wakely wrote:
>>
>> On Thu, 5 Sep 2019 at 12:21, Martin Liška wrote:
>>>
>>> On 9/5/19 1:09 PM, Richard Biener wrote:
So, let's just remove it now?
>>>
>>> I'm all for that. May I install the patch?
>>
>> To b
On Thu, Sep 5, 2019 at 2:06 PM Jonathan Wakely wrote:
>
> On Thu, 5 Sep 2019 at 12:21, Martin Liška wrote:
> >
> > On 9/5/19 1:09 PM, Richard Biener wrote:
> > > So, let's just remove it now?
> >
> > I'm all for that. May I install the patch?
>
> To be clear, I wasn't objecting to installing the
On Thu, 5 Sep 2019 at 12:21, Martin Liška wrote:
>
> On 9/5/19 1:09 PM, Richard Biener wrote:
> > So, let's just remove it now?
>
> I'm all for that. May I install the patch?
To be clear, I wasn't objecting to installing the patch now, just
asking whether it would be possible to revert it later i
On 9/5/19 1:09 PM, Richard Biener wrote:
> So, let's just remove it now?
I'm all for that. May I install the patch?
Martin
On Thu, Sep 5, 2019 at 1:02 PM Nathan Sidwell wrote:
>
> On 9/5/19 6:03 AM, Martin Liška wrote:
> > On 9/5/19 12:01 PM, Richard Biener wrote:
> >> On Wed, Sep 4, 2019 at 2:57 PM Nathan Sidwell wrote:
> >>>
> >>> On 9/4/19 7:20 AM, Martin Liška wrote:
> On 9/4/19 11:22 AM, Jonathan Wakely wro
On 9/5/19 6:03 AM, Martin Liška wrote:
On 9/5/19 12:01 PM, Richard Biener wrote:
On Wed, Sep 4, 2019 at 2:57 PM Nathan Sidwell wrote:
On 9/4/19 7:20 AM, Martin Liška wrote:
On 9/4/19 11:22 AM, Jonathan Wakely wrote:
The point of the warning was to see if users complain. Three weeks
isn't
On 9/5/19 12:01 PM, Richard Biener wrote:
> On Wed, Sep 4, 2019 at 2:57 PM Nathan Sidwell wrote:
>>
>> On 9/4/19 7:20 AM, Martin Liška wrote:
>>> On 9/4/19 11:22 AM, Jonathan Wakely wrote:
>>
>>
The point of the warning was to see if users complain. Three weeks
isn't a very long time to
On Wed, Sep 4, 2019 at 2:57 PM Nathan Sidwell wrote:
>
> On 9/4/19 7:20 AM, Martin Liška wrote:
> > On 9/4/19 11:22 AM, Jonathan Wakely wrote:
>
>
> >> The point of the warning was to see if users complain. Three weeks
> >> isn't a very long time to see if users are going to complain :-)
> >>
> >
On 9/4/19 7:20 AM, Martin Liška wrote:
On 9/4/19 11:22 AM, Jonathan Wakely wrote:
The point of the warning was to see if users complain. Three weeks
isn't a very long time to see if users are going to complain :-)
I see :) That said, I'm going to install the patch close to the end
of stage
On 9/4/19 11:22 AM, Jonathan Wakely wrote:
> On Wed, 4 Sep 2019 at 09:13, Martin Liška wrote:
>>
>> On 7/9/19 3:00 PM, Martin Liška wrote:
>>> Great. Then I'm sending patch that does the functionality removal.
>>
>> Hi.
>>
>> The GCC 9.2.0 is released and the version contains a deprecation
>> warni
On Wed, 4 Sep 2019 at 09:13, Martin Liška wrote:
>
> On 7/9/19 3:00 PM, Martin Liška wrote:
> > Great. Then I'm sending patch that does the functionality removal.
>
> Hi.
>
> The GCC 9.2.0 is released and the version contains a deprecation
> warning for -frepo.
>
> Is it the right time now to remov
On 7/9/19 3:00 PM, Martin Liška wrote:
Great. Then I'm sending patch that does the functionality removal.
Hi.
The GCC 9.2.0 is released and the version contains a deprecation
warning for -frepo.
Is it the right time now to remove it from trunk?
Thanks,
Martin
On Wed, Jul 10, 2019 at 02:53:35PM +0200, Martin Liška wrote:
> On 7/10/19 2:48 PM, Nathan Sidwell wrote:
> > On 7/10/19 7:28 AM, Martin Liška wrote:
> >
> >> Great, thank you.
> >>
> >> There's a patch for deprecating of the option in GCC 9 changes.
> >>
> >> May I install the patch right now or
On 7/10/19 8:53 AM, Martin Liška wrote:
nathan
That's done by 'Deprecated' keyword put on frepo in *.opt file:
$ ./gcc/xgcc -Bgcc -frepo /tmp/main.c
xgcc: warning: switch ‘-frepo’ is no longer supported
I've already used the same mechanism for other deprecated options e.g.:
$ ./gcc/xgcc -Bg
On 7/10/19 2:48 PM, Nathan Sidwell wrote:
> On 7/10/19 7:28 AM, Martin Liška wrote:
>
>> Great, thank you.
>>
>> There's a patch for deprecating of the option in GCC 9 changes.
>>
>> May I install the patch right now or should I wait?
>>
>
> I think there needs to be a code patch so that use of t
On 7/10/19 7:28 AM, Martin Liška wrote:
Great, thank you.
There's a patch for deprecating of the option in GCC 9 changes.
May I install the patch right now or should I wait?
I think there needs to be a code patch so that use of the option gives a
warning.
nathan
--
Nathan Sidwell
On 7/9/19 11:14 PM, Jason Merrill wrote:
> On 7/9/19 1:48 PM, Nathan Sidwell wrote:
>> On 7/9/19 9:00 AM, Martin Liška wrote:
>>> On 7/9/19 1:41 PM, Nathan Sidwell wrote:
On 7/9/19 6:39 AM, Richard Biener wrote:
> On Mon, Jul 8, 2019 at 2:04 PM Martin Liška wrote:
>>
>>
>
On 7/9/19 1:48 PM, Nathan Sidwell wrote:
On 7/9/19 9:00 AM, Martin Liška wrote:
On 7/9/19 1:41 PM, Nathan Sidwell wrote:
On 7/9/19 6:39 AM, Richard Biener wrote:
On Mon, Jul 8, 2019 at 2:04 PM Martin Liška wrote:
Same happens also for GCC7. It does 17 iteration (#define
MAX_ITERATIONS
On 7/9/19 9:00 AM, Martin Liška wrote:
On 7/9/19 1:41 PM, Nathan Sidwell wrote:
On 7/9/19 6:39 AM, Richard Biener wrote:
On Mon, Jul 8, 2019 at 2:04 PM Martin Liška wrote:
Same happens also for GCC7. It does 17 iteration (#define MAX_ITERATIONS 17) and
apparently 17 is not enough to reso
On 7/9/19 1:41 PM, Nathan Sidwell wrote:
> On 7/9/19 6:39 AM, Richard Biener wrote:
>> On Mon, Jul 8, 2019 at 2:04 PM Martin Liška wrote:
>>>
>
>>>
>>> Same happens also for GCC7. It does 17 iteration (#define MAX_ITERATIONS
>>> 17) and
>>> apparently 17 is not enough to resolve all symbols. And
On 7/9/19 6:39 AM, Richard Biener wrote:
On Mon, Jul 8, 2019 at 2:04 PM Martin Liška wrote:
Same happens also for GCC7. It does 17 iteration (#define MAX_ITERATIONS 17) and
apparently 17 is not enough to resolve all symbols. And it's really slow.
Ouch.
hm, 17 is a magic number. in C++
On Mon, Jul 8, 2019 at 2:04 PM Martin Liška wrote:
>
> On 6/21/19 4:28 PM, Richard Biener wrote:
> > On Fri, Jun 21, 2019 at 4:13 PM Jakub Jelinek wrote:
> >>
> >> On Fri, Jun 21, 2019 at 04:04:00PM +0200, Martin Liška wrote:
> >>> On 6/21/19 1:58 PM, Jakub Jelinek wrote:
> On Fri, Jun 21, 2
On 6/21/19 4:28 PM, Richard Biener wrote:
> On Fri, Jun 21, 2019 at 4:13 PM Jakub Jelinek wrote:
>>
>> On Fri, Jun 21, 2019 at 04:04:00PM +0200, Martin Liška wrote:
>>> On 6/21/19 1:58 PM, Jakub Jelinek wrote:
On Fri, Jun 21, 2019 at 01:52:09PM +0200, Martin Liška wrote:
> On 6/21/19 1:47
>
> > On 27 Jun 2019, at 19:21, Jan Hubicka wrote:
> >
> >>
> >> It's useful on targets without COMDAT support. Are there any such
> >> that we care about at this point?
> >>
> >> If the problem is the combination with LTO, why not just prohibit that?
> >
> > The problem is that at the colle
> On 27 Jun 2019, at 19:21, Jan Hubicka wrote:
>
>>
>> It's useful on targets without COMDAT support. Are there any such
>> that we care about at this point?
>>
>> If the problem is the combination with LTO, why not just prohibit that?
>
> The problem is that at the collect2 time we want to
>
> It's useful on targets without COMDAT support. Are there any such
> that we care about at this point?
>
> If the problem is the combination with LTO, why not just prohibit that?
The problem is that at the collect2 time we want to decide whether to
hold stderr/stdout of the linker. The issue
On Thu, Jun 27, 2019 at 10:23 AM Martin Liška wrote:
>
> On 6/27/19 2:58 PM, Jonathan Wakely wrote:
> > On Thu, 27 Jun 2019 at 13:30, Martin Liška wrote:
> >>
> >> On 6/21/19 4:28 PM, Richard Biener wrote:
> >>> On Fri, Jun 21, 2019 at 4:13 PM Jakub Jelinek wrote:
>
> On Fri, Jun 21, 2
On 6/27/19 2:58 PM, Jonathan Wakely wrote:
> On Thu, 27 Jun 2019 at 13:30, Martin Liška wrote:
>>
>> On 6/21/19 4:28 PM, Richard Biener wrote:
>>> On Fri, Jun 21, 2019 at 4:13 PM Jakub Jelinek wrote:
On Fri, Jun 21, 2019 at 04:04:00PM +0200, Martin Liška wrote:
> On 6/21/19 1:58 PM,
On Thu, 27 Jun 2019 at 13:30, Martin Liška wrote:
>
> On 6/21/19 4:28 PM, Richard Biener wrote:
> > On Fri, Jun 21, 2019 at 4:13 PM Jakub Jelinek wrote:
> >>
> >> On Fri, Jun 21, 2019 at 04:04:00PM +0200, Martin Liška wrote:
> >>> On 6/21/19 1:58 PM, Jakub Jelinek wrote:
> On Fri, Jun 21, 20
On 6/21/19 4:28 PM, Richard Biener wrote:
> On Fri, Jun 21, 2019 at 4:13 PM Jakub Jelinek wrote:
>>
>> On Fri, Jun 21, 2019 at 04:04:00PM +0200, Martin Liška wrote:
>>> On 6/21/19 1:58 PM, Jakub Jelinek wrote:
On Fri, Jun 21, 2019 at 01:52:09PM +0200, Martin Liška wrote:
> On 6/21/19 1:47
On Fri, Jun 21, 2019 at 4:13 PM Jakub Jelinek wrote:
>
> On Fri, Jun 21, 2019 at 04:04:00PM +0200, Martin Liška wrote:
> > On 6/21/19 1:58 PM, Jakub Jelinek wrote:
> > > On Fri, Jun 21, 2019 at 01:52:09PM +0200, Martin Liška wrote:
> > >> On 6/21/19 1:47 PM, Jonathan Wakely wrote:
> > >>> On Fri,
On Fri, Jun 21, 2019 at 04:04:00PM +0200, Martin Liška wrote:
> On 6/21/19 1:58 PM, Jakub Jelinek wrote:
> > On Fri, Jun 21, 2019 at 01:52:09PM +0200, Martin Liška wrote:
> >> On 6/21/19 1:47 PM, Jonathan Wakely wrote:
> >>> On Fri, 21 Jun 2019 at 11:40, Martin Liška wrote:
> Yes, I would be f
survives regression tests.
Martin
>
> Jakub
>
>From 2eeaa3bbe9cacf4d3d407797e38c00e062c6bfd5 Mon Sep 17 00:00:00 2001
From: Martin Liska
Date: Fri, 21 Jun 2019 14:18:11 +0200
Subject: [PATCH] Deprecate -frepo option.
gcc/ChangeLog:
2019-06-21 Martin Liska
* doc/extend
On Fri, Jun 21, 2019 at 01:52:09PM +0200, Martin Liška wrote:
> On 6/21/19 1:47 PM, Jonathan Wakely wrote:
> > On Fri, 21 Jun 2019 at 11:40, Martin Liška wrote:
> >> Yes, I would be fine to deprecate that for GCC 10.1
> >
> > Would it be appropriate to issue a warning in GCC 10.x if the option is
; option from your makefiles (or other build system) and let the linker
> handle things. You'd get larger object files and slower links, but it
> should work.
>
>From 103ae184e4f6cb5e11f3777845828e3677bc74b7 Mon Sep 17 00:00:00 2001
From: Martin Liska
Date: Fri, 21 Jun 2019 13:39:23 +
41 matches
Mail list logo
