Snapshot gcc-7-20190620 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/7-20190620/
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
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
>remove
>>> support for repo files (tlink). If I'm
Any use of a host library should come with associated configure options to
specify header and library paths for that library (and documentation for
those options). (See existing --with-gmp*, --with-isl* etc. options.)
--
Joseph S. Myers
jos...@codesourcery.com
Dell Customer Communication - Confidential
> From: Martin Liška
> Sent: Thursday, June 20, 2019 9:49 AM
> I see. What about the following patch:
>
> $ ./gcc/xgcc -Bgcc /tmp/main.c --coverage
> -fprofile-note=/tmp/main.gcno $ ls -l /tmp/main.gcno
> -rw-r--r-- 1 marxin users 428 Jun 20 15:48 /tm
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 remove
>> support for repo files (tlink). If I'm correctly it's only used by AIX
>> target. Would it be possible to dro
> On 20 Jun 2019, at 15:21, 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 remove
>> support for repo files (tlink). If I'm correctly it's only used by AIX
>> target. Would it be
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 remove
> support for repo files (tlink). If I'm correctly it's only used by AIX
> target. Would it be possible to drop that for the future? Is it even
> used?
AIX cur
On Jun 20 2019, Jonathan Wakely wrote:
> Other people have reported that their clones updated the tag without
> any problems, so the "would clobber existing tag" error I got might be
> because I've been creating and removing that tag locally.
You need to have a recent version of git to get that
Hi.
In order to not buffer stderr output in LTO mode, I would like to remove
support for repo files (tlink). If I'm correctly it's only used by AIX
target. Would it be possible to drop that for the future? Is it even
used?
Thank you,
Martin
On 6/20/19 3:29 PM, david.tay...@dell.com wrote:
>> From: Martin Liška
>> Sent: Thursday, June 20, 2019 9:07 AM
>>
>> On 6/20/19 3:00 PM, david.tay...@dell.com wrote:
>>>
From: Martin Liška
Sent: Thursday, June 20, 2019 5:12 AM
On 6/19/19 7:11 PM, david.tay...@dell.com wrote:
> From: Martin Liška
> Sent: Thursday, June 20, 2019 9:07 AM
>
> On 6/20/19 3:00 PM, david.tay...@dell.com wrote:
> >
> >> From: Martin Liška
> >> Sent: Thursday, June 20, 2019 5:12 AM
> >>
> >> On 6/19/19 7:11 PM, david.tay...@dell.com wrote:
> >>> Thanks for the patch. Standalone it is not su
> Am 20.06.19 um 15:00 schrieb david.tay...@dell.com:
> > Dell Customer Communication - Confidential
>
> Can't expect me to read this, then? :-)
Grumble. For every email, even internal ones, we are asked
it's 'sensitivity'. I explicitly marked that one as 'external public'.
It should not have s
On 6/20/19 3:00 PM, david.tay...@dell.com wrote:
> Dell Customer Communication - Confidential
>
>> From: Martin Liška
>> Sent: Thursday, June 20, 2019 5:12 AM
>> To: taylor, david; richard.guent...@gmail.com
>> Cc: gcc@gcc.gnu.org
>> Subject: Re: gcc: -ftest-coverage and -auxbase
>>
>> On 6/19/19
Am 20.06.19 um 15:00 schrieb david.tay...@dell.com:
Dell Customer Communication - Confidential
Can't expect me to read this, then? :-)
Dell Customer Communication - Confidential
> From: Martin Liška
> Sent: Thursday, June 20, 2019 5:12 AM
> To: taylor, david; richard.guent...@gmail.com
> Cc: gcc@gcc.gnu.org
> Subject: Re: gcc: -ftest-coverage and -auxbase
>
> On 6/19/19 7:11 PM, david.tay...@dell.com wrote:
> > Thanks for the p
On Thu, 20 Jun 2019 at 13:25, Vladislav Ivanishin wrote:
>
> Jonathan Wakely writes:
>
> > On Wed, 12 Jun 2019 at 09:24, Thomas Schwinge
> > wrote:
> >>
> >> Hi!
> >>
> >> On Tue, 11 Jun 2019 16:35:40 +0100, Jonathan Wakely
> >> wrote:
> >> > On Tue, 11 Jun 2019 at 16:33, Jonathan Wakely
>
Jonathan Wakely writes:
> On Wed, 12 Jun 2019 at 09:24, Thomas Schwinge wrote:
>>
>> Hi!
>>
>> On Tue, 11 Jun 2019 16:35:40 +0100, Jonathan Wakely
>> wrote:
>> > On Tue, 11 Jun 2019 at 16:33, Jonathan Wakely
>> > wrote:
>> > > On Tue, 11 Jun 2019 at 16:29, Thomas Schwinge
>> > > wrote:
>>
Hi Martin,
LTO bytecode is not supposed to be a distributable format.
One of my dreams is to make libgfortran LTO-clean. There is
a lot of performance to be gained both in I/O (where a huge
number of special cases could be shortcut by LTO, because
hardly any program uses them all) and in arra
On Wed, 12 Jun 2019 at 09:24, Thomas Schwinge wrote:
>
> Hi!
>
> On Tue, 11 Jun 2019 16:35:40 +0100, Jonathan Wakely
> wrote:
> > On Tue, 11 Jun 2019 at 16:33, Jonathan Wakely wrote:
> > > On Tue, 11 Jun 2019 at 16:29, Thomas Schwinge
> > > wrote:
> > > > On Tue, 11 Jun 2019 16:18:51 +0100, J
> On 6/20/19 12:58 PM, Thomas Koenig wrote:
> > Am 20.06.19 um 11:07 schrieb Martin Liška:
> >> On the contrary, decompression
> >> of zstd with zlib will end with:
> >> lto1: internal compiler error: compressed stream: data error
> >
> > Sogenerating object files on one system and trying to read
On 6/20/19 12:46 PM, Segher Boessenkool wrote:
> OTOH, how well has this been tested, then? On different platforms, etc.?
Dunno.
The algorithm is quite new (4 years), but as it's becoming more popular.
So I would expect coverage would be quite good.
Maybe Nathan can comment on this?
Martin
On 6/20/19 12:58 PM, Thomas Koenig wrote:
> Am 20.06.19 um 11:07 schrieb Martin Liška:
>> On the contrary, decompression
>> of zstd with zlib will end with:
>> lto1: internal compiler error: compressed stream: data error
>
> Sogenerating object files on one system and trying to read them
> on anot
Am 20.06.19 um 11:07 schrieb Martin Liška:
On the contrary, decompression
of zstd with zlib will end with:
lto1: internal compiler error: compressed stream: data error
Sogenerating object files on one system and trying to read them
on another system which does not happen to have a particular
li
On Wed, Jun 19, 2019 at 09:29:54PM +0200, Jan Hubicka wrote:
> >
> > At least allow it to be built as part of the normal build like GMP,
> > etc. are done.
> > And include it in downloading using contrib/download_prerequisites
> > like the libraries are done.
>
> Anoying detail is that zstd build
On 6/19/19 7:11 PM, david.tay...@dell.com wrote:
> Thanks for the patch. Standalone it is not sufficient. Combined
> with the other two changes that have been discussed --
Why is that not sufficient? If you build from top-level and you have .o files
that overwrite each other, then you can set
-
Hello.
As mentioned by Honza, it's using cmake and to be honest I prefer to use a
shared
library than a statically build library. Moreover, it's an optional requirement
and
so that we don't have to include that to contrib/download_prerequisites.
I like the idea of marking of compression algorit
On Wed, Jun 19, 2019 at 11:37:52AM -0600, Jeff Law wrote:
> On 6/19/19 11:09 AM, Segher Boessenkool wrote:
> > On Wed, Jun 19, 2019 at 09:39:01AM -0600, Jeff Law wrote:
> >> A label used as a value, but which is not a jump target will have an
> >> indeterminate value -- it'll end up somewhere in it
27 matches
Mail list logo
