Re: LTO problems with -fprofile-generate (aarch64)
> Hi,
>
> I have problems compiling xalan as part of spec2006 benchmark for aarch64,
> both native and cross.
> The issue arises when both -flto and -fprofile-generate are enabled during
> LTO.
> Compiling with the same flags for x86 has no problem.
> Also other projects for aarch64 compile with -flto and -fprofile-generate
> without problem.
>
> lto1: internal compiler error: in add_symbol_to_partition_1, at
> lto/lto-partition.c:210
>
> 204 /* Ensure that SAME_COMDAT_GROUP lists all allways added in a group.
> */
> 205 if (node->same_comdat_group)
> 206 for (node1 = node->same_comdat_group;
> 207 node1 != node; node1 = node1->same_comdat_group)
> 208 if (!node->alias)
> 209 {
> 210 bool added = add_symbol_to_partition_1 (part, node1);
> 211 gcc_assert (added);
> 212 }
> 213 return true;
> 214 }
>
> Is this a known issue? How can I debug this? Do I need additional options?
> Any hints?
I am not aware of similar PR. Can you please just fill in an PR and attach
dumps of
-fdump-ipa-cgraph
I think the bug is quite obivous - the function recurses to
add_symbol_to_partition_1
and if you have more than 2 symbols in a group it needs to ICE, but I would
like to double
check it is indeed the case.
You can just rmeove the assert to see if it lets things to compile well.
Honza
>
>
> I get this error:
>
> lto1: internal compiler error: in add_symbol_to_partition_1, at
> lto/lto-partition.c:210
> 0x484349 add_symbol_to_partition_1
>
> /home/bhuber/sandbox/gcc/toolchain-build-scripts/buildroot/../src/gcc/gcc/lto/lto-partition.c:210
> 0x48442d add_symbol_to_partition_1
>
> /home/bhuber/sandbox/gcc/toolchain-build-scripts/buildroot/../src/gcc/gcc/lto/lto-partition.c:182
> 0x48442d add_symbol_to_partition_1
>
> /home/bhuber/sandbox/gcc/toolchain-build-scripts/buildroot/../src/gcc/gcc/lto/lto-partition.c:182
> 0x48442d add_symbol_to_partition_1
>
> /home/bhuber/sandbox/gcc/toolchain-build-scripts/buildroot/../src/gcc/gcc/lto/lto-partition.c:182
> 0x484403 add_symbol_to_partition_1
>
> /home/bhuber/sandbox/gcc/toolchain-build-scripts/buildroot/../src/gcc/gcc/lto/lto-partition.c:180
> 0x4854a1 lto_balanced_map(int)
>
> /home/bhuber/sandbox/gcc/toolchain-build-scripts/buildroot/../src/gcc/gcc/lto/lto-partition.c:549
> 0x47e277 do_whole_program_analysis
>
> /home/bhuber/sandbox/gcc/toolchain-build-scripts/buildroot/../src/gcc/gcc/lto/lto.c:3297
> 0x47e277 lto_main()
>
> /home/bhuber/sandbox/gcc/toolchain-build-scripts/buildroot/../src/gcc/gcc/lto/lto.c:3451
> Please submit a full bug report,
> with preprocessed source if appropriate.
> Please include the complete backtrace with any bug report.
> See for instructions.
> lto-wrapper: fatal error:
> /home/bhuber/sandbox/gcc/toolchain-build-scripts/buildroot-upstream/upstream-le/install/opt/for-aarch64/upstream-le/bin/aarch64-for-linux-gnu-g++
> returned 1 exit status
> compilation terminated.
> collect2: fatal error: lto-wrapper returned 1 exit status
> compilation terminated.
>
>
> I am using a very recent 5.0 based gcc:
>
> commit e0eaf9732ae973d6204928da23a954683dcfe304
> Author: edlinger
> Date: Sun Feb 22 19:38:53 2015 +
>
> 2015-02-22 Bernd Edlinger
>
> PR fortran/64980
> PR fortran/61960
> * trans-expr.c (gfc_apply_interface_mapping_to_expr): Remove
> mapping
> for component references to class objects.
> (gfc_conv_procedure_call): Compare the class by name.
>
> testsuite:
> 2015-02-22 Bernd Edlinger
>
> PR fortran/64980
> PR fortran/61960
> * gfortran.dg/pr61960.f90: New.
> * gfortran.dg/pr64230.f90: New.
> * gfortran.dg/pr64980.f03: New.
>
>
> git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@220899
> 138bc75d-0d04-0410-961f-82ee72b054a4
>
>
> Compilation command is (same for all *.cpp):
>
> /home/bhuber/sandbox/gcc/toolchain-build-scripts/buildroot-upstream/upstream-le/install/opt/for-aarch64/upstream-le/bin/aarch64-for-linux-gnu-g++
> -c -O3 -flto=8
> -I/home/bhuber/sandbox/spec/cpu2006/benchspec/CPU2006/483.xalancbmk/src
> -I/home/bhuber/sandbox/spec/cpu2006/benchspec/CPU2006/483.xalancbmk/src/xercesc
> -I/home/bhuber/sandbox/spec/cpu2006/benchspec/CPU2006/483.xalancbmk/src/xercesc/dom
> -I/home/bhuber/sandbox/spec/cpu2006/benchspec/CPU2006/483.xalancbmk/src/xercesc/dom/impl
> -I/home/bhuber/sandbox/spec/cpu2006/benchspec/CPU2006/483.xalancbmk/src/xercesc/sax
> -I/home/bhuber/sandbox/spec/cpu2006/benchspec/CPU2006/483.xalancbmk/src/xercesc/util/MsgLoaders/InMemory
> -I/home/bhuber/sandbox/spec/cpu2006/benchspec/CPU2006/483.xalancbmk/src/xercesc/util/Transcoders/Iconv
> -I/home/bhuber/sandbox/spec/cpu2006/benchspec/CPU2006/483.xalancbmk/src/xalanc/include
> -DSPEC_CPU_LP64 -DSPEC_CPU_LINUX -DNDEBUG -DSPEC_CPU -DAPP_NO_THREADS
> -DXALAN_INMEM_MSG_
Re: need help with Pointer Bounds Checking documentation
On 02/25/2015 12:56 AM, Ilya Enkovich wrote: 2015-02-24 19:47 GMT+03:00 Sandra Loosemore : Poking around, I see that the -fcheck-pointer-bounds and various -fchkp-* options are listed in c-family/c.opt, but they are not listed in the GCC manual. The section on intrinsics is not enough, by itself, to tell users how to use this feature. Can we please try to get in the documentation for the options that have been implemented so far? That's a requirement of the GCC coding conventions. I see Joseph already brought up the issue of missing documentation back in November: https://gcc.gnu.org/ml/gcc-patches/2014-11/msg01566.html But I cannot find any proposed documentation patch for these options either. Here it is: https://gcc.gnu.org/ml/gcc-patches/2014-11/msg03010.html From that thread, it looks like Jeff Law already approved the code changes in the patch. Were you waiting for a documentation maintainer to approve the new documentation before committing it? I can see that it needs copy-editing and am willing to help with that, but I'd rather not mix that up in the same patch with code changes I don't know how to test. Or were the bundled code changes withdrawn for some reason? I think it's important that the already-committed new command-line options be documented, so we need to separate that out if necessary and get it checked in. -Sandra
Re: need help with Pointer Bounds Checking documentation
2015-02-25 19:16 GMT+03:00 Sandra Loosemore : > On 02/25/2015 12:56 AM, Ilya Enkovich wrote: >> >> 2015-02-24 19:47 GMT+03:00 Sandra Loosemore : >>> >>> >>> Poking around, I see that the -fcheck-pointer-bounds and various -fchkp-* >>> options are listed in c-family/c.opt, but they are not listed in the GCC >>> manual. The section on intrinsics is not enough, by itself, to tell >>> users >>> how to use this feature. Can we please try to get in the documentation >>> for >>> the options that have been implemented so far? That's a requirement of >>> the >>> GCC coding conventions. >>> >>> I see Joseph already brought up the issue of missing documentation back >>> in >>> November: >>> >>> https://gcc.gnu.org/ml/gcc-patches/2014-11/msg01566.html >>> >>> But I cannot find any proposed documentation patch for these options >>> either. >> >> >> Here it is: https://gcc.gnu.org/ml/gcc-patches/2014-11/msg03010.html > > > From that thread, it looks like Jeff Law already approved the code changes > in the patch. Were you waiting for a documentation maintainer to approve > the new documentation before committing it? I can see that it needs > copy-editing and am willing to help with that, but I'd rather not mix that > up in the same patch with code changes I don't know how to test. Or were > the bundled code changes withdrawn for some reason? I think it's important > that the already-committed new command-line options be documented, so we > need to separate that out if necessary and get it checked in. Patch is a part of a series which is waiting for additional steering committee approval due to copyright and a license. Ilya > > -Sandra >
Re: LTO problems with -fprofile-generate (aarch64)
Compiling with -flto-partition=none succeeds,
however increases compilation time significantly.
One interesting thing is that even the failed compile
produces an executable that works. Is that normal?
Should I really attach the ipa-cgraph dump to the bug report?
The file is 945M big, 27M compressed.
I could preprocess it to extract only the important data,
if you can tell me how.
Removing the assertion causes a segmentation fault.
I assume that this is not a good solution.
lto1: internal compiler error: Segmentation fault
0x8a865f crash_signal
/home/bhuber/sandbox/gcc/toolchain-build-scripts/buildroot-upstream/../src/gcc/gcc/toplev.c:383
0x721394 symbol_table::remove_unreachable_nodes(_IO_FILE*)
/home/bhuber/sandbox/gcc/toolchain-build-scripts/buildroot-upstream/../src/gcc/gcc/ipa.c:419
0x47e0c0 read_cgraph_and_symbols
/home/bhuber/sandbox/gcc/toolchain-build-scripts/buildroot-upstream/../src/gcc/gcc/lto/lto.c:3118
0x47e0c0 lto_main()
/home/bhuber/sandbox/gcc/toolchain-build-scripts/buildroot-upstream/../src/gcc/gcc/lto/lto.c:3441
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See for instructions.
make: *** [/tmp/ccIQbPRz.ltrans7.ltrans.o] Error 1
make: *** Waiting for unfinished jobs
lto-wrapper: fatal error: make returned 2 exit status
compilation terminated.
collect2: fatal error: lto-wrapper returned 1 exit status
compilation terminated.
On 25 Feb 2015, at 11:42, Jan Hubicka wrote:
>> Hi,
>>
>> I have problems compiling xalan as part of spec2006 benchmark for aarch64,
>> both native and cross.
>> The issue arises when both -flto and -fprofile-generate are enabled during
>> LTO.
>> Compiling with the same flags for x86 has no problem.
>> Also other projects for aarch64 compile with -flto and -fprofile-generate
>> without problem.
>>
>> lto1: internal compiler error: in add_symbol_to_partition_1, at
>> lto/lto-partition.c:210
>>
>> 204 /* Ensure that SAME_COMDAT_GROUP lists all allways added in a group.
>> */
>> 205 if (node->same_comdat_group)
>> 206 for (node1 = node->same_comdat_group;
>> 207 node1 != node; node1 = node1->same_comdat_group)
>> 208 if (!node->alias)
>> 209 {
>> 210 bool added = add_symbol_to_partition_1 (part, node1);
>> 211 gcc_assert (added);
>> 212 }
>> 213 return true;
>> 214 }
>>
>> Is this a known issue? How can I debug this? Do I need additional options?
>> Any hints?
>
> I am not aware of similar PR. Can you please just fill in an PR and attach
> dumps of
> -fdump-ipa-cgraph
> I think the bug is quite obivous - the function recurses to
> add_symbol_to_partition_1
> and if you have more than 2 symbols in a group it needs to ICE, but I would
> like to double
> check it is indeed the case.
>
> You can just rmeove the assert to see if it lets things to compile well.
>
> Honza
>>
>>
>> I get this error:
>>
>> lto1: internal compiler error: in add_symbol_to_partition_1, at
>> lto/lto-partition.c:210
>> 0x484349 add_symbol_to_partition_1
>>
>> /home/bhuber/sandbox/gcc/toolchain-build-scripts/buildroot/../src/gcc/gcc/lto/lto-partition.c:210
>> 0x48442d add_symbol_to_partition_1
>>
>> /home/bhuber/sandbox/gcc/toolchain-build-scripts/buildroot/../src/gcc/gcc/lto/lto-partition.c:182
>> 0x48442d add_symbol_to_partition_1
>>
>> /home/bhuber/sandbox/gcc/toolchain-build-scripts/buildroot/../src/gcc/gcc/lto/lto-partition.c:182
>> 0x48442d add_symbol_to_partition_1
>>
>> /home/bhuber/sandbox/gcc/toolchain-build-scripts/buildroot/../src/gcc/gcc/lto/lto-partition.c:182
>> 0x484403 add_symbol_to_partition_1
>>
>> /home/bhuber/sandbox/gcc/toolchain-build-scripts/buildroot/../src/gcc/gcc/lto/lto-partition.c:180
>> 0x4854a1 lto_balanced_map(int)
>>
>> /home/bhuber/sandbox/gcc/toolchain-build-scripts/buildroot/../src/gcc/gcc/lto/lto-partition.c:549
>> 0x47e277 do_whole_program_analysis
>>
>> /home/bhuber/sandbox/gcc/toolchain-build-scripts/buildroot/../src/gcc/gcc/lto/lto.c:3297
>> 0x47e277 lto_main()
>>
>> /home/bhuber/sandbox/gcc/toolchain-build-scripts/buildroot/../src/gcc/gcc/lto/lto.c:3451
>> Please submit a full bug report,
>> with preprocessed source if appropriate.
>> Please include the complete backtrace with any bug report.
>> See for instructions.
>> lto-wrapper: fatal error:
>> /home/bhuber/sandbox/gcc/toolchain-build-scripts/buildroot-upstream/upstream-le/install/opt/for-aarch64/upstream-le/bin/aarch64-for-linux-gnu-g++
>> returned 1 exit status
>> compilation terminated.
>> collect2: fatal error: lto-wrapper returned 1 exit status
>> compilation terminated.
>>
>>
>> I am using a very recent 5.0 based gcc:
>>
>> commit e0eaf9732ae973d6204928da23a954683dcfe304
>> Author: edlinger
>> Date: Sun Feb 22 19:38:53 2015 +
>>
>>2015-02-22 Bernd Edlinger
>>
>>PR fortran/64980
>>
Re: need help with Pointer Bounds Checking documentation
On 02/25/2015 09:47 AM, Ilya Enkovich wrote: 2015-02-25 19:16 GMT+03:00 Sandra Loosemore : On 02/25/2015 12:56 AM, Ilya Enkovich wrote: 2015-02-24 19:47 GMT+03:00 Sandra Loosemore : Poking around, I see that the -fcheck-pointer-bounds and various -fchkp-* options are listed in c-family/c.opt, but they are not listed in the GCC manual. The section on intrinsics is not enough, by itself, to tell users how to use this feature. Can we please try to get in the documentation for the options that have been implemented so far? That's a requirement of the GCC coding conventions. I see Joseph already brought up the issue of missing documentation back in November: https://gcc.gnu.org/ml/gcc-patches/2014-11/msg01566.html But I cannot find any proposed documentation patch for these options either. Here it is: https://gcc.gnu.org/ml/gcc-patches/2014-11/msg03010.html From that thread, it looks like Jeff Law already approved the code changes in the patch. Were you waiting for a documentation maintainer to approve the new documentation before committing it? I can see that it needs copy-editing and am willing to help with that, but I'd rather not mix that up in the same patch with code changes I don't know how to test. Or were the bundled code changes withdrawn for some reason? I think it's important that the already-committed new command-line options be documented, so we need to separate that out if necessary and get it checked in. Patch is a part of a series which is waiting for additional steering committee approval due to copyright and a license. I don't imagine the documentation for *features already committed* needs to wait for steering committee approval; per the GCC coding standards, it should have been checked in at the same time as the features themselves. Can you please split that out from the rest of the patch series so we can get it in? -Sandra
Re: How to update reg_dead notes
Am 02/24/2015 um 07:33 PM schrieb Kenneth Zadeck:
when i suggested that you do a build with all of the checking turned on, i
wanted you to this without you new code in it.there is a good possibility
that the problem is that your port is generating bad rtl.
Ah, ok. This actually revealed an ice-checking; but that was not related to
the df problems...
I think the problem was that I tried to run passes needing df after free_cfg.
My current solution works so far: It fixes the test case (correct code + insn
lengths) and it did not ICE up to now.
Stuff is running a bit slow with all checks on so building and running tests
will take a while...
FYI, you find my current patch attached.
Thanks for your help and time,
Johann
Index: config/avr/avr.c
===
--- config/avr/avr.c(revision 220963)
+++ config/avr/avr.c(working copy)
@@ -51,6 +51,8 @@
#include "target-def.h"
#include "params.h"
#include "df.h"
+#include "context.h"
+#include "tree-pass.h"
/* Maximal allowed offset for an address in the LD command */
#define MAX_LD_OFFSET(MODE) (64 - (signed)GET_MODE_SIZE (MODE))
@@ -285,6 +287,58 @@ avr_to_int_mode (rtx x)
}
+static const pass_data avr_pass_data_recompute_notes =
+{
+ RTL_PASS, /* type */
+ "avr-xx", /* name (will be patched) */
+ OPTGROUP_NONE, /* optinfo_flags */
+ false, /* has_gate */
+ true, /* has_execute */
+ TV_DF_SCAN, /* tv_id */
+ 0, /* properties_required */
+ 0, /* properties_provided */
+ 0, /* properties_destroyed */
+ 0, /* todo_flags_start */
+ (TODO_df_finish | TODO_verify_rtl_sharing
+ | TODO_verify_flow ), /* todo_flags_finish */
+};
+
+
+class avr_pass_recompute_notes : public rtl_opt_pass
+{
+public:
+ avr_pass_recompute_notes (gcc::context *ctxt, const char *pass_name)
+: rtl_opt_pass (avr_pass_data_recompute_notes, ctxt)
+ {
+name = pass_name;
+ }
+
+ unsigned int execute ()
+ {
+df_note_add_problem ();
+df_analyze ();
+
+return 0;
+ }
+}; // avr_pass_recompute_notes
+
+
+static void
+avr_register_passes (void)
+{
+ /* This avr-specific pass (re)computes insn notes, in particular REG_DEAD
+ notes which are used by `avr.c::reg_unused_after' and branch offset
+ computations. These notes must be correct, i.e. there must be no
+ dangling REG_DEAD notes; otherwise wrong code might result, cf. PR64331.
+
+ DF needs (correct) CFG, hence right before free_cfg is the last
+ opportunity to rectify notes. */
+
+ register_pass (new avr_pass_recompute_notes (g, "avr-notes-free-cfg"),
+ PASS_POS_INSERT_BEFORE, "*free_cfg", 1);
+}
+
+
/* Implement `TARGET_OPTION_OVERRIDE'. */
static void
@@ -346,6 +400,11 @@ avr_option_override (void)
init_machine_status = avr_init_machine_status;
avr_log_set_avr_log();
+
+ /* Register some avr-specific pass(es). There is no canonical place for
+ pass registration. This function is convenient. */
+
+ avr_register_passes ();
}
/* Function to set up the backend function structure. */
Re: How to update reg_dead notes
it is a good policy to do a run with full checking every once in a
while. it is easy to have some garbage sneak in.df is particularly
sensitive to bad rtl so that was my first suggestion.i had forgotten
that df (as well as a lot of the infrastructure) does not work very late.
On 02/25/2015 01:54 PM, Georg-Johann Lay wrote:
Am 02/24/2015 um 07:33 PM schrieb Kenneth Zadeck:
when i suggested that you do a build with all of the checking turned
on, i
wanted you to this without you new code in it.there is a good
possibility
that the problem is that your port is generating bad rtl.
Ah, ok. This actually revealed an ice-checking; but that was not
related to the df problems...
I think the problem was that I tried to run passes needing df after
free_cfg.
My current solution works so far: It fixes the test case (correct code
+ insn lengths) and it did not ICE up to now.
Stuff is running a bit slow with all checks on so building and running
tests will take a while...
FYI, you find my current patch attached.
Thanks for your help and time,
Johann
Index: config/avr/avr.c
===
--- config/avr/avr.c(revision 220963)
+++ config/avr/avr.c(working copy)
@@ -51,6 +51,8 @@
#include "target-def.h"
#include "params.h"
#include "df.h"
+#include "context.h"
+#include "tree-pass.h"
/* Maximal allowed offset for an address in the LD command */
#define MAX_LD_OFFSET(MODE) (64 - (signed)GET_MODE_SIZE (MODE))
@@ -285,6 +287,58 @@ avr_to_int_mode (rtx x)
}
+static const pass_data avr_pass_data_recompute_notes =
+{
+ RTL_PASS, /* type */
+ "avr-xx", /* name (will be patched) */
+ OPTGROUP_NONE, /* optinfo_flags */
+ false, /* has_gate */
+ true, /* has_execute */
+ TV_DF_SCAN, /* tv_id */
+ 0, /* properties_required */
+ 0, /* properties_provided */
+ 0, /* properties_destroyed */
+ 0, /* todo_flags_start */
+ (TODO_df_finish | TODO_verify_rtl_sharing
+ | TODO_verify_flow ), /* todo_flags_finish */
+};
+
+
+class avr_pass_recompute_notes : public rtl_opt_pass
+{
+public:
+ avr_pass_recompute_notes (gcc::context *ctxt, const char *pass_name)
+: rtl_opt_pass (avr_pass_data_recompute_notes, ctxt)
+ {
+name = pass_name;
+ }
+
+ unsigned int execute ()
+ {
+df_note_add_problem ();
+df_analyze ();
+
+return 0;
+ }
+}; // avr_pass_recompute_notes
+
+
+static void
+avr_register_passes (void)
+{
+ /* This avr-specific pass (re)computes insn notes, in particular
REG_DEAD
+ notes which are used by `avr.c::reg_unused_after' and branch offset
+ computations. These notes must be correct, i.e. there must be no
+ dangling REG_DEAD notes; otherwise wrong code might result, cf.
PR64331.
+
+ DF needs (correct) CFG, hence right before free_cfg is the last
+ opportunity to rectify notes. */
+
+ register_pass (new avr_pass_recompute_notes (g, "avr-notes-free-cfg"),
+ PASS_POS_INSERT_BEFORE, "*free_cfg", 1);
+}
+
+
/* Implement `TARGET_OPTION_OVERRIDE'. */
static void
@@ -346,6 +400,11 @@ avr_option_override (void)
init_machine_status = avr_init_machine_status;
avr_log_set_avr_log();
+
+ /* Register some avr-specific pass(es). There is no canonical
place for
+ pass registration. This function is convenient. */
+
+ avr_register_passes ();
}
/* Function to set up the backend function structure. */
Announcing Ilya Enkovich as bounded pointer/MPX maintainer and MPX runtime maintainer
I'm pleased to announce Ilya Enkovich has been appointed as the maintainer for the generic bounded pointer infrastructure, the MPX implementation of bounded pointers and the MPX runtime for GCC. Ilya, if you could add yourself to the MAINTAINERS file in the additional roles, it would be appreciated. I believe you have a patch or two to self-approve ;-) We'll discuss inclusion of the MPX runtime for GCC 5 separately with the release managers. We may be too late in the game to make that happen. So please don't commit the MPX runtime bits yet. Jeff
Announcing Kirill Yukhin as x86 vector ISA extension maintainer
I'm pleased to announce that Kirill Yukhin has been appointed as the maintainer for the vector ISA extensions for the x86 port. Kirill, if you could add yourself to the MAINTAINERS file for the additional role, it would be appreciated. Thanks, Jeff
MPX runtime inclusion for GCC 5
So the steering committee has agreed to include the MPX runtime in GCC. The runtime bits are a necessary component to actually make use of the MPX capabilities. GCC is a downstream consumer of the core runtime and the canonical repository for the wrapper subpart of that runtime. The question is whether or not to try and get the MPX runtime integrated for GCC 5 or wait until the next stage 1. I'm hesitant to add at this stage, but if we could limit it to only building on host/target combinations where we know it works, then perhaps including it might make sense as it'll be easier for developers who want to take advantage of MPX to get everything they need from the GCC release rather than stitching things together from multiple locations. Jakub, Joseph & Richi have the final say here for inclusion in GCC 5. Jeff
gcc-4.9-20150225 is now available
Snapshot gcc-4.9-20150225 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.9-20150225/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.9 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_9-branch revision 220992 You'll find: gcc-4.9-20150225.tar.bz2 Complete GCC MD5=13644c34c38387517b87ca054e04cf6b SHA1=a1829c8802e613789e2c30705ebca09d63eaac75 Diffs from 4.9-20150218 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.9 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.
Re: need help with Pointer Bounds Checking documentation
On Wed, 25 Feb 2015, Sandra Loosemore wrote: >> Patch is a part of a series which is waiting for additional steering >> committee approval due to copyright and a license. > I don't imagine the documentation for *features already committed* > needs to wait for steering committee approval; per the GCC coding > standards, it should have been checked in at the same time as the > features themselves. Agreed. (As for the overall patch set, this was pinged and hopefully will be resolved swiftly now as well. Still, adding documentation for things already in the tree makes sense now.) Gerald
