Re: [GSOC] LTO dump tool project
Hi. There's working patch that really generates lto-dump binary. Martin diff --git a/gcc/lto/Make-lang.in b/gcc/lto/Make-lang.in index 46950776dd2..502afe94851 100644 --- a/gcc/lto/Make-lang.in +++ b/gcc/lto/Make-lang.in @@ -21,10 +21,14 @@ # The name of the LTO compiler. LTO_EXE = lto1$(exeext) +LTO_DUMP_EXE = lto-dump$(exeext) # The LTO-specific object files inclued in $(LTO_EXE). LTO_OBJS = lto/lto-lang.o lto/lto.o lto/lto-object.o attribs.o lto/lto-partition.o lto/lto-symtab.o lto_OBJS = $(LTO_OBJS) +LTO_DUMP_OBJS = lto/lto-lang.o lto/lto-dump.o lto/lto-object.o attribs.o lto/lto-partition.o lto/lto-symtab.o +lto_dump_OBJS = $(LTO_DUMP_OBJS) + # this is only useful in a LTO bootstrap, but this does not work right # now. Should reenable after this is fixed, but only when LTO bootstrap # is enabled. @@ -39,8 +43,8 @@ lto_OBJS = $(LTO_OBJS) # These hooks are used by the main GCC Makefile. Consult that # Makefile for documentation. -lto.all.cross: $(LTO_EXE) -lto.start.encap: $(LTO_EXE) +lto.all.cross: $(LTO_EXE) $(LTO_DUMP_EXE) +lto.start.encap: $(LTO_EXE) $(LTO_DUMP_EXE) lto.rest.encap: lto.tags: lto.install-common: @@ -60,7 +64,7 @@ lto.srcinfo: lto.install-plugin: lto.mostlyclean: - rm -f $(LTO_OBJS) $(LTO_EXE) lto1.fda + rm -f $(LTO_DUMP_OBJS) $(LTO_DUMP_EXE) lto-dump.fda $(LTO_OBJS) $(LTO_EXE) lto1.fda lto.clean: lto.distclean: @@ -81,6 +85,10 @@ $(LTO_EXE): $(LTO_OBJS) $(BACKEND) $(LIBDEPS) +$(LLINKER) $(ALL_LINKERFLAGS) $(LDFLAGS) -o $@ \ $(LTO_OBJS) $(BACKEND) $(BACKENDLIBS) $(LIBS) +$(LTO_DUMP_EXE): $(LTO_DUMP_OBJS) $(BACKEND) $(LIBDEPS) + +$(LLINKER) $(ALL_LINKERFLAGS) $(LDFLAGS) -o $@ \ + $(LTO_DUMP_OBJS) $(BACKEND) $(BACKENDLIBS) $(LIBS) + lto1.fda: ../prev-gcc/lto1$(exeext) ../prev-gcc/$(PERF_DATA) $(CREATE_GCOV) -binary ../prev-gcc/lto1$(exeext) -gcov lto1.fda -profile ../prev-gcc/$(PERF_DATA) -gcov_version 1
Early bird rate available
Improving Patient Safety & Care 2019 Continuous Learning, Measurement & Improvement 6th of February 2019 - RSM, London As part of our ongoing series of conferences aimed at delivering key information and evidence based solutions in order to assist the communication and delivery of the NHS 5 yr forward view, Govconnect are proud to announce our inaugural Improving Patient Safety & Care conference taking place on February 6th 2019 at the Royal Society of Medicine, London. An Early Bird rate of 30% off the standard delegate rate for this event is currently available; enter promo code IPSC19_EARLYBIRD via the online registration system before 30th June to take advantange of this offer. This inaugural conference will assess how the NHS are making are currently making a difference in regards to improved safety and care and how it intends to do so in the future through a transparent constantly evolving patient centred system. It is therefore a must attend in the conference calendar for any one involved in the provision of patient centred services across the NHS, be that frontline, clinical or board level personnel. [1]Register to Attend [2]View Programme Speakers Include Prof Ted Baker Chief Inspector of Hospitals Care Quality Commission Prof Gillian Leng CBE Deputy Chief Executive National Institute for Health and Care Excellence Elizabeth Beech National Project Lead - Healthcare Associated Infections NHS Improvement John Welch President International Society for Rapid Response Systems Radhika Rangaraju e-RS Senior Programme Lead NHS England Lucy Watson Chair The Patients Association The conference will seek to positively disrupt the sector and provide a platform for both success and failures to be analysed. It will facilitate the sharing of ideas and plans for 18/19 and beyond whilst promoting new and innovative concepts, fresh thinking and strategic collaboration. With a focus on all post conference insight in turn leading to stimulated action. It is hoped this conference will enable all NHS employees to better manage safety and care across the system and adopt a whole system approach to achieving excellence in this regard. References 1. http://ipc2019.govconnect.org.uk/index.php?option=com_reg&pcode=IPSC19_EARLYBIRD 2. http://ipc2019.govconnect.org.uk/agenda Unsubscribe: http://app.icontact.com/icp/mmail-mprofile.php?r=49588037&l=20971&s=W8RL&m=313510&c=1594230 This message was sent to gcc@gcc.gnu.org from ips...@govconnect-events.co.uk Improving Patient Safety & Care 2019 Rob Daniels 5300 Lakeside Cheadle, Cheshire SK8 3GP, United Kingdom - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - iContact - Try it for FREE: https://www.icontact.com/signup-trial?utm_medium=poweredby&utm_source=footerlink&utm_campaign=iC%20Footer&afid=144186
Re: overflow check in extract_range_from_binary_1 useless?
On Fri, Jun 8, 2018 at 11:42 AM Aldy Hernandez wrote:
>
> Howdy.
>
> Am I missing something or are these two sets identical?
>
> > /* Get the lower and upper bounds of the type. */
> > if (TYPE_OVERFLOW_WRAPS (expr_type))
> > {
> > type_min = wi::min_value (prec, sgn);
> > type_max = wi::max_value (prec, sgn);
> > }
> > else
> > {
> > type_min = wi::to_wide (vrp_val_min (expr_type));
> > type_max = wi::to_wide (vrp_val_max (expr_type));
> > }
>
> Isn't wi::to_wide(TYPE_MIN/MAX_VALUE) the same as wi::min/max_value, or
> is there some weird language (*cough ada*) subtlety I'm missing?
It might have subtle differences for -fstrict-enums or other language specific
types where the legal value-range doesn't cover all of the types precision.
I think you can safely use the wi::max/min_value variant and IMHO
vrp_val_min/max should use wi::min/max_value as well (well, it returns
a tree so better not re-create that all the time).
Richard.
> Confused.
> Aldy
Re: libstdc++ bootstrap failure after r261525
Hi, On 13/06/2018 08:11, François Dumont wrote: On 12/06/2018 23:26, Martin Sebor wrote: Bootstrap fails in libstdc++ with the following error. I haven't investigated it much except to take a peek at recent libstdc++ commits where r261525 looks like it introduced __glibcxx_check_can_increment_range, so it seems like it might have something to do with it. I don't see a __glibcxx_requires_can_increment_range macro defined anywhere in the patch so maybe it's a typo? Francois, can you please see what's going on? /opt/notnfs/msebor/build/gcc-86114/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/stl_algobase.h:452:45: error: ‘__glibcxx_requires_can_increment_range’ was not declared in this scope __glibcxx_requires_can_increment_range(__first, __last, __result); Thanks Martin . I had missed the fact that the patch didn't apply correctly on include/debug/debug.h as stated in the ChangeLog entry. It is fixed now. But even after r261537 we are seeing the regressions: FAIL: g++.dg/warn/pr31246.C -std=gnu++11 (test for excess errors) FAIL: g++.dg/warn/pr31246.C -std=gnu++14 (test for excess errors) FAIL: g++.dg/warn/pr31246.C -std=gnu++98 (test for excess errors) Which definitely are related. Paolo.
Re: libstdc++ bootstrap failure after r261525
On 13/06/18 13:42 +0200, Paolo Carlini wrote: Hi, On 13/06/2018 08:11, François Dumont wrote: On 12/06/2018 23:26, Martin Sebor wrote: Bootstrap fails in libstdc++ with the following error. I haven't investigated it much except to take a peek at recent libstdc++ commits where r261525 looks like it introduced __glibcxx_check_can_increment_range, so it seems like it might have something to do with it. I don't see a __glibcxx_requires_can_increment_range macro defined anywhere in the patch so maybe it's a typo? Francois, can you please see what's going on? /opt/notnfs/msebor/build/gcc-86114/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/stl_algobase.h:452:45: error: ‘__glibcxx_requires_can_increment_range’ was not declared in this scope __glibcxx_requires_can_increment_range(__first, __last, __result); Thanks Martin . I had missed the fact that the patch didn't apply correctly on include/debug/debug.h as stated in the ChangeLog entry. It is fixed now. But even after r261537 we are seeing the regressions: FAIL: g++.dg/warn/pr31246.C -std=gnu++11 (test for excess errors) FAIL: g++.dg/warn/pr31246.C -std=gnu++14 (test for excess errors) FAIL: g++.dg/warn/pr31246.C -std=gnu++98 (test for excess errors) Which definitely are related. And failing Debug Mode tests: FAIL: 20_util/hash/84998.cc (test for excess errors) FAIL: 23_containers/vector/cons/destructible_debug_neg.cc (test for excess errors) FAIL: 25_algorithms/binary_search/partitioned.cc (test for excess errors) FAIL: 25_algorithms/equal_range/partitioned.cc (test for excess errors) FAIL: 25_algorithms/lexicographical_compare/71545.cc (test for excess errors) FAIL: 25_algorithms/lower_bound/partitioned.cc (test for excess errors) FAIL: 25_algorithms/upper_bound/partitioned.cc (test for excess errors) FAIL: ext/profile/mutex_extensions_neg.cc (test for excess errors) The logs show: /home/jwakely/src/gcc/build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/stl_algobase.h:452: error: '__can_advance' is not a member of '__gnu_debug' /home/jwakely/src/gcc/build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/stl_algobase.h:484: error: '__can_advance' is not a member of '__gnu_debug' /home/jwakely/src/gcc/build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/stl_algobase.h:629: error: '__can_advance' is not a member of '__gnu_debug' /home/jwakely/src/gcc/build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/stl_algobase.h:664: error: '__can_advance' is not a member of '__gnu_debug'
Re: libstdc++ bootstrap failure after r261525
I pick up the wrong "can_advance" patch. I should have taken another one first. So I'll send and apply the missing one providing the debug __can_advance in a couple of hours. Sorry On 13/06/2018 15:24, Jonathan Wakely wrote: On 13/06/18 13:42 +0200, Paolo Carlini wrote: Hi, On 13/06/2018 08:11, François Dumont wrote: On 12/06/2018 23:26, Martin Sebor wrote: Bootstrap fails in libstdc++ with the following error. I haven't investigated it much except to take a peek at recent libstdc++ commits where r261525 looks like it introduced __glibcxx_check_can_increment_range, so it seems like it might have something to do with it. I don't see a __glibcxx_requires_can_increment_range macro defined anywhere in the patch so maybe it's a typo? Francois, can you please see what's going on? /opt/notnfs/msebor/build/gcc-86114/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/stl_algobase.h:452:45: error: ‘__glibcxx_requires_can_increment_range’ was not declared in this scope __glibcxx_requires_can_increment_range(__first, __last, __result); Thanks Martin . I had missed the fact that the patch didn't apply correctly on include/debug/debug.h as stated in the ChangeLog entry. It is fixed now. But even after r261537 we are seeing the regressions: FAIL: g++.dg/warn/pr31246.C -std=gnu++11 (test for excess errors) FAIL: g++.dg/warn/pr31246.C -std=gnu++14 (test for excess errors) FAIL: g++.dg/warn/pr31246.C -std=gnu++98 (test for excess errors) Which definitely are related. And failing Debug Mode tests: FAIL: 20_util/hash/84998.cc (test for excess errors) FAIL: 23_containers/vector/cons/destructible_debug_neg.cc (test for excess errors) FAIL: 25_algorithms/binary_search/partitioned.cc (test for excess errors) FAIL: 25_algorithms/equal_range/partitioned.cc (test for excess errors) FAIL: 25_algorithms/lexicographical_compare/71545.cc (test for excess errors) FAIL: 25_algorithms/lower_bound/partitioned.cc (test for excess errors) FAIL: 25_algorithms/upper_bound/partitioned.cc (test for excess errors) FAIL: ext/profile/mutex_extensions_neg.cc (test for excess errors) The logs show: /home/jwakely/src/gcc/build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/stl_algobase.h:452: error: '__can_advance' is not a member of '__gnu_debug' /home/jwakely/src/gcc/build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/stl_algobase.h:484: error: '__can_advance' is not a member of '__gnu_debug' /home/jwakely/src/gcc/build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/stl_algobase.h:629: error: '__can_advance' is not a member of '__gnu_debug' /home/jwakely/src/gcc/build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/stl_algobase.h:664: error: '__can_advance' is not a member of '__gnu_debug'
-v should print also the revision number in repo
Hi, currently -v (ie. gcc -v) prints these data: gcc version 9.0.0 20180613 (experimental) (GCC) It would be nice, when building from a repository that then the resulting target should contain also the revision number (for example "r261543") of the underlying repository, so that gcc -v then prints this info as well. Maybe the respective revision nbr of the repository used (svn, git, ...), or perhaps better: a new generic solution with a unique & common rev-nbr for all repos (and non-repos): a new file with rev-info in the repo-root could do the trick, IMO... Thx
Re: -v should print also the revision number in repo
On Wednesday, June 13, 2018, U.Mutlu wrote: > Hi, > > currently -v (ie. gcc -v) prints these data: > > gcc version 9.0.0 20180613 (experimental) (GCC) > > It would be nice, when building from a repository that then the resulting > target should contain also the revision number (for example "r261543") > of the underlying repository, so that gcc -v then prints this info as well. > > Maybe the respective revision nbr of the repository used (svn, git, ...), > or perhaps better: a new generic solution with a unique & common rev-nbr > for all repos (and non-repos): a new file with rev-info in the repo-root > could do the trick, IMO... If you use contrib/gcc_update, it will place the right thing in the needed file and will display the revision. Thanks, Andrew > > Thx >
2018 UNPAID FUND RECOVERED LETTER
2018 UNPAID FUND RECOVERED LETTER
Re: -v should print also the revision number in repo
Andrew Pinski wrote on 06/13/2018 10:06 PM: On Wednesday, June 13, 2018, U.Mutlu mailto:u...@mutluit.com>> wrote: Hi, currently -v (ie. gcc -v) prints these data: gcc version 9.0.0 20180613 (experimental) (GCC) It would be nice, when building from a repository that then the resulting target should contain also the revision number (for example "r261543") of the underlying repository, so that gcc -v then prints this info as well. Maybe the respective revision nbr of the repository used (svn, git, ...), or perhaps better: a new generic solution with a unique & common rev-nbr for all repos (and non-repos): a new file with rev-info in the repo-root could do the trick, IMO... If you use contrib/gcc_update, it will place the right thing in the needed file and will display the revision. Ah, cool! Will try it out, thx.
Re: libstdc++ bootstrap failure after r261525
Here is the missing part of the can_advance patch.
* include/debug/helper_functions.h
(__gnu_debug::_Safe_iterator<>): Add declaration.
(__can_advance(_Ite, _Size)): New.
(__can_advance(const _Safe_iterator<>&, _Size)): Overload declaration.
* include/debug/functions.h
(__gnu_debug::_Safe_iterator<>): Remove declaration.
* include/debug/stl_iterator.h
(__can_advance(const _Safe_iterator<>&)): New definition.
* include/debug/stl_iterator.h
(__can_advance(const std::reverse_iterator<>&, _Size)): New.
(__can_advance(const std::move_iterator<>&, _Size)): New.
* include/debug/macros.h (__glibcxx_check_can_increment): New.
* include/debug/debug.h (__glibcxx_requires_can_increment): New.
* include/bits/stl_algobase.h (fill_n): Use latter.
* testsuite/25_algorithms/fill_n/2.cc: New.
* testsuite/25_algorithms/fill_n/debug/1_neg.cc: New.
* testsuite/25_algorithms/fill_n/debug/2_neg.cc: New.
* testsuite/25_algorithms/fill_n/debug/3_neg.cc: New.
* testsuite/25_algorithms/fill_n/debug/4_neg.cc: New.
Tested under linux x86_64, normal and debug modes.
Now I understand why applying the patch in the first place failed.
François
On 13/06/2018 15:24, Jonathan Wakely wrote:
On 13/06/18 13:42 +0200, Paolo Carlini wrote:
Hi,
On 13/06/2018 08:11, François Dumont wrote:
On 12/06/2018 23:26, Martin Sebor wrote:
Bootstrap fails in libstdc++ with the following error.
I haven't investigated it much except to take a peek
at recent libstdc++ commits where r261525 looks like it
introduced __glibcxx_check_can_increment_range, so it
seems like it might have something to do with it. I don't
see a __glibcxx_requires_can_increment_range macro defined
anywhere in the patch so maybe it's a typo? Francois, can
you please see what's going on?
/opt/notnfs/msebor/build/gcc-86114/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/stl_algobase.h:452:45:
error: ‘__glibcxx_requires_can_increment_range’ was not declared in
this scope
__glibcxx_requires_can_increment_range(__first, __last,
__result);
Thanks
Martin
.
I had missed the fact that the patch didn't apply correctly on
include/debug/debug.h as stated in the ChangeLog entry.
It is fixed now.
But even after r261537 we are seeing the regressions:
FAIL: g++.dg/warn/pr31246.C -std=gnu++11 (test for excess errors)
FAIL: g++.dg/warn/pr31246.C -std=gnu++14 (test for excess errors)
FAIL: g++.dg/warn/pr31246.C -std=gnu++98 (test for excess errors)
Which definitely are related.
And failing Debug Mode tests:
FAIL: 20_util/hash/84998.cc (test for excess errors)
FAIL: 23_containers/vector/cons/destructible_debug_neg.cc (test for
excess errors)
FAIL: 25_algorithms/binary_search/partitioned.cc (test for excess errors)
FAIL: 25_algorithms/equal_range/partitioned.cc (test for excess errors)
FAIL: 25_algorithms/lexicographical_compare/71545.cc (test for excess
errors)
FAIL: 25_algorithms/lower_bound/partitioned.cc (test for excess errors)
FAIL: 25_algorithms/upper_bound/partitioned.cc (test for excess errors)
FAIL: ext/profile/mutex_extensions_neg.cc (test for excess errors)
The logs show:
/home/jwakely/src/gcc/build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/stl_algobase.h:452:
error: '__can_advance' is not a member of '__gnu_debug'
/home/jwakely/src/gcc/build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/stl_algobase.h:484:
error: '__can_advance' is not a member of '__gnu_debug'
/home/jwakely/src/gcc/build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/stl_algobase.h:629:
error: '__can_advance' is not a member of '__gnu_debug'
/home/jwakely/src/gcc/build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/stl_algobase.h:664:
error: '__can_advance' is not a member of '__gnu_debug'
diff --git a/libstdc++-v3/include/bits/stl_algobase.h b/libstdc++-v3/include/bits/stl_algobase.h
index 877f32b..022a3f1 100644
--- a/libstdc++-v3/include/bits/stl_algobase.h
+++ b/libstdc++-v3/include/bits/stl_algobase.h
@@ -783,6 +783,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
{
// concept requirements
__glibcxx_function_requires(_OutputIteratorConcept<_OI, _Tp>)
+ __glibcxx_requires_can_increment(__first, __n);
return _OI(std::__fill_n_a(std::__niter_base(__first), __n, __value));
}
diff --git a/libstdc++-v3/include/debug/debug.h b/libstdc++-v3/include/debug/debug.h
index d055dcb..f157a6d 100644
--- a/libstdc++-v3/include/debug/debug.h
+++ b/libstdc++-v3/include/debug/debug.h
@@ -62,6 +62,7 @@ namespace __gnu_debug
# define __glibcxx_requires_cond(_Cond,_Msg)
# define __glibcxx_requires_valid_range(_First,_Last)
+# define __glibcxx_requires_can_increment(_First,_Size)
# define __glibcxx_requires_can_increment_range(_First1,_Last1,_First2)
# define __glibcxx_requires_can_decrement_range(_First1,_Last1,_First2)
# define __glibcxx_requires_sorted(_First,_Last)
@@ -88,6 +89,8 @@ namespace __gnu_debug
# define __glibcxx_requires_cond(_Cond,_Msg) _GLIBCXX_DEBUG_VERIFY(_Cond,_Msg)
Re: -v should print also the revision number in repo
U.Mutlu wrote on 06/13/2018 10:26 PM: Andrew Pinski wrote on 06/13/2018 10:06 PM: On Wednesday, June 13, 2018, U.Mutlu mailto:u...@mutluit.com>> wrote: Hi, currently -v (ie. gcc -v) prints these data: gcc version 9.0.0 20180613 (experimental) (GCC) It would be nice, when building from a repository that then the resulting target should contain also the revision number (for example "r261543") of the underlying repository, so that gcc -v then prints this info as well. Maybe the respective revision nbr of the repository used (svn, git, ...), or perhaps better: a new generic solution with a unique & common rev-nbr for all repos (and non-repos): a new file with rev-info in the repo-root could do the trick, IMO... If you use contrib/gcc_update, it will place the right thing in the needed file and will display the revision. Ah, cool! Will try it out, thx. Ok, it worked like a charm: gcc version 9.0.0 20180613 (experimental) [trunk revision 261570] (GCC)
gcc-6-20180613 is now available
Snapshot gcc-6-20180613 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/6-20180613/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 6 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-6-branch revision 261574 You'll find: gcc-6-20180613.tar.xzComplete GCC SHA256=072cce71e59e01ad7ce2d833bdb3c2137153f0dccf89f982a7a4d6ee11fdb5c0 SHA1=244cd011543a0c0da19c9c20a60fcfc04ba08086 Diffs from 6-20180606 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-6 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
