[PATCH] d: Add windows support for D compiler (PR91595)
Hi,
This patch adds necessary backend support for MinGW/Cygwin targets so
that all relevant predefined version conditions are available, a
prerequesite for building most parts of libphobos.
Tested gdc by building x86_64-pc-mingw64 as a cross compiler, before I
commit it to mainline, is there anything glaringly missing in the
configure file changes?
Regards
Iain
---
gcc/ChangeLog:
PR d/91595
* config.gcc (*-*-cygwin*): Add winnt-d.o
(*-*-mingw*): Likewise.
* config/i386/cygwin.h (EXTRA_TARGET_D_OS_VERSIONS): New macro.
* config/i386/mingw32.h (EXTRA_TARGET_D_OS_VERSIONS): Likewise.
* config/t-winnt: Add winnt-d.o.
* config/winnt-d.c: New file.
---
gcc/config.gcc| 6 ++
gcc/config/i386/cygwin.h | 8
gcc/config/i386/mingw32.h | 11 ++
gcc/config/t-winnt| 4
gcc/config/winnt-d.c | 43 +++
5 files changed, 72 insertions(+)
create mode 100644 gcc/config/winnt-d.c
diff --git a/gcc/config.gcc b/gcc/config.gcc
index 9cecc140c83..b3b84374fd0 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -2121,6 +2121,8 @@ i[34567]86-*-cygwin*)
extra_objs="${extra_objs} winnt.o winnt-stubs.o"
c_target_objs="${c_target_objs} msformat-c.o"
cxx_target_objs="${cxx_target_objs} winnt-cxx.o msformat-c.o"
+ d_target_objs="${d_target_objs} winnt-d.o"
+ target_has_targetdm="yes"
if test x$enable_threads = xyes; then
thread_file='posix'
fi
@@ -2137,6 +2139,8 @@ x86_64-*-cygwin*)
extra_objs="${extra_objs} winnt.o winnt-stubs.o"
c_target_objs="${c_target_objs} msformat-c.o"
cxx_target_objs="${cxx_target_objs} winnt-cxx.o msformat-c.o"
+ d_target_objs="${d_target_objs} winnt-d.o"
+ target_has_targetdm="yes"
if test x$enable_threads = xyes; then
thread_file='posix'
fi
@@ -2149,7 +2153,9 @@ i[34567]86-*-mingw* | x86_64-*-mingw*)
xm_file=i386/xm-mingw32.h
c_target_objs="${c_target_objs} winnt-c.o"
cxx_target_objs="${cxx_target_objs} winnt-c.o"
+ d_target_objs="${d_target_objs} winnt-d.o"
target_has_targetcm="yes"
+ target_has_targetdm="yes"
case ${target} in
x86_64-*-* | *-w64-*)
need_64bit_isa=yes
diff --git a/gcc/config/i386/cygwin.h b/gcc/config/i386/cygwin.h
index db0a3cc0b35..f28c6974cdc 100644
--- a/gcc/config/i386/cygwin.h
+++ b/gcc/config/i386/cygwin.h
@@ -29,6 +29,14 @@ along with GCC; see the file COPYING3. If not see
} \
while (0)
+#define EXTRA_TARGET_D_OS_VERSIONS() \
+ do \
+{ \
+ builtin_version ("Cygwin"); \
+ builtin_version ("Posix"); \
+} \
+ while (0)
+
#undef CPP_SPEC
#define CPP_SPEC "%(cpp_cpu) %{posix:-D_POSIX_SOURCE} \
%{!ansi:-Dunix} \
diff --git a/gcc/config/i386/mingw32.h b/gcc/config/i386/mingw32.h
index 1a6a3a07ca6..0589d39230d 100644
--- a/gcc/config/i386/mingw32.h
+++ b/gcc/config/i386/mingw32.h
@@ -53,6 +53,17 @@ along with GCC; see the file COPYING3. If not see
} \
while (0)
+#define EXTRA_TARGET_D_OS_VERSIONS() \
+ do \
+{ \
+ builtin_version ("MinGW"); \
+ if (TARGET_64BIT && ix86_abi == MS_ABI) \
+ builtin_version ("Win64"); \
+ else if (!TARGET_64BIT) \
+ builtin_version ("Win32"); \
+} \
+ while (0)
+
#ifndef TARGET_USE_PTHREAD_BY_DEFAULT
#define SPEC_PTHREAD1 "pthread"
#define SPEC_PTHREAD2 "!no-pthread"
diff --git a/gcc/config/t-winnt b/gcc/config/t-winnt
index 9587f66b3db..00bd3c348b4 100644
--- a/gcc/config/t-winnt
+++ b/gcc/config/t-winnt
@@ -20,3 +20,7 @@ winnt-c.o: config/winnt-c.c $(CONFIG_H) $(SYSTEM_H)
coretypes.h \
$(C_TARGET_H) $(C_TARGET_DEF_H)
$(COMPILER) -c $(ALL_COMPILERFLAGS) $(ALL_CPPFLAGS) \
$< $(OUTPUT_OPTION)
+
+winnt-d.o: config/winnt-d.c
+ $(COMPILE) $<
+ $(POSTCOMPILE)
diff --git a/gcc/config/winnt-d.c b/gcc/config/winnt-d.c
new file mode 100644
index 000..f3a36c28293
--- /dev/null
+++ b/gcc/config/winnt-d.c
@@ -0,0 +1,43 @@
+/* Windows support needed only by D front-end.
+ Copyright (C) 2021 Free Software Foundation, Inc.
+
+GCC is free software; you can redistribute it and/or modify
[PATCH] d: Add openbsd support for D compiler (PR99691)
Hi,
This patch adds necessary backend support for OpenBSD targets so that
all relevant predefined version conditions are available, a prerequesite
for building most parts of libphobos.
Tested gdc by building x86_64-pc-openbsd as a cross compiler, and I've
been doing some preliminary testing on an OpenBSD VM - libphobos
specific patches will come later - before I commit it to mainline, is
there anything glaringly missing in the configure file changes?
Regards
Iain
---
gcc/ChangeLog:
PR d/99691
* config.gcc (*-*-openbsd*): Add openbsd-d.o.
* config/t-openbsd: Add openbsd-d.o.
* config/openbsd-d.c: New file.
---
gcc/config.gcc | 2 ++
gcc/config/openbsd-d.c | 38 ++
gcc/config/t-openbsd | 5 +
3 files changed, 45 insertions(+)
create mode 100644 gcc/config/openbsd-d.c
diff --git a/gcc/config.gcc b/gcc/config.gcc
index b3b84374fd0..3394f1191f6 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -917,6 +917,8 @@ case ${target} in
default_use_cxa_atexit=yes
;;
esac
+ d_target_objs="${d_target_objs} openbsd-d.o"
+ target_has_targetdm=yes
;;
*-*-phoenix*)
gas=yes
diff --git a/gcc/config/openbsd-d.c b/gcc/config/openbsd-d.c
new file mode 100644
index 000..d9c8160e24a
--- /dev/null
+++ b/gcc/config/openbsd-d.c
@@ -0,0 +1,38 @@
+/* Functions for generic OpenBSD as target machine for GNU D compiler.
+ Copyright (C) 2021 Free Software Foundation, Inc.
+
+This file is part of GCC.
+
+GCC is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 3, or (at your option)
+any later version.
+
+GCC is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+GNU General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with GCC; see the file COPYING3. If not see
+
Re: [PATCH] [PR99581] Define relaxed memory and use it for aarch64
Vladimir Makarov writes:
> On 2021-03-19 11:42 a.m., Richard Sandiford wrote:
>> Vladimir Makarov via Gcc-patches writes:
>>> The following patch solves P1 PR99581
>>>
>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99581
>>>
>>> The patch was successfully tested and bootstrapped on x86-64, ppc64le,
>>> aarch64.
>>>
>>> Is it ok for the trunk?
>>
>> I'm not trying to reject the patch as such. I just think we need to
>> have a clearer picture first.
>>
> I agree that 'o' should be treated as a subset of 'm' and therefore its
> definition should have a check as 'm' has. Still my patch is not about
> treatment of constraint 'o' only.
>
> My approach for LRA development is minimal changes, as radical changes
> (even if they look right) results long lasting unpredictable effects on
> many targets.
>
> The patch in which you introduced a new function valid_address_p and new
> treatment of **all** memory constraints was too big change with this
> point of view and finally it resulted in this problem after recent
> partially fixing mess in process_address_1.
>
> My patch fixes this radical change. So I think we still need the patch
> I've submitted.
OK, fair enough. I have some minor cosmetic comments below, but
otherwise the patch is OK for trunk and branch.
Thanks,
Richard
> diff --git a/gcc/doc/md.texi b/gcc/doc/md.texi
> index e3686dbfe61..90dd0401fa0 100644
> --- a/gcc/doc/md.texi
> +++ b/gcc/doc/md.texi
> @@ -4567,6 +4567,17 @@ The syntax and semantics are otherwise identical to
> @code{define_constraint}.
> @end deffn
> +@deffn {MD Expression} define_relaxed_memory_constraint name docstring exp
> +Usually memory address in @code{reload} pass is checked to be a legitimate
> +one besides checking the memory itself to satisfy the instruction
> +constraint. Sometimes you need to avoid legitimate address check for
> +memory and use only check for memory to satisfy the constraint. Use
> +this expression to describe operands for such cases.
How about something like:
---
The test expression in a @code{define_memory_constraint} can assume
that @code{TARGET_LEGITIMATE_ADDRESS_P} holds for the address inside
a @code{mem} rtx and so it does not need to test this condition itself.
In other words, a @code{define_memory_constraint} test of the form:
@smallexample
(match_test "mem")
@end smallexample
is enough to test whether an rtx is a @code{mem} @emph{and} whether
its address satisfies @code{TARGET_MEM_CONSTRAINT} (which is usually
@samp{'m'}). Thus the conditions imposed by a @code{define_memory_constraint}
always apply on top of the conditions imposed by @code{TARGET_MEM_CONSTRAINT}.
However, it is sometimes useful to define memory constraints that allow
addresses beyond those accepted by @code{TARGET_LEGITIMATE_ADDRESS_P}.
@code{define_relaxed_memory_constraint} exists for this case.
The test expression in a @code{define_relaxed_memory_constraint} is
applied with no preconditions, so that the expression can determine
``from scratch'' exactly which addresses are valid and which are not.
---
> +
> +The syntax and semantics are otherwise identical to
> +@code{define_constraint}.
Think @code{define_memory_constraint} would be a better
reference point here.
> @@ -756,15 +759,15 @@ mangle (const char *name)
>return XOBFINISH (rtl_obstack, const char *);
> }
> -/* Add one constraint, of any sort, to the tables. NAME is its name;
> - REGCLASS is the register class, if any; EXP is the expression to
> - test, if any; IS_MEMORY, IS_SPECIAL_MEMORY and IS_ADDRESS indicate
> - memory, special memory, and address constraints, respectively; LOC
> - is the .md file location.
> +/* Add one constraint, of any sort, to the tables. NAME is its name;
> REGCLASS
> + is the register class, if any; EXP is the expression to test, if any;
> + IS_MEMORY, IS_SPECIAL_MEMORY, IS_RELAXED_MEMORY and IS_ADDRESS indicate
> + memory, special memory, and address constraints, respectively; LOC is the
> .md
Long line.
> + file location.
> Not all combinations of arguments are valid; most importantly,
> REGCLASS is mutually exclusive with EXP, and
> - IS_MEMORY/IS_SPECIAL_MEMORY/IS_ADDRESS are only meaningful for
> + IS_MEMORY/IS_SPECIAL_MEMORY/IS_RELAXED_MEMORY/IS_ADDRESS are only
> meaningful for
Same here.
> constraints with EXP.
> This function enforces all syntactic and semantic rules about what
> @@ -773,7 +776,7 @@ mangle (const char *name)
> static void
> add_constraint (const char *name, const char *regclass,
> rtx exp, bool is_memory, bool is_special_memory,
> - bool is_address, file_location loc)
> + bool is_relaxed_memory, bool is_address, file_location loc)
> {
>class constraint_data *c, **iter, **slot;
>const char *p;
> @@ -895,6 +898,17 @@ add_constraint (const char *
Re: [PATCH] fwprop: Fix single_use_p calculation
Ilya Leoshkevich writes:
> Bootstrapped and regtested on x86_64-redhat-linux, ppc64le-redhat-linux
> and s390x-redhat-linux. Ok for master?
Given what was said downthread, I agree we should fix this for GCC 11.
Sorry for missing this problem in the initial review.
> Commit efb6bc55a93a ("fwprop: Allow (subreg (mem)) simplifications")
> introduced a check that was supposed to look at the propagated def's
> number of uses. It uses insn_info::num_uses (), which in reality
> returns the number of uses def's insn has. The whole change therefore
> works only by accident.
>
> Fix by looking at def_info's uses instead of insn_info's uses. This
> requires passing around def_info instead of insn_info.
>
> gcc/ChangeLog:
>
> 2021-03-02 Ilya Leoshkevich
>
> * fwprop.c (def_has_single_use_p): New function.
> (fwprop_propagation::fwprop_propagation): Look at
> def_info's uses.
> (try_fwprop_subst_note): Use def_info instead of insn_info.
> (try_fwprop_subst_pattern): Likewise.
> (try_fwprop_subst_notes): Likewise.
> (try_fwprop_subst): Likewise.
> (forward_propagate_subreg): Likewise.
> (forward_propagate_and_simplify): Likewise.
> (forward_propagate_into): Likewise.
> * iterator-utils.h (single_element_p): New function.
> ---
> gcc/fwprop.c | 89 ++--
> gcc/iterator-utils.h | 10 +
> 2 files changed, 62 insertions(+), 37 deletions(-)
>
> diff --git a/gcc/fwprop.c b/gcc/fwprop.c
> index 4b8a554e823..478dcdd96cc 100644
> --- a/gcc/fwprop.c
> +++ b/gcc/fwprop.c
> @@ -175,7 +175,7 @@ namespace
> static const uint16_t CONSTANT = FIRST_SPARE_RESULT << 1;
> static const uint16_t PROFITABLE = FIRST_SPARE_RESULT << 2;
>
> -fwprop_propagation (insn_info *, insn_info *, rtx, rtx);
> +fwprop_propagation (insn_info *, def_info *, rtx, rtx);
use->def () returns a set_info *, and since you want set_info stuff,
I think it would probably be better to pass around a set_info * instead.
(Let's keep the variable names the same though. “def” is still accurate
and IMO the natural choice.)
> @@ -191,13 +191,27 @@ namespace
>};
> }
>
> -/* Prepare to replace FROM with TO in INSN. */
> +/* Return true if DEF has a single non-debug non-phi use. */
> +
> +static bool
> +def_has_single_use_p (def_info *def)
> +{
> + if (!is_a (def))
> +return false;
> +
> + set_info *set = as_a (def);
> +
> + return single_element_p (set->nondebug_insn_uses ())
> + && !set->has_phi_uses ();
I think instead we should add:
// If exactly one nondebug instruction uses the set's result, return
// the use by that instruction, otherwise return null.
use_info *single_nondebug_insn_use () const;
// If there is exactly one nondebug use of the set's result,
// return that use, otherwise return null. The use might be in
// instruction or a phi node.
use_info *single_nondebug_use () const;
before the declaration of set_info::is_local_to_ebb.
> +}
> +
> +/* Prepare to replace FROM with TO in USE_INSN. */
>
> fwprop_propagation::fwprop_propagation (insn_info *use_insn,
> - insn_info *def_insn, rtx from, rtx to)
> + def_info *def, rtx from, rtx to)
>: insn_propagation (use_insn->rtl (), from, to),
> -single_use_p (def_insn->num_uses () == 1),
> -single_ebb_p (use_insn->ebb () == def_insn->ebb ())
> +single_use_p (def_has_single_use_p (def)),
> +single_ebb_p (use_insn->ebb () == def->insn ()->ebb ())
Just def->ebb ()
> @@ -538,7 +554,7 @@ try_fwprop_subst_pattern (obstack_watermark &attempt,
> insn_change &use_change,
> {
>if ((REG_NOTE_KIND (note) == REG_EQUAL
> || REG_NOTE_KIND (note) == REG_EQUIV)
> - && try_fwprop_subst_note (use_insn, def_insn, note,
> + && try_fwprop_subst_note (use_insn, def, note,
> dest, src, false) < 0)
Very minor, sorry, but this now fits on one line.
> @@ -584,10 +600,11 @@ try_fwprop_subst_notes (insn_info *use_insn, insn_info
> *def_insn,
> Return true on success, otherwise leave USE_INSN unchanged. */
>
> static bool
> -try_fwprop_subst (use_info *use, insn_info *def_insn,
> +try_fwprop_subst (use_info *use, def_info *def,
> rtx *loc, rtx dest, rtx src)
Same here.
Thanks,
Richard
Re: [PATCH] dwarf2out: Fix debug info for 2 byte floats [PR99388]
On 3/5/2021 3:21 AM, Jakub Jelinek via Gcc-patches wrote:
Hi!
Aarch64, ARM and a couple of other architectures have 16-bit floats, HFmode.
As can be seen e.g. on
void
foo (void)
{
__fp16 a = 1.0;
asm ("nop");
a = 2.0;
asm ("nop");
a = 3.0;
asm ("nop");
}
testcase, GCC mishandles this on the dwarf2out.c side by assuming all
floating point types have sizes in multiples of 4 bytes, so what GCC emits
is it says that e.g. the DW_OP_implicit_value will be 2 bytes but then
doesn't emit anything and so anything emitted after it is treated by
consumers as the value and then they get out of sync.
real_to_target which insert_float uses indeed fills it that way, but putting
into an array of long 32 bits each time, but for the half floats it puts
everything into the least significant 16 bits of the first long no matter
what endianity host or target has.
The following patch fixes it. With the patch the -g -O2 -dA output changes
(in a cross without .uleb128 support):
.byte 0x9e// DW_OP_implicit_value
.byte 0x2 // uleb128 0x2
+ .2byte 0x3c00 // fp or vector constant word 0
.byte 0x7 // DW_LLE_start_end (*.LLST0)
.8byte .LVL1 // Location list begin address (*.LLST0)
.8byte .LVL2 // Location list end address (*.LLST0)
.byte 0x4 // uleb128 0x4; Location expression size
.byte 0x9e// DW_OP_implicit_value
.byte 0x2 // uleb128 0x2
+ .2byte 0x4000 // fp or vector constant word 0
.byte 0x7 // DW_LLE_start_end (*.LLST0)
.8byte .LVL2 // Location list begin address (*.LLST0)
.8byte .LFE0 // Location list end address (*.LLST0)
.byte 0x4 // uleb128 0x4; Location expression size
.byte 0x9e// DW_OP_implicit_value
.byte 0x2 // uleb128 0x2
+ .2byte 0x4200 // fp or vector constant word 0
.byte 0 // DW_LLE_end_of_list (*.LLST0)
Bootstrapped/regtested on x86_64-linux, aarch64-linux and
armv7hl-linux-gnueabi, ok for trunk?
I fear the CONST_VECTOR case is still broken, while HFmode elements of vectors
should be fine (it uses eltsize of the element sizes) and likewise SFmode could
be fine, DFmode vectors are emitted as two 32-bit ints regardless of endianity
and I'm afraid it can't be right on big-endian. But I haven't been able to
create a testcase that emits a CONST_VECTOR, for e.g. unused vector vars
with constant operands we emit CONCATN during expansion and thus ...
DW_OP_*piece for each element of the vector and for
DW_TAG_call_site_parameter we give up (because we handle CONST_VECTOR only
in loc_descriptor, not mem_loc_descriptor).
2021-03-04 Jakub Jelinek
PR debug/99388
* dwarf2out.c (insert_float): Change return type from void to
unsigned, handle GET_MODE_SIZE (mode) == 2 and return element size.
(mem_loc_descriptor, loc_descriptor, add_const_value_attribute):
Adjust callers.
OK. Note that I also expect we'll some pushes for 8-bit floats in the
not too distant future, so I fully expect we'll be coming back to this
again in the future.
Jeff
Re: [PATCH] ipa: Check that scalar types that IPA-CP comes up with are sane (PR99122)
On 3/5/2021 8:27 AM, Martin Jambor wrote: Hi, this patch fixes the last bit of PR 99122 where various bits of IPA infrastructure are presented with a program with type mismatches that make it have undefined behavior, and when inlining or performing IPA-CP, and encountering such mismatch, we basically try to VIEW_CONVERT_EXPR whatever the caller has into whatever the callee has or simply use an empty constructor if that cannot be done. This however does not work when the callee has VLA parameters because we ICE in the process. Richi has already disabled inlining for such cases, this patch avoids the issue in IPA-CP. It adds checks that whatever constant the propagation arrived at is actually compatible or fold_convertible to the callees formal parameer type. Unlike in the past, we now have types of all parameters of functions that we have analyzed, even with LTO, and so can do it. This should prevent only bogus propagations. I have looked at the effect of the patch on WPA of Firefox and did not have any. I have bootstrapped and LTO bootstrapped and tested the patch on x86_64-linux. OK for trunk? And perhaps later for GCC 10 too? Thanks gcc/ChangeLog: 2021-02-26 Martin Jambor PR ipa/99122 * ipa-cp.c (initialize_node_lattices): Mark as bottom all parameters with unknown type. (ipacp_value_safe_for_type): New function. (propagate_vals_across_arith_jfunc): Verify that the constant type can be used for a type of the formal parameter. (propagate_vals_across_ancestor): Likewise. (propagate_scalar_across_jump_function): Likewise. Pass the type also to propagate_vals_across_ancestor. gcc/testsuite/ChangeLog: 2021-02-26 Martin Jambor PR ipa/99122 * gcc.dg/pr99122-3.c: Remove -fno-ipa-cp from options. OK Jeff
Re: [committed] [PR99680] Check empty constraint before using CONSTRAINT_LEN.
Hi!
On Sat, Mar 20, 2021 at 10:53:32AM -0400, Vladimir Makarov via Gcc-patches
wrote:
> It seems CONSTRAINT_LEN treats constraint '\0' as one having length 1.
Maybe we should fix that? See attached patch.
Segher
diff --git a/gcc/genpreds.c b/gcc/genpreds.c
index 8499a2a2383b..b83a030d6a5d 100644
--- a/gcc/genpreds.c
+++ b/gcc/genpreds.c
@@ -1141,6 +1141,9 @@ write_insn_constraint_len (void)
" switch (fc)\n"
"{");
+ /* Empty constraints have length 0. */
+ printf ("case 0: return 0;\n");
+
for (i = 0; i < ARRAY_SIZE (constraints_by_letter_table); i++)
{
class constraint_data *c = constraints_by_letter_table[i];
@@ -1470,14 +1473,9 @@ write_tm_preds_h (void)
address_start, address_end);
write_allows_reg_mem_function ();
- if (constraint_max_namelen > 1)
-{
- write_insn_constraint_len ();
- puts ("#define CONSTRAINT_LEN(c_,s_) "
- "insn_constraint_len (c_,s_)\n");
- }
- else
- puts ("#define CONSTRAINT_LEN(c_,s_) 1\n");
+ write_insn_constraint_len ();
+ puts ("#define CONSTRAINT_LEN(c_,s_) insn_constraint_len (c_,s_)\n");
+
if (have_register_constraints)
puts ("extern enum reg_class reg_class_for_constraint_1 "
"(enum constraint_num);\n"
[Patch] Fortran: Fix 'name' bound size [PR99688]
The gfc_match_select_rank issue showed up in the testsuite
and was found by Martin's asan-bootstrapped GCC. First
analysis by Harald – thanks to both!
However, I think the other variables I fixed were also
prone to overflows; see below for its usage.
OK for mainline? Other branches?
Tobias
PS: Other pending Fortran patches – please review!
[Patch] Fortran: Fix intrinsic null() handling [PR99651]
[Patch] Fortran: Fix func decl mismatch [PR93660]
PPS: Usage of 'name' in the patched functions:
resolve_select_type (gfc_code *code, gfc_namespace *old_ns)
char name[GFC_MAX_SYMBOL_LEN];
...
sprintf (name, "__tmp_class_%s", c->ts.u.derived->name);
select_intrinsic_set_tmp (gfc_typespec *ts)
{
char name[GFC_MAX_SYMBOL_LEN];
...
sprintf (name, "__tmp_class_%s", ts->u.derived->name);
gfc_match_select_type (void)
...
char name[GFC_MAX_SYMBOL_LEN];
...
m = gfc_match (" %n => %e", name, &expr2);
gfc_match_select_rank (void)
...
char name[GFC_MAX_SYMBOL_LEN];
...
m = gfc_match (" %n => %e", name, &expr2);
Fortran: Fix 'name' bound size [PR99688]
gcc/fortran/ChangeLog:
PR fortran/99688
* match.c (select_type_set_tmp, gfc_match_select_type,
(gfc_match_select_rank): Fix 'name' buffersize to avoid out of bounds.
* resolve.c (resolve_select_type): Likewise.
/lhome/tburnus/repos/gcc/gcc/fortran
diff --git a/gcc/fortran/match.c b/gcc/fortran/match.c
index 4d5890fd523..29462013038 100644
--- a/gcc/fortran/match.c
+++ b/gcc/fortran/match.c
@@ -6330,7 +6332,7 @@ select_intrinsic_set_tmp (gfc_typespec *ts)
static void
select_type_set_tmp (gfc_typespec *ts)
{
- char name[GFC_MAX_SYMBOL_LEN];
+ char name[GFC_MAX_SYMBOL_LEN + 12 + 1];
gfc_symtree *tmp = NULL;
gfc_symbol *selector = select_type_stack->selector;
gfc_symbol *sym;
@@ -6409,7 +6411,7 @@ gfc_match_select_type (void)
{
gfc_expr *expr1, *expr2 = NULL;
match m;
- char name[GFC_MAX_SYMBOL_LEN];
+ char name[GFC_MAX_SYMBOL_LEN + 1];
bool class_array;
gfc_symbol *sym;
gfc_namespace *ns = gfc_current_ns;
@@ -6634,7 +6636,7 @@ gfc_match_select_rank (void)
{
gfc_expr *expr1, *expr2 = NULL;
match m;
- char name[GFC_MAX_SYMBOL_LEN];
+ char name[GFC_MAX_SYMBOL_LEN + 1];
gfc_symbol *sym, *sym2;
gfc_namespace *ns = gfc_current_ns;
gfc_array_spec *as = NULL;
diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c
index 32015c21efc..715fecd4b3a 100644
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -9246,7 +9246,7 @@ resolve_select_type (gfc_code *code, gfc_namespace *old_ns)
gfc_code *class_is = NULL, *default_case = NULL;
gfc_case *c;
gfc_symtree *st;
- char name[GFC_MAX_SYMBOL_LEN];
+ char name[GFC_MAX_SYMBOL_LEN + 12 + 1];
gfc_namespace *ns;
int error = 0;
int rank = 0;
Re: [PING][PATCH] adjust "partly out of bounds" warning (PR 98503)
On 3/20/21 10:48 AM, Jeff Law via Gcc-patches wrote: On 3/18/2021 4:18 PM, Martin Sebor via Gcc-patches wrote: Ping: https://gcc.gnu.org/pipermail/gcc-patches/2021-January/564483.html The review of this patch digressed into a design discussion of a new, more capable implementation of -Wstrict-aliasing, but the proposed patch turning just this one instance of -Warray-bounds into -Wstrict-aliasing and making it subject to -fstrict-aliasing wasn't decided. PR 98503 was raised by someone working with the kernel which uses -fno-strict-aliasing, and so to them the warning isn't useful. But since the warning does find potential bugs when strict aliasing is in effect, I'd still like to consider this patch for GCC 11 so that the kernel (and other such projects) doesn't have to deal with the false positives. If/when we add a new, dedicated solution for -Wstrict-aliasing I'll move this instance from gimple-array-bounds.cc there. I'm still not comfortable with the bleeding of strict aliasing bits into the gimple array-bounds checking bits. I think that needs to be fixed in a cleaner manner before this can go forward. I can't really think of any other way to resolve PR 98503 for GCC 11 than something like this. I suppose I could make the existing -Warra-bounds conditional on -fstrict-aliasing (without actually emitting -Wstrict-aliasing). That way the kernel would be able to disable it without giving up the aspects of the warning that are relevant to them. Would that be acceptable to you? If not, what would be? Martin
Re: [committed] nios2: Fix format complaints and similar diagnostics
On 3/17/21 6:00 PM, Sandra Loosemore wrote: On 3/17/21 4:40 PM, Martin Sebor wrote: [*] Does -Wformat-diag really trigger when using older GCC to build? I thought it only triggered in stage 2 and 3 when using the same GCC to rebuild itself. I always end up hopelessly confused by anything involving configure scripts and makefiles, but Our scripts normally configure cross-compilers with --disable-build-format-warnings and there's a comment on that bit that these diagnostics are normally enabled when building non-stage-1 compilers. A cross compiler doesn't bootstrap so is never stage 1, I guess. For the purposes of testing this patch I did an explicit --enable-build-format-warnings instead, anyway. Jan-Benedict, who reported the problem to me off-list, said he just did configure --target=nios2-linux-gnu and make all-gcc using the host gcc including with his distro, identified as "Debian 10.2.1-6". I see. I routinely notice -Wformat warnings when building cross-compilers (my system compiler is GCC 8.3) so I've been assuming they're to be expected. For instance this one: /src/gcc/master/gcc/gimple-fold.c: In function ‘bool gimple_fold_builtin_strncpy(gimple_stmt_iterator*, tree, tree, tree)’: /src/gcc/master/gcc/gimple-fold.c:1921:4: warning: format ‘%G’ expects argument of type ‘gcall*’, but argument 4 has type ‘gimple*’ [-Wformat=] "%G%qD destination unchanged after copying no bytes " ^ "from a string of length %E", stmt, fndecl, slen); Since, as you say, cross-compilers don't build stages 2 and later, disabling these warnings for their builds would seem like the only solution. Either that, or building them with the current GCC. Either way, I'll try to remember to relax the warning for GCC 12 as I mentioned. Martin
New Swedish PO file for 'gcc' (version 11.1-b20210207)
Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'gcc' has been submitted by the Swedish team of translators. The file is available at: https://translationproject.org/latest/gcc/sv.po (This file, 'gcc-11.1-b20210207.sv.po', has just now been sent to you in a separate email.) All other PO files for your package are available in: https://translationproject.org/latest/gcc/ Please consider including all of these in your next release, whether official or a pretest. Whenever you have a new distribution with a new version number ready, containing a newer POT file, please send the URL of that distribution tarball to the address below. The tarball may be just a pretest or a snapshot, it does not even have to compile. It is just used by the translators when they need some extra translation context. The following HTML page has been updated: https://translationproject.org/domain/gcc.html If any question arises, please contact the translation coordinator. Thank you for all your work, The Translation Project robot, in the name of your translation coordinator.
Re: [Patch] Fortran: Fix 'name' bound size [PR99688]
Hi Tobias and others,
Reembering some of my own history, we always have used a +1 on
'LENGTH_MAX' items to allow the C null termination on strings or buffers
for obvious reasons.
Certainly OK for trunk and backports.
Regards,
Jerry
On 3/21/21 9:08 AM, Tobias Burnus wrote:
The gfc_match_select_rank issue showed up in the testsuite
and was found by Martin's asan-bootstrapped GCC. First
analysis by Harald – thanks to both!
However, I think the other variables I fixed were also
prone to overflows; see below for its usage.
OK for mainline? Other branches?
Tobias
PS: Other pending Fortran patches – please review!
[Patch] Fortran: Fix intrinsic null() handling [PR99651]
[Patch] Fortran: Fix func decl mismatch [PR93660]
PPS: Usage of 'name' in the patched functions:
resolve_select_type (gfc_code *code, gfc_namespace *old_ns)
char name[GFC_MAX_SYMBOL_LEN];
...
sprintf (name, "__tmp_class_%s", c->ts.u.derived->name);
select_intrinsic_set_tmp (gfc_typespec *ts)
{
char name[GFC_MAX_SYMBOL_LEN];
...
sprintf (name, "__tmp_class_%s", ts->u.derived->name);
gfc_match_select_type (void)
...
char name[GFC_MAX_SYMBOL_LEN];
...
m = gfc_match (" %n => %e", name, &expr2);
gfc_match_select_rank (void)
...
char name[GFC_MAX_SYMBOL_LEN];
...
m = gfc_match (" %n => %e", name, &expr2);
[PATCH] AIX struct alignment (PR 99557)
The AIX power alignment rules apply the natural alignment of the
"first member" if it is of a floating-point data type (or is an aggregate
whose recursively "first" member or element is such a type). The alignment
associated with these types for subsequent members use an alignment value
where the floating-point data type is considered to have 4-byte alignment.
GCC had been stripping array type but had not recursively looked
within structs and unions. This also applies to classes and
subclasses and, therefore, becomes more prominent with C++.
For example,
struct A {
double x[2];
int y;
};
struct B {
int i;
struct A a;
};
struct A has double-word alignment when referenced independently, but
word alignment and offset within struct B despite the alignment of
struct A. If struct A were the first member of struct B, struct B
would have double-word alignment. One must search for the innermost
first member to increase the alignment if double and then search for
the innermost first member to reduce the alignment if the TYPE had
double-word alignment solely because the innermost first member was
double.
This patch recursively looks through the first member to apply the
double-word alignment to the struct / union as a whole and to apply
the word alignment to the struct or union as a member within a struct
or union.
This is an ABI change for GCCon AIX, but GCC on AIX had not correctly
implemented the AIX ABI and had not been compatible with the IBM XL
compiler.
If anyone can double-check that the patch walks the fields correctly
and handles the error conditions correctly, it would be appreciated.
Bootstrapped on powerpc-ibm-aix7.2.3.0.
Thanks, David
* config/rs6000/aix.h (ADJUST_FIELD_ALIGN): Call function.
* config/rs6000/rs6000-protos.h: Declare.
* config/rs6000/rs6000.c: Define.
index 2db50c8007f..7fccb31307b 100644
--- a/gcc/config/rs6000/aix.h
+++ b/gcc/config/rs6000/aix.h
@@ -223,10 +223,8 @@
/* This now supports a natural alignment mode. */
/* AIX word-aligns FP doubles but doubleword-aligns 64-bit ints. */
#define ADJUST_FIELD_ALIGN(FIELD, TYPE, COMPUTED) \
- ((TARGET_ALIGN_NATURAL == 0 \
-&& (TYPE_MODE (strip_array_types (TYPE)) == DFmode \
- || TYPE_MODE (strip_array_types (TYPE)) == DCmode)) \
- ? MIN ((COMPUTED), 32) \
+ (TARGET_ALIGN_NATURAL == 0 \
+ ? rs6000_special_adjust_field_align (TYPE, COMPUTED)
\
: (COMPUTED))
/* AIX increases natural record alignment to doubleword if the first
diff --git a/gcc/config/rs6000/rs6000-protos.h
b/gcc/config/rs6000/rs6000-protos.h
index 203660b0a78..c44fd3d0263 100644
--- a/gcc/config/rs6000/rs6000-protos.h
+++ b/gcc/config/rs6000/rs6000-protos.h
@@ -227,6 +227,7 @@ address_is_prefixed (rtx addr,
#ifdef TREE_CODE
extern unsigned int rs6000_data_alignment (tree, unsigned int, enum data_align)
;
extern bool rs6000_special_adjust_field_align_p (tree, unsigned int);
+extern unsigned int rs6000_special_adjust_field_align (tree, unsigned int);
extern unsigned int rs6000_special_round_type_align (tree, unsigned int,
unsigned int);
extern unsigned int darwin_rs6000_special_round_type_align (tree, unsigned int,
diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index 712dd1c460b..eed51e8d4a2 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -7856,6 +7856,41 @@ rs6000_special_adjust_field_align_p (tree type, unsigned
int computed)
return false;
}
+/* AIX word-aligns FP doubles but doubleword-aligns 64-bit ints. */
+
+unsigned int
+rs6000_special_adjust_field_align (tree type, unsigned int computed)
+{
+ /* If RECORD or UNION, recursively find the first field. */
+ while (TREE_CODE (type) == RECORD_TYPE
+|| TREE_CODE (type) == UNION_TYPE
+|| TREE_CODE (type) == QUAL_UNION_TYPE)
+{
+ tree field = TYPE_FIELDS (type);
+
+ /* Skip all non field decls */
+ while (field != NULL
+&& (TREE_CODE (field) != FIELD_DECL
+|| DECL_FIELD_ABI_IGNORED (field)))
+ field = DECL_CHAIN (field);
+
+ if (field != NULL && field != type)
+ type = TREE_TYPE (field);
+ else
+ break;
+}
+
+ /* Strip arrays. */
+ while (TREE_CODE (type) == ARRAY_TYPE)
+type = TREE_TYPE (type);
+
+ if (type != error_mark_node
+ && (TYPE_MODE (type) == DFmode || TYPE_MODE (type) == DCmode))
+computed = MIN (computed, 32);
+
+ return computed;
+}
+
/* AIX increases natural record alignment to doubleword if the first
field is an FP double while the FP fields remain word aligned. */
@@ -7864,25 +7899,33 @@ rs6000_special_round_type_align (tree type,unsigned int
computed,
unsigned int specified)
{
unsigned int align = MAX (computed,
回复: 回复: [PATCH v4 1/2] MIPS: Not trigger error for pre-R6 and -mcompact-branches=always
> -邮件原件- > 发件人: Jeff Law > 发送时间: 2021年3月20日 23:42 > 收件人: yunqiang...@cipunited.com; gcc-patches@gcc.gnu.org > 抄送: ma...@orcam.me.uk; l...@redhat.com; d...@debian.org; > s...@debian.org; jiaxun.y...@flygoat.com > 主题: Re: 回复: [PATCH v4 1/2] MIPS: Not trigger error for pre-R6 and > -mcompact-branches=always > > > On 3/3/2021 8:33 PM, yunqiang...@cipunited.com wrote: > >> On 2/23/21 3:14 AM, YunQiang Su wrote: > >>> For MIPSr6, we may wish to use compact-branches only. > >>> Currently, we have to use `always' option, while it is mark as > >>> conflict with pre-R6. > >>>cc1: error: unsupported combination: ‘mips32r2’ > >>> -mcompact-branches=always Just ignore -mcompact-branches=always > for > >> pre-R6. > >>> This patch also defines > >>> __mips_compact_branches_never > >>> __mips_compact_branches_always > >>> __mips_compact_branches_optimal predefined macros > >>> > >>> gcc/ChangeLog: > >>> * config/mips/mips.c (mips_option_override): > >>> * config/mips/mips.h (TARGET_RTP_PIC): not trigger error for > >>> compact-branches=always for pre-R6. > >>> (TARGET_CB_NEVER): Likewise. > >>> (TARGET_CB_ALWAYS): Likewise. > >>> (struct mips_cpu_info): define macros for compact branch policy. > >>> * doc/invoke.texi: Document "always" with pre-R6. > >>> > >>> gcc/testsuite/ChangeLog: > >>> * gcc.target/mips/compact-branches-1.c: add isa_rev>=6. > >>> * gcc.target/mips/mips.exp: don't add -mipsXXr6 option for > >>> -mcompact-branches=always. It is usable for pre-R6 now. > >>> * gcc.target/mips/compact-branches-8.c: New test. > >>> * gcc.target/mips/compact-branches-9.c: New test. > >> So I think Maciej's comment was that you simply shouldn't be using > >> -mcompact-branches=always at mips32r2 (or anything pre-r6) together. > >> > >> I think what you're trying to do here is set up a scenario where > >> you're defaulting to mips32r6 and compact-branches, but not error if > >> something specifies -mcpu=mips32r2 or something similar, right? > >> > > Yes. If we introduce the build time option, and configure gcc with > > always, then gcc will always try to Pass -mconpact-branches=always to cc1, > even we use something like: > > mipsisa32r6el-linux-gnu-gcc -mips32r2 -c xx.c It may break > > something. > > So would it be possible to make the mips32rX (for X <6) option also turn off Yes. It is possible, while it may introduce lots of complexity to the code. > compact-branches? Maciej, is that less problematical from your > standpoint? Or is this just ultimately a bad idea from start to finish? > > > Jeff
Re: [PATCH] MIPS: R6: load/store can process unaligned address
Ping for this patch again.
Re: [PATCH] rs6000: Fix some unexpected empty split conditions
Hi Segher, on 2021/3/20 上午5:58, Segher Boessenkool wrote: > On Fri, Mar 19, 2021 at 11:50:41PM +0800, Kewen.Lin wrote: >>> I am curious if the splitters ever triggered where they should not have? >> >> Do you have any suggestion to catch this? I thought the regression >> testing probably can show something different but it didn't unfortunately. > > Well, you can compare the generated binaries with a compiler binary > before and after the patch, for something that will match the splitters, > so with a lot of float<->integer conversions for example. > > I usually look at cc1 or vmlinux, but those both are nice for integer > code only. > > Maybe we should have some tool that for every define_insn finds which > define_splits can possibly match it. > Thanks for the suggestion. I did the binary comparison for SPEC2017 executables built before and after this patch on both Power8 and Power9, I still didn't see any differences, it seems hard to trigger it. Committed via r11-7756. >>> You might want to make this error easier to detect? Maybe make >>> define_insn_and_split raise an error if the split condition is empty but >>> the insn condition is not? >> >> Good idea! Is there any possible reason to write this kind of >> define_insn_and_split? If no (we should forbid it), I think we can add >> the check and raise an error if hits in gensupport.c. >> >> I'll send out a RFC once GCC12 starts. > > There is no good reason for it. If you really want a > define_insn_and_split that splits more than just that insn, you should > just write the define_insn and the define_split separately. Much > clearer that way. A reader does not expect a define_insn_and_split to > split any other insns. (Or they should not, IMO, of course :-) ) > > And yes, because that might well break things for some targets, or > change behaviour at least, it is a GCC 12 thing. It will be a nice > cleanup though :-) > Got it! Thanks for the further explanation. :) BR, Kewen
[PATCH] x86: Add __volatile__ to __cpuid and __cpuid_count
Tested on Linux/x86-64 and Linux/i686. OK for master and release
branches?
Thanks.
H.J.
---
Since CPUID instruction may return different values on hybrid core.
volatile is needed on asm statements in .
PR target/99704
* config/i386/cpuid.h (__cpuid): Add __volatile__.
(__cpuid_count): Likewise.
---
gcc/config/i386/cpuid.h | 36 ++--
1 file changed, 18 insertions(+), 18 deletions(-)
diff --git a/gcc/config/i386/cpuid.h b/gcc/config/i386/cpuid.h
index 539325d6438..aebc17c6827 100644
--- a/gcc/config/i386/cpuid.h
+++ b/gcc/config/i386/cpuid.h
@@ -212,28 +212,28 @@
/* At least one cpu (Winchip 2) does not set %ebx and %ecx
for cpuid leaf 1. Forcibly zero the two registers before
calling cpuid as a precaution. */
-#define __cpuid(level, a, b, c, d) \
- do { \
-if (__builtin_constant_p (level) && (level) != 1) \
- __asm__ ("cpuid\n\t" \
- : "=a" (a), "=b" (b), "=c" (c), "=d" (d) \
- : "0" (level)); \
-else \
- __asm__ ("cpuid\n\t" \
- : "=a" (a), "=b" (b), "=c" (c), "=d" (d) \
- : "0" (level), "1" (0), "2" (0)); \
+#define __cpuid(level, a, b, c, d) \
+ do { \
+if (__builtin_constant_p (level) && (level) != 1) \
+ __asm__ __volatile__ ("cpuid\n\t"
\
+ : "=a" (a), "=b" (b), "=c" (c), "=d" (d)\
+ : "0" (level)); \
+else \
+ __asm__ __volatile__ ("cpuid\n\t"
\
+ : "=a" (a), "=b" (b), "=c" (c), "=d" (d)\
+ : "0" (level), "1" (0), "2" (0)); \
} while (0)
#else
-#define __cpuid(level, a, b, c, d) \
- __asm__ ("cpuid\n\t" \
- : "=a" (a), "=b" (b), "=c" (c), "=d" (d) \
- : "0" (level))
+#define __cpuid(level, a, b, c, d) \
+ __asm__ __volatile__ ("cpuid\n\t"\
+ : "=a" (a), "=b" (b), "=c" (c), "=d" (d)\
+ : "0" (level))
#endif
-#define __cpuid_count(level, count, a, b, c, d)\
- __asm__ ("cpuid\n\t" \
- : "=a" (a), "=b" (b), "=c" (c), "=d" (d) \
- : "0" (level), "2" (count))
+#define __cpuid_count(level, count, a, b, c, d)
\
+ __asm__ __volatile__ ("cpuid\n\t"\
+ : "=a" (a), "=b" (b), "=c" (c), "=d" (d)\
+ : "0" (level), "2" (count))
/* Return highest supported input value for cpuid instruction. ext can
--
2.30.2
