Hi.
The patch is about a new ELF section that will contain information
about LTO version. And for the future, used compression will be stored
here. The patch removes streaming of the version into each section.
Disadvantage is a format change that will lead to following errors when
LTO bytecode is
On 6/20/19 9:53 PM, Richard Biener wrote:
> On June 20, 2019 5:09:55 PM GMT+02:00, "Martin Liška" wrote:
>> On 6/20/19 4:21 PM, David Edelsohn wrote:
>>> On Thu, Jun 20, 2019 at 10:05 AM Martin Liška wrote:
Hi.
In order to not buffer stderr output in LTO mode, I would like to
On Fri, 21 Jun 2019 at 11:22, Martin Liška wrote:
>
> On 6/20/19 9:53 PM, Richard Biener wrote:
> > On June 20, 2019 5:09:55 PM GMT+02:00, "Martin Liška"
> > wrote:
> >> On 6/20/19 4:21 PM, David Edelsohn wrote:
> >>> On Thu, Jun 20, 2019 at 10:05 AM Martin Liška wrote:
>
> Hi.
>
> On 21 Jun 2019, at 11:28, Jonathan Wakely wrote:
>
> On Fri, 21 Jun 2019 at 11:22, Martin Liška wrote:
>>
>> On 6/20/19 9:53 PM, Richard Biener wrote:
>>> On June 20, 2019 5:09:55 PM GMT+02:00, "Martin Liška"
>>> wrote:
On 6/20/19 4:21 PM, David Edelsohn wrote:
> On Thu, Jun 20,
On 6/21/19 12:34 PM, Iain Sandoe wrote:
>
>> On 21 Jun 2019, at 11:28, Jonathan Wakely wrote:
>>
>> On Fri, 21 Jun 2019 at 11:22, Martin Liška wrote:
>>>
>>> On 6/20/19 9:53 PM, Richard Biener wrote:
On June 20, 2019 5:09:55 PM GMT+02:00, "Martin Liška"
wrote:
> On 6/20/19 4:21 P
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 used?
I think in most cases the "fix" would be to simply remove the -frepo
option from your makefiles (or other build sys
> On 21 Jun 2019, at 11:40, Martin Liška wrote:
>
> On 6/21/19 12:34 PM, Iain Sandoe wrote:
>>
>>> On 21 Jun 2019, at 11:28, Jonathan Wakely wrote:
>>>
>>> On Fri, 21 Jun 2019 at 11:22, Martin Liška wrote:
On 6/20/19 9:53 PM, Richard Biener wrote:
> On June 20, 2019 5:09:55 P
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 used?
Sure. With the patch attached one will see:
$ gcc -frepo /tmp/ma
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
On Wed, Jun 19, 2019 at 5:15 AM Martin Sebor wrote:
>
> Bug 90923 shows that even though GCC hash-table based containers
> like hash_map can be instantiated on types with user-defined ctors
> and dtors they invoke the dtors of such types without invoking
> the corresponding ctors.
>
> It was thank
On Fri, Jun 21, 2019 at 12:20 PM Martin Liška wrote:
>
> Hi.
>
> The patch is about a new ELF section that will contain information
> about LTO version. And for the future, used compression will be stored
> here. The patch removes streaming of the version into each section.
I'd like each section
On Fri, Jun 21, 2019 at 1:50 PM Iain Sandoe wrote:
>
>
> > On 21 Jun 2019, at 11:40, Martin Liška wrote:
> >
> > On 6/21/19 12:34 PM, Iain Sandoe wrote:
> >>
> >>> On 21 Jun 2019, at 11:28, Jonathan Wakely wrote:
> >>>
> >>> On Fri, 21 Jun 2019 at 11:22, Martin Liška wrote:
>
> On 6/2
On 6/21/19 2:34 PM, Richard Biener wrote:
> On Fri, Jun 21, 2019 at 12:20 PM Martin Liška wrote:
>>
>> Hi.
>>
>> The patch is about a new ELF section that will contain information
>> about LTO version. And for the future, used compression will be stored
>> here. The patch removes streaming of the
> > >> I should have been clearer about Darwin:
> > >>
> > >> collect2 is required because it wraps the calling of lto-wrapper and ld.
> > >>
> > >> FWIW Darwin also passes all the “-frepo” testcases, however, I’m not
> > >> aware of anyone actually
> > >> using case #2 from Jonathan’s post.
> > >
> On 6/21/19 2:34 PM, Richard Biener wrote:
> > On Fri, Jun 21, 2019 at 12:20 PM Martin Liška wrote:
> >>
> >> Hi.
> >>
> >> The patch is about a new ELF section that will contain information
> >> about LTO version. And for the future, used compression will be stored
> >> here. The patch removes s
> On 21 Jun 2019, at 13:49, Jan Hubicka wrote:
>
> I should have been clearer about Darwin:
>
> collect2 is required because it wraps the calling of lto-wrapper and ld.
>
> FWIW Darwin also passes all the “-frepo” testcases, however, I’m not
> aware of anyone actually
On 6/19/19 11:04 PM, Kugan Vivekanandarajah wrote:
Hi Andrew,
Thanks for working on this.
Enable elimination of zext/sext with VRP patch had to be reverted in
(https://gcc.gnu.org/ml/gcc-patches/2014-09/msg00672.html) due to the
need for value ranges in PROMOTED_MODE precision for at least 1 te
On 6/21/19 2:57 PM, Jan Hubicka wrote:
> This looks like good step (and please stream it in host independent
> way). I suppose all these issues can be done one-by-one.
So there's a working patch for that. However one will see following errors
when using an older compiler or older LTO bytecode:
$
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 fine to deprecate that for GCC 10.1
>>>
>>> Would it be appropriate to is
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
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,
Hi Christophe,
we’ve been looking at some cases where Darwin tests fail or pass unexpectedly
depending on
options. It came as a surprise to see it failing a test for shared support
(since it’s always
supported shared libs).
-
It’s a long time ago, but in r216117 you added this to target-s
On Fri, Jun 21, 2019 at 10:29 AM Iain Sandoe wrote:
>
> Hi Christophe,
>
> we’ve been looking at some cases where Darwin tests fail or pass unexpectedly
> depending on
> options. It came as a surprise to see it failing a test for shared support
> (since it’s always
> supported shared libs).
>
>
On 6/21/19 6:06 AM, Richard Biener wrote:
On Wed, Jun 19, 2019 at 5:15 AM Martin Sebor wrote:
Bug 90923 shows that even though GCC hash-table based containers
like hash_map can be instantiated on types with user-defined ctors
and dtors they invoke the dtors of such types without invoking
the c
Hi,
Hope you are doing well!
I wanted to check if you'd be interested in purchasing 2019 updated Quest
User List for your marketing initiatives?
We also have related technology users like: Schneider, Salesforce, Oracle,
IBM, Cisco, Microsoft and many more...
Let me know if you are interested a
Snapshot gcc-8-20190621 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/8-20190621/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 8 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-8
Hi Andrew,
Thanks for looking into it and my apologies for not being clear.
My proposal was to use value ranges when expanding gimple to RTL and
eliminate redundant zero/sign extensions. I.e., if we know the value
generated by some gimple operation is already in the (zero/sign)
extended from base
Hello all,
I have been trying to run a test which assigns a value from non-atomic to
an atomic pointer type. The code is as follows:
/* File: xyz.c */
/* { dg-do compile } */
/* { dg-options "-std=c11 -pedantic-errors" } */
#include
typedef __SIZE_TYPE__ size_t;
extern void abort (void);
exte
28 matches
Mail list logo
