PR tree-optimization/91940
* tree-vect-patterns.c: Include tree-vector-builder.h and
vec-perm-indices.h.
(vect_recog_rotate_pattern): Also handle __builtin_bswap16, either by
unpromoting the argument back to uint16_t, or by converting into a
rotate, or into shifts plus ior.
* gcc.dg/vect/vect-bswap16.c: Add -msse4 on x86, run on all targets,
expect vectorized 1 loops message on both vect_bswap and sse4_runtime
targets.
* gcc.dg/vect/vect-bswap16a.c: New test.
From-SVN: r276442
One effect of https://gcc.gnu.org/ml/gcc-patches/2019-09/msg00802.html
was to strengthen the sanity check in lra_assigns so that it checks
whether reg_renumber is consistent with the whole conflict set.
This duly tripped on csky for a pseudo that had been allocated
to the eliminated frame pointer. (csky doesn't have a separate
hard frame pointer.)
lra-lives uses:
/* Set of hard regs (except eliminable ones) currently live. */
static HARD_REG_SET hard_regs_live;
to track the set of live directly-referenced hard registers, and it
correctly implements the exclusion when setting up the initial set:
hard_regs_live &= ~eliminable_regset;
But later calls to make_hard_regno_live and make_hard_regno_dead
would process eliminable registers like other registers, recording
conflicts for them and potentially making them live. (Note that
after r266086, make_hard_regno_dead adds conflicts for registers
that are already marked dead.) I think this would have had the
effect of pessimising targets without a separate hard frame pointer.
2019-10-02 Richard Sandiford <richard.sandiford@arm.com>
gcc/
PR middle-end/91957
* lra-lives.c (make_hard_regno_dead): Don't record conflicts for
eliminable registers.
(make_hard_regno_live): Likewise, and don't make them live.
From-SVN: r276440
2019-10-01 Jerry DeLisle <jvdelisle@gcc.gnu.org>
PR libfortran/91593
* io/read.c (read_decimal): Cast constant to size_t to turn off
a bogus warning.
* io/write.c (btoa_big): Use memset in lieu of setting the null
byte in a string buffer to turn off a bogus warning.
From-SVN: r276439
As part of adding [[]]-style attributes, C2x adds the token :: for use
in scoped attribute names.
This patch adds corresponding support for that token in C to GCC. The
token is supported both for C2x and for older gnu* standards (on the
basis that extensions are normally supported in older gnu* versions;
people will expect to be able to use [[]] attributes, before C2x is
the default, without needing to use -std=gnu2x).
There are no cases in older C standards where the token : can be
followed by a token starting with : in syntactically valid sources;
the only cases the :: token could break in older standard C thus are
ones involving concatenation of pp-tokens where the result does not
end up as tokens (e.g., gets stringized). In GNU C extensions, the
main case where :: might appear in existing sources is in asm
statements, and the C parser is thus made to handle it like two
consecutive : tokens, which the C++ parser already does. A limited
test of various positionings of :: in asm statements is added to the
testsuite (in particular, to cover the syntax error when :: means too
many colons but a single : would be OK), but existing tests cover a
variety of styles there anyway.
Technically there are cases in Objective-C and OpenMP for which this
also changes how previously valid code is lexed: the objc-selector-arg
syntax allows multiple consecutive : tokens (although I don't think
they are particularly useful there), while OpenMP syntax includes
array section syntax such as [:] which, before :: was a token, could
also be written as [::> (there might be other OpenMP cases potentially
affected, I didn't check all the OpenMP syntax in detail). I don't
think either of those cases affects the basis for supporting the ::
token in all -std=gnu* modes, or that there is any obvious need to
special-case handling of CPP_SCOPE tokens for those constructs the way
there is for asm statements.
cpp_avoid_paste, which determines when spaces need adding between
tokens in preprocessed output where there wouldn't otherwise be
whitespace between them (e.g. if stringized), already inserts space
between : and : unconditionally, rather than only for C++, so no
change is needed there (but a C2x test is added that such space is
indeed inserted).
Bootstrapped with no regressions on x86-64-pc-linux-gnu.
gcc/c:
* c-parser.c (c_parser_asm_statement): Handle CPP_SCOPE like two
CPP_COLON tokens.
gcc/testsuite:
* gcc.dg/asm-scope-1.c, gcc.dg/cpp/c11-scope-1.c,
gcc.dg/cpp/c17-scope-1.c, gcc.dg/cpp/c2x-scope-1.c,
gcc.dg/cpp/c2x-scope-2.c, gcc.dg/cpp/c90-scope-1.c,
gcc.dg/cpp/c94-scope-1.c, gcc.dg/cpp/c99-scope-1.c,
gcc.dg/cpp/gnu11-scope-1.c, gcc.dg/cpp/gnu17-scope-1.c,
gcc.dg/cpp/gnu89-scope-1.c, gcc.dg/cpp/gnu99-scope-1.c: New tests.
libcpp:
* include/cpplib.h (struct cpp_options): Add member scope.
* init.c (struct lang_flags, lang_defaults): Likewise.
(cpp_set_lang): Set scope member of pfile.
* lex.c (_cpp_lex_direct): Test CPP_OPTION (pfile, scope) not
CPP_OPTION (pfile, cplusplus) for creating CPP_SCOPE tokens.
From-SVN: r276434
Previously, diagnostic_show_locus saved and restored the pretty_printer's
prefix, clearing it for the duration of the call.
I have a patch kit in development that can benefit from applying a prefix
to the output of d_s_l, so this patch adds support to d_s_l for printing
such prefixes.
It moves the save and restore of the pp's prefix from d_s_l to all of its
callers, and updates diagnostic-show-locus.c to properly handle prefixes.
gcc/c-family/ChangeLog:
* c-opts.c (c_diagnostic_finalizer): Temporarily clear prefix when
calling diagnostic_show_locus, rather than destroying it afterwards.
gcc/ChangeLog:
* diagnostic-show-locus.c (layout::print_gap_in_line_numbering):
Call pp_emit_prefix.
(layout::print_source_line): Likewise.
(layout::start_annotation_line): Likewise.
(diagnostic_show_locus): Remove call to temporarily clear the
prefix.
(selftest::test_one_liner_fixit_remove): Add test coverage for the
interaction of pp_set_prefix with rulers and fix-it hints.
* diagnostic.c (default_diagnostic_finalizer): Temporarily clear
prefix when calling diagnostic_show_locus, rather than destroying
it afterwards.
(print_parseable_fixits): Temporarily clear prefix.
* pretty-print.c (pp_format): Save and restore line_length, rather
than assuming it is zero.
(pp_output_formatted_text): Remove assertion that line_length is
zero.
gcc/fortran/ChangeLog:
* error.c (gfc_diagnostic_starter): Clear the prefix before
calling diagnostic_show_locus.
gcc/testsuite/ChangeLog:
* gcc.dg/plugin/diagnostic_group_plugin.c (test_begin_group_cb):
Clear the prefix before emitting the "END GROUP" line.
* gcc.dg/plugin/diagnostic_plugin_test_show_locus.c
(custom_diagnostic_finalizer): Temporarily clear prefix when
calling diagnostic_show_locus, rather than destroying it
afterwards.
From-SVN: r276433
This makes the __parallel::equal and __parallel:lexicographical_compare
algorithms usable in constant expressions, by dispatching to the
sequential algorithm when calling during constant evaluation.
* include/parallel/algobase.h (equal, lexicographical_compare): Add
_GLIBCXX20_CONSTEXPR and dispatch to sequential algorithm when being
constant evaluated.
* include/parallel/algorithmfwd.h (equal, lexicographical_compare):
Add _GLIBCXX20_CONSTEXPR.
From-SVN: r276431
Respect the `--enable-version-specific-runtime-libs' configuration
option in libada/, so that shared gnatlib libraries will be installed
in non-version-specific $(toolexeclibdir) if requested. In a
cross-compilation environment this helps setting up a consistent
sysroot, which can then be shared between the host and the target
system.
This lets one have `libgnarl-10.so' and `libgnat-10.so' installed in say
/usr/lib and /usr/$(target_alias)/lib for a native and a cross-build
respectively, rather than in /usr/lib/gcc/$(target_alias)/10.0.0/adalib.
Update the settings of $(toolexecdir) and $(toolexeclibdir), unused till
now, to keep the current arrangement in the version-specific case and
make the new option to be enabled by default, unlike with the other
target libraries, so as to keep existing people's build infrastructure
unaffected.
Of course if someone does use `--disable-version-specific-runtime-libs'
already, then the installation location of shared gnatlib libraries will
change, but presumably this is what they do want anyway as the current
situation where the option is ignored in libada/ only is an anomaly
really rather than one that is expected or desired.
gcc/ada/
* gcc-interface/Makefile.in (ADA_RTL_DSO_DIR): New variable.
(install-gnatlib): Use it in place of ADA_RTL_OBJ_DIR for shared
library installation.
libada/
* Makefile.in (toolexecdir, toolexeclibdir): New variables.
(LIBADA_FLAGS_TO_PASS): Add `toolexeclibdir'.
* configure.ac: Add `--enable-version-specific-runtime-libs'.
Update version-specific `toolexecdir' and `toolexeclibdir' from
ADA_RTL_OBJ_DIR from gcc/ada/gcc-interface/Makefile.in.
* configure: Regenerate.
From-SVN: r276424
For some reason, presumably historical, the `install-gnatlib' target for
the default multilib is invoked twice, once via the `ada.install-common'
target in `gcc/ada/gcc-interface/Make-lang.in' invoked from gcc/ and
again via the `install-libada' target in libada/.
Apart from doing the same twice this is actually harmful in sufficiently
parallelized `make' invocation, as the removal of old files performed
within the `install-gnatlib' recipe in the former case actually races
with the installation of new files done in the latter case, causing the
recipe to fail and abort, however non-fatally, having not completed the
installation of all the built files needed for the newly-built compiler
to work correctly.
This can be observed with a native `x86_64-linux-gnu' bootstrap:
make[4]: Entering directory '.../gcc/ada'
rm -rf .../lib/gcc/x86_64-linux-gnu/10.0.0/adalib
rm: cannot remove '.../lib/gcc/x86_64-linux-gnu/10.0.0/adalib': Directory not empty
make[4]: *** [gcc-interface/Makefile:512: install-gnatlib] Error 1
make[4]: Leaving directory '.../gcc/ada'
make[3]: *** [.../gcc/ada/gcc-interface/Make-lang.in:853: install-gnatlib] Error 2
make[2]: [.../gcc/ada/gcc-interface/Make-lang.in:829: ada.install-common] Error 2 (ignored)
which then causes missing files to be reported when an attempt is made
to use the newly-installed non-functional compiler to build a
`riscv-linux-gnu' cross-compiler:
(cd ada/bldtools/sinfo; gnatmake -q xsinfo ; ./xsinfo sinfo.h )
error: "ada.ali" not found, "ada.ads" must be compiled
error: "s-memory.ali" not found, "s-memory.adb" must be compiled
gnatmake: *** bind failed.
/bin/sh: ./xsinfo: No such file or directory
make[2]: *** [.../gcc/ada/Make-generated.in:45: ada/sinfo.h] Error 127
make[2]: Leaving directory '.../gcc'
make[1]: *** [Makefile:4369: all-gcc] Error 2
make[1]: Leaving directory '...'
make: *** [Makefile:965: all] Error 2
Depending on timing `.../lib/gcc/x86_64-linux-gnu/10.0.0/adainclude' may
cause an installation failure instead and the resulting compiler may be
non-functional in a different way.
Only invoke `install-gnatlib' from within gcc/ then if a legacy build
process is being used with libada disabled and gnatlib built manually
with `make -C gcc gnatlib'.
gcc/
* Makefile.in (gnat_install_lib): New variable.
* configure.ac: Substitute it.
* configure: Regenerate.
gcc/ada/
* gcc-interface/Make-lang.in (ada.install-common): Split into...
(gnat-install-tools, gnat-install-lib): ... these.
From-SVN: r276422
PR lto/91222
* ipa-devirt.c (warn_types_mismatch): Do not ICE when anonymous type
is matched with non-C++ type
* g++.dg/lto/odr-6_0.C: New testcase.
* g++.dg/lto/odr-6_1.c: New testcase.
From-SVN: r276420
s390.md uses a lot of near-identical expanders that perform dispatching
to other expanders based on operand types. Since the following patch
would require even more of these, avoid copy-pasting the code by
generating these expanders using an iterator.
gcc/ChangeLog:
2019-10-01 Ilya Leoshkevich <iii@linux.ibm.com>
PR target/77918
* config/s390/s390.c (s390_expand_vec_compare): Use
gen_vec_cmpordered and gen_vec_cmpunordered.
* config/s390/vector.md (vec_cmpuneq, vec_cmpltgt, vec_ordered,
vec_unordered): Delete.
(vec_ordered<mode>): Rename to vec_cmpordered<mode>.
(vec_unordered<mode>): Rename to vec_cmpunordered<mode>.
(VEC_CMP_EXPAND): New iterator for the generic dispatcher.
(vec_cmp<code>): Generic dispatcher.
From-SVN: r276409
Currently gcc does not emit wf{c,k}* instructions when comparing long
double values. Middle-end actually adds them in the first place, but
then veclower pass replaces them with floating point register pair
operations, because the corresponding expander is missing.
gcc/ChangeLog:
2019-10-01 Ilya Leoshkevich <iii@linux.ibm.com>
PR target/77918
* config/s390/vector.md (V_HW): Add V1TI in order to make
vcond$a$b generate vcondv1tiv1tf.
From-SVN: r276408
The code was passing a pseudo rather than its allocated hard reg
to ira_need_caller_save_p. Running under valgrind to reproduce
the failure also showed that ALLOCNO_CROSSED_CALLS_ABIS wasn't
being explicitly initialised.
2019-10-01 Richard Sandiford <richard.sandiford@arm.com>
gcc/
PR rtl-optimization/91948
* ira-build.c (ira_create_allocno): Initialize
ALLOCNO_CROSSED_CALLS_ABIS.
* ira-color.c (allocno_reload_assign): Pass hard_regno rather
than regno to ira_need_caller_save_p.
From-SVN: r276407
flag_omit_frame_pointer is set in machine-independent code depending
on the optimization level. It is then overridden in x86
target-specific code depending on a macro defined by
--enable-frame-pointer.
Uses of attribute optimize go through machine-independent overriding
of flag_omit_frame_pointer, but the x86-specific overriding code did
NOT cover this flag, so, even if the attribute does not change the
optimization level, flag_omit_frame_pointer may end up with a
different value, and prevent inlining because of incompatible flags,
as detected by the gcc.dg/ipa/iinline-attr.c test on an
--enable-frame-pointer x86 toolchain.
for gcc/ChangeLog
* config/i386/i386-options.c
(ix86_recompute_optlev_based_flags): New, moved out of...
(ix86_option_override_internal): ... this. Call it.
(ix86_override_options_after_change): Call it here too.
From-SVN: r276405
Optimizing gcc.dg/torture/pr41094.c, the compiler computes the
constant value and short-circuits the whole thing. At -O0, however,
on 32-bit x86, the call to pow() remains, and the program compares the
returned value in a stack register, with excess precision, with the
exact return value expected from pow(). If libm's pow() returns a
slightly off result, the compare fails. If the value in the register
is stored in a separate variable, so it gets rounded to double
precision, and then compared, the compare passes.
It's not clear that the test was meant to detect libm's reliance on
rounding off the excess precision, but I guess it wasn't, so I propose
this slight change that enables it to pass regardless of the slight
inaccuracy of the C library in use.
for gcc/testsuite/ChangeLog
* gcc.dg/torture/pr41094.c: Introduce intermediate variable.
From-SVN: r276404
A variable redeclaration or definition that provides additional type
information for it, e.g. outermost array bounds, is not reflected in
the debug information for the variable. With this patch, the debug
info of the variable specialization gets a type attribute with the
adjusted type.
This patch affects mostly only array bounds. However, when the
symbolic type used in a declaration and in a definition are different,
although they refer to the same type, debug information will end up
(correctly?) naming different symbolic types in the specification and
the definition. Also, when a readonly declaration of an array loses
the readonly flag at the definition because of the initializer, the
definition may end up referencing a type while the specification
refers to a const-qualified version of that type. If the type of the
variable is already const-qualified, e.g. an array of a const type,
the difference is meaningless.
for gcc/ChangeLog
PR debug/91507
* dwarf2out.c (override_type_for_decl_p): New.
(gen_variable_die): Use it.
for gcc/testsuite/ChangeLog
PR debug/91507
* gcc.dg/debug/dwarf2/array-0.c: New.
* gcc.dg/debug/dwarf2/array-1.c: New.
* gcc.dg/debug/dwarf2/array-2.c: New.
* gcc.dg/debug/dwarf2/array-3.c: New.
* g++.dg/debug/dwarf2/array-0.C: New.
* g++.dg/debug/dwarf2/array-1.C: New.
* g++.dg/debug/dwarf2/array-2.C: New. Based on libstdc++-v3's
src/c++98/pool_allocator.cc:__pool_alloc_base::_S_heap_size.
* g++.dg/debug/dwarf2/array-3.C: New. Based on
gcc's config/i386/i386-features.c:xlogue_layout::s_instances.
* g++.dg/debug/dwarf2/array-4.C: New.
From-SVN: r276403
The regrename pass temporarily changes some operand RTL to CC0 so that
note_stores and scan_rtx don't see those operands. CC0 is deprecated
and we want to remove it, so we need to use something else here.
PC fits the bill fine.
* regrename.c (hide_operands): Use pc_rtx instead of cc0_rtx.
(build_def_use): Use PC instead of CC0 in a comment.
From-SVN: r276401
diag-aka-1.c tests that:
struct T { int i; } T;
void *a;
T *t = a;
produces:
request for implicit conversion from 'void *' to 'T *' {aka 'struct T *'} ...
But printing an aka for the tag seems a bit redundant when the tag name
is the same as the typedef name. It's probably not going to be telling
the user anything they don't already know, and can be distracting if "T"
rather than "struct T" is the preferred choice for an exported interface.
This is even more true if the tag is anonymous; e.g.:
struct { int i; } T;
void *a;
T *t = a;
gives:
request for implicit conversion from 'void *' to 'T *' {aka 'struct <anonymous> *'}
Rather than just drop the test above, the patch instead tests for:
struct T { int i; } *T;
where seeing the tag definitely helps.
2019-10-01 Richard Sandiford <richard.sandiford@arm.com>
gcc/c/
* c-objc-common.c (useful_aka_type_p): New function.
(print_type): Use it to decide whether an aka type is worth printing.
gcc/testsuite/
* gcc.dg/diag-aka-1.c (T): Turn into a pointer typedef.
(foo): Update accordingly.
* gcc.dg/diag-aka-4.c: New test.
From-SVN: r276395
Given the following invalid arm_neon.h-based code:
float x;
int8x8_t y = x;
the error message we emit is pretty good:
incompatible types when initializing type 'int8x8_t' using type 'float'
But convert the types to pointers:
int8x8_t *ptr = &x;
and the message becomes:
initialization of '__vector(8) signed char *' from incompatible pointer type 'float *'
Although it's reasonably obvious what '__vector(8) signed char *' means,
it isn't valid C or C++ syntax and is quite far from what the user wrote,
so using 'int8x8_t *' would be better.
This patch therefore prints the type name of vectors that have one.
It's still OK to print the __vector syntax as an "aka", although I have
a follow-on patch to tweak this slightly for types defined in system
header files. The follow-on patch also addresses the ??? in
gcc.target/aarch64/diag_aka_1.c.
The C++ test already passed, but it seemed worth including for
consistency.
2019-10-01 Richard Sandiford <richard.sandiford@arm.com>
gcc/c-family/
* c-pretty-print.c (pp_c_specifier_qualifier_list): If a vector type
has a type name, use it in preference to the __vector syntax.
gcc/testsuite/
* gcc.dg/diag-aka-3.c: New test.
* gcc.target/aarch64/diag_aka_1.c: New test.
* g++.dg/diagnostic/aka4.C: New test.
From-SVN: r276394
One (unintended) side effect of the patches to support multiple
ABIs is that we can now represent tlsdesc calls as normal calls
on SVE targets. This is likely to be handled more efficiently than
clobber_high, and for example fixes the long-standing failure in
gcc.target/aarch64/sve/tls_preserve_1.c.
2019-10-01 Richard Sandiford <richard.sandiford@arm.com>
gcc/
PR target/91452
* config/aarch64/aarch64.h (ARM_PCS_TLSDESC): New arm_pcs.
* config/aarch64/aarch64-protos.h (aarch64_tlsdesc_abi_id): Declare.
* config/aarch64/aarch64.c (aarch64_hard_regno_call_part_clobbered):
Handle ARM_PCS_TLSDESC.
(aarch64_tlsdesc_abi_id): New function.
* config/aarch64/aarch64.md (tlsdesc_small_sve_<mode>): Use a call
rtx instead of a list of clobbers and clobber_highs.
(tlsdesc_small_<mode>): Update accordingly.
From-SVN: r276392
At the moment we rely on SYMBOL_REF_DECL to get the ABI of the callee
of a call insn, falling back to the default ABI if the decl isn't
available. I think it'd be cleaner to attach the ABI directly to the
call instruction instead, which would also have the very minor benefit
of handling indirect calls more efficiently.
2019-10-01 Richard Sandiford <richard.sandiford@arm.com>
gcc/
* config/aarch64/aarch64-protos.h (aarch64_expand_call): Take an
extra callee_abi argument.
* config/aarch64/aarch64.c (aarch64_expand_call): Likewise.
Insert a CALLEE_ABI unspec into the call pattern as the second
element in the PARALLEL.
(aarch64_simd_call_p): Delete.
(aarch64_insn_callee_abi): Get the arm_pcs of the callee from
the new CALLEE_ABI element of the PARALLEL.
(aarch64_init_cumulative_args): Get the arm_pcs of the callee
from the function type, if given.
(aarch64_function_arg_advance): Handle ARM_PCS_SIMD.
(aarch64_function_arg): Likewise. Return the arm_pcs of the callee
when passed the function_arg_info end marker.
(aarch64_output_mi_thunk): Pass the arm_pcs of the callee as the
final argument of gen_sibcall.
* config/aarch64/aarch64.md (UNSPEC_CALLEE_ABI): New unspec.
(call): Make operand 2 a const_int_operand and pass it to expand_call.
Wrap it in an UNSPEC_CALLEE_ABI unspec for the dummy define_expand
pattern.
(call_value): Likewise operand 3.
(sibcall): Likewise operand 2. Place the unspec before rather than
after the return.
(sibcall_value): Likewise operand 3.
(*call_insn, *call_value_insn): Include an UNSPEC_CALLEE_ABI.
(tlsgd_small_<mode>, *tlsgd_small_<mode>): Likewise.
(*sibcall_insn, *sibcall_value_insn): Likewise. Remove empty
constraint strings.
(untyped_call): Pass const0_rtx as the callee ABI to gen_call.
gcc/testsuite/
* gcc.target/aarch64/torture/simd-abi-10.c: New test.
* gcc.target/aarch64/torture/simd-abi-11.c: Likewise.
From-SVN: r276391
It says "size N/2" in a few places where "size S/2" is meant.
* doc/md.texi (vec_pack_trunc_@var{m}): Fix typo.
(vec_pack_sfix_trunc_@var{m}, vec_pack_ufix_trunc_@var{m}): Ditto.
(vec_packs_float_@var{m}, vec_packu_float_@var{m}): Ditto.
From-SVN: r276387
2019-09-30 Andreas Tobler <andreast@gcc.gnu.org>
* include/experimental/internet: Include netinet/in.h if we have
_GLIBCXX_HAVE_NETINET_IN_H defined.
From-SVN: r276374
This patch improves the handling of large numbers of labels within a
rich_location: previously, overlapping labels could lead to an assertion
failure within layout::print_any_labels. Also, the labels were printed
in reverse order of insertion into the rich_location.
This patch moves the determination of whether a vertical bar should
be printed for a line_label into the
'Figure out how many "label lines" we need, and which
one each label is printed in.'
step of layout::print_any_labels, rather than doing it as the lines
are printed. It also flips the sort order, so that labels at the
same line/column are printed in order of insertion into the
rich_location.
I haven't run into these issues with our existing diagnostics, but it
affects a patch kit I'm working on that makes more extensive use of
labels.
gcc/ChangeLog:
* diagnostic-show-locus.c (line_label::line_label): Initialize
m_has_vbar.
(line_label::comparator): Reverse the sort order by m_state_idx,
so that when the list is walked backwards the labels appear in
order of insertion into the rich_location.
(line_label::m_has_vbar): New field.
(layout::print_any_labels): When dealing with multiple labels at
the same line and column, only print vertical bars for the one
with the highest label_line.
(selftest::test_one_liner_labels): Update test for multiple labels
to expect the labels to be in the order of insertion into the
rich_location. Add a test for many such labels, where the column
numbers are out-of-order relative to the insertion order.
From-SVN: r276371
Richard Biener
Jakub Jelinek
Richard Sandiford
Jerry DeLisle
GCC Administrator
Joseph Myers
David Malcolm
Jonathan Wakely
Maciej W. Rozycki
Jan Hubicka
Maya Rashish
Prathamesh Kulkarni
Oleg Endo
William Schmidt
Ilya Leoshkevich
Alexandre Oliva
Segher Boessenkool
Frederik Harwath
Ian Lance Taylor
François Dumont
Andreas Tobler