The r12-5978 change caused a -fcompare-debug issue, because without
-g a chain might start with a noop move, but with -g there could be
one or more DEBUG_INSNs in the chain before the noop move and so
regrename could make different decisions between -g and -g0.
Note, I must say I don't really understand the original change much,
if we want to make sure the noop moves are removed, couldn't regrename
during building of those du chains simply remove the noop moves instead?
2021-12-30 Jakub Jelinek <jakub@redhat.com>
PR rtl-optimization/103756
* regrename.c (find_rename_reg): Test noop_move_p on the first
non-debug insn in the chain rather than on the first insn.
* g++.dg/opt/pr103756.C: New test.
In the following testcase we incorrectly error about pasting / token
with padding token (which is a result of __VA_OPT__); instead we should
like e.g. for ##arg where arg is empty macro argument clear PASTE_LEFT
flag of the previous token if __VA_OPT__ doesn't add any real tokens
(which can happen either because the macro doesn't have any tokens
passed to ... (i.e. __VA_ARGS__ expands to empty) or when __VA_OPT__
doesn't have any tokens in between ()s).
2021-12-30 Jakub Jelinek <jakub@redhat.com>
PR preprocessor/89971
libcpp/
* macro.c (replace_args): For ##__VA_OPT__, if __VA_OPT__ expands
to no tokens at all, drop PASTE_LEFT flag from the previous token.
gcc/testsuite/
* c-c++-common/cpp/va-opt-9.c: New test.
Currently libiberty fails to demangle the name of cloned functions if
the clone-type-identifier contains numbers.
This can be observed with the following example:
$ cat > ex.cc <<EOT
void foo (float *, float *)
__attribute__((target_clones("avx2,avx,sse4.1,default")));
void foo (float *, float *) {}
EOT
$ gcc -c ex.cc
$ nm -C ex.o | grep foo
0000000000000000 i foo(float*, float*)
0000000000000026 t foo(float*, float*) [clone .avx.1]
0000000000000013 t _Z3fooPfS_.avx2.0
0000000000000000 t foo(float*, float*) [clone .default.3]
0000000000000000 W foo(float*, float*) [clone .resolver]
0000000000000039 t _Z3fooPfS_.sse4_1.2
In this example, gcc creates clones for the FOO function, each matching
one of the specified targets. When inspecting the binary, nm (and other
libiberty-based tools, including gdb) fails to demangle the symbol names
if the clone identifier contains numbers.
Form my understanding of the mangling convention[1], clone names are
part of vendor-specific suffixes and do not have rule preventing them
from containing digits.
This commit proposes to fix the demangling. With this commit (ported to
binutils), nm gives the following output:
$ nm-new -C ex.o | grep foo
0000000000000000 i foo(float*, float*)
0000000000000026 t foo(float*, float*) [clone .avx.1]
0000000000000013 t foo(float*, float*) [clone .avx2.0]
0000000000000000 t foo(float*, float*) [clone .default.3]
0000000000000000 W foo(float*, float*) [clone .resolver]
0000000000000039 t foo(float*, float*) [clone .sse4_1.2]
Tested on x86_86-linux with 'make check-libiberty'.
[1] https://itanium-cxx-abi.github.io/cxx-abi/abi.html#mangling
libiberty/ChangeLog:
* cp-demangle.c (d_clone_suffix): Support digits in clone tag
names.
* testsuite/demangle-expected: Check demangling of clone symbols
with digits in name.
We get a -fcompare-debug FAIL on the following testcase. The problem is
that during cprop we get when a TImode pseudo holding x is being
constructed:
(debug_insn 111 59 103 7 (var_location:TI D#2 (clobber (const_int 0 [0]))) -1
(nil))
(insn 103 111 110 7 (clobber (reg/v:TI 89 [ x ])) "pr103808.c":8:9 -1
(nil))
(debug_insn 110 103 104 7 (var_location:TI D#2 (subreg:TI (reg:DI 111 [ x ]) 0)) -1
(nil))
(insn 104 110 109 7 (set (subreg:DI (reg/v:TI 89 [ x ]) 0)
(reg:DI 111 [ x ])) "pr103808.c":8:9 80 {*movdi_internal}
(expr_list:REG_DEAD (reg:DI 111 [ x ])
(nil)))
Now, during RA that paradoxical subreg in a debug insn obviously can't
affect where pseudo 111 is allocated and RA puts it into the bp register,
so we have:
(debug_insn 110 111 109 4 (var_location:TI D#2 (reg:TI 6 bp [orig:111 x ] [111])) -1
(nil))
Now, during var-tracking when we for:
(debug_insn 25 23 26 3 (var_location:TI x (concatn/v:TI [
(reg:DI 6 bp [orig:111 x ] [111])
(subreg:DI (debug_expr:TI D#2) 8)
])) "pr103808.c":8:9 -1
(nil))
try to simplify the highpart subreg of bp, gen_rtx_REG_offset is called in:
if (HARD_REGISTER_NUM_P (final_regno))
{
rtx x = gen_rtx_REG_offset (op, outermode, final_regno,
subreg_memory_offset (outermode,
innermode, byte));
and that unfortunately sets REG_ATTRS on stack_pointer_rtx, because
gen_rtx_REG_offset uses gen_rtx_REG which for Pmode STACK_POINTER_REGNUM
returns stack_pointer_rtx rather than newly created register.
The clobbering of REG_ATTRS on the shared stack_pointer_rtx then shows up
in the dumps as (reg/f:DI 7 sp [ x+8 ]) instead of (reg/f:DI 7 sp)
that shows up without var-tracking.
Clobbering of REG_ATTRS on the shared *_pointer_rtx looks just wrong.
So, IMHO either simplify_gen_subreg -> gen_rtx_REG_offset should call
gen_raw_REG to make sure we get a new non-shared REG we can set REG_ATTRS
on, or we should make sure that we don't overwrite the REG_ATTRS on the
shared REGs (but then simplify_gen_subreg shouldn't try to overwrite
ORIGINAL_REGNO on those either).
For non-DEBUG_INSNs, I'd hope this never happens, the RA shouldn't allocate
multi-word regs overlapping with stack pointer, hard frame pointer etc.
2021-12-30 Jakub Jelinek <jakub@redhat.com>
PR debug/103808
* emit-rtl.c (gen_rtx_REG_offset): Use gen_raw_REG instead of
gen_rtx_REG.
* gcc.dg/pr103808.c: New test.
The following testcases ICE when an optimize or target pragma
is followed by a long line (4096+ chars).
This is because on such long lines we can't use columns anymore,
but the cpp_define calls performed by c_cpp_builtins_optimize_pragma
or from the backend hooks for target pragma are done on temporary
buffers and expect to get columns from whatever line they appear on
(which happens to be the long line after optimize/target pragma),
and we run into:
#0 fancy_abort (file=0x3abec67 "../../libcpp/line-map.c", line=502, function=0x3abecfc "linemap_add") at ../../gcc/diagnostic.c:1986
#1 0x0000000002e7c335 in linemap_add (set=0x7ffff7fca000, reason=LC_RENAME, sysp=0, to_file=0x41287a0 "pr103012.i", to_line=3) at ../../libcpp/line-map.c:502
#2 0x0000000002e7cc24 in linemap_line_start (set=0x7ffff7fca000, to_line=3, max_column_hint=128) at ../../libcpp/line-map.c:827
#3 0x0000000002e7ce2b in linemap_position_for_column (set=0x7ffff7fca000, to_column=1) at ../../libcpp/line-map.c:898
#4 0x0000000002e771f9 in _cpp_lex_direct (pfile=0x40c3b60) at ../../libcpp/lex.c:3592
#5 0x0000000002e76c3e in _cpp_lex_token (pfile=0x40c3b60) at ../../libcpp/lex.c:3394
#6 0x0000000002e610ef in lex_macro_node (pfile=0x40c3b60, is_def_or_undef=true) at ../../libcpp/directives.c:601
#7 0x0000000002e61226 in do_define (pfile=0x40c3b60) at ../../libcpp/directives.c:639
#8 0x0000000002e610b2 in run_directive (pfile=0x40c3b60, dir_no=0, buf=0x7fffffffd430 "__OPTIMIZE__ 1\n", count=14) at ../../libcpp/directives.c:589
#9 0x0000000002e650c1 in cpp_define (pfile=0x40c3b60, str=0x2f784d1 "__OPTIMIZE__") at ../../libcpp/directives.c:2513
#10 0x0000000002e65100 in cpp_define_unused (pfile=0x40c3b60, str=0x2f784d1 "__OPTIMIZE__") at ../../libcpp/directives.c:2522
#11 0x0000000000f50685 in c_cpp_builtins_optimize_pragma (pfile=0x40c3b60, prev_tree=<optimization_node 0x7fffea042000>, cur_tree=<optimization_node 0x7fffea042020>)
at ../../gcc/c-family/c-cppbuiltin.c:600
assertion that LC_RENAME doesn't happen first.
I think the right fix is emit those predefined macros upon
optimize/target pragmas with BUILTINS_LOCATION, like we already do
for those macros at the start of the TU, they don't appear in columns
of the next line after it. Another possibility would be to force them
at the location of the pragma.
2021-12-30 Jakub Jelinek <jakub@redhat.com>
PR c++/103012
gcc/
* config/i386/i386-c.c (ix86_pragma_target_parse): Perform
cpp_define/cpp_undef calls with forced token locations
BUILTINS_LOCATION.
* config/arm/arm-c.c (arm_pragma_target_parse): Likewise.
* config/aarch64/aarch64-c.c (aarch64_pragma_target_parse): Likewise.
* config/s390/s390-c.c (s390_pragma_target_parse): Likewise.
gcc/c-family/
* c-cppbuiltin.c (c_cpp_builtins_optimize_pragma): Perform
cpp_define_unused/cpp_undef calls with forced token locations
BUILTINS_LOCATION.
gcc/testsuite/
PR c++/103012
* g++.dg/cpp/pr103012.C: New test.
* g++.target/i386/pr103012.C: New test.
The following testcase is miscompiled, because a prologue which
contains subq $8, %rsp instruction is emitted at the start of
a basic block which contains conditional jump that depends on
flags register set in an earlier basic block, the prologue instruction
then clobbers those flags.
Normally this case is checked by can_get_prologue predicate, but this
is done only at the start of the loop. If we update pro later in the
loop (because some bb shouldn't be duplicated) and then don't push
anything further into vec and the vec is already empty (this can happen
when the new pro is already in bb_with bitmask and either has no successors
(that is the case in the testcase where that bb ends with a trap) or
all the successors are already in bb_with, then the loop doesn't iterate
further and can_get_prologue will not be checked.
The following simple patch makes sure we call can_get_prologue even after
the last former iteration when vec is already empty and only break from
the loop afterwards (and only if the updating of pro done because of
!can_get_prologue didn't push anything into vec again).
2021-12-30 Jakub Jelinek <jakub@redhat.com>
PR rtl-optimization/103860
* shrink-wrap.c (try_shrink_wrapping): Make sure can_get_prologue is
called on pro even if nothing further is pushed into vec.
* gcc.dg/pr103860.c: New test.
Change the compiler to not add zero padding because of zero-sized
fields named "_", since those can't be referenced anyhow.
Change the sparc-linux64 epollevent struct to name the alignment
field "_", to avoid zero padding.
Fixes PR go/103847
PR go/103847
* godump.c (go_force_record_alignment): Name the alignment
field "_".
Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/374914
make_forwarders_with_degenerate_phis causes a -fcompare-debug failure on the
following testcase.
The problem is that on:
# iftmp.4_8 = PHI <&D.2582(6), &D.2583(4), &D.2582(7), &D.2583(5)>
the exact DECL_UIDs are different between -g and -g0 (which is ok, with -g
the decls can have larger gaps in between the uids), which means
iterative_hash_expr is different and because there are 2 pairs of edges
with matching phi arguments, the function processes them in different
orders.
The following patch fixes it by using the iterative_hash_expr order
only to determine which arguments are the same, then replaces the hashes
with the minimum dest_idx in the set of matching arguments and qsorts
again (which makes it stable for -fcompare-debug) and only splits edges etc.
on that stable order.
As a small optimization, if no arguments are equal, it doesn't do the
second qsort and continues, and if all arguments of the PHI are
constants or SSA_NAMEs (I think that is a pretty common case for many
PHIs), then it doesn't do the second qsort either, because in that case
the hash values will be stable, only computed from the constant values or
SSA_NAME_VERSIONs.
2021-12-29 Jakub Jelinek <jakub@redhat.com>
PR debug/103742
* tree-ssa-dce.c (make_forwarders_with_degenerate_phis): If any phi
argument is not CONSTANT_CLASS_P or SSA_NAME and any arguments are
equal, change second from hash value to lowest dest_idx from the
edges which have equal argument and resort to ensure -fcompare-debug
stability.
* g++.dg/opt/pr103742.C: New test.
Fortran 2018 added some synonyms to the existing values, namely
IEEE_NEGATIVE_SUBNORMAL (which is the same as IEEE_NEGATIVE_DENORMAL)
and IEEE_POSITIVE_SUBNORMAL (same as IEEE_POSITIVE_DENORMAL). When they
were added to the C side, they were not kept in sync with the Fortran
part of the library. Thew new values are not used (yet), so it is
currently harmless, but better fix it.
libgfortran/ChangeLog:
* ieee/ieee_helper.c: Fix enum values.
Warnings like:
warning: using serial compilation of 2 LTRANS jobs
warning: visibility attribute not supported in this configuration; ignored\[^\n\]*" $text "" text
are pruned by lto.exp, but not for LTO testcases when run in other parts
of the testsuite. They will be, now.
gcc/testsuite/ChangeLog:
PR testsuite/47334
PR testsuite/103823
* lib/prune.exp: Prune some warnings related to LTO and
visibility.
lowpart_subreg might fail in some cases when trying to create paradoxical
SUBREGs. Use force_reg on input operand, use new temporary output operand
and emit move into the destination afterwards.
Also, replace simplify_gen_subreg (Mx, op, My, 0)
with equivalent lowpart_subreg (Mx, op, My).
2021-12-29 Uroš Bizjak <ubizjak@gmail.com>
gcc/ChangeLog:
* config/i386/sse.md (vec_pack<floatprefix>_float_<mode>):
Perform gen_avx512dq_float<floatunssuffix>v2div2sf2 into a
pseudo and emit move insn into operands[0].
(fix<fixunssuffix>_truncv2sfv2di2): Use lowpart_subreg
instead of simplify_gen_subreg.
(trunc<mode><pmov_dst_3_lower>2): Perform
gen_avx512vl_truncate<mode>v<ssescalarnum>qi2 into a
pseudo and emit move insn into operands[0].
(trunc<mode><pmov_dst_4_lower>2): Perform
gen_avx512vl_truncate<mode>v<ssescalarnum>hi2 into a
pseudo and emit move insn into operands[0].
(truncv2div2si2): Perform gen_avx512vl_truncatev2div2si2 into a
pseudo and emit move insn into operands[0].
(truncv8div8qi2): Perform gen_avx512f_truncatev8div16qi2 into a
pseudo and emit move insn into operands[0].
(<any_extend:insn>v8qiv8hi2): Use lowpart_subreg
instead of simplify_gen_subreg.
(<any_extend:insn>v8qiv8si2): Ditto.
(<any_extend:insn>v4qiv4si2): Ditto.
(<any_extend:insn>v4hiv4si2): Ditto.
(<any_extend:insn>v8qiv8di2): Ditto.
(<any_extend:insn>v4qiv4di2): Ditto.
(<any_extend:insn>v2qiv2di2): Ditto.
(<any_extend:insn>v4hiv4di2): Ditto.
(<any_extend:insn>v2hiv2di2): Ditto.
(<any_extend:insn>v2siv2di2): Ditto.
no-guess-branch-probability option requires profile_count scaling with
initialized_p guard, use multiply instead of apply_scale, which will do
the right thing to undefined probabilities and will not cause unnecesary
roundoff errors and precision info loss.
Also merge the missed part of r12-6086 of factor out function to avoid
duplicate code.
Regression testest pass on Power and X86.
gcc/ChangeLog:
PR tree-optimization/103793
* tree-ssa-loop-split.c (fix_loop_bb_probability): New function.
(split_loop): Use multiply to scale loop1's exit probability.
(do_split_loop_on_cond): Call fix_loop_bb_probability.
gcc/testsuite/ChangeLog:
PR tree-optimization/103793
* gcc.dg/pr103793.c: New test.
On non-ELF targets, the Makefile needs a newline inside the sed REPLACE
string. The way it is currently done fails with GNU Make < 4, but GCC
only requires "GNU make version 3.80 (or later)".
The portable solution is given in the autoconf manual:
https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/Newlines-in-Make-Rules.html
libbacktrace/ChangeLog:
PR libbacktrace/103822
* Makefile.am: Fix newline.
* Makefile.in: Regenerate.
Make the front-end emit the right type for CHARACTER(C_CHAR), VALUE
arguments to BIND(C) procedures. They are scalar integers of C type
char, and should be emitted as such. They are not strings or arrays,
and are not promoted to C int, either.
gcc/fortran/ChangeLog:
PR fortran/103828
* trans-decl.c (generate_local_decl): Do not call
gfc_conv_scalar_char_value(), but check the type tree.
* trans-expr.c (gfc_conv_scalar_char_value): Rename to
conv_scalar_char_value, do not alter type tree.
(gfc_conv_procedure_call): Adjust call to renamed
conv_scalar_char_value() function.
* trans-types.c (gfc_sym_type): Take care of
CHARACTER(C_CHAR), VALUE arguments.
* trans.h (gfc_conv_scalar_char_value): Remove prototype.
gcc/testsuite/ChangeLog:
PR fortran/103828
* gfortran.dg/c_char_tests_3.f90: New file.
* gfortran.dg/c_char_tests_3_c.c: New file.
* gfortran.dg/c_char_tests_4.f90: New file.
* gfortran.dg/c_char_tests_5.f90: New file.
BOOLEAN_TYPE also counts as integral, so verify_type should allow it.
PR c++/99968
gcc/ChangeLog:
* tree.c (verify_type): Allow enumerator with BOOLEAN_TYPE.
gcc/testsuite/ChangeLog:
* g++.dg/ext/is_enum2.C: New test.
Some time ago I've changed const_binop -> wide_int_binop, so that it punts
on shifts by negative count. fold_truth_andor_1 doesn't check the results
of const_binop (?SHIFT_EXPR, ) though and assumes they will be always
non-NULL, which is no longer the case.
2021-12-28 Jakub Jelinek <jakub@redhat.com>
PR middle-end/103813
* fold-const.c (fold_truth_andor_1): Punt of const_binop LSHIFT_EXPR
or RSHIFT_EXPR returns NULL. Formatting fix.
* gcc.c-torture/compile/pr103813.c: New test.
In the following testcase we have a -fcompare-debug failure, because
can_move_invariant_reg doesn't ignore DEBUG_INSNs in its decisions.
In the testcase we have due to uninitialized variable:
loop_header
debug_insn using pseudo84
pseudo84 = invariant
insn using pseudo84
end loop
and with -g decide not to move the pseudo84 = invariant before the
loop header; in this case not resetting the debug insns might be fine.
But, we could have also:
pseudo84 = whatever
loop_header
debug_insn using pseudo84
pseudo84 = invariant
insn using pseudo84
end loop
and in that case not resetting the debug insns would result in wrong-debug.
And, we don't really have generally a good substitution on what pseudo84
contains, it could inherit various values from different paths.
So, the following patch ignores DEBUG_INSNs in the decisions, and if there
are any that previously prevented the optimization, resets them before
return true.
2021-12-28 Jakub Jelinek <jakub@redhat.com>
PR rtl-optimization/103837
* loop-invariant.c (can_move_invariant_reg): Ignore DEBUG_INSNs in
the decisions whether to return false or continue and right before
returning true reset those debug insns that previously caused
returning false.
* gcc.dg/pr103837.c: New test.
These two spots are meant to punt if the newly added code contains
any CALL_INSNs, because in that case having a large sequence of insns
that also calls something is undesirable, better have one call that
is optimized in itself well.
The functions do last = get_last_insn (); before emitting any insns
(and expand_binop as the ultimate caller uses delete_insns_since if
the expansion fails), but the checks were incorrect for 2 reasons:
1) it checked not just what follows after that last insn, but also
the last insn itself; so, if the division or modulo is immediately
preceded by a CALL_INSN, then we punt; this also causes -fcompare-debug
failures if the CALL_INSN is with -g followed by one or more DEBUG_INSNs
2) if get_last_insn () is NULL (i.e. emitting into a new sequence), then
we didn't check anything
2021-12-28 Jakub Jelinek <jakub@redhat.com>
PR debug/103838
* optabs.c (expand_doubleword_mod, expand_doubleword_divmod): Only
check newly added insns for CALL_P, not the last insn of previous
code.
* gcc.dg/pr103838.c: New test.
It happens that options are parsed and various diagnostics happen
in finish_options. That's a proper place as the function is also called
for optimize/target attributes (pragmas). However, it is possible that
target overwrites an option from command line and so the diagnostics
does not happen. That's fixed in the patch.
- options are parsed and finish_options is called:
if (opts->x_flag_unwind_tables
&& !targetm_common.unwind_tables_default
&& opts->x_flag_reorder_blocks_and_partition
&& (ui_except == UI_SJLJ || ui_except >= UI_TARGET))
{
if (opts_set->x_flag_reorder_blocks_and_partition)
inform (loc,
"%<-freorder-blocks-and-partition%> does not support "
"unwind info on this architecture");
opts->x_flag_reorder_blocks_and_partition = 0;
opts->x_flag_reorder_blocks = 1;
}
It's not triggered because of opts->x_flag_unwind_tables is false by default, but
the option is overwritten in target:
...
if (TARGET_64BIT_P (opts->x_ix86_isa_flags))
{
if (opts->x_optimize >= 1)
SET_OPTION_IF_UNSET (opts, opts_set, flag_omit_frame_pointer,
!USE_IX86_FRAME_POINTER);
if (opts->x_flag_asynchronous_unwind_tables
&& TARGET_64BIT_MS_ABI)
SET_OPTION_IF_UNSET (opts, opts_set, flag_unwind_tables, 1);
...
PR driver/103465
gcc/ChangeLog:
* opts.c (finish_options): More part of diagnostics to ...
(diagnose_options): ... here. Call the function from both
finish_options and process_options.
* opts.h (diagnose_options): Declare.
* toplev.c (process_options): Call diagnose_options.
register_operand predicate allows not just REGs, but also SUBREGs of REGs,
and for the latter lowpart_subreg might FAIL when trying to create paradoxical
SUBREG in some cases. For the input operand fixed by force_reg on it first,
for the output operand handled by always dividing into a fresh V4SFmode temporary
and emit_move_insn into the destination afterwards, that is also beneficial for
combine.
2021-12-28 Jakub Jelinek <jakub@redhat.com>
PR target/103842
* config/i386/mmx.md (divv2sf3): Use force_reg on op1. Always perform
divv4sf3 into a pseudo and emit_move_insn into operands[0].
* g++.dg/opt/pr103842.C: New test.
gcc/testsuite/ChangeLog:
* gcc.target/i386/amx-check.h (check_float_tile_register):
New check function for float to prevent precision loss.
* gcc.target/i386/amxbf16-dpbf16ps-2.c: Correct the type convert
and byte offset. Use the new check function.
The r12-6123 fix for SFINAE with p+N and incomplete type also fixed
the analogous issue with p[N].
PR c++/101239
gcc/testsuite/ChangeLog:
* g++.dg/template/sfinae32a.C: New test.
In pointer_int_sum when called from a SFINAE context, we need to avoid
calling size_in_bytes_loc on an incomplete pointed-to type since this
latter function isn't SFINAE-enabled and always emits an error on such
input.
PR c++/103700
gcc/c-family/ChangeLog:
* c-common.c (pointer_int_sum): When quiet, return
error_mark_node for an incomplete pointed-to type and don't
call size_in_bytes_loc.
gcc/testsuite/ChangeLog:
* g++.dg/template/sfinae32.C: New test.
The 'm' constraint is defined with define_memory_constraint which allows
LRA to convert the operand to the form '(mem (reg X))', where X is a
base register. To prevent LRA from generating '(mem (reg X))' from a
register:
1. Add a 'BM' constraint which is similar to the 'm' constraint, but
is defined with define_constraint.
2. Add a 'm' mode attribute which is mapped to the 'm' constraint for
general_operand and the 'BM' constraint for x86_64_general_operand.
3. Replace the 'm' constraint on <general_operand> with the '<m>'
constraint.
4. Replace the 'm' constraint on x86_64_general_operand with the 'BM'
constraint.
gcc/
PR target/103762
* config/i386/constraints.md (BM): New constraint.
* config/i386/i386.md (m): New mode attribute.
Replace the 'm' constraint on <general_operand> with the '<m>'
constraint.
Replace the 'm' constraint on x86_64_general_operand with the
'BM' constraint.
gcc/testsuite/
* gcc.target/i386/pr103762-1a.c: New test.
* gcc.target/i386/pr103762-1b.c: Likewise.
* gcc.target/i386/pr103762-1c.c: Likewise.
libgfortran/ChangeLog:
PR libfortran/98076
* runtime/string.c (itoa64, itoa64_pad19): New helper functions.
(gfc_itoa): On targets with 128-bit integers, call fast
64-bit functions to avoid many slow divisions.
gcc/testsuite/ChangeLog:
PR libfortran/98076
* gfortran.dg/pr98076.f90: New test.
libgfortran/ChangeLog:
PR libfortran/81986
PR libfortran/99191
* libgfortran.h: Remove gfc_xtoa(), adjust gfc_itoa() and
GFC_ITOA_BUF_SIZE.
* io/write.c (write_decimal): conversion parameter is always
gfc_itoa(), so remove it. Protect from overflow.
(xtoa): Move gfc_xtoa and update its name.
(xtoa_big): Renamed from ztoa_big for consistency.
(write_z): Adjust to new function names.
(write_i, write_integer): Remove last arg of write_decimal.
* runtime/backtrace.c (error_callback): Comment on the use of
gfc_itoa().
* runtime/error.c (gfc_xtoa): Move to io/write.c.
* runtime/string.c (gfc_itoa): Take an unsigned argument,
remove the handling of negative values.
As per title.
Signed-off-by: Iain Sandoe <iain@sandoe.co.uk>
gcc/ChangeLog:
* config/darwin.c (darwin_override_options): Make a comment
more inclusive.
The current rule was too strict and has not been required since Darwin11.
This relaxes the constraint to allow up to 2^28 alignment for non-common
entities. Common is still restricted to a maximum aligment of 2^15.
When the host is an older version of Darwin ( earlier that 11 ) then the
existing constraint is still applied. Note that this is a host constraint
not a target one (so that a compilation on 10.7 targeting 10.6 is allowed
to use a greater alignment than the tools on 10.6 support). This matches
the behaviour of clang.
Signed-off-by: Iain Sandoe <iain@sandoe.co.uk>
gcc/ChangeLog:
* config.gcc: Emit L2_MAX_OFILE_ALIGNMENT with suitable
values for the host.
* config/darwin.c (darwin_emit_common): Error for alignment
values > 32768.
* config/darwin.h (MAX_OFILE_ALIGNMENT): Rework to use the
configured L2_MAX_OFILE_ALIGNMENT.
gcc/testsuite/ChangeLog:
* gcc.dg/darwin-aligned-globals.c: New test.
* gcc.dg/darwin-comm-1.c: New test.
* gcc.dg/attr-aligned.c: Amend for new alignment values on
Darwin.
* gcc.target/i386/pr89261.c: Likewise.
We were checking whether the flag had been set by the user, but not if
it was set to true. Which means that the check fails in its intent when
the user puts -fno-reorder-and-partition.
Signed-off-by: Iain Sandoe <iain@sandoe.co.uk>
gcc/ChangeLog:
* config/darwin.c (darwin_override_options): When checking for the
flag-reorder-and-partition case, also check that it is set on.
There are places that we need to make different codegen depending
on the object format rather than on the arch. We already have
definitions for ELF, COFF etc. this adds one for MACHO.
Signed-off-by: Iain Sandoe <iain@sandoe.co.uk>
gcc/ChangeLog:
* config/darwin.h (OBJECT_FORMAT_MACHO): New.
Jakub Jelinek
Lancelot SIX
Martin Liska
Xionghu Luo
GCC Administrator
Ian Lance Taylor
Francois-Xavier Coudert
Francois-Xavier Coudert
Harald Anlauf
Uros Bizjak
Jason Merrill
Haochen Jiang
John David Anglin
Patrick Palka
H.J. Lu
LiaoShihua
Iain Sandoe