On Tue, May 11, 2021 at 3:39 PM Jakub Jelinek wrote:
>
> On Tue, May 11, 2021 at 03:33:58PM +0200, Martin Liška wrote:
> > On 5/11/21 9:49 AM, Richard Biener wrote:
> > > I wonder if we can instead upstream the build-id use and conditionalize
> > > the checksum stuff on some configury? Some peopl
On Tue, May 11, 2021 at 03:33:58PM +0200, Martin Liška wrote:
> On 5/11/21 9:49 AM, Richard Biener wrote:
> > I wonder if we can instead upstream the build-id use and conditionalize
> > the checksum stuff on some configury? Some people do seem worried
> > about "weakening" the checksum.
>
> I lik
On 5/11/21 9:49 AM, Richard Biener wrote:
I wonder if we can instead upstream the build-id use and conditionalize
the checksum stuff on some configury? Some people do seem worried
about "weakening" the checksum.
I like the build-id approach. Can we please upstream it?
If it's not feasible the
On Tue, May 11, 2021 at 8:46 AM Martin Liška wrote:
>
> On 4/23/21 1:37 PM, Martin Liška wrote:
> > On 4/23/21 12:59 PM, Richard Biener wrote:
> >> True, the question is on how much detail we have to pay attention to.
> >
> > Agree with that.
> >
> >> For us of course the build-id solution works f
On 4/23/21 1:37 PM, Martin Liška wrote:
On 4/23/21 12:59 PM, Richard Biener wrote:
True, the question is on how much detail we have to pay attention to.
Agree with that.
For us of course the build-id solution works fine. And hopefully the
days of PCH are counted...
Yes.
I have a tentativ
> The following patch fixes that, ready for master?
Sure, thanks!
--
Eric Botcazou
On 5/10/21 5:59 PM, Eric Botcazou wrote:
Do you know Eric where version.o needs to be added to be included in the
problematic command line?
You can presumably remove it from GNATLINK_OBJS & GNATMAKE_OBJS. And it needs
to be added to GNAT1_C_OBJS instead of GNAT_ADA_OBJS in Make-lang.in.
Tha
> Do you know Eric where version.o needs to be added to be included in the
> problematic command line?
You can presumably remove it from GNATLINK_OBJS & GNATMAKE_OBJS. And it needs
to be added to GNAT1_C_OBJS instead of GNAT_ADA_OBJS in Make-lang.in.
--
Eric Botcazou
> Do you know Eric where version.o needs to be added to be included in the
> problematic command line?
Presumably to the beginning of TOOLS_LIBS in ada/gcc-interface/Makefile.in:
TOOLS_LIBS = ../version.o ../link.o ../targext.o ../../ggc-none.o \
--
Eric Botcazou
> I have a slightly different issue, last week it was still okay,
> but now I get (using gcc-4.8 as bootstrap compiler):
>
> gcc -std=gnu99 -c -g -gnatpg -gnatwns -gnata -W -Wall -nostdinc -I- -I.
> -Iada/generated -Iada -Iada/gcc-interface -I../../gcc-trunk/gcc/ada
> -I../../gcc-trunk/gcc/ada/gc
Hi Eric,
I have a slightly different issue, last week it was still okay,
but now I get (using gcc-4.8 as bootstrap compiler):
gcc -std=gnu99 -c -g -gnatpg -gnatwns -gnata -W -Wall -nostdinc -I- -I.
-Iada/generated -Iada -Iada/gcc-interface -I../../gcc-trunk/gcc/ada
-I../../gcc-trunk/gcc/ada/gc
On 5/10/21 11:01 AM, Eric Botcazou wrote:
Ready for master?
/usr/lib64/gcc/x86_64-suse-linux/7/../../../../x86_64-suse-linux/bin/ld: ada/
gnatvsn.o: in function `gnatvsn__gnat_version_string':
/home/eric/cvs/gcc/gcc/ada/gnatvsn.adb:67: undefined reference to
`version_string'
/usr/lib64/gcc/x86_
> Ready for master?
/usr/lib64/gcc/x86_64-suse-linux/7/../../../../x86_64-suse-linux/bin/ld: ada/
gnatvsn.o: in function `gnatvsn__gnat_version_string':
/home/eric/cvs/gcc/gcc/ada/gnatvsn.adb:67: undefined reference to
`version_string'
/usr/lib64/gcc/x86_64-suse-linux/7/../../../../x86_64-suse-li
> Ready for master?
This breaks the build for me:
make[3]: *** No rule to make target '/home/eric/cvs/gcc/gcc/version.c', needed
by 'ada/stamp-sdefault'. Stop.
make[3]: *** Waiting for unfinished jobs
--
Eric Botcazou
On 4/23/21 12:59 PM, Richard Biener wrote:
> True, the question is on how much detail we have to pay attention to.
Agree with that.
> For us of course the build-id solution works fine. And hopefully the
> days of PCH are counted...
Yes.
I have a tentative patch that emits the attached checksum
On Fri, Apr 23, 2021 at 11:51 AM Jan Hubicka wrote:
>
> > > That needs to be combined with the generated auto-host.h header file.
> > > From which locations do you want to build the hash? Any other $objdir
> > > files except auto-host.h?
> >
> > In fact for PCH just summing the gengtype generated
> > That needs to be combined with the generated auto-host.h header file.
> > From which locations do you want to build the hash? Any other $objdir
> > files except auto-host.h?
>
> In fact for PCH just summing the gengtype generated files would be
> good enough I guess ...
I think one can, for e
On Fri, Apr 23, 2021 at 9:59 AM Martin Liška wrote:
>
> On 4/23/21 9:28 AM, Richard Biener wrote:
> > On Tue, Apr 20, 2021 at 8:49 PM Martin Liška wrote:
> >>
> >> On 4/20/21 2:46 PM, Richard Biener wrote:
> >>> OK. Can you somehow arrange for trunk to pick up LTO_major from GCC
> >>> major auto
On 4/23/21 9:28 AM, Richard Biener wrote:
> On Tue, Apr 20, 2021 at 8:49 PM Martin Liška wrote:
>>
>> On 4/20/21 2:46 PM, Richard Biener wrote:
>>> OK. Can you somehow arrange for trunk to pick up LTO_major from GCC
>>> major automagically then?
>>
>> I have a pretty nice solution for it where I
On Tue, Apr 20, 2021 at 8:49 PM Martin Liška wrote:
>
> On 4/20/21 2:46 PM, Richard Biener wrote:
> > OK. Can you somehow arrange for trunk to pick up LTO_major from GCC
> > major automagically then?
>
> I have a pretty nice solution for it where I extended (and simplified)
> the existing gcov-io
On 4/20/21 2:46 PM, Richard Biener wrote:
> OK. Can you somehow arrange for trunk to pick up LTO_major from GCC
> major automagically then?
I have a pretty nice solution for it where I extended (and simplified)
the existing gcov-iov.c generator. Doing that we can remove gcc/version.[ch].
Using t
On Tue, Apr 20, 2021 at 11:57 AM Martin Liška wrote:
>
> It seems we bumped LTO_major_version last time 2 years ago.
>
> Right now, the following is seen when one links a GCC 10.2.x LTO object file:
> $ gcc a.o
>
> lto1: fatal error: bytecode stream in file ‘a.o’ generated with LTO version
> 9.2
It seems we bumped LTO_major_version last time 2 years ago.
Right now, the following is seen when one links a GCC 10.2.x LTO object file:
$ gcc a.o
lto1: fatal error: bytecode stream in file ‘a.o’ generated with LTO version 9.2
instead of the expected 9.0
I suggest bumping LTO_major_version fo
This bumps the bytecode version.
Committed to trunk.
Richard.
2018-04-25 Richard Biener
* lto-streamer.h (LTO_major_version): Bump to 8.
Index: gcc/lto-streamer.h
===
--- gcc/lto-streamer.h (revision 259637)
+++ gcc/l
Was still the same as on the GCC 5 branch.
Committed as obvious.
Richard.
2015-06-29 Richard Biener
* lto-streamer.h (LTO_major_version): Bump to 5.
Index: gcc/lto-streamer.h
===
--- gcc/lto-streamer.h (revision 22511
This bumps LTO_major_version on trunk to avoid ICEing when
accidentially mixing objects with 4.9 ones. We'll soon start
to diverge (if we didn't already).
Committed.
Richard.
2014-04-15 Richard Biener
* lto-streamer.h (LTO_major_version): Bump to 4.
Index: gcc/lto-streamer.h
=
26 matches
Mail list logo
