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/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 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
Is it time to deprecate traditional preprocessing? It's been 30 years
since C89. Are (non-compiler) tools that use it still things?
Handling it gets its hooks into a bunch of odd places in libcpp.
To be specific: deprecate -traditional-cpp for GCC10, remove in GCC11.
nathan
--
Nathan Sidwe
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 Thu, Sep 5, 2019 at 2:08 PM Nathan Sidwell wrote:
>
> Is it time to deprecate traditional preprocessing? It's been 30 years
> since C89. Are (non-compiler) tools that use it still things?
>
> Handling it gets its hooks into a bunch of odd places in libcpp.
>
> To be specific: deprecate -trad
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, 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 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 Sep 05 2019, Nathan Sidwell wrote:
> Is it time to deprecate traditional preprocessing? It's been 30 years
> since C89. Are (non-compiler) tools that use it still things?
It's probably still used together with -xassembler-with-cpp.
Andreas.
--
Andreas Schwab, SUSE Labs, sch...@suse.de
G
On Thu, Sep 05, 2019 at 02:33:35PM +0200, Andreas Schwab wrote:
> On Sep 05 2019, Nathan Sidwell wrote:
>
> > Is it time to deprecate traditional preprocessing? It's been 30 years
> > since C89. Are (non-compiler) tools that use it still things?
>
> It's probably still used together with -xas
* Nathan Sidwell:
> Is it time to deprecate traditional preprocessing? It's been 30
> years since C89. Are (non-compiler) tools that use it still things?
Doesn't imake still use it?
checking for cpp... /usr/bin/cpp
checking if /usr/bin/cpp requires -undef... yes
checking if /usr/bin/cpp requi
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
* Jakub Jelinek:
> On Thu, Sep 05, 2019 at 02:33:35PM +0200, Andreas Schwab wrote:
>> On Sep 05 2019, Nathan Sidwell wrote:
>>
>> > Is it time to deprecate traditional preprocessing? It's been 30 years
>> > since C89. Are (non-compiler) tools that use it still things?
>>
>> It's probably sti
Hi,
On Thu, Sep 05 2019, Nathan Sidwell wrote:
> Is it time to deprecate traditional preprocessing? It's been 30 years
> since C89. Are (non-compiler) tools that use it still things?
xrdb runs .Xdefaults and I believe .Xresources files through the
pre-processor and I still use the latter to c
I think since the upgrade to GCC 9.2 in Fedora, the glibc test
nptl/tst-cancelx18 (which is built with -fexceptions) fails on the Arm
32-bit architecture (and only there). I'm not 100% certain that it's
caused by the GCC update, but the patterns of failures and passes
strongly suggests that.
I do
* Florian Weimer:
> I think since the upgrade to GCC 9.2 in Fedora, the glibc test
> nptl/tst-cancelx18 (which is built with -fexceptions) fails on the Arm
> 32-bit architecture (and only there). I'm not 100% certain that it's
> caused by the GCC update, but the patterns of failures and passes
>
On Thu, Sep 05, 2019 at 02:16:08PM +0300, Janne Blomqvist wrote:
> On Thu, Sep 5, 2019 at 2:08 PM Nathan Sidwell wrote:
> >
> > Is it time to deprecate traditional preprocessing? It's been 30 years
> > since C89. Are (non-compiler) tools that use it still things?
> >
> > Handling it gets its ho
On Thu, Sep 05, 2019 at 07:03:25AM -0700, Steve Kargl wrote:
> On Thu, Sep 05, 2019 at 02:16:08PM +0300, Janne Blomqvist wrote:
> > On Thu, Sep 5, 2019 at 2:08 PM Nathan Sidwell wrote:
> > >
> > > Is it time to deprecate traditional preprocessing? It's been 30 years
> > > since C89. Are (non-co
On Thu, Sep 05, 2019 at 07:08:48AM -0700, Steve Kargl wrote:
> On Thu, Sep 05, 2019 at 07:03:25AM -0700, Steve Kargl wrote:
> > On Thu, Sep 05, 2019 at 02:16:08PM +0300, Janne Blomqvist wrote:
> > > On Thu, Sep 5, 2019 at 2:08 PM Nathan Sidwell wrote:
> > > >
> > > > Is it time to deprecate tradit
Steve Kargl writes:
> On Thu, Sep 05, 2019 at 07:08:48AM -0700, Steve Kargl wrote:
>> On Thu, Sep 05, 2019 at 07:03:25AM -0700, Steve Kargl wrote:
>> > On Thu, Sep 05, 2019 at 02:16:08PM +0300, Janne Blomqvist wrote:
>> > > On Thu, Sep 5, 2019 at 2:08 PM Nathan Sidwell wrote:
>> > > >
>> > > > I
Snapshot gcc-7-20190905 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/7-20190905/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 7 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-7
I have a use case where I would like gcc to accept -Kthread
and act as if it was passed -pthread. So -Kthread would
be a synonym for -pthread.
I am having trouble figuring out how the option processing is handled.
Possibly in gcc/gcc.c but I am stumped here.
Any pointers would be welcome.
Than
On 9/5/19 11:25 PM, Tim Rice wrote:
I have a use case where I would like gcc to accept -Kthread
and act as if it was passed -pthread. So -Kthread would
be a synonym for -pthread.
I am having trouble figuring out how the option processing is handled.
Possibly in gcc/gcc.c but I am stumped here.
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
25 matches
Mail list logo
