Re: [PATCH] lto-wrapper.c (copy_file): Fix resource leaks
Le 15/05/2017 à 23:58, Jeff Law a écrit : > On 05/14/2017 04:00 AM, Sylvestre Ledru wrote: >> Add missing fclose >> CID 1407987, 1407986 >> >> S >> >> >> >> 0005-2017-05-14-Sylvestre-Ledru-sylvestre-debian.org.patch >> >> >> From d255827a64012fb81937d6baa8534eabecf9b735 Mon Sep 17 00:00:00 2001 >> From: Sylvestre Ledru >> Date: Sun, 14 May 2017 11:37:37 +0200 >> Subject: [PATCH 5/5] 2017-05-14 Sylvestre Ledru >> >> * lto-wrapper.c (copy_file): Fix resource leaks >>CID 1407987, 1407986 > Doesn't this still leak in the cases were we call fatal_error? Indeed. thanks! Patch updated! S fclose.dif Description: video/dv
[2/2] PR 80769: Incorrect strlen optimisation
In this testcase, we (correctly) record after:
strcpy (p1, "abcde");
char *p2 = strchr (p1, '\0');
strcpy (p2, q);
that the length of p1 and p2 can be calculated by converting the
second strcpy to:
tmp = stpcpy (p2, q)
and then doing tmp - p1 for p1 and tmp - p2 for p2. This is delayed
until we know whether we actually need it. Then:
char *p3 = strchr (p2, '\0');
forces us to calculate the length of p2 in this way. At this point
we had three related strinfos:
p1: delayed length, calculated from tmp = stpcpy (p2, q)
p2: known length, tmp - p2
p3: known length, 0
After:
memcpy (p3, "x", 2);
we use adjust_related_strinfos to add 1 to each length. However,
that didn't do anything for delayed lengths because:
else if (si->stmt != NULL)
/* Delayed length computation is unaffected. */
;
So after the memcpy we had:
p1: delayed length, calculated from tmp = stpcpy (p2, q)
p2: known length, tmp - p2 + 1
p3: known length, 1
where the length of p1 was no longer correct.
I thought about three fixes:
(1) Make adjust_related_strinfos drop strinfos with a delayed length.
(2) Make adjust_related_strinfos compute the length itself
(via get_string_length).
(3) Make get_string_length update all related strinfos. We can then
maintain the invariant that all lengths in a chain are delayed or
none are.
(3) seemed like the best. get_string_length has already made the
invasive step of changing the code and computing the length for one
strinfo. Updating the related strinfos is just a couple of fold_builds,
of the kind that the pass already does in several places.
The point is that the code above only triggers if one of the delayed
lengths has been computed. That makes (1) unnecessarily pessimistic.
It also wasn't obvious (to me) from first glance, so (2) might look
more intrusive than it is. I think it becomes easier to reason about
if we do (3) and can assume that all lengths are delayed or none are.
It also makes the min-length/maybe-not-terminated patch easier.
[ I can go into more detail about why this should be enough to
maintain the invariant, and why the asserts should be valid,
but the message is already pretty long. ]
Tested on aarch64-linux-gnu and x86_64-linux-gnu. OK to install?
Thanks,
Richard
2017-05-16 Richard Sandiford
gcc/
PR tree-optimization/80769
* tree-ssa-strlen.c (strinfo): Document that "stmt" is also used
for malloc and calloc. Document the new invariant that all related
strinfos have delayed lengths or none do.
(verify_related_strinfos): Move earlier in file.
(set_endptr_and_length): New function, split out from...
(get_string_length): ...here. Also set the lengths of related
strinfos.
(zero_length_string): Assert that chainsi has known (rather than
delayed) lengths.
(adjust_related_strinfos): Likewise.
gcc/testsuite/
PR tree-optimization/80769
* gcc.dg/strlenopt-31.c: New test.
* gcc.dg/strlenopt-31g.c: Likewise.
Index: gcc/tree-ssa-strlen.c
===
--- gcc/tree-ssa-strlen.c 2017-05-16 08:00:03.808133862 +0100
+++ gcc/tree-ssa-strlen.c 2017-05-16 08:20:51.408572143 +0100
@@ -61,7 +61,13 @@ struct strinfo
tree length;
/* Any of the corresponding pointers for querying alias oracle. */
tree ptr;
- /* Statement for delayed length computation. */
+ /* This is used for two things:
+
+ - To record the statement that should be used for delayed length
+ computations. We maintain the invariant that all related strinfos
+ have delayed lengths or none do.
+
+ - To record the malloc or calloc call that produced this result. */
gimple *stmt;
/* Pointer to '\0' if known, if NULL, it can be computed as
ptr + length. */
@@ -451,6 +457,45 @@ set_strinfo (int idx, strinfo *si)
(*stridx_to_strinfo)[idx] = si;
}
+/* Return the first strinfo in the related strinfo chain
+ if all strinfos in between belong to the chain, otherwise NULL. */
+
+static strinfo *
+verify_related_strinfos (strinfo *origsi)
+{
+ strinfo *si = origsi, *psi;
+
+ if (origsi->first == 0)
+return NULL;
+ for (; si->prev; si = psi)
+{
+ if (si->first != origsi->first)
+ return NULL;
+ psi = get_strinfo (si->prev);
+ if (psi == NULL)
+ return NULL;
+ if (psi->next != si->idx)
+ return NULL;
+}
+ if (si->idx != si->first)
+return NULL;
+ return si;
+}
+
+/* Set SI's endptr to ENDPTR and compute its length based on SI->ptr.
+ Use LOC for folding. */
+
+static void
+set_endptr_and_length (location_t loc, strinfo *si, tree endptr)
+{
+ si->endptr = endptr;
+ si->stmt = NULL;
+ tree start_as_size = fold_convert_loc (loc, size_type_node, si->ptr);
+ tree end_as_size = fold_convert_loc (loc, size_type_node, endptr);
+ si->length = fold_
[1/2] Add get_next_strinfo helper function
This patch just adds a helper function for getting the next strinfo
in a chain, since part 2 adds another place where we do that.
Tested on aarch64-linux-gnu and x86_64-linux-gnu. OK to install?
Thanks,
Richard
2017-05-16 Richard Sandiford
gcc/
* tree-ssa-strlen.c (get_next_strinfo): New function.
(get_stridx_plus_constant): Use it.
(zero_length_string): Likewise.
(adjust_related_strinfos): Likewise.
(adjust_last_stmt): Likewise.
Index: gcc/tree-ssa-strlen.c
===
--- gcc/tree-ssa-strlen.c 2017-05-15 19:57:18.899053381 +0100
+++ gcc/tree-ssa-strlen.c 2017-05-15 20:50:21.412511763 +0100
@@ -156,6 +156,19 @@ get_strinfo (int idx)
return (*stridx_to_strinfo)[idx];
}
+/* Get the next strinfo in the chain after SI, or null if none. */
+
+static inline strinfo *
+get_next_strinfo (strinfo *si)
+{
+ if (si->next == 0)
+return NULL;
+ strinfo *nextsi = get_strinfo (si->next);
+ if (nextsi == NULL || nextsi->first != si->first || nextsi->prev != si->idx)
+return NULL;
+ return nextsi;
+}
+
/* Helper function for get_stridx. */
static int
@@ -665,10 +678,8 @@ get_stridx_plus_constant (strinfo *bases
gcc_checking_assert (compare_tree_int (si->length, off) != -1);
for (chainsi = si; chainsi->next; chainsi = si)
{
- si = get_strinfo (chainsi->next);
+ si = get_next_strinfo (chainsi);
if (si == NULL
- || si->first != chainsi->first
- || si->prev != chainsi->idx
|| si->length == NULL_TREE
|| TREE_CODE (si->length) != INTEGER_CST)
break;
@@ -736,26 +747,18 @@ zero_length_string (tree ptr, strinfo *c
si = verify_related_strinfos (chainsi);
if (si)
{
- chainsi = si;
- for (; chainsi->next; chainsi = si)
+ do
{
- if (chainsi->endptr == NULL_TREE)
+ gcc_assert (si->length || si->stmt);
+ if (si->endptr == NULL_TREE)
{
- chainsi = unshare_strinfo (chainsi);
- chainsi->endptr = ptr;
+ si = unshare_strinfo (si);
+ si->endptr = ptr;
}
- si = get_strinfo (chainsi->next);
- if (si == NULL
- || si->first != chainsi->first
- || si->prev != chainsi->idx)
- break;
- }
- gcc_assert (chainsi->length || chainsi->stmt);
- if (chainsi->endptr == NULL_TREE)
- {
- chainsi = unshare_strinfo (chainsi);
- chainsi->endptr = ptr;
+ chainsi = si;
+ si = get_next_strinfo (si);
}
+ while (si != NULL);
if (chainsi->length && integer_zerop (chainsi->length))
{
if (chainsi->next)
@@ -833,12 +836,8 @@ adjust_related_strinfos (location_t loc,
si->endptr = NULL_TREE;
si->dont_invalidate = true;
}
- if (si->next == 0)
- return;
- nsi = get_strinfo (si->next);
- if (nsi == NULL
- || nsi->first != si->first
- || nsi->prev != si->idx)
+ nsi = get_next_strinfo (si);
+ if (nsi == NULL)
return;
si = nsi;
}
@@ -995,15 +994,9 @@ adjust_last_stmt (strinfo *si, gimple *s
return;
while (firstsi != lastsi)
{
- strinfo *nextsi;
- if (firstsi->next == 0)
- return;
- nextsi = get_strinfo (firstsi->next);
- if (nextsi == NULL
- || nextsi->prev != firstsi->idx
- || nextsi->first != si->first)
+ firstsi = get_next_strinfo (firstsi);
+ if (firstsi == NULL)
return;
- firstsi = nextsi;
}
}
Re: [PATCH] [i386] Recompute the frame layout less often
On 05/16/2017 07:00, Daniel Santos wrote:
>
> Ian, would you mind looking at this please? A combination of my
> -mcall-ms2sysv-xlogues patch with Bernd's patch is causing problems when
> ix86_expand_split_stack_prologue() calls ix86_expand_call().
Here is what I am testing currently.
I fixed the test case that crashed before, and it bootstraps and reg-tests
cleanly.
It would be good to have test cases for each of the not-supported warnings that
can happen, so far I only managed to get a test case for -fsplit-stack.
But I am not sure if a similar problem exists with ix86_static_chain_on_stack.
It is not obvious if that can change after reload_completed or not.
Thanks
Bernd.Index: gcc/config/i386/i386.c
===
--- gcc/config/i386/i386.c (revision 248031)
+++ gcc/config/i386/i386.c (working copy)
@@ -2425,7 +2425,9 @@ static int const x86_64_int_return_registers[4] =
/* Additional registers that are clobbered by SYSV calls. */
-unsigned const x86_64_ms_sysv_extra_clobbered_registers[12] =
+#define NUM_X86_64_MS_CLOBBERED_REGS 12
+static int const x86_64_ms_sysv_extra_clobbered_registers
+ [NUM_X86_64_MS_CLOBBERED_REGS] =
{
SI_REG, DI_REG,
XMM6_REG, XMM7_REG,
@@ -2484,13 +2486,13 @@ class xlogue_layout {
needs to store registers based upon data in the machine_function. */
HOST_WIDE_INT get_stack_space_used () const
{
-const struct machine_function &m = *cfun->machine;
-unsigned last_reg = m.call_ms2sysv_extra_regs + MIN_REGS - 1;
+const struct machine_function *m = cfun->machine;
+unsigned last_reg = m->call_ms2sysv_extra_regs + MIN_REGS - 1;
-gcc_assert (m.call_ms2sysv_extra_regs <= MAX_EXTRA_REGS);
+gcc_assert (m->call_ms2sysv_extra_regs <= MAX_EXTRA_REGS);
return m_regs[last_reg].offset
- + (m.call_ms2sysv_pad_out ? 8 : 0)
- + STUB_INDEX_OFFSET;
+ + (m->call_ms2sysv_pad_out ? 8 : 0)
+ + STUB_INDEX_OFFSET;
}
/* Returns the offset for the base pointer used by the stub. */
@@ -2532,7 +2534,7 @@ class xlogue_layout {
/* Lazy-inited cache of symbol names for stubs. */
char m_stub_names[XLOGUE_STUB_COUNT][VARIANT_COUNT][STUB_NAME_MAX_LEN];
- static const struct xlogue_layout GTY(()) s_instances[XLOGUE_SET_COUNT];
+ static const struct GTY(()) xlogue_layout s_instances[XLOGUE_SET_COUNT];
};
const char * const xlogue_layout::STUB_BASE_NAMES[XLOGUE_STUB_COUNT] = {
@@ -2573,7 +2575,7 @@ const unsigned xlogue_layout::REG_ORDER[xlogue_lay
};
/* Instantiates all xlogue_layout instances. */
-const struct xlogue_layout GTY(())
+const struct GTY(()) xlogue_layout
xlogue_layout::s_instances[XLOGUE_SET_COUNT] = {
xlogue_layout (0, false),
xlogue_layout (8, false),
@@ -2583,7 +2585,8 @@ xlogue_layout::s_instances[XLOGUE_SET_COUNT] = {
/* Return an appropriate const instance of xlogue_layout based upon values
in cfun->machine and crtl. */
-const struct xlogue_layout &xlogue_layout::get_instance ()
+const struct xlogue_layout &
+xlogue_layout::get_instance ()
{
enum xlogue_stub_sets stub_set;
bool aligned_plus_8 = cfun->machine->call_ms2sysv_pad_in;
@@ -2607,10 +2610,11 @@ unsigned
xlogue_layout::compute_stub_managed_regs (HARD_REG_SET &stub_managed_regs)
{
bool hfp = frame_pointer_needed || stack_realign_fp;
-
unsigned i, count;
unsigned regno;
+ CLEAR_HARD_REG_SET (stub_managed_regs);
+
for (i = 0; i < NUM_X86_64_MS_CLOBBERED_REGS; ++i)
{
regno = x86_64_ms_sysv_extra_clobbered_registers[i];
@@ -2630,8 +2634,8 @@ xlogue_layout::compute_stub_managed_regs (HARD_REG
add_to_hard_reg_set (&stub_managed_regs, DImode, regno);
++count;
}
-gcc_assert (count >= MIN_REGS && count <= MAX_REGS);
-return count;
+ gcc_assert (count >= MIN_REGS && count <= MAX_REGS);
+ return count;
}
/* Constructor for xlogue_layout. */
@@ -2639,11 +2643,11 @@ xlogue_layout::xlogue_layout (HOST_WIDE_INT stack_
: m_hfp (hfp) , m_nregs (hfp ? 17 : 18),
m_stack_align_off_in (stack_align_off_in)
{
+ HOST_WIDE_INT offset = stack_align_off_in;
+ unsigned i, j;
+
memset (m_regs, 0, sizeof (m_regs));
memset (m_stub_names, 0, sizeof (m_stub_names));
-
- HOST_WIDE_INT offset = stack_align_off_in;
- unsigned i, j;
for (i = j = 0; i < MAX_REGS; ++i)
{
unsigned regno = REG_ORDER[i];
@@ -2662,11 +2666,12 @@ xlogue_layout::xlogue_layout (HOST_WIDE_INT stack_
m_regs[j].regno= regno;
m_regs[j++].offset = offset - STUB_INDEX_OFFSET;
}
-gcc_assert (j == m_nregs);
+ gcc_assert (j == m_nregs);
}
-const char *xlogue_layout::get_stub_name (enum xlogue_stub stub,
- unsigned n_extra_regs) const
+const char *
+xlogue_layout::get_stub_name (enum xlogue_stub stub,
+ unsigned n_extra_regs) const
{
xlogue_layout *writey_this = const_cast(this);
char *name = writey_this->m_stub_names[stub][n_extra_regs];
@@ -2676,7 +2681,7 @@ xlogue_layout::xlogue_layou
RE: [ARM] Enable FP16 vector arithmetic operations.
Hi Kyrill, > > Sorry for missing this. > For the record you are referring to the patch at: > https://gcc.gnu.org/ml/gcc-patches/2016-09/msg01700.html > > This is ok and in line with what we do for the f32 intrinsics. > My only concern was that we can do this only if > __ARM_FEATURE_FP16_VECTOR_ARITHMETIC > is defined from the architecture/fpu level, but these intrinsics are already > gated on that in arm_neon.h. > > This is ok for trunk if a bootstrap and test run on arm-none-linux-gnueabihf > with current trunk shows no issues. Thanks, bootstrapped and regtested now on arm-none-linux-gnueabihf and no issues. I'll go ahead and commit then. Regards, Tamar > > Thanks, > Kyrill > > > Tamar > > > > From: gcc-patches-ow...@gcc.gnu.org > on > > behalf of Matthew Wahab > > Sent: Friday, September 23, 2016 4:02 PM > > To: gcc-patches > > Subject: [ARM] Enable FP16 vector arithmetic operations. > > > > Hello, > > > > Support for the ARMv8.2-A FP16 NEON arithmetic instructions was added > > using non-standard names for the instruction patterns. This was needed > > because the NEON floating point semantics meant that their use by the > > compiler for HFmode arithmetic operations needed to be restricted. > > This follows the implementation for 32-bit NEON intructions. > > > > As with the 32-bit instructions, the restriction on the HFmode > > operation can be lifted when -funsafe-math-optimizations is enabled. > > This patch does that, defining the standard pattern names addhf3, > > subhf3, mulhf3 and fmahf3. > > > > This patch also updates the NEON intrinsics to use the arithmetic > > operations when -ffast-math is enabled. This is to make keep the > > 16-bit support consistent with the 32-bit supportd. It is needed so > > that code using the f16 intrinsics are subject to the same > > optimizations as code using the f32 intrinsics would be. > > > > Tested for arm-none-linux-gnueabihf with native bootstrap and make > > check on ARMv8-A and for arm-none-eabi and armeb-none-eabi with > > cross-compiled make check on an ARMv8.2-A emulator. > > > > Ok for trunk? > > Matthew > > > > gcc/ > > 2016-09-23 Matthew Wahab > > > > * config/arm/arm_neon.h (vadd_f16): Use standard arithmetic > > operations in fast-math mode. > > (vaddq_f16): Likewise. > > (vmul_f16): Likewise. > > (vmulq_f16): Likewise. > > (vsub_f16): Likewise. > > (vsubq_f16): Likewise. > > * config/arm/neon.md (add3): New. > > (sub3): New. > > (fma:3): New. Also remove outdated comment. > > (mul3): New. > > > > testsuite/ > > 2016-09-23 Matthew Wahab > > > > * gcc.target/arm/armv8_2-fp16-arith-1.c: Expand comment. Update > > expected output of vadd, vsub and vmul instructions. > > * gcc.target/arm/armv8_2-fp16-arith-2.c: New. > > * gcc.target/arm/armv8_2-fp16-neon-2.c: New. > > * gcc.target/arm/armv8_2-fp16-neon-3.c: New.
[PATCH][OBVIOUS] Fix 2 typos in ipa-devirt.c.
Hello.
This fixes 2 typos in ipa-devirt.c, applying as obvious.
Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.
Martin
>From 3ca7dbf8b4006813320852480509de1571cc3154 Mon Sep 17 00:00:00 2001
From: marxin
Date: Mon, 15 May 2017 15:44:27 +0200
Subject: [PATCH] Fix 2 typos in ipa-devirt.c.
gcc/ChangeLog:
2017-05-15 Martin Liska
PR ipa/79849.
PR ipa/79850.
* ipa-devirt.c (warn_types_mismatch): Fix typo.
(odr_types_equivalent_p): Likewise.
---
gcc/ipa-devirt.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/gcc/ipa-devirt.c b/gcc/ipa-devirt.c
index 20e0dd68b4d..2813394274f 100644
--- a/gcc/ipa-devirt.c
+++ b/gcc/ipa-devirt.c
@@ -1227,7 +1227,7 @@ warn_types_mismatch (tree t1, tree t2, location_t loc1, location_t loc2)
if (types_odr_comparable (t1, t2, true)
&& types_same_for_odr (t1, t2, true))
inform (loc_t1,
- "type %qT itself violate the C++ One Definition Rule", t1);
+ "type %qT itself violates the C++ One Definition Rule", t1);
/* Prevent pointless warnings like "struct aa" should match "struct aa". */
else if (TYPE_NAME (t1) == TYPE_NAME (t2)
&& TREE_CODE (t1) == TREE_CODE (t2) && !loc_t2_useful)
@@ -1574,7 +1574,7 @@ odr_types_equivalent_p (tree t1, tree t2, bool warn, bool *warned,
if (DECL_ARTIFICIAL (f1))
break;
warn_odr (t1, t2, f1, f2, warn, warned,
- G_("fields has different layout "
+ G_("fields have different layout "
"in another translation unit"));
return false;
}
--
2.12.2
Re: Fix minor reorg.c bug affecting MIPS targets
Hi:
There are new failures between r248067 and r248036 on
mips64el-unknown-linux-gnu.
ERROR: gcc.target/mips/reorgbug-1.c -O0 : Unrecognised option: -O2
for " dg-options 1 "-O2 -msoft-float -mips2" "
UNRESOLVED: gcc.target/mips/reorgbug-1.c -O0 : Unrecognised
option: -O2 for " dg-options 1 "-O2 -msoft-float -mips2" "
ERROR: gcc.target/mips/reorgbug-1.c -O1 : Unrecognised option: -O2
for " dg-options 1 "-O2 -msoft-float -mips2" "
UNRESOLVED: gcc.target/mips/reorgbug-1.c -O1 : Unrecognised
option: -O2 for " dg-options 1 "-O2 -msoft-float -mips2" "
ERROR: gcc.target/mips/reorgbug-1.c -O2 -flto
-fno-use-linker-plugin -flto-partition=none : Unrecognised option: -O2
for " dg-options 1 "-O2 -msoft-float -mips2" "
UNRESOLVED: gcc.target/mips/reorgbug-1.c -O2 -flto
-fno-use-linker-plugin -flto-partition=none : Unrecognised option: -O2
for " dg-options 1 "-O2 -msoft-float -mips2" "
ERROR: gcc.target/mips/reorgbug-1.c -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects : Unrecognised option: -O2 for " dg-options 1
"-O2 -msoft-float -mips2" "
UNRESOLVED: gcc.target/mips/reorgbug-1.c -O2 -flto
-fuse-linker-plugin -fno-fat-lto-objects : Unrecognised option: -O2
for " dg-options 1 "-O2 -msoft-float -mips2" "
ERROR: gcc.target/mips/reorgbug-1.c -O2 : Unrecognised option: -O2
for " dg-options 1 "-O2 -msoft-float -mips2" "
UNRESOLVED: gcc.target/mips/reorgbug-1.c -O2 : Unrecognised
option: -O2 for " dg-options 1 "-O2 -msoft-float -mips2" "
ERROR: gcc.target/mips/reorgbug-1.c -O3 -g : Unrecognised option:
-O2 for " dg-options 1 "-O2 -msoft-float -mips2" "
UNRESOLVED: gcc.target/mips/reorgbug-1.c -O3 -g : Unrecognised
option: -O2 for " dg-options 1 "-O2 -msoft-float -mips2" "
ERROR: gcc.target/mips/reorgbug-1.c -Os : Unrecognised option: -O2
for " dg-options 1 "-O2 -msoft-float -mips2" "
UNRESOLVED: gcc.target/mips/reorgbug-1.c -Os : Unrecognised
option: -O2 for " dg-options 1 "-O2 -msoft-float -mips2" "
I don't know why? just delete the "-O2" options in dg-options, then
the test passed.
diff --git a/gcc/testsuite/gcc.target/mips/reorgbug-1.c
b/gcc/testsuite/gcc.target/mips/reorgbug-1.c
index b820a2b..9537d21 100644
--- a/gcc/testsuite/gcc.target/mips/reorgbug-1.c
+++ b/gcc/testsuite/gcc.target/mips/reorgbug-1.c
@@ -1,4 +1,4 @@
-/* { dg-options "-O2 -msoft-float -mips2" } */
+/* { dg-options "-msoft-float -mips2" } */
typedef long int __int32_t;
typedef long unsigned int __uint32_t;
config info:Compiler version: 8.0.0 20170515 (experimental) (gcc trunk
r248067 mips64el o32 n32 n64)
Platform: mips64el-unknown-linux-gnu
configure flags: --prefix=/home/xuchenghua/toolchain/gcc-trunk-r248067
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --enable-multilib--with-system-zlib
--enable-__cxa_atexit --disable-libunwind-exceptions
--enable-gnu-unique-object --enable-linker-build-id
--enable-languages=c,c++,fortran --enable-plugin
--enable-initfini-array --disable-libgcj --with-arch=mips64r2
--with-abi=64 --with-multilib-list=32,n32,64
--enable-gnu-indirect-function --with-long-double-128
--build=mips64el-unknown-linux --target=mips64el-unknown-linux
--with-pkgversion='gcc trunk r248067 mips64el o32 n32 n64'
--disable-werror
paul
On Tue, May 16, 2017 at 1:22 AM, Jeff Law wrote:
>
>
> There's a subtle bug in reorg.c's relax_delay_slots that my tester tripped
> this weekend. Not sure what changed code generation wise as the affected
> port built just fine last week. But it is what is is.
>
>
>
> Assume before this code we've set TARGET_LABEL to the code_label associated
> with DELAY_JUMP_INSN (which is what we want)...
>
>
>
> /* If the first insn at TARGET_LABEL is redundant with a previous
> insn, redirect the jump to the following insn and process again.
> We use next_real_insn instead of next_active_insn so we
> don't skip USE-markers, or we'll end up with incorrect
> liveness info. */
>
> [ ... ]
>
> /* Similarly, if it is an unconditional jump with one insn in its
> delay list and that insn is redundant, thread the jump. */
> rtx_sequence *trial_seq =
> trial ? dyn_cast (PATTERN (trial)) : NULL;
> if (trial_seq
> && trial_seq->len () == 2
> && JUMP_P (trial_seq->insn (0))
> && simplejump_or_return_p (trial_seq->insn (0))
> && redundant_insn (trial_seq->insn (1), insn, vNULL))
> {
> target_label = JUMP_LABEL (trial_seq->insn (0));
> if (ANY_RETURN_P (target_label))
> target_label = find_end_label (target_label);
>
> if (target_label
> && redirect_with_delay_slots_safe_p (delay_jump_insn,
>target_label, insn))
> {
> update_block (trial_seq->insn (1), insn);
> reorg_redirect_jump (delay_jump_insn, target_label);
> next = insn;
> cont
[PATCH] Add cross-reference for BADNAMES in libstdc++ manual
The bad names are not in a file called BADNAMES, so link from the old chunk of documentation to the new position in the manual. * doc/xml/manual/appendix_contributing.xml: Link to the list of bad identifiers. * doc/html/*: Regenerate. Committed to trunk. commit fe4721b08daaf8af40859c9fef15ef7d601906a4 Author: Jonathan Wakely Date: Tue May 16 10:45:30 2017 +0100 Add cross-reference for BADNAMES in libstdc++ manual * doc/xml/manual/appendix_contributing.xml: Link to the list of bad identifiers. * doc/html/*: Regenerate. diff --git a/libstdc++-v3/doc/xml/manual/appendix_contributing.xml b/libstdc++-v3/doc/xml/manual/appendix_contributing.xml index dbc671e..f5b759a 100644 --- a/libstdc++-v3/doc/xml/manual/appendix_contributing.xml +++ b/libstdc++-v3/doc/xml/manual/appendix_contributing.xml @@ -898,7 +898,7 @@ indicate a place that may require attention for multi-thread safety. Examples: _S_max_elements _S_default_value Don't use names in the same scope that differ only in the prefix, - e.g. _S_top and _M_top. See BADNAMES for a list of forbidden names. + e.g. _S_top and _M_top. See BADNAMES for a list of forbidden names. (The most tempting of these seem to be and "_T" and "__sz".) Names must never have "__" internally; it would confuse name
Re: dejagnu version update?
On 13 May 2017 at 11:38, Jakub Jelinek wrote: > On Sat, May 13, 2017 at 12:24:12PM +0200, Bernhard Reutner-Fischer wrote: >> I guess neither redhat >> (https://access.redhat.com/downloads/content/dejagnu/ redirects to a >> login page but there seem to be 1.5.1 packages) nor SuSE did update dejagnu >> in the meantime. > > Fedora has dejagnu-1.6 in Fedora 25 and later, dejagnu-1.5.3 in Fedora 24, > older > Fedora versions are EOL. RHEL 7 has dejagnu-1.5.1, RHEL 6 as well as RHEL 5 > has > dejagnu-1.4.4, older RHEL versions are EOL. FWIW 1.5.3 has a fix which I rely on for libstdc++ testing, but since newer versions are trivial to install by hand I'll be OK if we only bump the minimum to 1.5.0
Re: [gcn][patch] Add -mgpu option and plumb in assembler/linker
On 02/05/17 18:08, Martin Jambor wrote: 1. Add specs to drive the LLVM assembler and linker. It requires them to be installed as "as" and "ld", under $target/bin, but then the compiler Just Works with these specs. ...is that I do not have llvm linker at hand and without it I did not manage to make the patch produce loadable code. Because ROCm 1.5 has been released today, I will update our environment, which is a bit obsolete, get llvm ld and try again. This might take me a few days, so please bear with me for a little more, I would like to make sure it works on carrizos. Any news? If you're happy with the patch I can fix the comment style, and add the documentation Joseph asked for, and get it committed. Andrew
Re: [PATCH] Add cross-reference for BADNAMES in libstdc++ manual
On 16/05/17 10:47 +0100, Jonathan Wakely wrote: The bad names are not in a file called BADNAMES, so link from the old chunk of documentation to the new position in the manual. * doc/xml/manual/appendix_contributing.xml: Link to the list of bad identifiers. * doc/html/*: Regenerate. Committed to trunk. Another cross-reference, committed to trunk. commit 44a0bb0aa0449b85a96f46234aa6245d4e972fd7 Author: Jonathan Wakely Date: Tue May 16 11:37:01 2017 +0100 Add cross-reference for test permutations in libstdc++ manual * doc/xml/manual/appendix_contributing.xml: Link to test docs and note higher DejaGnu version requirement. * doc/html/*: Regenerate. diff --git a/libstdc++-v3/doc/xml/manual/appendix_contributing.xml b/libstdc++-v3/doc/xml/manual/appendix_contributing.xml index f5b759a..4133547 100644 --- a/libstdc++-v3/doc/xml/manual/appendix_contributing.xml +++ b/libstdc++-v3/doc/xml/manual/appendix_contributing.xml @@ -358,7 +358,9 @@ It has subdirectories: library. Support for "make check" and "make check-install" is complete, and runs through all the subdirectories here when this command is issued from the build directory. Please note that -"make check" requires DejaGNU 1.4 or later to be installed. +"make check" requires DejaGnu 1.4 or later to be installed, +or for extra permutations +DejaGnu 1.5.3 or later.
Re: [PATCH] Two DW_OP_GNU_variable_value fixes / tweaks
On Mon, May 15, 2017 at 3:19 PM, Jakub Jelinek wrote: > On Mon, May 15, 2017 at 02:43:43PM +0200, Richard Biener wrote: >> >> While bringing early LTO debug up-to-speed I noticed the following two >> issues. The first patch avoids useless work in >> note_variable_value_in_expr and actually makes use of the DIE we >> eventually create in resolve_variable_value_in_expr. >> >> The second avoids generating a DW_OP_GNU_variable_value for a decl >> we'll never have a DIE for -- this might be less obvious than the >> other patch but I think we'll also never have any other debug info >> we can resolve the decl with(?) >> >> Bootstrapped and tested the first patch sofar >> on x86_64-unknown-linux-gnu, 2nd is pending. >> >> Ok? >> >> Thanks, >> Richard. >> >> 2017-05-15 Richard Biener >> >> * dwarf2out.c (resolve_variable_value_in_expr): Lookup DIE >> just generated. >> (note_variable_value_in_expr): If we resolved the decl ref >> do not push to the stack. > > LGTM. > >> 2017-05-15 Richard Biener >> >> * dwarf2out.c (loc_list_from_tree_1): Do not create >> DW_OP_GNU_variable_value for DECL_IGNORED_P decls. > > Can you verify it e.g. in a bootstrapped cc1plus doesn't change the debug info > (except for dwarf2out.o itself)? > It looks reasonable and it would surprise me if did, just want to be sure. Done. Note it only happened for Ada. Richard. > Jakub
[PATCH] LTO early-debug incremental changes
The following patch ontop of early LTO debug patches get us back to
LTO bootstrap (see also the DW_OP_GNU_variable_value fixes / tweaks mail).
With early LTO debug we have to resolve DW_OP_GNU_variable_value early
as we are going to output the DIEs early. The following patch always
does that conservatively when we generate LTO IL (and does not undo
that for the eventual fat part of the object).
The patch also adjusts asan patterns for PR78063 (libbacktrace doesn't
handle location attributes being in an abstract origin imported from a
different CU). We then print an address rather than file + line info.
The patch also adds a -flto run for the libstdc++ pretty printers
(the original motivation of early LTO debug -- make those work).
I had to work around ld/20882 here.
Richard.
Index: early-lto-debug/gcc/dwarf2out.c
===
--- early-lto-debug.orig/gcc/dwarf2out.c2017-05-16 13:03:51.583346409
+0200
+++ early-lto-debug/gcc/dwarf2out.c 2017-05-16 12:58:20.509820311 +0200
@@ -30643,6 +30642,20 @@ note_variable_value_in_expr (dw_die_ref
{
tree decl = loc->dw_loc_oprnd1.v.val_decl_ref;
dw_die_ref ref = lookup_decl_die (decl);
+ if (! ref && flag_generate_lto)
+ {
+ /* ??? This is somewhat a hack because we do not create DIEs
+ for variables not in BLOCK trees early but when generating
+ early LTO output we need the dw_val_class_decl_ref to be
+ fully resolved. For fat LTO objects we'd also like to
+ undo this after LTO dwarf output. */
+ gcc_assert (DECL_CONTEXT (decl));
+ dw_die_ref ctx = lookup_decl_die (DECL_CONTEXT (decl));
+ gcc_assert (ctx != NULL);
+ gen_decl_die (decl, NULL_TREE, NULL, ctx);
+ ref = lookup_decl_die (decl);
+ gcc_assert (ref != NULL);
+ }
if (ref)
{
loc->dw_loc_oprnd1.val_class = dw_val_class_die_ref;
Index: early-lto-debug/gcc/testsuite/c-c++-common/asan/global-overflow-1.c
===
--- early-lto-debug.orig/gcc/testsuite/c-c++-common/asan/global-overflow-1.c
2017-05-16 10:07:02.111097130 +0200
+++ early-lto-debug/gcc/testsuite/c-c++-common/asan/global-overflow-1.c
2017-05-16 10:07:09.427211120 +0200
@@ -23,6 +23,6 @@ int main() {
}
/* { dg-output "READ of size 1 at 0x\[0-9a-f\]+ thread T0.*(\n|\r\n|\r)" } */
-/* { dg-output "#0 0x\[0-9a-f\]+ +(in _*main
(\[^\n\r]*global-overflow-1.c:20|\[^\n\r]*:0)|\[(\])\[^\n\r]*(\n|\r\n|\r).*" }
*/
+/* { dg-output "#0 0x\[0-9a-f\]+ +(in _*main
(\[^\n\r]*global-overflow-1.c:20|\[^\n\r]*:0|\[^\n\r]*\\+0x\[0-9a-z\]*)|\[(\])\[^\n\r]*(\n|\r\n|\r).*"
} */
/* { dg-output "0x\[0-9a-f\]+ is located 0 bytes to the right of global
variable" } */
/* { dg-output ".*YYY\[^\n\r]* of size 10\[^\n\r]*(\n|\r\n|\r)" } */
Index: early-lto-debug/gcc/testsuite/c-c++-common/asan/heap-overflow-1.c
===
--- early-lto-debug.orig/gcc/testsuite/c-c++-common/asan/heap-overflow-1.c
2017-05-16 10:08:38.876604540 +0200
+++ early-lto-debug/gcc/testsuite/c-c++-common/asan/heap-overflow-1.c
2017-05-16 10:08:45.796712320 +0200
@@ -24,8 +24,8 @@ int main(int argc, char **argv) {
}
/* { dg-output "READ of size 1 at 0x\[0-9a-f\]+ thread T0.*(\n|\r\n|\r)" } */
-/* { dg-output "#0 0x\[0-9a-f\]+ +(in _*main
(\[^\n\r]*heap-overflow-1.c:21|\[^\n\r]*:0)|\[(\]).*(\n|\r\n|\r)" } */
+/* { dg-output "#0 0x\[0-9a-f\]+ +(in _*main
(\[^\n\r]*heap-overflow-1.c:21|\[^\n\r]*:0|\[^\n\r]*\\+0x\[0-9a-z\]*)|\[(\]).*(\n|\r\n|\r)"
} */
/* { dg-output "\[^\n\r]*0x\[0-9a-f\]+ is located 0 bytes to the right of
10-byte region\[^\n\r]*(\n|\r\n|\r)" } */
/* { dg-output "\[^\n\r]*allocated by thread T0 here:\[^\n\r]*(\n|\r\n|\r)" }
*/
/* { dg-output "#0 0x\[0-9a-f\]+ +(in
_*(interceptor_|wrap_|)malloc|\[(\])\[^\n\r]*(\n|\r\n|\r)" } */
-/* { dg-output "#1 0x\[0-9a-f\]+ +(in _*main
(\[^\n\r]*heap-overflow-1.c:19|\[^\n\r]*:0)|\[(\])\[^\n\r]*(\n|\r\n|\r)" } */
+/* { dg-output "#1 0x\[0-9a-f\]+ +(in _*main
(\[^\n\r]*heap-overflow-1.c:19|\[^\n\r]*:0|\[^\n\r]*\\+0x\[0-9a-z\]*)|\[(\])\[^\n\r]*(\n|\r\n|\r)"
} */
Index: early-lto-debug/gcc/testsuite/c-c++-common/asan/misalign-1.c
===
--- early-lto-debug.orig/gcc/testsuite/c-c++-common/asan/misalign-1.c
2017-04-26 16:15:21.708936635 +0200
+++ early-lto-debug/gcc/testsuite/c-c++-common/asan/misalign-1.c
2017-05-16 10:09:59.333857466 +0200
@@ -39,5 +39,5 @@ main ()
/* { dg-output "ERROR: AddressSanitizer:\[^\n\r]*on address\[^\n\r]*" } */
/* { dg-output "0x\[0-9a-f\]+ at pc 0x\[0-9a-f\]+ bp 0x\[0-9a-f\]+ sp
0x\[0-9a-f\]+\[^\n\r]*(\n|\r\n|\r)" } */
/* { dg-output "\[^\n\r]*READ of size 4 at 0x\[0-9a-f\]+ thread
T0\[^\n\r]*(\n|\r\n|\r)" } */
-
[C++ PATCH] namespace depth
Currently, namespace_decls have no record of how deep they reside in the
namespace tree. That makes is_ancestor overly complex (and therefore
bleeds over into unqualified namespace lookup)
This patch adds a SCOPE_DEPTH macro (it may be useful to extend to other
scope-like things). It uses the base.u.bits.address_space field, which
is available to us.
We 'only' permit 255 levels of namespace.
nathan
--
Nathan Sidwell
2017-05-16 Nathan Sidwell
* cp-tree.h (SCOPE_DEPTH): New.
* name-lookup.h (is_nested_namespace): Declare.
* name-lookup.c (is_nested_namespace): New.
(is_ancestor): Use it.
(set_decl_namespace): Likewise.
(push_namespace): Set SCOPE_DEPTH.
* pt.c (check_specialization_namespace): Use is_nested_namespace.
(check_unqualigied_spec_or_inst): Likewise.
Index: cp-tree.h
===
--- cp-tree.h (revision 248094)
+++ cp-tree.h (working copy)
@@ -2917,6 +2917,11 @@ struct GTY(()) lang_decl {
#define LOCAL_CLASS_P(NODE)\
(decl_function_context (TYPE_MAIN_DECL (NODE)) != NULL_TREE)
+/* The nesting depth of namespace, class or function. Makes is_ancestor much
+ simpler. Only 8 bits available. */
+#define SCOPE_DEPTH(NODE) \
+ (NAMESPACE_DECL_CHECK (NODE)->base.u.bits.address_space)
+
/* Whether the namepace is an inline namespace. */
#define DECL_NAMESPACE_INLINE_P(NODE) \
TREE_LANG_FLAG_0 (NAMESPACE_DECL_CHECK (NODE))
Index: name-lookup.c
===
--- name-lookup.c (revision 248094)
+++ name-lookup.c (working copy)
@@ -3327,6 +3327,25 @@ do_local_using_decl (tree decl, tree sco
cp_emit_debug_info_for_using (orig_decl, current_scope());
}
+/* Returns true if ANCESTOR encloses DESCENDANT, including matching.
+ Both are namespaces. */
+
+bool
+is_nested_namespace (tree ancestor, tree descendant, bool inline_only)
+{
+ int depth = SCOPE_DEPTH (ancestor);
+
+ if (!depth && !inline_only)
+/* The global namespace encloses everything. */
+return true;
+
+ while (SCOPE_DEPTH (descendant) > depth
+ && (!inline_only || DECL_NAMESPACE_INLINE_P (descendant)))
+descendant = CP_DECL_CONTEXT (descendant);
+
+ return ancestor == descendant;
+}
+
/* Returns true if ROOT (a namespace, class, or function) encloses
CHILD. CHILD may be either a class type or a namespace. */
@@ -3343,19 +3362,22 @@ is_ancestor (tree root, tree child)
if (root == global_namespace)
return true;
- while (true)
+ /* Search until we reach namespace scope. */
+ while (TREE_CODE (child) != NAMESPACE_DECL)
{
- /* If we've run out of scopes, stop. */
- if (!child)
- return false;
/* If we've reached the ROOT, it encloses CHILD. */
if (root == child)
return true;
/* Go out one level. */
if (TYPE_P (child))
child = TYPE_NAME (child);
- child = DECL_CONTEXT (child);
+ child = CP_DECL_CONTEXT (child);
}
+
+ if (TREE_CODE (root) == NAMESPACE_DECL)
+return is_nested_namespace (root, child);
+
+ return false;
}
/* Enter the class or namespace scope indicated by T suitable for name
@@ -4076,7 +4098,7 @@ set_decl_namespace (tree decl, tree scop
scope = ORIGINAL_NAMESPACE (scope);
/* It is ok for friends to be qualified in parallel space. */
- if (!friendp && !is_ancestor (current_namespace, scope))
+ if (!friendp && !is_nested_namespace (current_namespace, scope))
error ("declaration of %qD not in a namespace surrounding %qD",
decl, scope);
DECL_CONTEXT (decl) = FROB_CONTEXT (scope);
@@ -4153,7 +4175,7 @@ set_decl_namespace (tree decl, tree scop
}
if (found)
{
- if (!is_associated_namespace (scope, CP_DECL_CONTEXT (found)))
+ if (!is_nested_namespace (scope, CP_DECL_CONTEXT (found), true))
goto complain;
if (DECL_HIDDEN_FRIEND_P (found))
{
@@ -6499,6 +6521,11 @@ push_namespace (tree name, bool make_inl
if (!ns)
{
ns = build_lang_decl (NAMESPACE_DECL, name, void_type_node);
+ SCOPE_DEPTH (ns) = SCOPE_DEPTH (current_namespace) + 1;
+ if (!SCOPE_DEPTH (ns))
+ /* We only allow depth 255. */
+ sorry ("cannot nest more than %d namespaces",
+ SCOPE_DEPTH (current_namespace));
DECL_CONTEXT (ns) = FROB_CONTEXT (current_namespace);
new_ns = true;
Index: name-lookup.h
===
--- name-lookup.h (revision 248094)
+++ name-lookup.h (working copy)
@@ -292,6 +292,8 @@ extern void print_binding_stack (void);
extern void pop_everything (void);
extern void keep_next_level (bool);
extern bool is_ancestor (tree ancestor, tree descendant);
+extern bool is_nested_namespace (tree parent, tree descendant,
+ bool inline_only = false);
extern tree push_scope (tree);
extern void pop_scope (tree);
extern tree push_inner_scope (tree);
Index: pt.c
===
--- pt.c (revision 2480
Re: [RFC] propagate malloc attribute in ipa-pure-const pass
On Mon, 15 May 2017, Prathamesh Kulkarni wrote:
> Hi,
> I have attached a bare-bones prototype patch that propagates malloc attribute
> in
> ipa-pure-const. As far as I understand, from the doc a function could
> be annotated
> with malloc attribute if it returns a pointer to a newly allocated
> memory block (uninitialized or zeroed) and the pointer does not alias
> any other valid pointer ?
>
> * Analysis
> The analysis used by the patch in malloc_candidate_p is too conservative,
> and I would be grateful for suggestions on improving it.
> Currently it only checks if:
> 1) The function returns a value of pointer type.
> 2) SSA_NAME_DEF_STMT (return_value) is either a function call or a phi, and
> SSA_NAME_DEF_STMT(each element of phi) is function call.
> 3) The return-value has immediate uses only within comparisons (gcond
> or gassign) and return_stmt (and likewise a phi arg has immediate use only
> within comparison or the phi stmt).
>
> The intent is that malloc_candidate_p(node) returns true if node
> returns the return value of it's callee, and the return value is only
> used for comparisons within node.
> Then I assume it's safe (although conservative) to decide that node
> could possibly be a malloc function if callee is found to be malloc ?
>
> for eg:
> void *f(size_t n)
> {
> void *p = __builtin_malloc (n);
> if (p == 0)
> __builtin_abort ();
> return p;
> }
>
> malloc_candidate_p would determine f to be a candidate for malloc
> attribute since it returns the return-value of it's callee
> (__builtin_malloc) and the return value is used only within comparison
> and return_stmt.
>
> However due to the imprecise analysis it misses this case:
> char **g(size_t n)
> {
> char **p = malloc (sizeof(char *) * 10);
> for (int i = 0; i < 10; i++)
> p[i] = malloc (sizeof(char) * n);
> return p;
> }
> I suppose g() could be annotated with malloc here ?
It cannot because what p points to is initialized. If you do then
char **x = g(10);
**x = 1;
will be optimized away. Now what would be interesting is to do
"poor mans IPA PTA", namely identify functions that are a) small,
b) likely return a newly allocated pointer. At PTA time then
"inline" all such wrappers, but only for the PTA constraints.
That will give more precise points-to results (and can handle more
cases, esp. initialization) than just annotating functions with 'malloc'.
+ /* With non-call exceptions we can't say for sure if other function
+body was not possibly optimized to still throw. */
+ if (!non_call || node->binds_to_current_def_p ())
+ {
+ DECL_IS_MALLOC (node->decl) = true;
+ *changed = true;
I don't see how malloc throwing would be an issue.
+ FOR_EACH_IMM_USE_STMT (use_stmt, use_iter, retval)
+if (gcond *cond = dyn_cast (use_stmt))
+ {
+ enum tree_code code = gimple_cond_code (cond);
+ if (TREE_CODE_CLASS (code) != tcc_comparison)
always false
+ RETURN_FROM_IMM_USE_STMT (use_iter, false);
I think you want to disallow eq/ne_expr against sth not integer_zerop.
+else if (gassign *ga = dyn_cast (use_stmt))
+ {
+ enum tree_code code = gimple_assign_rhs_code (ga);
+ if (TREE_CODE_CLASS (code) != tcc_comparison)
+ RETURN_FROM_IMM_USE_STMT (use_iter, false);
likewise.
+static bool
+malloc_candidate_p (function *fun, vec& callees)
+{
+ basic_block bb;
+ FOR_EACH_BB_FN (bb, fun)
+{
+ for (gimple_stmt_iterator gsi = gsi_start_bb (bb);
+ !gsi_end_p (gsi);
+ gsi_next (&gsi))
+ {
+ greturn *ret_stmt = dyn_cast (gsi_stmt (gsi));
+ if (ret_stmt)
I think you want do do this much cheaper by only walking the last
stmt of predecessor(s) of EXIT_BLOCK_FOR_FN. (s) because
we have multiple return stmts for
int foo (int i)
{
if (i)
return;
else
return i;
}
but all return stmts will be the last stmt in one of the exit block
predecessors.
+ if (!check_retval_uses (retval, ret_stmt))
+ return false;
+
+ gimple *def = SSA_NAME_DEF_STMT (retval);
+ if (gcall *call_stmt = dyn_cast (def))
+ {
+ tree callee_decl = gimple_call_fndecl (call_stmt);
+ /* FIXME: In case of indirect call, callee_decl might be
NULL
+Not sure what to do in that case, punting for now.
*/
+ if (!callee_decl)
+ return false;
+ cgraph_node *callee = cgraph_node::get_create
(callee_decl);
+ callees.safe_push (callee);
+ }
+ else if (gphi *phi = dyn_cast (def))
+ for (unsigned i = 0; i < gimple_phi_num_args (phi); ++i)
+ {
+ tree arg = gimple_phi_arg_def (phi, i);
+ if (TREE_CODE (arg) != SSA_NAME)
+ return false;
+ if (!check_retval_uses (arg, phi))
+ return
Re: Bump version namespace and remove _Rb_tree useless template parameter
On 11/05/17 22:31 +0200, François Dumont wrote: On 10/05/2017 22:44, François Dumont wrote: On 10/05/2017 11:28, Jonathan Wakely wrote: On 10/05/17 11:15 +0200, Paolo Carlini wrote: Hi, On 10/05/2017 11:12, Jonathan Wakely wrote: Looks good to me. Paolo, what do you think about bumping the versioned namespace and SONAME to 8? Sure, makes sense to me too. Please commit it then, François - thanks! Done, don't hesitate to update the ChangeLog if I used some wrong terms. I'll also send some changes requiring this bump. François I just realized that I forgot to commit the small _Rb_tree_impl change part. It is done now. And also the regenerated configure script. I'll do that.
Re: dejagnu version update?
On 16 May 2017 11:54:18 CEST, Jonathan Wakely wrote: >On 13 May 2017 at 11:38, Jakub Jelinek wrote: >> On Sat, May 13, 2017 at 12:24:12PM +0200, Bernhard Reutner-Fischer >wrote: >>> I guess neither redhat >>> (https://access.redhat.com/downloads/content/dejagnu/ redirects to a >>> login page but there seem to be 1.5.1 packages) nor SuSE did update >dejagnu in the meantime. >> >> Fedora has dejagnu-1.6 in Fedora 25 and later, dejagnu-1.5.3 in >Fedora 24, older >> Fedora versions are EOL. RHEL 7 has dejagnu-1.5.1, RHEL 6 as well as >RHEL 5 has >> dejagnu-1.4.4, older RHEL versions are EOL. > >FWIW 1.5.3 has a fix which I rely on for libstdc++ testing, but since >newer versions are trivial to install by hand I'll be OK if we only >bump the minimum to 1.5.0 1.5.0 wouldn't buy us anything as the "libdirs" handling is only in 1.5.2 and later. thanks
Re: dejagnu version update?
On 16 May 2017 at 13:13, Bernhard Reutner-Fischer wrote: > 1.5.0 wouldn't buy us anything as the "libdirs" handling is only in 1.5.2 and > later. Ah I missed that in the earlier discussion. The change I care about in 1.5.3 is http://git.savannah.gnu.org/gitweb/?p=dejagnu.git;a=commit;h=5256bd82343000c76bc0e48139003f90b6184347
Re: dejagnu version update?
On 16 May 2017 at 14:16, Jonathan Wakely wrote: > On 16 May 2017 at 13:13, Bernhard Reutner-Fischer wrote: >> 1.5.0 wouldn't buy us anything as the "libdirs" handling is only in 1.5.2 >> and later. > > Ah I missed that in the earlier discussion. > > The change I care about in 1.5.3 is > http://git.savannah.gnu.org/gitweb/?p=dejagnu.git;a=commit;h=5256bd82343000c76bc0e48139003f90b6184347 the libdirs handling is http://git.savannah.gnu.org/gitweb/?p=dejagnu.git;a=commit;h=5481f29161477520c691d525653323b82fa47ad7 and applies cleanly to everything 1.5.x-ish. Didn't try if it applies to 1.4.4. thanks,
[gomp4] Implement OpenACC 2.5 reference counting, and finalize clause
This patch for gomp-4_0-branch implements OpenACC 2.5 reference counting of mappings, the finalize clause of the exit data directive, and the corresponding API routines. Tested without regressions, committed to gomp-4_0-branch. Chung-Lin 2017-05-16 Chung-Lin Tang gcc/c/ * c-parser.c (c_parser_omp_clause_name): Handle 'finalize' clause. (c_parser_oacc_simple_clause): Add 'finalize' to comments. (c_parser_oacc_all_clauses): Handle PRAGMA_OACC_CLAUSE_FINALIZE. (OACC_EXIT_DATA_CLAUSE_MASK): Add PRAGMA_OACC_CLAUSE_FINALIZE. * c-typeck.c (c_finish_omp_clauses): Handle OMP_CLAUSE_FINALIZE. gcc/cp/ * parser.c (cp_parser_omp_clause_name): Handle 'finalize' clause. (cp_parser_oacc_simple_clause): Add 'finalize' to comments. (cp_parser_oacc_all_clauses): Handle PRAGMA_OACC_CLAUSE_FINALIZE. (OACC_EXIT_DATA_CLAUSE_MASK): Add PRAGMA_OACC_CLAUSE_FINALIZE. * semantics.c (finish_omp_clauses): Handle OMP_CLAUSE_FINALIZE. gcc/c-family/ * c-pragma.h (enum pragma_omp_clause): Add PRAGMA_OACC_CLAUSE_FINALIZE. gcc/fortran/ * gfortran.h (struct gfc_omp_clauses): Add 'finalize:1' bitfield. * openmp.c (enum omp_mask2): Add OMP_CLAUSE_FINALIZE. (gfc_match_omp_clauses): Handle 'finalize' clause. (OACC_EXIT_DATA_CLAUSES): Add OMP_CLAUSE_FINALIZE. * trans-openmp.c (gfc_trans_omp_clauses_1): Handle finalize bit. gcc/ * tree-core.h (enum omp_clause_code): Add OMP_CLAUSE_FINALIZE. * tree.c (omp_clause_num_ops): Add entry for OMP_CLAUSE_FINALIZE. (omp_clause_code_name): Add "finalize" entry. * omp-low.c (scan_sharing_clauses): Handle OMP_CLAUSE_FINALIZE. (expand_omp_target): Add finalize argument for GOACC_enter_exit_data call. * gimplify.c (gimplify_scan_omp_clauses): Handle OMP_CLAUSE_FINALIZE. (gimplify_adjust_omp_clauses): Likewise. libgomp/ * openacc.h (acc_copyout_finalize): Declare new API function. (acc_copyout_finalize_async): Likewise. (acc_delete_finalize): Likewise. (acc_delete_finalize_async): Likewise. * openacc_lib.h (acc_copyout_finalize): Declare new API function. (acc_copyout_finalize_async): Likewise. (acc_delete_finalize): Likewise. (acc_delete_finalize_async): Likewise. * openacc.f90 (acc_copyout_finalize_32_h): Define. (acc_copyout_finalize_64_h): Likewise. (acc_copyout_finalize_array_h): Likewise. (acc_copyout_finalize_l): Likewise. (acc_copyout_finalize_async_32_h): Define. (acc_copyout_finalize_async_64_h): Likewise. (acc_copyout_finalize_async_array_h): Likewise. (acc_copyout_finalize_async_l): Likewise. (acc_delete_finalize_32_h): Define. (acc_delete_finalize_64_h): Likewise. (acc_delete_finalize_array_h): Likewise. (acc_delete_finalize_l): Likewise. (acc_delete_finalize_async_32_h): Define. (acc_delete_finalize_async_64_h): Likewise. (acc_delete_finalize_async_array_h): Likewise. (acc_delete_finalize_async_l): Likewise. * libgomp.map (OACC_2.5): Add acc_copyout_finalize* and acc_delete_finalize* entries. * libgomp.h (struct splay_tree_key_s): Add 'dynamic_refcount' field. (gomp_acc_remove_pointer): Adjust declaration. (gomp_remove_var): New declaration. * libgomp_g.h (GOACC_enter_exit_data): Adjust declaration. * oacc-mem.c (acc_map_data): Adjust new key refcount to REFCOUNT_INFINITY. (acc_unmap_data): Adjust key refcount to 1 for removal. (present_create_copy): Increment mapping refcounts when mapping exists, initialize dynamic refcount when creating new mapping. (FLAG_FINALIZE): Define macro. (delete_copyout): Adjust delete/copyout handling, add handling for FLAG_FINALIZE. (acc_delete_finalize): Define new API function. (acc_delete_finalize_async): Likewise. (acc_copyout_finalize): Likewise. (acc_copyout_finalize_async): Likewise. (gomp_acc_insert_pointer): Adjust handling. (gomp_acc_remove_pointer): Add finalize parameter, adjust handling. * oacc-parallel.c (GOACC_parallel_keyed): Disable async registering when no copyout needed. (GOACC_enter_exit_data): Add and handle finalize argument, adjust gomp_acc_insert_pointer and gomp_acc_remove_pointer calls. (GOACC_declare): Adjust calls to GOACC_enter_exit_data. * target.c (gomp_map_vars): Initialize dynamic_refcount. (gomp_remove_var): Abstract out key unreferencing into new function. (gomp_unmap_vars): Adjust to call gomp_remove_var. (gomp_unload_image_from_device): Likewise. (gomp_exit_data): Likewise. * testsuite/libgomp.oacc-c-c++-common/data-2.c: Adjust testcase for 2.5 reference counting.
Re: Bump version namespace and remove _Rb_tree useless template parameter
On 16/05/17 12:48 +0100, Jonathan Wakely wrote: On 11/05/17 22:31 +0200, François Dumont wrote: On 10/05/2017 22:44, François Dumont wrote: On 10/05/2017 11:28, Jonathan Wakely wrote: On 10/05/17 11:15 +0200, Paolo Carlini wrote: Hi, On 10/05/2017 11:12, Jonathan Wakely wrote: Looks good to me. Paolo, what do you think about bumping the versioned namespace and SONAME to 8? Sure, makes sense to me too. Please commit it then, François - thanks! Done, don't hesitate to update the ChangeLog if I used some wrong terms. I'll also send some changes requiring this bump. François I just realized that I forgot to commit the small _Rb_tree_impl change part. It is done now. And also the regenerated configure script. I'll do that. Like so, tested x86_64-linux and committed to trunk. There seems to be a problem bootstrapping with the versioned-namespace on ppc64le-linux, but I haven't tried to debug it. commit 98d080cdac7052e2fa8a423cf6263fc3df5dd6d8 Author: Jonathan Wakely Date: Tue May 16 12:53:01 2017 +0100 Regenerate libstdc++-v3/configure for versioned-namespace soname * configure: Regenerate. diff --git a/libstdc++-v3/configure b/libstdc++-v3/configure index 2406cb9..7c10c9e 100755 --- a/libstdc++-v3/configure +++ b/libstdc++-v3/configure @@ -79282,7 +79282,7 @@ $as_echo "#define _GLIBCXX_SYMVER_GNU 1" >>confdefs.h ;; gnu-versioned-namespace) -libtool_VERSION=7:0:0 +libtool_VERSION=8:0:0 SYMVER_FILE=config/abi/pre/gnu-versioned-namespace.ver $as_echo "#define _GLIBCXX_SYMVER_GNU_NAMESPACE 1" >>confdefs.h
Re: [RFC, testsuite] Add dg-save-linenr
Hi Tom,
sorry for chiming in so very late: I've been on vacation and sick in
between...
> On 04/24/2017 05:20 PM, David Malcolm wrote:
>> On Sat, 2017-04-22 at 19:49 +0200, Tom de Vries wrote:
>>> Hi,
>>>
>>> there are currently two types of line number supported in
>>> dg-{error,warning,message,bogus} directives: absolute and relative.
>>> With an absolute line number, it's immediately clear what line number
>>> is
>>> meant, but when a line is added at the start of the file, the line
>>> number needs to be updated. With a relative line number, that
>>> problem
>>> is solved, but when relative line numbers become large, it becomes
>>> less
>>> clear what line it refers to, and when adding a line inbetween the
>>> directive using the relative line number and the line it refers to,
>>> the
>>> relative line number still needs to be updated.
>>>
>>> This patch adds a directive dg-save-linenr with argument varname,
>>> that
>>> saves the line number of the directive in a variable varname, which
>>> can
>>> be used as line number in dg directives.
>>>
>>> Testing status:
>>> - tested updated test-case objc.dg/try-catch-12.m
>>> - ran tree-ssa.exp
>>>
>>> RFC:
>>> - good idea?
>>
>> Excellent idea; thanks! There are various places where I'd find this
>> useful.
>>
>>> - naming of directive dg-save-linenr (dg-linenr, dg-save-line-nr,
>>>dg-save-lineno, dg-save-line-number, etc)
>>
>> How about just "dg-line"? (if it's not already taken)
>
> Done.
I'd have preferred dg-linenum: it clarifiers that it's a number and we
have precedent in DejaGnu's dg-linenum-format and dg-format-linenum...
>>> - error message formulation
>>
>> Nit: the new function should have a leading comment, explaining the
>> usage.
>>
>
> Done.
Not only that, but the new proc needs documenting in sourcebuild.texi.
(It's already way too hard for testsuite writers to find their way with
the documentation; if parts are missing, it gets next to impossible.)
Besides, it may be worthwhile contributing/suggesting this upstream.
Thanks.
Rainer
--
-
Rainer Orth, Center for Biotechnology, Bielefeld University
[C++ PATCH] get_fns cleanups
Some random cleanups with get_fns & get_first_fn from the modules
branch. I started cleaning up these and is_overloaded_fn & friends, but
that turned into a bit of a rat hole. There's certainly more mileage to
be gotten though.
These cleanups are generally callers unnecessarily stripping bits off
the get_fns deals with itself. Or in the omp error case, unnecessarily
peeking behind the curtain of OVERLOAD abstraction.
Applied to trunk.
nathan
--
Nathan Sidwell
2017-05-16 Nathan Sidwell
* pt.c (tsubst_copy_and_build): Remove unnecessary COMPONENT_REF
peeking.
* semantics.c (finish_id_expression): Directly init local var.
(finish_omp_reduction_clause): Use really_overloaded_fn.
* tree.c (get_fns): Document. Assert we got an overload.
(get_first_fn) Document.
* typeck.c (cp_build_addr_expr_1): Pass arg directly to
really_overloaded_fn.
* typeck2.c (cxx_inomplete_type_diagnostic): Use get_first_fn directly.
Index: pt.c
===
--- pt.c (revision 248095)
+++ pt.c (working copy)
@@ -17187,10 +17187,9 @@ tsubst_copy_and_build (tree t,
if (diag)
{
tree fn = unq;
+
if (INDIRECT_REF_P (fn))
fn = TREE_OPERAND (fn, 0);
- if (TREE_CODE (fn) == COMPONENT_REF)
- fn = TREE_OPERAND (fn, 1);
if (is_overloaded_fn (fn))
fn = get_first_fn (fn);
Index: semantics.c
===
--- semantics.c (revision 248095)
+++ semantics.c (working copy)
@@ -3749,9 +3749,8 @@ finish_id_expression (tree id_expression
}
else if (is_overloaded_fn (decl))
{
- tree first_fn;
+ tree first_fn = get_first_fn (decl);
- first_fn = get_first_fn (decl);
if (TREE_CODE (first_fn) == TEMPLATE_DECL)
first_fn = DECL_TEMPLATE_RESULT (first_fn);
@@ -5615,7 +5614,6 @@ finish_omp_reduction_clause (tree c, boo
{
if (id == error_mark_node)
return true;
- id = OVL_CURRENT (id);
mark_used (id);
tree body = DECL_SAVED_TREE (id);
if (!body)
@@ -6924,13 +6922,13 @@ finish_omp_clauses (tree clauses, enum c
{
if (OMP_CLAUSE_CODE (c) == OMP_CLAUSE_TO_DECLARE)
{
- if (TREE_CODE (t) == OVERLOAD && OVL_CHAIN (t))
+ if (TREE_CODE (t) == TEMPLATE_ID_EXPR)
error_at (OMP_CLAUSE_LOCATION (c),
- "overloaded function name %qE in clause %qs", t,
+ "template %qE in clause %qs", t,
omp_clause_code_name[OMP_CLAUSE_CODE (c)]);
- else if (TREE_CODE (t) == TEMPLATE_ID_EXPR)
+ else if (really_overloaded_fn (t))
error_at (OMP_CLAUSE_LOCATION (c),
- "template %qE in clause %qs", t,
+ "overloaded function name %qE in clause %qs", t,
omp_clause_code_name[OMP_CLAUSE_CODE (c)]);
else
error_at (OMP_CLAUSE_LOCATION (c),
Index: tree.c
===
--- tree.c (revision 248095)
+++ tree.c (working copy)
@@ -2146,10 +2146,11 @@ really_overloaded_fn (tree x)
return is_overloaded_fn (x) == 2;
}
+/* Get the overload set FROM refers to. */
+
tree
get_fns (tree from)
{
- gcc_assert (is_overloaded_fn (from));
/* A baselink is also considered an overloaded function. */
if (TREE_CODE (from) == OFFSET_REF
|| TREE_CODE (from) == COMPONENT_REF)
@@ -2158,9 +2159,13 @@ get_fns (tree from)
from = BASELINK_FUNCTIONS (from);
if (TREE_CODE (from) == TEMPLATE_ID_EXPR)
from = TREE_OPERAND (from, 0);
+ gcc_assert (TREE_CODE (from) == OVERLOAD
+ || TREE_CODE (from) == FUNCTION_DECL);
return from;
}
+/* Return the first function of the overload set FROM refers to. */
+
tree
get_first_fn (tree from)
{
Index: typeck.c
===
--- typeck.c (revision 248095)
+++ typeck.c (working copy)
@@ -5603,7 +5603,7 @@ cp_build_addr_expr_1 (tree arg, bool str
gcc_assert (!identifier_p (arg) || !IDENTIFIER_OPNAME_P (arg));
if (TREE_CODE (arg) == COMPONENT_REF && type_unknown_p (arg)
- && !really_overloaded_fn (TREE_OPERAND (arg, 1)))
+ && !really_overloaded_fn (arg))
{
/* They're trying to take the address of a unique non-static
member function. This is ill-formed (except in MS-land),
Index: typeck2.c
===
--- typeck2.c (revision 248095)
+++ typeck2.c (working copy)
@@ -506,9 +506,8 @@ cxx_incomplete_type_diagnostic (location
case OFFSET_TYPE:
bad_member:
{
- tree member = TREE_OPERAND (value, 1);
- if (is_overloaded_fn (member))
- member = get_first_fn (member);
+ tree member = get_first_fn (TREE_OPERAND (value, 1));
+
if (DECL_FUNCTION_MEMBER_P (member)
&& ! flag_ms_extensions)
emit_diagnostic (diag_kind, loc, 0,
Re: [PATCH] PR libstdc++/80285 optimize std::make_shared for -fno-rtti
On 11/05/17 15:19 +0100, Jonathan Wakely wrote:
std::make_shared didn't support embedding the object within the
shared_ptr bookkeeping structure when -fno-rtti was used. This was
because the trick I use for getting the address of the embedded
object relied on typeid, so without RTTI it just creating the object
separately on the heap.
This removes the alternative code path for -fno-rtti and simply forms
a fake std::type_info& reference using reinterpret_cast. This allows
us to embed the object and get its address without typeid, so we avoid
the second allocation even when -fno-rtti is used.
PR libstdc++/80285
* include/bits/shared_ptr_base.h (_Sp_make_shared_tag::_S_ti): Define
function to get unique fake std::type_info reference.
(_Sp_counted_ptr_inplace::_M_get_deleter) [!__cpp_rtti]: Compare to
_S_ti() fake reference.
(__shared_ptr(_Sp_make_shared_tag, const Alloc&, Args&&...)): Share
single implementation with or without RTTI enable.
[!__cpp_rtti]: Pass fake reference to _M_get_deleter.
* testsuite/20_util/shared_ptr/creation/alloc.cc: Change expected
allocation and deallocation counts.
* testsuite/20_util/shared_ptr/creation/single_allocation.cc: New.
* testsuite/20_util/shared_ptr/creation/single_allocation_no_rtti.cc:
New.
Tested powerpc64le-linux, committed to trunk.
This fix is needed for gnu-versioned-namespace builds, because
std::type_info should not be declared inside the versioned namespace.
Tested x86_64-linux, comitted to trunk.
commit e14f89bd9e529b3343c0b8c5fce3377394f6cbc7
Author: Jonathan Wakely
Date: Tue May 16 14:13:40 2017 +0100
Fix forward declaration of std::type_info for versioned-namespace
PR libstdc++/80285
* include/bits/shared_ptr_base.h [!__cpp_rtti] (type_info): Declare
outside versioned namespace.
diff --git a/libstdc++-v3/include/bits/shared_ptr_base.h b/libstdc++-v3/include/bits/shared_ptr_base.h
index 6918579..b4a5edf 100644
--- a/libstdc++-v3/include/bits/shared_ptr_base.h
+++ b/libstdc++-v3/include/bits/shared_ptr_base.h
@@ -59,6 +59,10 @@
namespace std _GLIBCXX_VISIBILITY(default)
{
+#if !__cpp_rtti
+ class type_info;
+#endif
+
_GLIBCXX_BEGIN_NAMESPACE_VERSION
#if _GLIBCXX_USE_DEPRECATED
@@ -68,10 +72,6 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
#pragma GCC diagnostic pop
#endif
-#if !__cpp_rtti
- class type_info;
-#endif
-
/**
* @brief Exception possibly thrown by @c shared_ptr.
* @ingroup exceptions
[C++ PATCH] OVERLOAD abstractions part 1
My reworking of overload management will be introducing
overloads-of-overloads as lookup results.
This patch introduces OVL_FIRST to get the first function of a lookup
set, and OVL_NAME to get the DECL_NAME of that (a useful accessor). In
many case we were unnecessarily using get_fns or get_first_fn, and this
patch cleans that up.
I made OVL_FIRST forward to a new inline function, which simply loops
until the thing it has is not an OVERLOAD. Right now that's only ever
one loop, but in future will be more than one. I didn't feel like
manually unrolling that loop, which could only ever be done twice.
applied to trunk.
nathan
--
Nathan Sidwell
2017-05-16 Nathan Sidwell
* cp-tree.h (OVL_FIRST, OVL_NAME): New.
(ovl_first): New.
* constexpr.c (function_concept_check): Use OVL_FIRST.
* cvt.c (build_expr_type_conversion): Likewise.
* decl.c (poplevel, grokdeclarator): Use OVL_NAME.
* decl2.c (mark_used): Use OVL_FIRST.
* error.c (dump_decl): Use OVL_FIRST, OVL_NAME.
(dump_expr, location_of): Use OVL_FIRST.
* friend.c (do_friend): Use OVL_NAME.
* init.c (build_offset_ref): Use OVL_FIRST.
* mangle.c (write_member_name): Likewise.
(write_expression): Use OVL_NAME.
* method.c (strip_inheriting_ctors): Use OVL_FIRST.
* name-lookup.c (pushdecl_class_level): Use OVL_NAME.
* pt.c (check_explicit_specialization): Use OVL_FIRST.
(check_template_shadow): Likewise.
(tsubst_template_args): Use OVL_NAME.
(tsubst_baselink): Use OVL_FIRST.
* semantics.c (perform_koenig_lookup): Use OVL_NAME.
* tree.c (get_first_fn): Use OVL_FIRST.
* typeck.c (finish_class_member_access_expr): Use OVL_NAME.
(cp_build_addr_expr_1): Use OVL_FIRST.
Index: constraint.cc
===
--- constraint.cc (revision 248095)
+++ constraint.cc (working copy)
@@ -117,10 +117,9 @@ function_concept_check_p (tree t)
gcc_assert (TREE_CODE (t) == CALL_EXPR);
tree fn = CALL_EXPR_FN (t);
if (fn != NULL_TREE
- && TREE_CODE (fn) == TEMPLATE_ID_EXPR
- && TREE_CODE (TREE_OPERAND (fn, 0)) == OVERLOAD)
+ && TREE_CODE (fn) == TEMPLATE_ID_EXPR)
{
- tree f1 = get_first_fn (fn);
+ tree f1 = OVL_FIRST (TREE_OPERAND (fn, 0));
if (TREE_CODE (f1) == TEMPLATE_DECL
&& DECL_DECLARED_CONCEPT_P (DECL_TEMPLATE_RESULT (f1)))
return true;
Index: cp-tree.h
===
--- cp-tree.h (revision 248095)
+++ cp-tree.h (working copy)
@@ -626,6 +626,11 @@ typedef struct ptrmem_cst * ptrmem_cst_t
and can be freed afterward. */
#define OVL_ARG_DEPENDENT(NODE) TREE_LANG_FLAG_0 (OVERLOAD_CHECK (NODE))
+/* The first decl of an overload. */
+#define OVL_FIRST(NODE) ovl_first (NODE)
+/* The name of the overload set. */
+#define OVL_NAME(NODE) DECL_NAME (OVL_FIRST (NODE))
+
struct GTY(()) tree_overload {
struct tree_common common;
tree function;
@@ -6668,6 +6673,13 @@ extern tree hash_tree_cons (tree, tree
extern tree hash_tree_chain (tree, tree);
extern tree build_qualified_name (tree, tree, tree, bool);
extern tree build_ref_qualified_type (tree, cp_ref_qualifier);
+inline tree
+ovl_first (tree node)
+{
+ while (TREE_CODE (node) == OVERLOAD)
+node = OVL_FUNCTION (node);
+ return node;
+}
extern int is_overloaded_fn (tree);
extern tree dependent_name (tree);
extern tree get_fns(tree);
Index: cvt.c
===
--- cvt.c (revision 248095)
+++ cvt.c (working copy)
@@ -1722,7 +1722,7 @@ build_expr_type_conversion (int desires,
int win = 0;
tree candidate;
tree cand = TREE_VALUE (conv);
- cand = OVL_CURRENT (cand);
+ cand = OVL_FIRST (cand);
if (winner && winner == cand)
continue;
Index: decl.c
===
--- decl.c (revision 248095)
+++ decl.c (working copy)
@@ -683,7 +683,7 @@ poplevel (int keep, int reverse, int fun
for (link = decls; link; link = TREE_CHAIN (link))
{
decl = TREE_CODE (link) == TREE_LIST ? TREE_VALUE (link) : link;
- tree name = DECL_NAME (OVL_CURRENT (decl));
+ tree name = OVL_NAME (decl);
if (leaving_for_scope && VAR_P (decl)
/* It's hard to make this ARM compatibility hack play nicely with
@@ -10104,10 +10104,7 @@ grokdeclarator (const cp_declarator *dec
if (variable_template_p (dname))
dname = DECL_NAME (dname);
else
- {
- gcc_assert (is_overloaded_fn (dname));
- dname = DECL_NAME (get_first_fn (dname));
- }
+ dname = OVL_NAME (dname);
}
}
/* Fall through. */
Index: decl2.c
===
--- decl2.c (revision 248095)
+++ decl2.c (working copy)
@@ -5029,7 +5029,7 @@ mark_used (tree decl, tsubst_flags_t com
decl = BASELINK_FUNCTIONS (decl);
if (really_overloaded_fn (decl))
return true;
- decl =
Re: [ARM] Enable FP16 vector arithmetic operations.
Hi, On 16 May 2017 at 10:48, Tamar Christina wrote: > Hi Kyrill, >> >> Sorry for missing this. >> For the record you are referring to the patch at: >> https://gcc.gnu.org/ml/gcc-patches/2016-09/msg01700.html >> >> This is ok and in line with what we do for the f32 intrinsics. >> My only concern was that we can do this only if >> __ARM_FEATURE_FP16_VECTOR_ARITHMETIC >> is defined from the architecture/fpu level, but these intrinsics are already >> gated on that in arm_neon.h. >> >> This is ok for trunk if a bootstrap and test run on arm-none-linux-gnueabihf >> with current trunk shows no issues. > > Thanks, bootstrapped and regtested now on arm-none-linux-gnueabihf and no > issues. > I'll go ahead and commit then. > One of the new tests fails on arm-none-linux-gnueabi (non-hf) targets: FAIL:gcc.target/arm/armv8_2-fp16-neon-2.c scan-assembler-times vceq\\.f16\\td[0-9]+, d[0-0]+, #0 1 For instance when configured --with-cpu=cortex-a9. Christophe > Regards, > Tamar > >> >> Thanks, >> Kyrill >> >> > Tamar >> > >> > From: gcc-patches-ow...@gcc.gnu.org >> on >> > behalf of Matthew Wahab >> > Sent: Friday, September 23, 2016 4:02 PM >> > To: gcc-patches >> > Subject: [ARM] Enable FP16 vector arithmetic operations. >> > >> > Hello, >> > >> > Support for the ARMv8.2-A FP16 NEON arithmetic instructions was added >> > using non-standard names for the instruction patterns. This was needed >> > because the NEON floating point semantics meant that their use by the >> > compiler for HFmode arithmetic operations needed to be restricted. >> > This follows the implementation for 32-bit NEON intructions. >> > >> > As with the 32-bit instructions, the restriction on the HFmode >> > operation can be lifted when -funsafe-math-optimizations is enabled. >> > This patch does that, defining the standard pattern names addhf3, >> > subhf3, mulhf3 and fmahf3. >> > >> > This patch also updates the NEON intrinsics to use the arithmetic >> > operations when -ffast-math is enabled. This is to make keep the >> > 16-bit support consistent with the 32-bit supportd. It is needed so >> > that code using the f16 intrinsics are subject to the same >> > optimizations as code using the f32 intrinsics would be. >> > >> > Tested for arm-none-linux-gnueabihf with native bootstrap and make >> > check on ARMv8-A and for arm-none-eabi and armeb-none-eabi with >> > cross-compiled make check on an ARMv8.2-A emulator. >> > >> > Ok for trunk? >> > Matthew >> > >> > gcc/ >> > 2016-09-23 Matthew Wahab >> > >> > * config/arm/arm_neon.h (vadd_f16): Use standard arithmetic >> > operations in fast-math mode. >> > (vaddq_f16): Likewise. >> > (vmul_f16): Likewise. >> > (vmulq_f16): Likewise. >> > (vsub_f16): Likewise. >> > (vsubq_f16): Likewise. >> > * config/arm/neon.md (add3): New. >> > (sub3): New. >> > (fma:3): New. Also remove outdated comment. >> > (mul3): New. >> > >> > testsuite/ >> > 2016-09-23 Matthew Wahab >> > >> > * gcc.target/arm/armv8_2-fp16-arith-1.c: Expand comment. Update >> > expected output of vadd, vsub and vmul instructions. >> > * gcc.target/arm/armv8_2-fp16-arith-2.c: New. >> > * gcc.target/arm/armv8_2-fp16-neon-2.c: New. >> > * gcc.target/arm/armv8_2-fp16-neon-3.c: New. >
[PATCH] Implement std::experimental::source_location (N4519)
This is a partial implementation of ,
see the commented-out lines in the testcase for the missing pieces.
I'll be opening a PR to get the needed front-end support complete it.
* configure: Regenerate.
* doc/xml/manual/status_cxx2017.xml: Update status table.
* doc/html/*: Regenerate.
* include/Makefile.am: Add new header.
* include/Makefile.in: Regenerate.
* include/experimental/source_location: New header implementing N4519.
* testsuite/experimental/source_location/1.cc: New test.
Tested x86_64-linux, committed to trunk.
commit ddd130b3fc040f63dd89bc87fe8b7834506105d2
Author: Jonathan Wakely
Date: Tue May 16 12:16:50 2017 +0100
Implement std::experimental::source_location (N4519)
* configure: Regenerate.
* doc/xml/manual/status_cxx2017.xml: Update status table.
* doc/html/*: Regenerate.
* include/Makefile.am: Add new header.
* include/Makefile.in: Regenerate.
* include/experimental/source_location: New header implementing N4519.
* testsuite/experimental/source_location/1.cc: New test.
diff --git a/libstdc++-v3/doc/xml/manual/status_cxx2017.xml
b/libstdc++-v3/doc/xml/manual/status_cxx2017.xml
index 0e35f75..a208238 100644
--- a/libstdc++-v3/doc/xml/manual/status_cxx2017.xml
+++ b/libstdc++-v3/doc/xml/manual/status_cxx2017.xml
@@ -878,14 +878,13 @@ Feature-testing recommendations for C++.
-
http://www.w3.org/1999/xlink";
xlink:href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4519.pdf";>
N4519
Source-Code Information Capture
- N
+ Y
Library Fundamentals 2 TS
diff --git a/libstdc++-v3/include/Makefile.am b/libstdc++-v3/include/Makefile.am
index 3703bd1..a651736 100644
--- a/libstdc++-v3/include/Makefile.am
+++ b/libstdc++-v3/include/Makefile.am
@@ -679,6 +679,7 @@ experimental_headers = \
${experimental_srcdir}/ratio \
${experimental_srcdir}/regex \
${experimental_srcdir}/set \
+ ${experimental_srcdir}/source_location \
${experimental_srcdir}/string \
${experimental_srcdir}/string_view \
${experimental_srcdir}/system_error \
diff --git a/libstdc++-v3/include/experimental/source_location
b/libstdc++-v3/include/experimental/source_location
new file mode 100644
index 000..b06d8b6
--- /dev/null
+++ b/libstdc++-v3/include/experimental/source_location
@@ -0,0 +1,86 @@
+// -*- C++ -*-
+
+// Copyright (C) 2015 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library. This library 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.
+
+// This library 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.
+
+// Under Section 7 of GPL version 3, you are granted additional
+// permissions described in the GCC Runtime Library Exception, version
+// 3.1, as published by the Free Software Foundation.
+
+// You should have received a copy of the GNU General Public License and
+// a copy of the GCC Runtime Library Exception along with this program;
+// see the files COPYING3 and COPYING.RUNTIME respectively. If not, see
+//
C PATCH to fix ASAN ICE with a compound literal (PR sanitizer/80659)
Martin L. asked me to have a look at this ICE with ASAN. This is an ICE with a
compound literal in a switch. A hash map gimplify_ctxp->live_switch_vars is
filled when processing DECL_EXPRs with their DECL_EXPR_DECLs. Such decls should
then be removed from the hash map when gimplifying a BIND_EXPR.
In C, non-static compound literals aren't pushed into any scope, so they were
never found by gimplify_bind_expr, so they stayed in the hash map resulting in
a crash on
2299 if (gimplify_ctxp->live_switch_vars)
2300 {
2301 gcc_assert (gimplify_ctxp->live_switch_vars->elements () == 0);
2302 delete gimplify_ctxp->live_switch_vars;
2303 }
We don't add artificial decls to the hash map:
1647 if (!DECL_ARTIFICIAL (decl) && gimplify_ctxp->live_switch_vars)
1648 gimplify_ctxp->live_switch_vars->add (decl);
build_compound_literal only marks a decl of a compound literal as artificial
when the compound literal is static. I think there's no harm in marking
decls of non-static compound literals as artificial, too (provided it's fine to
skip asan instrumentation of compound literals).
Bootstrapped/regtested on x86_64-linux, ok for trunk?
2017-05-16 Marek Polacek
PR sanitizer/80659
* c-decl.c (build_compound_literal): Set DECL_ARTIFICIAL even for
non-static compound literals.
* gcc.dg/asan/pr80659.c: New test.
diff --git gcc/c/c-decl.c gcc/c/c-decl.c
index b779d37..887e95d 100644
--- gcc/c/c-decl.c
+++ gcc/c/c-decl.c
@@ -5261,6 +5261,7 @@ build_compound_literal (location_t loc, tree type, tree
init, bool non_const)
DECL_CONTEXT (decl) = current_function_decl;
TREE_USED (decl) = 1;
DECL_READ_P (decl) = 1;
+ DECL_ARTIFICIAL (decl) = 1;
TREE_TYPE (decl) = type;
TREE_READONLY (decl) = (TYPE_READONLY (type)
|| (TREE_CODE (type) == ARRAY_TYPE
@@ -5297,7 +5298,6 @@ build_compound_literal (location_t loc, tree type, tree
init, bool non_const)
set_compound_literal_name (decl);
DECL_DEFER_OUTPUT (decl) = 1;
DECL_COMDAT (decl) = 1;
- DECL_ARTIFICIAL (decl) = 1;
DECL_IGNORED_P (decl) = 1;
pushdecl (decl);
rest_of_decl_compilation (decl, 1, 0);
diff --git gcc/testsuite/gcc.dg/asan/pr80659.c
gcc/testsuite/gcc.dg/asan/pr80659.c
index e69de29..0cbf2e4 100644
--- gcc/testsuite/gcc.dg/asan/pr80659.c
+++ gcc/testsuite/gcc.dg/asan/pr80659.c
@@ -0,0 +1,13 @@
+/* PR sanitizer/80659 */
+/* { dg-do compile } */
+
+void
+foo (int a)
+{
+ switch (a)
+{
+case 0:
+ (int[3]) { };
+ int h;
+}
+}
Marek
Re: [RFC] Do we want hierarchical options & encapsulation in a class
On Mon, May 15, 2017 at 4:21 PM, Martin Liška wrote: > On 05/15/2017 04:12 PM, Nathan Sidwell wrote: >> On 05/15/2017 09:06 AM, Martin Liška wrote: >> Given a blank sheet of paper, the current 'TDF_tree' dumps should really be 'TDF_gimple' dumps, so we'd have lang/ipa/gimple/rtl kinds of dumps. Such a renaming may be an unacceptable amount of churn though. >>> >>> Well, I would prefer to introduce new enum for kind of dump: >>> https://gcc.gnu.org/ml/gcc-patches/2017-05/msg01033.html >> >> Right, I understand that. My point is that it might be confusing to users >> of the dump machinery (i.e. me), at the command-line level where 'rtl' means >> different things in different contexts. And we have 'tree' dumps that dump >> gimple and 'lang' dumps that also (can) dump trees. > > Right. To be honest, originally I was convinced about positive impact of > hierarchical options. But changing names of dump suboptions will bring > inconvenience for current developers of GCC (who mainly use it). And I also > noticed that one can write -fdump-tree-ifcvt-stats-blocks-details, > a combination of multiple suboptions. Which makes it even more complex :) > > That said, I'm not inclining to that. Then it's questionable whether to > encapsulate masking enum to a class? So replying to the last mail in this thread. Originally the motivation was to get more bits when we disallow some flags for some categories (lang, tree, rtl, ipa). Now given that we have 32bits free and that Nathans TDF_lang stuff should add missing hierarchy the only user-visible change I'd do is to disallow for example -fdump-rtl-vops or -fdump-tree-note with a diagnostic. That allows us to allocate overlapping bits. Like if we move TDF_* to a .def file and have DEFFLAG(EH, GIMPLE|RTL) DEFFLAG(NOTE, INFO) DEFFLAG(SCEV, GIMPLE) etc. and some "intelligent" generator that allocates the bits. Now, given we have 32bit free the pressure to do this is quite low (and I usally dislike changes that are just there for the sake of changes). Given the introduction of -lang, which I appreciate, there's the opportunity to do better than currently, esp. with respect to maintainance of dump flags and the machinery. I realize this doesn't really answer whether we want a class or a enum or a uint64_t for dump_flags. A class would be most forward-looking. An enum for the bit number then works well (I dislike "sparse" enums), so operator|, etc. would do the missing 1<< Richard. > Martin > >> >> We have a bunch of gimple optimization passes, but call the dumpers 'tree'. >> I know how we ended up here, but it seems confusing. >> >> nathan >> >
Re: [PATCH v2 01/N] Add default value for last argument of dump functions.
On Fri, May 12, 2017 at 2:57 PM, Martin Liška wrote: > Hello. > > After fiddling with that, I decided to come up with reworked first part > of the patch and eventual translation to a more hierarchical structure > is subject for discussion. > > This first patch adds default for couple of dump functions and it helps in > future > to transform 0 to a TDF_NONE (or whatever we call it). > > Patch can bootstrap on ppc64le-redhat-linux and survives regression tests. > > Ready to be installed? Works for me. Thanks, Richard. > Martin
Re: [PATCH v2 2/N] Introduce dump_flags_t type and use it instead of int, type.
On Fri, May 12, 2017 at 3:00 PM, Martin Liška wrote: > Second part changes 'int flags' to a new typedef. > All corresponding interfaces have been changed. > > Patch can bootstrap on ppc64le-redhat-linux and survives regression tests. > > Ready to be installed? @@ -113,6 +114,14 @@ enum tree_dump_index #define OPTGROUP_ALL(OPTGROUP_IPA | OPTGROUP_LOOP | OPTGROUP_INLINE \ | OPTGROUP_OMP | OPTGROUP_VEC | OPTGROUP_OTHER) +/* Dump flags type. */ + +typedef uint64_t dump_flags_t; + +/* Dump flags type. */ + +typedef uint64_t dump_flags_t; + duplicate. +#define TDF_NONE 0 this now seems to "conflict" with #define TDF_LANG0 /* is a lang-specific dump. */ ? that is, TDF_RTL | TDF_NONE would still be "none" conceptually ... Ok with the duplicate typedef removed. Thanks, Richard. > Martin
RE:[PATCH,AIX] Enable Stack Unwinding on AIX
Tests: The change has been tested in 32bit and 64bit on AIX 6.1, 7.1 & 7.2 by using the libbacktrace (with XCOFF support) within a signal handler context (we used a specific back.c program). And it has been tested with Go tests on AIX for sure (recover tests on SIGSEGV do not work without this change). ChangeLog: * config/rs6000/aix-unwind.h (ppc_aix_fallback_frame_state): Add 64 bit support for AIX 6.1 and 7.X and 32 bit support for AIX 7.2. Cordialement, Tony Reix Bull - ATOS IBM Coop Architect & Technical Leader Office : +33 (0) 4 76 29 72 67 1 rue de Provence - 38432 Échirolles - France www.atos.net De : David Edelsohn [dje@gmail.com] Envoyé : lundi 15 mai 2017 22:31 À : REIX, Tony Cc : GCC Patches; SARTER, MATTHIEU (ext) Objet : Re: [PATCH,AIX] Enable Stack Unwinding on AIX Please do not email my IBM Notes address with patches. Please copy this Gmail address for patch submissions. > * libgcc/config/rs6000/aix-unwind.h : Implements stack unwinding on AIX. This ChangeLog entry clearly is wrong because aix-unwind.h already implements ppc_aix_fallback_frame_state. The ChangeLog entry should reference the exact function being modified and a useful comment about how it is modified, e.g., * config/rs6000/aix-unwind.h (ppc_aix_fallback_frame_state): Add 64 bit support Add 32 bit support for AIX 6.1 and 7.2. The ChangeLog file is in libgcc, so the file reference is wrong because it should not use libgcc in the path. How was this tested? Thanks, David
[PATCH v2 04/N] Simplify usage of some TDF_* flags.
There's one another patch that merges some TDF_* flags that have
very similar meaning and do not influence test-suite, because
nobody is using them for scanning.
Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.
Ready to be installed?
Martin
>From d75cc6896b1041042c4aea316c67fbe47265f30d Mon Sep 17 00:00:00 2001
From: marxin
Date: Fri, 12 May 2017 15:55:24 +0200
Subject: [PATCH 4/4] Simplify usage of some TDF_* flags.
gcc/ChangeLog:
2017-05-12 Martin Liska
* cfg.c (check_bb_profile): Do not use TDF_COMMENT and print
always leading ';; '.
(dump_bb_info): Likewise.
(brief_dump_cfg): Likewise.
* cfgrtl.c (print_rtl_with_bb): Do not use TDF_COMMENT.
* dumpfile.c: Remove usage of TDF_STMTADDR and TDF_VERBOSE.
* dumpfile.h (enum dump_kind): Likewise.
* gimple-pretty-print.c (pp_gimple_stmt_1): Change TDF_STMTADDR
to TDF_ADDRESS.
(dump_gimple_bb_header): Do not use TDF_COMMENT.
* print-tree.c (debug_verbose): Remove.
* tree-cfg.c (gimple_dump_cfg): Do not use TDF_COMMENT.
(dump_function_to_file): Replace TDF_VERBOSE with TDF_DETAILS.
* tree-diagnostic.c (default_tree_printer): Replace
TDF_DIAGNOSTIC with TDF_SLIM.
* tree-pretty-print.c (dump_generic_node): Change TDF_STMTADDR
to TDF_ADDRESS.
---
gcc/cfg.c | 56 +++
gcc/cfgrtl.c | 4 ++--
gcc/dumpfile.c| 5 +
gcc/dumpfile.h| 7 --
gcc/gimple-pretty-print.c | 5 ++---
gcc/print-tree.c | 15 -
gcc/tree-cfg.c| 10 -
gcc/tree-diagnostic.c | 3 +--
gcc/tree-pretty-print.c | 2 +-
9 files changed, 35 insertions(+), 72 deletions(-)
diff --git a/gcc/cfg.c b/gcc/cfg.c
index ffac69f266d..aef053f5d22 100644
--- a/gcc/cfg.c
+++ b/gcc/cfg.c
@@ -396,7 +396,7 @@ clear_bb_flags (void)
It is still practical to have them reported for debugging of simple
testcases. */
static void
-check_bb_profile (basic_block bb, FILE * file, int indent, dump_flags_t flags)
+check_bb_profile (basic_block bb, FILE * file, int indent)
{
edge e;
int sum = 0;
@@ -425,17 +425,17 @@ check_bb_profile (basic_block bb, FILE * file, int indent, dump_flags_t flags)
if (found)
{
if (EDGE_COUNT (bb->succs) && abs (sum - REG_BR_PROB_BASE) > 100)
- fprintf (file, "%s%sInvalid sum of outgoing probabilities %.1f%%\n",
- (flags & TDF_COMMENT) ? ";; " : "", s_indent,
- sum * 100.0 / REG_BR_PROB_BASE);
+ fprintf (file,
+ ";; %sInvalid sum of outgoing probabilities %.1f%%\n",
+ s_indent, sum * 100.0 / REG_BR_PROB_BASE);
lsum = 0;
FOR_EACH_EDGE (e, ei, bb->succs)
lsum += e->count;
if (EDGE_COUNT (bb->succs)
&& (lsum - bb->count > 100 || lsum - bb->count < -100))
- fprintf (file, "%s%sInvalid sum of outgoing counts %i, should be %i\n",
- (flags & TDF_COMMENT) ? ";; " : "", s_indent,
- (int) lsum, (int) bb->count);
+ fprintf (file,
+ ";; %sInvalid sum of outgoing counts %i, should be %i\n",
+ s_indent, (int) lsum, (int) bb->count);
}
}
if (bb != ENTRY_BLOCK_PTR_FOR_FN (fun))
@@ -445,30 +445,28 @@ check_bb_profile (basic_block bb, FILE * file, int indent, dump_flags_t flags)
sum += EDGE_FREQUENCY (e);
if (abs (sum - bb->frequency) > 100)
fprintf (file,
- "%s%sInvalid sum of incoming frequencies %i, should be %i\n",
- (flags & TDF_COMMENT) ? ";; " : "", s_indent,
- sum, bb->frequency);
+ ";; %sInvalid sum of incoming frequencies %i, should be %i\n",
+ s_indent, sum, bb->frequency);
lsum = 0;
FOR_EACH_EDGE (e, ei, bb->preds)
lsum += e->count;
if (lsum - bb->count > 100 || lsum - bb->count < -100)
- fprintf (file, "%s%sInvalid sum of incoming counts %i, should be %i\n",
- (flags & TDF_COMMENT) ? ";; " : "", s_indent,
- (int) lsum, (int) bb->count);
+ fprintf (file, ";; %sInvalid sum of incoming counts %i, should be %i\n",
+ s_indent, (int) lsum, (int) bb->count);
}
if (BB_PARTITION (bb) == BB_COLD_PARTITION)
{
/* Warn about inconsistencies in the partitioning that are
currently caused by profile insanities created via optimization. */
if (!probably_never_executed_bb_p (fun, bb))
-fprintf (file, "%s%sBlock in cold partition with hot count\n",
- (flags & TDF_COMMENT) ? ";; " : "", s_indent);
+ fprintf (file, ";; %sBlock in cold partition with hot count\n",
+ s_indent);
FOR_EACH_EDGE (e, ei, bb->preds)
{
if (!probably_never_executed_edge_p (fun, e))
fprintf (file,
- "%s%sBlock in cold partition with incoming hot edge\n",
- (flags & TDF_COMMENT) ? ";; " : "", s_indent);
+ ";; %sBlock in cold partition with incoming hot edge\n",
+ s_indent);
}
}
}
@@ -737,8 +735,7 @@ dump_bb_info (FILE *outf, basic_block bb, int indent, dump_flags_t flags,
{
unsigned i;
- if
Re: [PATCH v2 3/N] Transform TDF_{lang,tree,ipa,rtl} to dump_kind enum.
On Fri, May 12, 2017 at 3:04 PM, Martin Liška wrote:
> Third part removes TDF_* flags mentioned in the subject. These flags are used
> to enable all passes of specific type and Nathan has recently separated these
> by a new pair of macros. I hope moving these to a separate enum will help
> even more.
>
> Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.
>
> Ready to be installed?
/* Table of tree dump switches. This must be consistent with the
TREE_DUMP_INDEX enumeration in dumpfile.h. */
static struct dump_file_info dump_files[TDI_end] =
{
...
+ dump_file_info (),
that will make it a runtime constructor unless you make dump_file_info
() constexpr.
ISTR we do have some C++11 stuff abstracted as macros. Ah, no, just
manually in vec.h.
need to look closer at the rest. Sth I notice is that it would be
nice to have dump_file
replaced by sth more elaborate (dump_file_info itself?), one could easily add an
implicit conversion to FILE * to make transition easy.
Well, one change at a time ;)
dump_flags, dump_file -> cdump ...
Richard.
> Martin
Re: [PATCH,AIX] Enable Stack Unwinding on AIX
On Tue, May 16, 2017 at 9:50 AM, REIX, Tony wrote: > Tests: > > The change has been tested in 32bit and 64bit on AIX 6.1, 7.1 & 7.2 by using > the libbacktrace (with XCOFF support) within a signal handler context (we > used a specific back.c program). > And it has been tested with Go tests on AIX for sure (recover tests on > SIGSEGV do not work without this change). > > ChangeLog: > > * config/rs6000/aix-unwind.h (ppc_aix_fallback_frame_state): Add 64 bit > support for AIX 6.1 and 7.X and 32 bit support for AIX 7.2. If ppc_aix_fallback_frame_state is used for both 32 bit and 64 bit, there is no need to define it twice. Just move the MD_FALLBACK_FRAME_STATE_FOR macro definition outside the #ifdef. This also needs a separate ChangeLog comment. The function that you modified is "ucontext_for". Please use that name in the ChangeLog entry. Will you need someone to apply the patch for you? Thanks, David
Re: [PATCH] Implement std::experimental::source_location (N4519)
On 16/05/17 14:40 +0100, Jonathan Wakely wrote:
This is a partial implementation of ,
see the commented-out lines in the testcase for the missing pieces.
I'll be opening a PR to get the needed front-end support complete it.
That's https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80780
+struct S {
+ string_view func;
+ source_location loc = source_location::current();
+
+ S(source_location loc = source_location::current())
+ : func(__FUNCTION__), loc(loc) // values of loc will be from call-site
+ {}
+
+ S(int)
+ : func(__FUNCTION__) // values of loc should be hereabouts
+ {}
+};
+
+void test02()
+{
+ S s0;
+ VERIFY( s0.loc.line() == 52 );
+ // static_assert( s0.loc.column() == 7 );
+ VERIFY( s0.loc.file_name() == __FILE__ );
+ VERIFY( s0.loc.function_name() == string_view(__FUNCTION__) );
+
+ S s1(1);
+ VERIFY( s1.loc.line() != 58 );
+ VERIFY( s1.loc.file_name() == __FILE__ );
+ // VERIFY( s1.loc.function_name() == s1.func );
I thought we didn't get the right location when current() is used in a
default member initializer, but we do, so this part of the test can be
uncommented. The implementation is more complete than I realised :-)
Tested x86_64-linux, committed to trunk.
commit 546efe296150b8e7db9e8c3287e19648c1736193
Author: Jonathan Wakely
Date: Tue May 16 15:18:29 2017 +0100
Test source_location::current() in default member initializer
* testsuite/experimental/source_location/1.cc: Change expected result
for source_location::current() used in default member initializer.
diff --git a/libstdc++-v3/testsuite/experimental/source_location/1.cc b/libstdc++-v3/testsuite/experimental/source_location/1.cc
index 2634ab4..febd84e 100644
--- a/libstdc++-v3/testsuite/experimental/source_location/1.cc
+++ b/libstdc++-v3/testsuite/experimental/source_location/1.cc
@@ -56,9 +56,9 @@ void test02()
VERIFY( s0.loc.function_name() == string_view(__FUNCTION__) );
S s1(1);
- VERIFY( s1.loc.line() != 58 );
+ VERIFY( s1.loc.line() == 46 );
VERIFY( s1.loc.file_name() == __FILE__ );
- // VERIFY( s1.loc.function_name() == s1.func );
+ VERIFY( s1.loc.function_name() == s1.func );
}
source_location f(source_location a = source_location::current()) {
RE: [ARM] Enable FP16 vector arithmetic operations.
Hi Christoph, > > Thanks, bootstrapped and regtested now on arm-none-linux-gnueabihf > and no issues. > > I'll go ahead and commit then. > > > > One of the new tests fails on arm-none-linux-gnueabi (non-hf) targets: > FAIL:gcc.target/arm/armv8_2-fp16-neon-2.c scan-assembler-times > vceq\\.f16\\td[0-9]+, d[0-0]+, #0 1 > > For instance when configured --with-cpu=cortex-a9. > Thanks, I'm making a non-hf build now to fix it. Tamar > Christophe > > > > Regards, > > Tamar > > > >> > >> Thanks, > >> Kyrill > >> > >> > Tamar > >> > > >> > From: gcc-patches-ow...@gcc.gnu.org ow...@gcc.gnu.org> > >> on > >> > behalf of Matthew Wahab > >> > Sent: Friday, September 23, 2016 4:02 PM > >> > To: gcc-patches > >> > Subject: [ARM] Enable FP16 vector arithmetic operations. > >> > > >> > Hello, > >> > > >> > Support for the ARMv8.2-A FP16 NEON arithmetic instructions was > >> > added using non-standard names for the instruction patterns. This > >> > was needed because the NEON floating point semantics meant that > >> > their use by the compiler for HFmode arithmetic operations needed to > be restricted. > >> > This follows the implementation for 32-bit NEON intructions. > >> > > >> > As with the 32-bit instructions, the restriction on the HFmode > >> > operation can be lifted when -funsafe-math-optimizations is enabled. > >> > This patch does that, defining the standard pattern names addhf3, > >> > subhf3, mulhf3 and fmahf3. > >> > > >> > This patch also updates the NEON intrinsics to use the arithmetic > >> > operations when -ffast-math is enabled. This is to make keep the > >> > 16-bit support consistent with the 32-bit supportd. It is needed so > >> > that code using the f16 intrinsics are subject to the same > >> > optimizations as code using the f32 intrinsics would be. > >> > > >> > Tested for arm-none-linux-gnueabihf with native bootstrap and make > >> > check on ARMv8-A and for arm-none-eabi and armeb-none-eabi with > >> > cross-compiled make check on an ARMv8.2-A emulator. > >> > > >> > Ok for trunk? > >> > Matthew > >> > > >> > gcc/ > >> > 2016-09-23 Matthew Wahab > >> > > >> > * config/arm/arm_neon.h (vadd_f16): Use standard arithmetic > >> > operations in fast-math mode. > >> > (vaddq_f16): Likewise. > >> > (vmul_f16): Likewise. > >> > (vmulq_f16): Likewise. > >> > (vsub_f16): Likewise. > >> > (vsubq_f16): Likewise. > >> > * config/arm/neon.md (add3): New. > >> > (sub3): New. > >> > (fma:3): New. Also remove outdated comment. > >> > (mul3): New. > >> > > >> > testsuite/ > >> > 2016-09-23 Matthew Wahab > >> > > >> > * gcc.target/arm/armv8_2-fp16-arith-1.c: Expand comment. > Update > >> > expected output of vadd, vsub and vmul instructions. > >> > * gcc.target/arm/armv8_2-fp16-arith-2.c: New. > >> > * gcc.target/arm/armv8_2-fp16-neon-2.c: New. > >> > * gcc.target/arm/armv8_2-fp16-neon-3.c: New. > >
RE:[PATCH,AIX] Enable FFI Go Closure on AIX
Hi David, We'll submit the patch to the libffi project asap. We have tested this patch on AIX 6.1 with libffi (master from github) in 32bit and 64bit with same results (same exact failures) when testing with and without our patch, using libffi testsuite. Without patch: === libffi Summary === 64bit & 32bit # of expected passes1870 # of unexpected failures38 # of unresolved testcases 2 # of unsupported tests 30 With patch: === libffi Summary === 64bit & 32bit # of expected passes1890 # of unexpected failures 38 # of unresolved testcases 2 # of unsupported tests28 We'll test with Python asap, probably this week. Cordialement, Tony Reix Bull - ATOS IBM Coop Architect & Technical Leader Office : +33 (0) 4 76 29 72 67 1 rue de Provence - 38432 Échirolles - France www.atos.net De : David Edelsohn [dje@gmail.com] Envoyé : lundi 15 mai 2017 22:36 À : REIX, Tony Cc : GCC Patches; SARTER, MATTHIEU (ext) Objet : Re: [PATCH,AIX] Enable FFI Go Closure on AIX This patch needs to be submitted to the libffi project. Also, the ChangeLog needs to specify exactly what is being changed not "Implement Go Closures". The patch clearly touches existing parts of the files that affect more than simply Go closures. How was this tested? libffi is used in many more places than Go, so any changes need to be tested very carefully and thoroughly. What are the results for the libffi testsuite? Have you tried building Python with a version of libffi built with this patch? Thanks, David
[C++ PATCH] OVERLOAD iterators #1
This patch implements new iterators for OVERLOADs. There are two iterators:
ovl_iterator for a plain iterator, that held on a binding
lkp_iterator for the overload set returned by lookup.
To use them simply:
for (lkp_iterator iter (INIT); iter; ++iter)
{ tree fn = *iter;
... }
Currently the latter simply defers to the former, but I'll be changing
lookup so that it can return an overload of overloads. (Right now it
simply flattens things, which is sub-optimal).
This changes the easier cases of iteration to use these. I'll be
working through the other cases to convert them.
nathan
--
Nathan Sidwell
2017-05-16 Nathan Sidwell
* cp-tree.h (class ovl_iterator, class lkp_iterator): New OVERLOAD
iterators.
(MAYBE_BASELINK_FUNCTIONS): New.
* constraint.cc (resolve_constraint_check): Use lkp_iterator.
* decl2.c (maybe_warn_sized_delete): Use ovl_iterator.
* lambda.c (maybe_generic_this_capture): Use lkp_iterator.
* method.c (inherited_ctor_binfo): Use ovl_iterator.
(binfo_inherited_from): Likewise.
* parser.c (lookup_literal_operator): Use lkp_iterator.
* pt.c (iterative_hash_template_arg): Use lkp_iterator.
(print_candidates_1): Likewise.
(determine_specialization): Likewise.
(resolve_overloaded_unification): Likewise.
(resolve_nondeduced_context): Likewise.
(type_dependent_expression_p): Likewise.
(dependent_template_p): Likewise.
* ptree.c (cxx_print_xnode): Likewise.
* semantics.c (omp_reduction_lookup): Use lkp_iterator.
(classtype_has_nothrow_assign_or_copy_p): Use ovl_iterator.
* typeck.c (check_template_keyword): Use lkp_iterator.
Index: constraint.cc
===
--- constraint.cc (revision 248109)
+++ constraint.cc (working copy)
@@ -204,10 +204,10 @@ resolve_constraint_check (tree ovl, tree
{
int nerrs = 0;
tree cands = NULL_TREE;
- for (tree p = ovl; p != NULL_TREE; p = OVL_NEXT (p))
+ for (lkp_iterator iter (ovl); iter; ++iter)
{
// Get the next template overload.
- tree tmpl = OVL_CURRENT (p);
+ tree tmpl = *iter;
if (TREE_CODE (tmpl) != TEMPLATE_DECL)
continue;
Index: cp-tree.h
===
--- cp-tree.h (revision 248109)
+++ cp-tree.h (working copy)
@@ -636,6 +636,62 @@ struct GTY(()) tree_overload {
tree function;
};
+/* Iterator for a 1 dimensional overload. */
+
+class ovl_iterator
+{
+ tree ovl;
+
+ public:
+ ovl_iterator (tree o)
+ :ovl (o)
+{}
+
+ ovl_iterator &operator= (const ovl_iterator &from)
+ {
+ovl = from.ovl;
+
+return *this;
+ }
+
+ public:
+ operator bool () const
+ {
+return ovl;
+ }
+ ovl_iterator &operator++ ()
+ {
+ovl = TREE_CODE (ovl) != OVERLOAD ? NULL_TREE : OVL_CHAIN (ovl);
+return *this;
+ }
+ tree operator* () const
+ {
+tree fn = TREE_CODE (ovl) != OVERLOAD ? ovl : OVL_FUNCTION (ovl);
+
+/* Check this is not an unexpected 2-dimensional overload. */
+gcc_checking_assert (TREE_CODE (fn) != OVERLOAD);
+
+return fn;
+ }
+};
+
+/* Iterator over a (potentially) 2 dimensional overload, which is
+ produced by name lookup. */
+
+/* Note this is currently a placeholder, as the name-lookup changes
+ are not yet committed. */
+
+class lkp_iterator : public ovl_iterator
+{
+ typedef ovl_iterator parent;
+
+ public:
+ lkp_iterator (tree o)
+: parent (o)
+ {
+ }
+};
+
struct GTY(()) tree_template_decl {
struct tree_decl_common common;
tree arguments;
@@ -653,6 +709,10 @@ struct GTY(()) tree_template_decl {
a TEMPLATE_DECL, an OVERLOAD, or a TEMPLATE_ID_EXPR. */
#define BASELINK_FUNCTIONS(NODE) \
(((struct tree_baselink*) BASELINK_CHECK (NODE))->functions)
+/* If T is a BASELINK, grab the functions, otherwise just T, which is
+ expected to already be a (list of) functions. */
+#define MAYBE_BASELINK_FUNCTIONS(T) \
+ (BASELINK_P (T) ? BASELINK_FUNCTIONS (T) : T)
/* The BINFO in which the search for the functions indicated by this baselink
began. This base is used to determine the accessibility of functions
selected by overload resolution. */
Index: decl2.c
===
--- decl2.c (revision 248109)
+++ decl2.c (working copy)
@@ -4390,10 +4390,10 @@ maybe_warn_sized_delete (enum tree_code
tree sized = NULL_TREE;
tree unsized = NULL_TREE;
- for (tree ovl = IDENTIFIER_GLOBAL_VALUE (cp_operator_id (code));
- ovl; ovl = OVL_NEXT (ovl))
+ for (ovl_iterator iter (IDENTIFIER_GLOBAL_VALUE (cp_operator_id (code)));
+ iter; ++iter)
{
- tree fn = OVL_CURRENT (ovl);
+ tree fn = *iter;
/* We're only interested in usual deallocation functions. */
if (!usual_deallocation_fn_p (fn))
continue;
Index: lambda.c
===
--- lambda.c (revision 248109)
+++ lambda.c (working copy)
@@ -841,18 +841,15 @@ maybe_generic_this_capture (tree
Re: [C++ PATCH] get_fns cleanups
The change to cxx_incomplete_type_diagnostic seems wrong; the member might be a data member. Jason
Re: [PATCH v2 2/N] Introduce dump_flags_t type and use it instead of int, type.
On 05/16/2017 03:48 PM, Richard Biener wrote: > On Fri, May 12, 2017 at 3:00 PM, Martin Liška wrote: >> Second part changes 'int flags' to a new typedef. >> All corresponding interfaces have been changed. >> >> Patch can bootstrap on ppc64le-redhat-linux and survives regression tests. >> >> Ready to be installed? > > @@ -113,6 +114,14 @@ enum tree_dump_index > #define OPTGROUP_ALL(OPTGROUP_IPA | OPTGROUP_LOOP | OPTGROUP_INLINE \ > | OPTGROUP_OMP | OPTGROUP_VEC | OPTGROUP_OTHER) > > +/* Dump flags type. */ > + > +typedef uint64_t dump_flags_t; > + > +/* Dump flags type. */ > + > +typedef uint64_t dump_flags_t; > + > > duplicate. Yes, wrong patch merge. > > +#define TDF_NONE 0 > > this now seems to "conflict" with > > #define TDF_LANG0 /* is a lang-specific dump. */ > > ? I'll make TDF_LANG 1 and will increment next TDF_KIND_MASK values. Re-running regression tests. Martin > > that is, TDF_RTL | TDF_NONE would still be "none" conceptually ... > > Ok with the duplicate typedef removed. > > Thanks, > Richard. > >> Martin
Re: [C++ PATCH] get_fns cleanups
On 05/16/2017 10:50 AM, Jason Merrill wrote: The change to cxx_incomplete_type_diagnostic seems wrong; the member might be a data member. I had convinced myself that at that point it couldn't be. Will take another look though. Anyway, thanks for the review! nathan -- Nathan Sidwell
[PATCH, i386]: Use Ym and Yn constraints in Simode interunit moves
Hello!
2017-05-16 Uros Bizjak
* config/i386.i386.md (*movsi_internal): Split (?rm,*y) alternative
to (?r,*Yn) and (?m,*y) alternatives, and (?*y,rm) to (?*Ym,r)
and (?*y,m). Update insn attributes.
Bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.
Committed to mainline SVN.
Uros.
Index: config/i386/i386.md
===
--- config/i386/i386.md (revision 248070)
+++ config/i386/i386.md (working copy)
@@ -2328,9 +2328,9 @@
(define_insn "*movsi_internal"
[(set (match_operand:SI 0 "nonimmediate_operand"
- "=r,m ,*y,*y,?rm,?*y,*v,*v,*v,m ,?r ,?r,?*Yi,*k,*k
,*rm")
+"=r,m ,*y,*y,?*y,?m,?r ,?*Ym,*v,*v,*v,m ,?r ,?r,?*Yi,*k,*k ,*rm")
(match_operand:SI 1 "general_operand"
- "g ,re,C ,*y,*y ,rm ,C ,*v,m ,*v,*Yj,*v,r
,*r,*km,*k"))]
+"g ,re,C ,*y,m ,*y,*Yn,r ,C ,*v,m ,*v,*Yj,*v,r ,*r,*km,*k"))]
"!(MEM_P (operands[0]) && MEM_P (operands[1]))"
{
switch (get_attr_type (insn))
@@ -2395,19 +2395,19 @@
}
}
[(set (attr "isa")
- (if_then_else (eq_attr "alternative" "11")
+ (if_then_else (eq_attr "alternative" "13")
(const_string "sse4")
(const_string "*")))
(set (attr "type")
(cond [(eq_attr "alternative" "2")
(const_string "mmx")
- (eq_attr "alternative" "3,4,5")
+ (eq_attr "alternative" "3,4,5,6,7")
(const_string "mmxmov")
- (eq_attr "alternative" "6,11")
+ (eq_attr "alternative" "8,13")
(const_string "sselog1")
- (eq_attr "alternative" "7,8,9,10,12")
+ (eq_attr "alternative" "9,10,11,12,14")
(const_string "ssemov")
- (eq_attr "alternative" "13,14,15")
+ (eq_attr "alternative" "15,16,17")
(const_string "mskmov")
(and (match_operand 0 "register_operand")
(match_operand 1 "pic_32bit_operand"))
@@ -2415,11 +2415,11 @@
]
(const_string "imov")))
(set (attr "length_immediate")
- (if_then_else (eq_attr "alternative" "11")
+ (if_then_else (eq_attr "alternative" "13")
(const_string "1")
(const_string "*")))
(set (attr "prefix_extra")
- (if_then_else (eq_attr "alternative" "11")
+ (if_then_else (eq_attr "alternative" "13")
(const_string "1")
(const_string "*")))
(set (attr "prefix")
@@ -2433,7 +2433,7 @@
(set (attr "mode")
(cond [(eq_attr "alternative" "2,3")
(const_string "DI")
- (eq_attr "alternative" "6,7")
+ (eq_attr "alternative" "8,9")
(cond [(ior (match_operand 0 "ext_sse_reg_operand")
(match_operand 1 "ext_sse_reg_operand"))
(const_string "XI")
@@ -2447,10 +2447,10 @@
]
(const_string "TI"))
- (and (eq_attr "alternative" "8,9")
+ (and (eq_attr "alternative" "10,11")
(not (match_test "TARGET_SSE2")))
(const_string "SF")
- (eq_attr "alternative" "11")
+ (eq_attr "alternative" "13")
(const_string "TI")
]
(const_string "SI")))])
Re: [PATCH] [i386] Recompute the frame layout less often
On 05/16/2017 03:34 AM, Bernd Edlinger wrote: It would be good to have test cases for each of the not-supported warnings that can happen, so far I only managed to get a test case for -fsplit-stack. Yes, I'm inclined to agree. I'll try to get this done today or tomorrow. I've also put in a limiter of one warning per TU. One problem is that there isn't a way to disable the warning, so I may want to add that. Daniel
Re: [PATCH,AIX] Enable FFI Go Closure on AIX
On Tue, May 16, 2017 at 10:44 AM, REIX, Tony wrote: > Hi David, > > We'll submit the patch to the libffi project asap. > > We have tested this patch on AIX 6.1 with libffi (master from github) in > 32bit and 64bit with same results (same exact failures) when testing with and > without our patch, using libffi testsuite. > > Without patch: > === libffi Summary === 64bit & 32bit > # of expected passes1870 > # of unexpected failures38 > # of unresolved testcases 2 > # of unsupported tests 30 > > With patch: > === libffi Summary === 64bit & 32bit > # of expected passes1890 > # of unexpected failures 38 > # of unresolved testcases 2 > # of unsupported tests28 > > We'll test with Python asap, probably this week. Libffi project now is on Github https://github.com/libffi/libffi I think that Anthony now uses pull requests. Once the patches are in the upstream project, we can backport them to GCC. Thanks, David
[PATCH] gcc::context creation
This patch breaks apart the creation of the pass manager from
gcc::context's ctor. This will allow us to register additional dumps
between the dumpfile manager creation and the pass manager. As I
described in https://gcc.gnu.org/ml/gcc-patches/2017-05/msg01164.html
when I tried to do this for the language-specific dumps, the existing
LANG_HOOKS_INIT_OPTIONS ran too late, and I had to create a new hook and
call it from gcc::context's constructor to get it done before the passes
were created. That's ugly. Calling the hook from toplev seems better.
Also, I noticed that we were passing a pointer to the
not-yet-fully-constructed context to the pass manager, which smells funny.
ok?
nathan
--
Nathan Sidwell
2017-05-16 Nathan Sidwell
* context.h (context::set_passes): New.
* context.c (context::context): Do not create pass manager.
* toplev.c (general_init): Create pass manager here.
Index: context.c
===
--- context.c (revision 248110)
+++ context.c (working copy)
@@ -29,14 +29,9 @@ along with GCC; see the file COPYING3.
gcc::context *g;
gcc::context::context ()
+ : m_passes (NULL), m_dumps (new gcc::dump_manager ())
{
have_offload = false;
-
- /* The pass manager's constructor uses the dump manager (to set up
- dumps for the various passes), so the dump manager must be set up
- before the pass manager. */
- m_dumps = new gcc::dump_manager ();
- m_passes = new gcc::pass_manager (this);
}
gcc::context::~context ()
Index: context.h
===
--- context.h (revision 248110)
+++ context.h (working copy)
@@ -39,6 +39,12 @@ public:
/* Pass-management. */
+ void set_passes (pass_manager *m)
+ {
+gcc_assert (!m_passes);
+m_passes = m;
+ }
+
pass_manager *get_passes () { gcc_assert (m_passes); return m_passes; }
/* Handling dump files. */
Index: toplev.c
===
--- toplev.c (revision 248110)
+++ toplev.c (working copy)
@@ -1154,9 +1154,13 @@ general_init (const char *argv0, bool in
processing. */
init_ggc_heuristics ();
- /* Create the singleton holder for global state.
- Doing so also creates the pass manager and with it the passes. */
+ /* Create the singleton holder for global state. This creates the
+ dump manager. */
g = new gcc::context ();
+
+ /* Create the passes. */
+ g->set_passes (new gcc::pass_manager (g));
+
symtab = new (ggc_cleared_alloc ()) symbol_table ();
statistics_early_init ();
[GCC][PATCH][ARM][Committed] Fix FP16 test assembler scans
Hi All, This fixes two assembler scan tests for ARM. The typo in the test made it fail if anything but d0 is used. Committed as r 248117 under the GCC obvious rule. gcc/testsuite/ 2017-05-16 Tamar Christina * gcc.target/arm/armv8_2-fp16-neon-1.c (vceqz): Fix regex. * gcc.target/arm/armv8_2-fp16-neon-2.c (vceqz): Fix regex. Thanks, Tamar fast-math-fp16-tests.patch Description: fast-math-fp16-tests.patch
RE: Fix minor reorg.c bug affecting MIPS targets
Hello Paul,
You're seeing this problem because mips.exp can't handle -O* in dg-options.
The other tests in gcc.target/mips use a dg-skip-if to skip for -O0 and -O1
instead of having -O2 in dg-options.
This is supposed to ensure that the tests are run for as many optimization
levels as possible.
I believe that Matthew can confirm this.
Regards,
Toma Tabacu
> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-ow...@gcc.gnu.org] On
> Behalf Of Paul Hua
> Sent: 16 May 2017 10:11
> To: Jeff Law
> Cc: gcc-patches
> Subject: Re: Fix minor reorg.c bug affecting MIPS targets
>
> Hi:
>
> There are new failures between r248067 and r248036 on
> mips64el-unknown-linux-gnu.
>
> ERROR: gcc.target/mips/reorgbug-1.c -O0 : Unrecognised option: -O2
> for " dg-options 1 "-O2 -msoft-float -mips2" "
> UNRESOLVED: gcc.target/mips/reorgbug-1.c -O0 : Unrecognised
> option: -O2 for " dg-options 1 "-O2 -msoft-float -mips2" "
> ERROR: gcc.target/mips/reorgbug-1.c -O1 : Unrecognised option: -O2
> for " dg-options 1 "-O2 -msoft-float -mips2" "
> UNRESOLVED: gcc.target/mips/reorgbug-1.c -O1 : Unrecognised
> option: -O2 for " dg-options 1 "-O2 -msoft-float -mips2" "
> ERROR: gcc.target/mips/reorgbug-1.c -O2 -flto
> -fno-use-linker-plugin -flto-partition=none : Unrecognised option: -O2
> for " dg-options 1 "-O2 -msoft-float -mips2" "
> UNRESOLVED: gcc.target/mips/reorgbug-1.c -O2 -flto
> -fno-use-linker-plugin -flto-partition=none : Unrecognised option: -O2
> for " dg-options 1 "-O2 -msoft-float -mips2" "
> ERROR: gcc.target/mips/reorgbug-1.c -O2 -flto -fuse-linker-plugin
> -fno-fat-lto-objects : Unrecognised option: -O2 for " dg-options 1
> "-O2 -msoft-float -mips2" "
> UNRESOLVED: gcc.target/mips/reorgbug-1.c -O2 -flto
> -fuse-linker-plugin -fno-fat-lto-objects : Unrecognised option: -O2
> for " dg-options 1 "-O2 -msoft-float -mips2" "
> ERROR: gcc.target/mips/reorgbug-1.c -O2 : Unrecognised option: -O2
> for " dg-options 1 "-O2 -msoft-float -mips2" "
> UNRESOLVED: gcc.target/mips/reorgbug-1.c -O2 : Unrecognised
> option: -O2 for " dg-options 1 "-O2 -msoft-float -mips2" "
> ERROR: gcc.target/mips/reorgbug-1.c -O3 -g : Unrecognised option:
> -O2 for " dg-options 1 "-O2 -msoft-float -mips2" "
> UNRESOLVED: gcc.target/mips/reorgbug-1.c -O3 -g : Unrecognised
> option: -O2 for " dg-options 1 "-O2 -msoft-float -mips2" "
> ERROR: gcc.target/mips/reorgbug-1.c -Os : Unrecognised option: -O2
> for " dg-options 1 "-O2 -msoft-float -mips2" "
> UNRESOLVED: gcc.target/mips/reorgbug-1.c -Os : Unrecognised
> option: -O2 for " dg-options 1 "-O2 -msoft-float -mips2" "
>
> I don't know why? just delete the "-O2" options in dg-options, then
> the test passed.
>
> diff --git a/gcc/testsuite/gcc.target/mips/reorgbug-1.c
> b/gcc/testsuite/gcc.target/mips/reorgbug-1.c
> index b820a2b..9537d21 100644
> --- a/gcc/testsuite/gcc.target/mips/reorgbug-1.c
> +++ b/gcc/testsuite/gcc.target/mips/reorgbug-1.c
> @@ -1,4 +1,4 @@
> -/* { dg-options "-O2 -msoft-float -mips2" } */
> +/* { dg-options "-msoft-float -mips2" } */
>
> typedef long int __int32_t;
> typedef long unsigned int __uint32_t;
>
> config info:Compiler version: 8.0.0 20170515 (experimental) (gcc trunk
> r248067 mips64el o32 n32 n64)
> Platform: mips64el-unknown-linux-gnu
> configure flags: --prefix=/home/xuchenghua/toolchain/gcc-trunk-r248067
> --enable-bootstrap --enable-shared --enable-threads=posix
> --enable-checking=release --enable-multilib--with-system-zlib
> --enable-__cxa_atexit --disable-libunwind-exceptions
> --enable-gnu-unique-object --enable-linker-build-id
> --enable-languages=c,c++,fortran --enable-plugin
> --enable-initfini-array --disable-libgcj --with-arch=mips64r2
> --with-abi=64 --with-multilib-list=32,n32,64
> --enable-gnu-indirect-function --with-long-double-128
> --build=mips64el-unknown-linux --target=mips64el-unknown-linux
> --with-pkgversion='gcc trunk r248067 mips64el o32 n32 n64'
> --disable-werror
>
>
> paul
>
> On Tue, May 16, 2017 at 1:22 AM, Jeff Law wrote:
> >
> >
> > There's a subtle bug in reorg.c's relax_delay_slots that my tester tripped
> > this weekend. Not sure what changed code generation wise as the affected
> > port built just fine last week. But it is what is is.
> >
> >
> >
> > Assume before this code we've set TARGET_LABEL to the code_label associated
> > with DELAY_JUMP_INSN (which is what we want)...
> >
> >
> >
> > /* If the first insn at TARGET_LABEL is redundant with a previous
> > insn, redirect the jump to the following insn and process again.
> > We use next_real_insn instead of next_active_insn so we
> > don't skip USE-markers, or we'll end up with incorrect
> > liveness info. */
> >
> > [ ... ]
> >
> > /* Similarly, if it is an unconditional jump with one insn in its
> > delay list and that insn is redundant, thread the jump. */
> > rtx_sequence *trial_seq =
> > trial
RE: [ARM] Enable FP16 vector arithmetic operations.
I've fixed the test, there was a typo in the regexpr that made it fail only when the register allocator happens to pick a register other than d0. Commited as r 248117. > -Original Message- > From: Christophe Lyon [mailto:christophe.l...@linaro.org] > Sent: 16 May 2017 14:21 > To: Tamar Christina > Cc: Kyrill Tkachov; Matthew Wahab; gcc-patches; nd; ni...@redhat.com; > Richard Earnshaw; Ramana Radhakrishnan > Subject: Re: [ARM] Enable FP16 vector arithmetic operations. > > Hi, > > On 16 May 2017 at 10:48, Tamar Christina > wrote: > > Hi Kyrill, > >> > >> Sorry for missing this. > >> For the record you are referring to the patch at: > >> https://gcc.gnu.org/ml/gcc-patches/2016-09/msg01700.html > >> > >> This is ok and in line with what we do for the f32 intrinsics. > >> My only concern was that we can do this only if > >> __ARM_FEATURE_FP16_VECTOR_ARITHMETIC > >> is defined from the architecture/fpu level, but these intrinsics are > >> already gated on that in arm_neon.h. > >> > >> This is ok for trunk if a bootstrap and test run on > >> arm-none-linux-gnueabihf with current trunk shows no issues. > > > > Thanks, bootstrapped and regtested now on arm-none-linux-gnueabihf > and no issues. > > I'll go ahead and commit then. > > > > One of the new tests fails on arm-none-linux-gnueabi (non-hf) targets: > FAIL:gcc.target/arm/armv8_2-fp16-neon-2.c scan-assembler-times > vceq\\.f16\\td[0-9]+, d[0-0]+, #0 1 > > For instance when configured --with-cpu=cortex-a9. > > Christophe > > > > Regards, > > Tamar > > > >> > >> Thanks, > >> Kyrill > >> > >> > Tamar > >> > > >> > From: gcc-patches-ow...@gcc.gnu.org ow...@gcc.gnu.org> > >> on > >> > behalf of Matthew Wahab > >> > Sent: Friday, September 23, 2016 4:02 PM > >> > To: gcc-patches > >> > Subject: [ARM] Enable FP16 vector arithmetic operations. > >> > > >> > Hello, > >> > > >> > Support for the ARMv8.2-A FP16 NEON arithmetic instructions was > >> > added using non-standard names for the instruction patterns. This > >> > was needed because the NEON floating point semantics meant that > >> > their use by the compiler for HFmode arithmetic operations needed to > be restricted. > >> > This follows the implementation for 32-bit NEON intructions. > >> > > >> > As with the 32-bit instructions, the restriction on the HFmode > >> > operation can be lifted when -funsafe-math-optimizations is enabled. > >> > This patch does that, defining the standard pattern names addhf3, > >> > subhf3, mulhf3 and fmahf3. > >> > > >> > This patch also updates the NEON intrinsics to use the arithmetic > >> > operations when -ffast-math is enabled. This is to make keep the > >> > 16-bit support consistent with the 32-bit supportd. It is needed so > >> > that code using the f16 intrinsics are subject to the same > >> > optimizations as code using the f32 intrinsics would be. > >> > > >> > Tested for arm-none-linux-gnueabihf with native bootstrap and make > >> > check on ARMv8-A and for arm-none-eabi and armeb-none-eabi with > >> > cross-compiled make check on an ARMv8.2-A emulator. > >> > > >> > Ok for trunk? > >> > Matthew > >> > > >> > gcc/ > >> > 2016-09-23 Matthew Wahab > >> > > >> > * config/arm/arm_neon.h (vadd_f16): Use standard arithmetic > >> > operations in fast-math mode. > >> > (vaddq_f16): Likewise. > >> > (vmul_f16): Likewise. > >> > (vmulq_f16): Likewise. > >> > (vsub_f16): Likewise. > >> > (vsubq_f16): Likewise. > >> > * config/arm/neon.md (add3): New. > >> > (sub3): New. > >> > (fma:3): New. Also remove outdated comment. > >> > (mul3): New. > >> > > >> > testsuite/ > >> > 2016-09-23 Matthew Wahab > >> > > >> > * gcc.target/arm/armv8_2-fp16-arith-1.c: Expand comment. > Update > >> > expected output of vadd, vsub and vmul instructions. > >> > * gcc.target/arm/armv8_2-fp16-arith-2.c: New. > >> > * gcc.target/arm/armv8_2-fp16-neon-2.c: New. > >> > * gcc.target/arm/armv8_2-fp16-neon-3.c: New. > >
Re: Fix minor reorg.c bug affecting MIPS targets
On 05/16/2017 10:01 AM, Toma Tabacu wrote: > Hello Paul, > > You're seeing this problem because mips.exp can't handle -O* in dg-options. > The other tests in gcc.target/mips use a dg-skip-if to skip for -O0 and -O1 > instead of having -O2 in dg-options. > This is supposed to ensure that the tests are run for as many optimization > levels as possible. > > I believe that Matthew can confirm this. Feel free to remove the -O2. The most important bits are -mips2 and -msoft-float. If nobody does it shortly, I'll take care of it myself. jeff
Re: [C++ PATCH] get_fns cleanups
On 05/16/2017 10:50 AM, Jason Merrill wrote:
The change to cxx_incomplete_type_diagnostic seems wrong; the member
might be a data member.
I couldn't get there with a non-overload, but then I couldn't convince
myself there was no other path. It's hardly a critical path, so reverted.
--
Nathan Sidwell
2017-05-16 Nathan Sidwell
* typeck2.c (cxx_incomplete_type_diagnostic): Revert change and
check is_overloaded_fn.
Index: typeck2.c
===
--- typeck2.c (revision 248109)
+++ typeck2.c (working copy)
@@ -506,7 +506,9 @@ cxx_incomplete_type_diagnostic (location
case OFFSET_TYPE:
bad_member:
{
- tree member = get_first_fn (TREE_OPERAND (value, 1));
+ tree member = TREE_OPERAND (value, 1);
+ if (is_overloaded_fn (member))
+ member = get_first_fn (member);
if (DECL_FUNCTION_MEMBER_P (member)
&& ! flag_ms_extensions)
Re: [PATCH] [i386] Recompute the frame layout less often
On Mon, May 15, 2017 at 10:00 PM, Daniel Santos wrote: > > Ian, would you mind looking at this please? A combination of my > -mcall-ms2sysv-xlogues patch with Bernd's patch is causing problems when > ix86_expand_split_stack_prologue() calls ix86_expand_call(). I don't have a lot of context here. I assume that ms2sysv is going to be used on Windows systems, where -fsplit-stack isn't really going to work anyhow, so I think it would probably be OK that reject that combination if it causes trouble. Also, it's overkill for ix86_expand_split_stack_prologue to call ix86_expand_call. The call is always to __morestack, and __morestack is written in assembler, so we could use a simpler version of ix86_expand_call if that helps. In particular we can decide that __morestack doesn't clobber any unusual registers, if that is what is causing the problem. Ian
[C++ PATCH] Overload iterators #2
This patch converts more pieces to use {ovl,lkp}_iterator. Also a few
places OVL_FIRST should now be being used.
I don't think anything here is particularly obscure.
nathan
--
Nathan Sidwell
2017-05-16 Nathan Sidwell
* call.c (build_user_type_conversion_1): Use OVL_FIRST.
(print_error_for_call_faulure): Use OVL_NAME.
(build_op_call_1): Use ovl_iterator.
(add_candidates): Use OVL_FIRST & lkp_iterator.
(build_op_delete_call): Use MAYBE_BASELINK_FUNCTIONS &
lkp_iterator.
* class.c (deduce_noexcept_on_destructors): Use ovl_iterator.
(type_has_user_nondefault_constructor,
in_class_defaulted_default_constructor,
type_has_user_provided_constructor,
type_has_user_provided_or_explicit_constructor,
type_has_non_user_provided_default_constructor,
vbase_has_user_provided_move_assign,
type_has_move_constructor, type_has_move_assign,
type_has_user_declared_move_constructor,
type_has_user_declared_move_assign,
type_build_ctor_call, type_build_dtor_call,
type_requires_array_cookie, explain_non_literal_class): Likewise.
(finish_struct): Use lkp_iterator.
(resolve_address_of_overloaded_function): Use OVL_NAME, lkp_iterator.
(note_name_declared_in_class): Use OVL_NAME.
* cxx-pretty-print.c (pp_cxx_unqualified_id): Use OVL_FIRST.
(pp_cxx_qualified_id, cxx_pretty_printer::id_expression,
cxx_pretty_printer::expression): Likewise.
* decl2.c (check_classfn): Use ovl_iterator.
* pt.c (retrieve_specialization): Use ovl_iterator.
* tree.c (cp_tree_equal): Use lkp_iterator.
(type_has_nontrivial_copy_init): Use ovl_iterator.
Index: call.c
===
--- call.c (revision 248119)
+++ call.c (working copy)
@@ -3783,8 +3783,8 @@ build_user_type_conversion_1 (tree totyp
/* We should never try to call the abstract or base constructor
from here. */
- gcc_assert (!DECL_HAS_IN_CHARGE_PARM_P (OVL_CURRENT (ctors))
- && !DECL_HAS_VTT_PARM_P (OVL_CURRENT (ctors)));
+ gcc_assert (!DECL_HAS_IN_CHARGE_PARM_P (OVL_FIRST (ctors))
+ && !DECL_HAS_VTT_PARM_P (OVL_FIRST (ctors)));
args = make_tree_vector_single (expr);
if (BRACE_ENCLOSED_INITIALIZER_P (expr))
@@ -4172,7 +4172,7 @@ print_error_for_call_failure (tree fn, v
targs = TREE_OPERAND (fn, 1);
fn = TREE_OPERAND (fn, 0);
}
- tree name = DECL_NAME (OVL_CURRENT (fn));
+ tree name = OVL_NAME (fn);
location_t loc = location_of (name);
if (targs)
name = lookup_template_function (name, targs);
@@ -4449,16 +4449,15 @@ build_op_call_1 (tree obj, vec *fn_args;
- fn = OVL_CURRENT (fns);
+ fn = *iter;
if (check_converting && DECL_NONCONVERTING_P (fn))
continue;
@@ -6201,8 +6199,7 @@ build_op_delete_call (enum tree_code cod
if (fn == error_mark_node)
return NULL_TREE;
- if (BASELINK_P (fn))
- fn = BASELINK_FUNCTIONS (fn);
+ fn = MAYBE_BASELINK_FUNCTIONS (fn);
/* "If the lookup finds the two-parameter form of a usual deallocation
function (3.7.4.2) and that function, considered as a placement
@@ -6221,10 +6218,10 @@ build_op_delete_call (enum tree_code cod
the usual deallocation function, so we shouldn't complain
about using the operator delete (void *, size_t). */
if (DECL_CLASS_SCOPE_P (fn))
- for (t = BASELINK_P (fns) ? BASELINK_FUNCTIONS (fns) : fns;
- t; t = OVL_NEXT (t))
+ for (lkp_iterator iter (MAYBE_BASELINK_FUNCTIONS (fns));
+ iter; ++iter)
{
- tree elt = OVL_CURRENT (t);
+ tree elt = *iter;
if (usual_deallocation_fn_p (elt)
&& FUNCTION_ARG_CHAIN (elt) == void_list_node)
goto ok;
@@ -6263,10 +6260,9 @@ build_op_delete_call (enum tree_code cod
allocation function. If the lookup finds a single matching
deallocation function, that function will be called; otherwise, no
deallocation function will be called." */
-for (t = BASELINK_P (fns) ? BASELINK_FUNCTIONS (fns) : fns;
- t; t = OVL_NEXT (t))
+for (lkp_iterator iter (MAYBE_BASELINK_FUNCTIONS (fns)); iter; ++iter)
{
- tree elt = OVL_CURRENT (t);
+ tree elt = *iter;
if (usual_deallocation_fn_p (elt))
{
if (!fn)
Index: class.c
===
--- class.c (revision 248119)
+++ class.c (working copy)
@@ -5069,8 +5069,8 @@ deduce_noexcept_on_destructors (tree t)
if (!CLASSTYPE_METHOD_VEC (t))
return;
- for (tree fns = CLASSTYPE_DESTRUCTORS (t); fns; fns = OVL_NEXT (fns))
-deduce_noexcept_on_destructor (OVL_CURRENT (fns));
+ for (ovl_iterator iter (CLASSTYPE_DESTRUCTORS (t)); iter; ++iter)
+deduce_noexcept_on_destructor (*iter);
}
/* Subroutine of set_one_vmethod_tm_attributes. Search base classes
@@ -5230,14 +5230,12 @@ default_ctor_p (tree fn)
bool
type_has_user_nondefault_constructor (tree t)
{
- tree fns;
-
if (!TYPE_HAS_USER_CONSTRUCTOR (t))
return false;
- for (fns = CLASSTYPE_CONSTRUCTORS (t); fns; fns = OVL_NEXT (fns))
+ for (ovl_ite
Re: [PATCH v2] C++: fix-it hints suggesting accessors for private fields
OK.
On Fri, May 5, 2017 at 6:50 PM, David Malcolm wrote:
> On Mon, 2017-05-01 at 14:43 -0400, Jason Merrill wrote:
>> On Thu, Apr 27, 2017 at 7:23 AM, Nathan Sidwell
>> wrote:
>> > On 04/26/2017 12:34 PM, David Malcolm wrote:
>> >
>> > > Thanks - yes; that gives information on the const vs non-const of
>> > > the
>> > > "this" parameter, but doesn't say whether the argument was const
>> > > vs non
>> > > -const.
>> >
>> >
>> > > However, within:
>> > >
>> > > int test_const_ptr (const t1 *ptr)
>> > > {
>> > >return ptr->m_color;
>> > > }
>> > > from which we can see the const-ness of the t1:
>> >
>> >
>> > correct.
>> >
>> > > but the call to lookup_member from within
>> > > finish_class_member_access_expr discards this information, giving
>> > > just
>> > > "access_path": a BINFO that wraps the RECORD_TYPE for t1
>> > > directly.
>> >
>> >
>> > Correct.
>> >
>> > lookup_member just looks for a matching name. the BINFO represents
>> > the
>> > class hierarchy - it's not modified depending on the cvquals of
>> > where you
>> > came from.
>> >
>> > > A somewhat invasive solution would be for lookup_member to grow
>> > > an extra:
>> > >tree object
>> > > parameter, and to pass this information down through the access
>> > > -enforcement code, so that locate_field_accessor can look at the
>> > > const
>> > > -ness of the lookup, and avoid suggesting const methods when the
>> > > object
>> > > is const. The code would probably need to support the new param
>> > > being
>> > > NULL_TREE for cases where we're looking up a static member. Or
>> > > maybe
>> > > an enum of access style for const vs non-const vs static.
>> > > Maybe name the param "access_hint" to signify that it's merely
>> > > there
>> > > for the purpose of hints for the user, and not to affect the
>> > > parsing
>> > > itself?
>> >
>> > Hm, that does seem rather unfortunate.
>> > >
>> > > Another solution would be to not bother offering non-const
>> > > methods as
>> > > accessors.
>> >
>> >
>> > I think that would be very unfortunate.
>> >
>> > How about adding a tsubst_flag value?
>> >
>> > tf_const_obj = 1 << 11, /* For alternative accessor suggestion
>> > help. */
>> >
>> > and pass that in? the tsubst flags have grown in meaning somewhat
>> > since
>> > they first appeared -- their name is no longer so appropriate.
>> >
>> > (of course we have the same problem with volatile, but that's
>> > probably
>> > overkill for first attempt.)
>> >
>> > Jason, WDYT?
>>
>> I'd suggest handling this diagnostic in
>> finish_class_member_access_expr, rather than try to push down context
>> information into lookup_member. Perhaps by adding another parameter
>> to lookup_member for passing back the inaccessible or ambiguous
>> lookup
>> result?
>>
>> Jason
>
> Thanks.
>
> Here's an updated version of the patch which adds an optional struct
> ptr, for writing back the info, which then gets emitted (if set)
> in finish_class_member_access_expr (and thus has access to the constness
> of the object).
>
> Successfully bootstrapped®rtested on x86_64-pc-linux-gnu.
>
> OK for trunk?
>
> gcc/cp/ChangeLog:
> * call.c (enforce_access): Add access_failure_info * param and use
> it to record access failures.
> * cp-tree.h (class access_failure_info): New class.
> (enforce_access): Add access_failure_info * param, defaulting to
> NULL.
> (lookup_member): Likewise.
> (locate_field_accessor): New function decl.
> (perform_or_defer_access_check): Add access_failure_info * param,
> defaulting to NULL.
> * search.c (lookup_member): Add access_failure_info * param and
> pass it on to call to perform_or_defer_access_check.
> (matches_code_and_type_p): New function.
> (field_access_p): New function.
> (direct_accessor_p): New function.
> (reference_accessor_p): New function.
> (field_accessor_p): New function.
> (struct locate_field_data): New struct.
> (dfs_locate_field_accessor_pre): New function.
> (locate_field_accessor): New function.
> * semantics.c (perform_or_defer_access_check): Add
> access_failure_info * param, and pass it on to call to
> enforce_access.
> * typeck.c (access_failure_info::record_access_failure): New method.
> (access_failure_info::maybe_suggest_accessor): New method.
> (finish_class_member_access_expr): Pass an access_failure_info
> instance to the lookup_member call, and call its
> maybe_suggest_accessor method afterwards.
>
> gcc/testsuite/ChangeLog:
> * g++.dg/other/accessor-fixits-1.C: New test case.
> * g++.dg/other/accessor-fixits-2.C: New test case.
> * g++.dg/other/accessor-fixits-3.C: New test case.
> * g++.dg/other/accessor-fixits-4.C: New test case.
> ---
> gcc/cp/call.c | 8 +-
> gcc/cp/cp-tree.h | 31 +++-
> gc
Re: [PATCH] new -fdump flag
On Tue, May 9, 2017 at 8:05 AM, Nathan Sidwell wrote: > I'm also prepared to remove the -fdump-translation-unit dumper, which is a > completely inscrutable c++ only dump, that I think is well past its > best-before date. (Jason?) I think that's left over from previous modulesish work by Gaby and Bjarne; tearing it out at this point seems fine. Jason
[C++ PATCH] Overload iterators #3
This patch to do_class_deduction notices that we currently add some
candidates and them immediately elide them from the set. Why not just
not add them?
Adding to the overload set uses a new lookup_add function, which in turn
uses a new ovl_make. A couple of new OVL_foo flags appear, which will
be used more in subsequent patches.
Also, you may notice that nothing currently adds to the ovl_cache of
reuseable overload nodes. That'll be rectified shortly.
(I'll be killing the current ovl_cons and build_overload later. One
reason for the name changing is that it ensures I converted all the uses.)
nathan
--
Nathan Sidwell
2017-05-16 Nathan Sidwell
* cp-tree.h (OVL_NESTED_P, OVL_LOOKUP_P): New.
(ovl_first): Move inline definition to end of file.
(ovl_make, lookup_add): Declare.
(get_fns, get_first_fn): Make pure.
* tree.c (ovl_cache): New.
(ovl_make, lookup_add): New.
* pt.c (do_class_deduction): Don't add candidates that will be
elided.
Index: cp-tree.h
===
--- cp-tree.h (revision 248120)
+++ cp-tree.h (working copy)
@@ -371,11 +371,13 @@ extern GTY(()) tree cp_global_trees[CPTI
CALL_EXPR_ORDERED_ARGS (in CALL_EXPR, AGGR_INIT_EXPR)
DECLTYPE_FOR_REF_CAPTURE (in DECLTYPE_TYPE)
CONSTUCTOR_C99_COMPOUND_LITERAL (in CONSTRUCTOR)
+ OVL_NESTED_P (in OVERLOAD)
4: TREE_HAS_CONSTRUCTOR (in INDIRECT_REF, SAVE_EXPR, CONSTRUCTOR,
CALL_EXPR, or FIELD_DECL).
IDENTIFIER_TYPENAME_P (in IDENTIFIER_NODE)
DECL_TINFO_P (in VAR_DECL)
FUNCTION_REF_QUALIFIED (in FUNCTION_TYPE, METHOD_TYPE)
+ OVL_LOOKUP_P (in OVERLOAD)
5: C_IS_RESERVED_WORD (in IDENTIFIER_NODE)
DECL_VTABLE_OR_VTT_P (in VAR_DECL)
FUNCTION_RVALUE_QUALIFIED (in FUNCTION_TYPE, METHOD_TYPE)
@@ -626,6 +628,11 @@ typedef struct ptrmem_cst * ptrmem_cst_t
and can be freed afterward. */
#define OVL_ARG_DEPENDENT(NODE) TREE_LANG_FLAG_0 (OVERLOAD_CHECK (NODE))
+/* If set, this overload contains a nested overload. */
+#define OVL_NESTED_P(NODE) TREE_LANG_FLAG_3 (OVERLOAD_CHECK (NODE))
+/* If set, this overload was constructed during lookup. */
+#define OVL_LOOKUP_P(NODE) TREE_LANG_FLAG_4 (OVERLOAD_CHECK (NODE))
+
/* The first decl of an overload. */
#define OVL_FIRST(NODE) ovl_first (NODE)
/* The name of the overload set. */
@@ -6733,17 +6740,14 @@ extern tree hash_tree_cons (tree, tree
extern tree hash_tree_chain (tree, tree);
extern tree build_qualified_name (tree, tree, tree, bool);
extern tree build_ref_qualified_type (tree, cp_ref_qualifier);
-inline tree
-ovl_first (tree node)
-{
- while (TREE_CODE (node) == OVERLOAD)
-node = OVL_FUNCTION (node);
- return node;
-}
+inline tree ovl_first(tree) ATTRIBUTE_PURE;
+extern tree ovl_make(tree fn,
+ tree next = NULL_TREE);
+extern tree lookup_add(tree lookup, tree ovl);
extern int is_overloaded_fn (tree);
extern tree dependent_name (tree);
-extern tree get_fns(tree);
-extern tree get_first_fn (tree);
+extern tree get_fns(tree) ATTRIBUTE_PURE;
+extern tree get_first_fn (tree) ATTRIBUTE_PURE;
extern tree ovl_cons(tree, tree);
extern tree build_overload (tree, tree);
extern tree ovl_scope(tree);
@@ -7188,6 +7192,16 @@ extern tree cp_ubsan_maybe_instrument_do
extern tree cp_ubsan_maybe_instrument_cast_to_vbase (location_t, tree, tree);
extern void cp_ubsan_maybe_initialize_vtbl_ptrs (tree);
+/* Inline bodies. */
+
+inline tree
+ovl_first (tree node)
+{
+ while (TREE_CODE (node) == OVERLOAD)
+node = OVL_FUNCTION (node);
+ return node;
+}
+
/* -- end of C++ */
#endif /* ! GCC_CP_TREE_H */
Index: pt.c
===
--- pt.c (revision 248120)
+++ pt.c (working copy)
@@ -25157,9 +25157,29 @@ do_class_deduction (tree ptype, tree tmp
tree cands = lookup_qualified_name (CP_DECL_CONTEXT (tmpl), dname,
/*type*/false, /*complain*/false,
/*hidden*/false);
+ bool elided = false;
if (cands == error_mark_node)
cands = NULL_TREE;
+ /* Prune explicit deduction guides in copy-initialization context. */
+ if (flags & LOOKUP_ONLYCONVERTING)
+{
+ for (lkp_iterator iter (cands); !elided && iter; ++iter)
+ if (DECL_NONCONVERTING_P (STRIP_TEMPLATE (*iter)))
+ elided = true;
+
+ if (elided)
+ {
+ /* Found a nonconverting guide, prune the candidates. */
+ tree pruned = NULL_TREE;
+ for (lkp_iterator iter (cands); iter; ++iter)
+ if (!DECL_NONCONVERTING_P (STRIP_TEMPLATE (*iter)))
+ pruned = lookup_add (pruned, *iter);
+
+ cands = pruned;
+ }
+}
+
tree outer_args = NULL_TREE;
if (DECL_CLASS_SCOPE_P (tmpl)
&& CLASSTYPE_TEMPLATE_INFO (DECL_CONTEXT (tmpl)))
@@ -25171,11 +25191,15 @@ do_class_deduction (tree ptype, tree tmp
bool saw_ctor = false;
if (CLASSTYPE_METHOD_VEC (type))
// FIXME cache artificial deduction guides
-for (tree fns = CLASSTYPE_CONS
Re: dejagnu version update?
On 16.05.2017 05:35, Bernhard Reutner-Fischer wrote: > On 16 May 2017 at 14:16, Jonathan Wakely wrote: >> On 16 May 2017 at 13:13, Bernhard Reutner-Fischer wrote: >>> 1.5.0 wouldn't buy us anything as the "libdirs" handling is only in 1.5.2 >>> and later. >> >> Ah I missed that in the earlier discussion. >> >> The change I care about in 1.5.3 is >> http://git.savannah.gnu.org/gitweb/?p=dejagnu.git;a=commit;h=5256bd82343000c76bc0e48139003f90b6184347 > > the libdirs handling is > http://git.savannah.gnu.org/gitweb/?p=dejagnu.git;a=commit;h=5481f29161477520c691d525653323b82fa47ad7 > and applies cleanly to everything 1.5.x-ish. Didn't try if it applies to > 1.4.4. this patch is part of dejagnu in Ubuntu 14.04 LTS.
Re: [PATCH] Don't fold in save_expr (PR sanitizer/80536, PR sanitizer/80386)
On Fri, May 12, 2017 at 6:09 AM, Marek Polacek wrote:
> On Fri, May 12, 2017 at 09:32:48AM +0200, Richard Biener wrote:
>> On Thu, May 11, 2017 at 3:49 PM, Marek Polacek wrote:
>> > I had an interesting time coming to grips with these two PRs. But it
>> > essentially comes down to the fold call in save_expr. With that, we can
>> > call
>> > fold() on an expression whose operands weren't folded yet, but that is what
>> > code in fold_binary_loc assumes. Since fold() is not recursive, we could
>> > end
>> > up there with expressions such as
>> > i * ((unsigned long) -0 + 1) * 2
>> > causing various sorts of problems: turning valid code into invalid,
>> > infinite
>> > recursion, etc.
>> >
>> > It's not clear why save_expr folds. I did some archeology but all I could
>> > find was r67189 (that's 2003) which had:
>> >
>> > - tree t = expr;
>> > + tree t = fold (expr);
>> >tree inner;
>> >
>> > - /* Don't fold a COMPONENT_EXPR: if the operand was a CONSTRUCTOR (the
>> > - only time it will fold), it can cause problems with PLACEHOLDER_EXPRs
>> > - in Ada. Moreover, it isn't at all clear why we fold here at all. */
>> > - if (TREE_CODE (t) != COMPONENT_REF)
>> > -t = fold (t);
>> >
>> > so it wasn't clear even 14 years ago. But now we know the call is harmful.
>
> I've come to believe this was purely to discover more invariants.
>
>> > Now, fold() doesn't recurse, but can it happen that it folds something
>> > anyway?
>> > And maybe turn the expression into an invariant so that we don't need to
>> > wrap
>> > it in a SAVE_EXPR? Turns out it can, but in the C FE, which either uses
>> > c_save_expr that c_fully_folds, or calls save_expr when in_late_binary_op
>> > (so
>> > the operands have already been folded), it's very rare, and can only be
>> > triggered
>> > by code such as
>> >
>> > void
>> > f (int i)
>> > {
>> > int (*a)[i];
>> > int x[sizeof (*a)];
>> > }
>> >
>> > so I'm not very worried about that. For C++, Jakub suggested to add
>> > SAVE_EXPR
>> > handling to cp_fold.
>> >
>> > Future work: get rid of c_save_expr, only use save_expr, and teach
>> > c_fully_fold
>> > how to fold SAVE_EXPR (once). Although there's this c_wrap_maybe_const
>> > business...
>> >
>> > Bootstrapped/regtested on x86_64-linux, ok for trunk?
>>
>> Interesting - I tried this once (removing fold () from save_expr) but
>> it failed miserably
>> (don't remember the details). Maybe the cp/ part fixes it up.
>
> I think that must've been before C++ added all that constexpr bits. The
> cp_fold part is just an optimization that triggers very rarely.
>
>> Did you include Ada in testing?
>
> Not before, so I've tested this now with Ada included -- looks fine still.
>
>> Otherwise the tree.c change is ok.
>
> Thanks. Jason/Joseph, any comments?
Looks good to me.
Jason
Re: [C++ PATCH, RFC] Implement new C++ intrinsics __is_assignable and __is_constructible.
On Fri, May 12, 2017 at 2:33 PM, Ville Voutilainen wrote: > On 12 May 2017 at 14:15, Ville Voutilainen > wrote: >> On 12 May 2017 at 14:06, Daniel Krügler wrote: >>> Your description sounds remotely similar to me to the current problem >>> of __is_trivially_constructible intrinsic, which seems to instantiate >>> the copy constructor definition albeit it (IMO) shouldn't: >>> >>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80654 >>> >>> Could there be a similar cause? >> >> >> Seems quite plausible to me. I would be happy to fix that bug in the >> same go, but I'm a bit >> lost as to what exactly causes the problem. constructible_expr in method.c >> does >> build_special_member_call for the constructor and the destructor, so >> perhaps there >> are some flags that could make it behave. > > Well, now that Jason pointed out that cp_unevaluated_operand is the > trick, here's a new > patch that fixes that bug and passes the full testsuite on Linux-x64. OK, thanks. Jason
RE: Fix minor reorg.c bug affecting MIPS targets
From: Jeff Law > On 05/16/2017 10:01 AM, Toma Tabacu wrote: >> Hello Paul, >> >> You're seeing this problem because mips.exp can't handle -O* in dg-options. >> The other tests in gcc.target/mips use a dg-skip-if to skip for -O0 and -O1 >> instead of having -O2 in dg-options. >> This is supposed to ensure that the tests are run for as many optimization >> levels as possible. >> >> I believe that Matthew can confirm this. > Feel free to remove the -O2. The most important bits are -mips2 and > -msoft-float. If nobody does it shortly, I'll take care of it myself. > >jeff Sorry, I won't be able to commit the fix until tomorrow. Thanks for taking care of this issue, though. Regards, Toma Tabacu
Re: [C++ PATCH] OVERLOAD iterators #1
On 05/16/2017 08:50 AM, Nathan Sidwell wrote:
This patch implements new iterators for OVERLOADs. There are two
iterators:
ovl_iterator for a plain iterator, that held on a binding
lkp_iterator for the overload set returned by lookup.
To use them simply:
for (lkp_iterator iter (INIT); iter; ++iter)
{ tree fn = *iter;
... }
Currently the latter simply defers to the former, but I'll be changing
lookup so that it can return an overload of overloads. (Right now it
simply flattens things, which is sub-optimal).
This changes the easier cases of iteration to use these. I'll be
working through the other cases to convert them.
I've often wished for nice interfaces like this to get away from
the low level macros and make working with trees feel at least
a little bit like using C++ :) Thanks for making it possible!
Just a couple of suggestions, It looks like the classes model
the concept of Forward Iterator. May I suggest to make them
model it more closely and make them behave in unsurprising
ways to those familiar with the concept?
E.g., define both pre-increment and post-increment, define
the equality operator (as a non-member), etc., based on
C++ Forward Iterator requirements.
I'm not sure I understand why the ovl_iterator assignment needs
to be provided but if it does, not also defining one on the derived
class will call the base and return a reference to the base, making
the result no longer suitable where the derived is needed. This
is true for any other base members that return [a reference to]
the base type.
(If distinct types for iterators modeling the same concept
are necessary (or helpful) I would actually suggest to avoid
inheritance and instead introduce a generic iterator as
a template, and as many distinct [implicit] specializations
as necessary, with typedefs for each to make them look and
feel like classes.)
Martin
PS More descriptive names would be a nice as well (neither
lkp_ nor ovl_ is intuitive enough at first glance.) Maybe
lookup_iter and overload_iter?
Re: [C++ PATCH] OVERLOAD iterators #1
Martin, Thanks for taking a look. There's a whole patch series I hope to land over the next couple of weeks. Things may be clearer at that point. Just a couple of suggestions, It looks like the classes model the concept of Forward Iterator. May I suggest to make them model it more closely and make them behave in unsurprising ways to those familiar with the concept? Sure -- I'm an STL weenie though. I only defined the members that I needed for what I wanted to do. (Originally I had hoped to turn OVERLOADS into vectors, but that didn't work out for reasons that I'll get to in later patches.) I'm not sure I understand why the ovl_iterator assignment needs to be provided but if it does, not also defining one on the derived class will call the base and return a reference to the base, making the result no longer suitable where the derived is needed. This is true for any other base members that return [a reference to] the base type. The assignment is needed when the 2-d iterator stuff lands. It becomes more complex then. But I think your point may still be valid. (If distinct types for iterators modeling the same concept are necessary (or helpful) I would actually suggest to avoid inheritance and instead introduce a generic iterator as a template, and as many distinct [implicit] specializations as necessary, with typedefs for each to make them look and feel like classes.) Right, that was my initial idea, but the polymorphism of tree didn't really help. The compiler can't deduce at compile time from a tree node, even if you know it's an OVERLOAD, as to which iterator you want. PS More descriptive names would be a nice as well (neither lkp_ nor ovl_ is intuitive enough at first glance.) Maybe lookup_iter and overload_iter? Works for me -- I just noticed we had things like vec_iterator already, and continued that naming. It was only recently I renamed lkp_iterator from ovl2_iterator! Let's get this landed before renaming things though? nathan -- Nathan Sidwell
Re: dejagnu version update?
On May 16, 2017, at 5:16 AM, Jonathan Wakely wrote: > The change I care about in 1.5.3 So, we haven't talked much about the version people want most. If we update, might as well get something that more people care about. 1.5.3 is in ubuntu LTS 16.04 and Fedora 24, so it's been around awhile. SUSU is said to be using 1.6, in the post 1.4.4 systems. People stated they want 1.5.2 and 1.5.3, so, I'm inclined to say, let's shoot for 1.5.3 when we do update. As for the machines in the FSF compile farm, nah, tail wagging the dog. I'd rather just update the requirement, and the owners or users of those machines can install a new dejagnu, if they are using one that is too old and they want to support testing gcc.
Re: [C++ PATCH] OVERLOAD iterators #1
On 05/16/2017 03:05 PM, Nathan Sidwell wrote: PS More descriptive names would be a nice as well (neither lkp_ nor ovl_ is intuitive enough at first glance.) Maybe lookup_iter and overload_iter? Works for me -- I just noticed we had things like vec_iterator already, and continued that naming. It was only recently I renamed lkp_iterator from ovl2_iterator! Let's get this landed before renaming things though? To be clear, I mean your suggestion works for me, not that the current names are intuitive to me (but that's also true as I've been exposed to them for several months) nathan -- Nathan Sidwell
Re: [C++ PATCH] OVERLOAD iterators #1
On Tue, May 16, 2017 at 2:50 PM, Martin Sebor wrote: > I'm not sure I understand why the ovl_iterator assignment needs > to be provided but if it does, not also defining one on the derived > class will call the base and return a reference to the base, making > the result no longer suitable where the derived is needed. This > is true for any other base members that return [a reference to] > the base type. > Huh? The implicitly declared copy assignment operator in a derived class will always hide the assignment operators from the base class. Also, operator bool() seems suspect. Consider the safe bool idiom? And is it intended that tree implicitly converts to both iterators, or should those constructors be explicit?
[C++ PATCH] decl shadow checking
This patch breaks out the shadowed variable checking from pushdecl to a
worker function. pushdecl was too big.
nathan
--
Nathan Sidwell
2017-05-16 Nathan Sidwell
* name-lookup.c (check_local_shadow): New, broke out of ...
(pushdecl_maybe_friend_1): ... here. Call it.
Index: name-lookup.c
===
--- name-lookup.c (revision 248121)
+++ name-lookup.c (working copy)
@@ -1184,6 +1184,215 @@ supplement_binding (cxx_binding *binding
return ret;
}
+/* DECL is being declared at a local scope. Emit suitable shadow
+ warnings. */
+
+static void
+check_local_shadow (tree decl)
+{
+ /* Don't complain about the parms we push and then pop
+ while tentatively parsing a function declarator. */
+ if (TREE_CODE (decl) == PARM_DECL && !DECL_CONTEXT (decl))
+return;
+
+ /* Inline decls shadow nothing. */
+ if (DECL_FROM_INLINE (decl))
+return;
+
+ /* External decls are something else. */
+ if (DECL_EXTERNAL (decl))
+return;
+
+ tree old = NULL_TREE;
+ cp_binding_level *old_scope = NULL;
+ if (cxx_binding *binding = outer_binding (DECL_NAME (decl), NULL, true))
+{
+ old = binding->value;
+ old_scope = binding->scope;
+}
+ while (old && VAR_P (old) && DECL_DEAD_FOR_LOCAL (old))
+old = DECL_SHADOWED_FOR_VAR (old);
+
+ tree shadowed = NULL_TREE;
+ if (old
+ && (TREE_CODE (old) == PARM_DECL
+ || VAR_P (old)
+ || (TREE_CODE (old) == TYPE_DECL
+ && (!DECL_ARTIFICIAL (old)
+ || TREE_CODE (decl) == TYPE_DECL)))
+ && (!DECL_ARTIFICIAL (decl)
+ || DECL_IMPLICIT_TYPEDEF_P (decl)
+ || (VAR_P (decl) && DECL_ANON_UNION_VAR_P (decl
+{
+ /* DECL shadows a local thing possibly of interest. */
+
+ /* Don't complain if it's from an enclosing function. */
+ if (DECL_CONTEXT (old) == current_function_decl
+ && TREE_CODE (decl) != PARM_DECL
+ && TREE_CODE (old) == PARM_DECL)
+ {
+ /* Go to where the parms should be and see if we find
+ them there. */
+ cp_binding_level *b = current_binding_level->level_chain;
+
+ if (FUNCTION_NEEDS_BODY_BLOCK (current_function_decl))
+ /* Skip the ctor/dtor cleanup level. */
+ b = b->level_chain;
+
+ /* ARM $8.3 */
+ if (b->kind == sk_function_parms)
+ {
+ error ("declaration of %q#D shadows a parameter", decl);
+ return;
+ }
+ }
+
+ /* The local structure or class can't use parameters of
+ the containing function anyway. */
+ if (DECL_CONTEXT (old) != current_function_decl)
+ {
+ for (cp_binding_level *scope = current_binding_level;
+ scope != old_scope; scope = scope->level_chain)
+ if (scope->kind == sk_class
+ && !LAMBDA_TYPE_P (scope->this_entity))
+ return;
+ }
+ /* Error if redeclaring a local declared in a
+ init-statement or in the condition of an if or
+ switch statement when the new declaration is in the
+ outermost block of the controlled statement.
+ Redeclaring a variable from a for or while condition is
+ detected elsewhere. */
+ else if (VAR_P (old)
+ && old_scope == current_binding_level->level_chain
+ && (old_scope->kind == sk_cond || old_scope->kind == sk_for))
+ {
+ error ("redeclaration of %q#D", decl);
+ inform (DECL_SOURCE_LOCATION (old),
+ "%q#D previously declared here", old);
+ return;
+ }
+ /* C++11:
+ 3.3.3/3: The name declared in an exception-declaration (...)
+ shall not be redeclared in the outermost block of the handler.
+ 3.3.3/2: A parameter name shall not be redeclared (...) in
+ the outermost block of any handler associated with a
+ function-try-block.
+ 3.4.1/15: The function parameter names shall not be redeclared
+ in the exception-declaration nor in the outermost block of a
+ handler for the function-try-block. */
+ else if ((TREE_CODE (old) == VAR_DECL
+ && old_scope == current_binding_level->level_chain
+ && old_scope->kind == sk_catch)
+ || (TREE_CODE (old) == PARM_DECL
+ && (current_binding_level->kind == sk_catch
+ || current_binding_level->level_chain->kind == sk_catch)
+ && in_function_try_handler))
+ {
+ if (permerror (input_location, "redeclaration of %q#D", decl))
+ inform (DECL_SOURCE_LOCATION (old),
+ "%q#D previously declared here", old);
+ return;
+ }
+
+ /* If '-Wshadow=compatible-local' is specified without other
+ -Wshadow= flags, we will warn only when the type of the
+ shadowing variable (DECL) can be converted to that of the
+ shadowed parameter (OLD_LOCAL). The reason why we only check
+ if DECL's type can be converted to OLD_LOCAL's type (but not the
+ other way around) is because when users accidentally shadow a
+ parameter, more than often they would use the variable
+ thinking (mistakenly) it's still the parameter. It would be
+ rare that users would use the variable in the place that
+ expects the parameter but thinking it's a new decl. */
+
+ enum opt_code warning_code;
Re: [C++ PATCH] OVERLOAD iterators #1
On 05/16/2017 03:20 PM, Tim Song wrote: Also, operator bool() seems suspect. Consider the safe bool idiom? ? And is it intended that tree implicitly converts to both iterators, or should those constructors be explicit? Maybe. Not caused a problem in practice -- never passing iterators around, so they're always effectively explicit. nathan -- Nathan Sidwell
Re: [C++ PATCH] OVERLOAD iterators #1
On Tue, May 16, 2017 at 3:24 PM, Nathan Sidwell wrote: > On 05/16/2017 03:20 PM, Tim Song wrote: > >> Also, operator bool() seems suspect. Consider the safe bool idiom? > > ? https://en.wikibooks.org/wiki/More_C%2B%2B_Idioms/Safe_bool I suspect that we don't want adding two ovl_iterators together to compile.
Re: [C++ PATCH] OVERLOAD iterators #1
On 05/16/2017 03:27 PM, Tim Song wrote: https://en.wikibooks.org/wiki/More_C%2B%2B_Idioms/Safe_bool Oh, I see. I'm not going to stop someone adding it, but for me, it's quite far down my priority list. I suspect that we don't want adding two ovl_iterators together to compile. Why would anyone write that :) nathan -- Nathan Sidwell
Re: [C++ PATCH] OVERLOAD iterators #1
On 05/16/2017 01:05 PM, Nathan Sidwell wrote:
Martin,
Thanks for taking a look. There's a whole patch series I hope to land
over the next couple of weeks. Things may be clearer at that point.
Just a couple of suggestions, It looks like the classes model
the concept of Forward Iterator. May I suggest to make them
model it more closely and make them behave in unsurprising
ways to those familiar with the concept?
Sure -- I'm an STL weenie though. I only defined the members that I
needed for what I wanted to do. (Originally I had hoped to turn
OVERLOADS into vectors, but that didn't work out for reasons that I'll
get to in later patches.)
I'm not sure I understand why the ovl_iterator assignment needs
to be provided but if it does, not also defining one on the derived
class will call the base and return a reference to the base, making
the result no longer suitable where the derived is needed. This
is true for any other base members that return [a reference to]
the base type.
The assignment is needed when the 2-d iterator stuff lands. It becomes
more complex then. But I think your point may still be valid.
(If distinct types for iterators modeling the same concept
are necessary (or helpful) I would actually suggest to avoid
inheritance and instead introduce a generic iterator as
a template, and as many distinct [implicit] specializations
as necessary, with typedefs for each to make them look and
feel like classes.)
Right, that was my initial idea, but the polymorphism of tree didn't
really help. The compiler can't deduce at compile time from a tree
node, even if you know it's an OVERLOAD, as to which iterator you want.
I'm not sure I explained it clearly enough (or maybe I don't
understand the problem you are referring to). Let me try to
sketch out what I meant (completely off the cuff):
template
class forward_iterator {
tree ovl;
public:
// this perhaps should be declared explicit
forward_iterator (tree);
forward_iterator& operator++ ();
forward_iterator operator++ (int) {
forward_iterator tmp (*this);
++*this;
return tmp;
}
// ...
};
template
bool opearator== (const forward_iterator &lhs,
const forward_iterator &rhs)
{
return lhs.ovl == rhs.ovl; // or whatever is appropriate
}
// repeat the above for other equality and relational operators
struct lkp_iterator_tag;
typedef forward_iterator lkp_iterator;
struct ovl_iterator_tag;
typedef forward_iterator ovl_iterator;
I.e., only one implementation template is needed and it gets
instantiated on a unique tag to make the iterators distinct
from one another. This avoids the slicing problem with
the derivation.
PS More descriptive names would be a nice as well (neither
lkp_ nor ovl_ is intuitive enough at first glance.) Maybe
lookup_iter and overload_iter?
Works for me -- I just noticed we had things like vec_iterator already,
and continued that naming. It was only recently I renamed lkp_iterator
from ovl2_iterator! Let's get this landed before renaming things though?
I'm sure it's easy to get used to. It's just a tiny bit easier
to read for those who see it for the first time. Whatever works
Martin
Re: [C++ Patch] Remove is_auto_or_concept, etc
Sorry for not getting back to your original post Paolo. I haven't been picking up mails for a while. On 2017-05-01 16:56, Jason Merrill wrote: On Thu, Apr 27, 2017 at 2:02 PM, Paolo Carlini wrote: On 26/04/2017 12:32, Paolo Carlini wrote: in 2013 (2013-09-16) Adam added two slightly obscure functions and I can't find much around in terms of rationale, etc: is_auto_or_concept (const_tree type) type_uses_auto_or_concept (tree type) I don't think they were there in the original 2009 version on the old lambdas branch -- but it stagnated somewhat and when I remade it against mainline (4.something) it was around the time that concepts were showing similar semantics (in terms of implicit/abbrievated templates). I made a cardinal sin and introduced an overly-generic function name expecting that a future concepts implementation would need to trigger at the same point of the parse too. I.e. if a concept name or 'auto' is seen we inject an implicit template parameter (or make the "plain" function into a template at that point). That intent was not well documented or published (other than in the API name) and, since -fconcepts is now working without any calls to this function, it's clearly not been necessary or has been more naturally done in a different way. The latter seems completely unused (it's meant for debugging purposes?); Quite possibly for debugging though maybe some refactoring got rid of the need for it and neglected to bin it. the former evidently simply forwards to is_auto, and we end up in the front-end with uses of both, which in fact are equivalent, which seems weird: IMHO, if they are actually equivalent in our implementation we should clearly explain that in the comment and have only one. Or what? ... replying to myself, in practice we could do the below, which certainly passes testing, and in fact now seems to me even more obvious than I thought a couple of days ago... Definitely OK to bin. No point in having dead or confusing code; it's complicated enough as it is. :)
Re: [PATCH] warn on mem calls modifying objects of non-trivial types (PR 80560)
On Thu, May 11, 2017 at 12:23 PM, Martin Sebor wrote: > The challenge with using memcpy or memset with class types is > figuring out if it's being called to copy-construct a new object > or assign a new value to an existing one. In general it's not > possible to tell so the conservative assumption is that it's > the latter. > > Because of that, relying on the trivially copyable property to > determine whether it's safe to assign a new value to an object > is not sufficient (or even necessary). The class must be at > a minimum trivially assignable. But it turns out that even > trivial assignability as defined by C++ isn't enough. A class > with a const data member or a member of a reference type is > considered "trivially assignable" but its copy assignment is > deleted, and so it can't be assigned to. Calling memset or > memcpy to write over an object of such a class can violate > the const invariant or corrupt the reference, respectively. Yes, "trivially copyable" elides the differences between initialization and assignment context. I agree that it makes sense to check for a trivial assignment operator specifically. I guess we want a slightly stronger "trivially copyable" that also requires a non-deleted assignment operator. It seems to me that the relevant tests are: bcopy/memcpy/memmove want trivally copyable + non-deleted assignment. bzero/memset want trivial + non-deleted assignment. I'm still not convinced we need to consider standard-layout at all. Jason
Re: [C++ PATCH] OVERLOAD iterators #1
On 05/16/2017 01:20 PM, Tim Song wrote: On Tue, May 16, 2017 at 2:50 PM, Martin Sebor wrote: I'm not sure I understand why the ovl_iterator assignment needs to be provided but if it does, not also defining one on the derived class will call the base and return a reference to the base, making the result no longer suitable where the derived is needed. This is true for any other base members that return [a reference to] the base type. Huh? The implicitly declared copy assignment operator in a derived class will always hide the assignment operators from the base class. Ah, yes, you're right about the copy assignment. Thanks for setting me straight! Clearly my C++ has become so rusty from working on a C++ compiler that I forgot this essential bit (making Nathan's C++-ification of GCC source code that much more important! ;) The general point is still valid that the other base members that return a reference to the base type will have the slicing effect above. Martin
Re: [PATCH] [i386] Recompute the frame layout less often
On 05/16/17 19:19, Ian Lance Taylor wrote:
> On Mon, May 15, 2017 at 10:00 PM, Daniel Santos
> wrote:
>>
>> Ian, would you mind looking at this please? A combination of my
>> -mcall-ms2sysv-xlogues patch with Bernd's patch is causing problems when
>> ix86_expand_split_stack_prologue() calls ix86_expand_call().
>
> I don't have a lot of context here. I assume that ms2sysv is going to
> be used on Windows systems, where -fsplit-stack isn't really going to
> work anyhow, so I think it would probably be OK that reject that
> combination if it causes trouble.
>
> Also, it's overkill for ix86_expand_split_stack_prologue to call
> ix86_expand_call. The call is always to __morestack, and __morestack
> is written in assembler, so we could use a simpler version of
> ix86_expand_call if that helps. In particular we can decide that
> __morestack doesn't clobber any unusual registers, if that is what is
> causing the problem.
>
I think I solved the problem with -fsplit-stack, I am not sure
if ix86_static_chain_on_stack might change after reload due to
final.c possibly calling targetm.calls.static_chain, but if that
is the case, that is an already pre-existing problem.
The goal of this patch is to make all decisions regarding the
frame layout before the reload pass, and to make sure that
the frame layout does not change unexpectedly it asserts
that the data that goes into the decision does not change
after reload_completed.
With the attached patch -fsplit-stack and the attribute ms_hook_prologue
is handed directly at the ix86_expand_call, because that data is
already known before expansion.
The calls_eh_return and ix86_static_chain_on_stack may become
known at a later time, but after reload it should not change any more.
To be sure, I added an assertion at ix86_static_chain, which the
regression test did not trigger, neither with -m64 nor with -m32.
I have bootstrapped the patch several times, and a few times I
encounterd a segfault in the garbage collection, but it did not
happen every time. Currently I think that is unrelated to this patch.
Bootstrapped and reg-tested on x86_64-pc-linux-gnu with -m64/-m32.
Is it OK for trunk?
Thanks
Bernd.
2017-05-16 Bernd Edlinger
* config/i386/i386.c (x86_64_ms_sysv_extra_clobbered_registers): Make
static.
(xlogue_layout::get_stack_space_used, xlogue_layout::s_instances,
xlogue_layout::get_instance, logue_layout::xlogue_layout,
xlogue_layout::get_stub_name, xlogue_layout::get_stub_rtx,
sp_valid_at, fp_valid_at, choose_basereg): Formatting.
(xlogue_layout::compute_stub_managed_regs): Clear out param first.
(stub_managed_regs): Remove.
(ix86_save_reg): Use xlogue_layout::compute_stub_managed_regs.
(disable_call_ms2sysv_xlogues): Rename to...
(warn_once_call_ms2sysv_xlogues): ...this, and warn only once.
(ix86_initial_elimination_offset, ix86_expand_call): Fix call_ms2sysv
warning logic.
(ix86_static_chain): Make sure that ix86_static_chain_on_stack can't
change after reload_completed.
(ix86_can_use_return_insn_p): Use the ix86_frame data structure
directly.
(ix86_expand_prologue): Likewise.
(ix86_expand_epilogue): Likewise.
(ix86_expand_split_stack_prologue): Likewise.
(ix86_compute_frame_layout): Remove frame parameter ...
(TARGET_COMPUTE_FRAME_LAYOUT): ... and export it as a target hook.
(ix86_finalize_stack_realign_flags): Call ix86_compute_frame_layout
only if necessary.
(ix86_init_machine_status): Don't set use_fast_prologue_epilogue_nregs.
(ix86_frame): Move from here ...
* config/i386/i386.h (ix86_frame): ... to here.
(machine_function): Remove use_fast_prologue_epilogue_nregs, cache the
complete ix86_frame data structure instead.
Index: gcc/config/i386/i386.c
===
--- gcc/config/i386/i386.c (revision 248031)
+++ gcc/config/i386/i386.c (working copy)
@@ -2425,7 +2425,9 @@ static int const x86_64_int_return_registers[4] =
/* Additional registers that are clobbered by SYSV calls. */
-unsigned const x86_64_ms_sysv_extra_clobbered_registers[12] =
+#define NUM_X86_64_MS_CLOBBERED_REGS 12
+static int const x86_64_ms_sysv_extra_clobbered_registers
+ [NUM_X86_64_MS_CLOBBERED_REGS] =
{
SI_REG, DI_REG,
XMM6_REG, XMM7_REG,
@@ -2484,13 +2486,13 @@ class xlogue_layout {
needs to store registers based upon data in the machine_function. */
HOST_WIDE_INT get_stack_space_used () const
{
-const struct machine_function &m = *cfun->machine;
-unsigned last_reg = m.call_ms2sysv_extra_regs + MIN_REGS - 1;
+const struct machine_function *m = cfun->machine;
+unsigned last_reg = m->call_ms2sysv_extra_regs + MIN_REGS - 1;
-gcc_assert (m.call_ms2sysv_extra_regs <= MAX_EXTRA_REGS);
+gcc_assert (m->call_ms2sysv_extra_regs <= MAX_EXTRA_REGS);
Re: [Patch, fortran] PR80554 [f08] variable redefinition in submodule
Hi Jerry and Steve, Thanks for taking a peek - committed as revision 248129. I'll commit to 7-branch in a couple of weeks. Cheers Paul On 15 May 2017 at 21:29, Jerry DeLisle wrote: > On 05/15/2017 04:10 AM, Paul Richard Thomas wrote: >> >> The attached bootstraps and regtests on FC23/x86_64 - OK for trunk and >> later for 7-branch? >> >> The comment in the patch and the ChangeLog are sufficiently clear that >> no further explanation is needed here. >> > > Looks OK Paul, thanks, > > Jerry -- "If you can't explain it simply, you don't understand it well enough" - Albert Einstein
Re: Default std::vector default and move constructor
On 15/05/2017 21:31, Marc Glisse wrote: On Mon, 15 May 2017, François Dumont wrote: I also added some optimizations. Especially replacement of std::fill with calls to __builtin_memset. Has anyone ever proposed to optimize std::fill in such a way ? It would require a test on the value used to fill the range but it might worth this additional runtime check, no ? Note that with -O3, gcc recognizes the pattern in std::fill and generates a call to memset (there is a bit too much extra code around the memset, but a couple match.pd transformations should fix that). Good to know, at least g++ will be able to spend more time on other optimizations :-) What is match.pd ? That doesn't mean we can't save it the work. If you want to save the runtime check, there is always __builtin_constant_p... Good point, I will give it a try. The __fill_bvector part of the fill overload for vector could do with some improvements as well. Looping is unnecessary, one just needs to produce the right mask and and or or with it, that shouldn't take more than 4 instructions or so. Yes, good idear, I'll submit another patch after this one. There was a time when I suggested overloading std::count and std::find in order to use __builtin_popcount, etc. But from what I've seen of committee discussions, I expect that there will be specialized algorithms (possibly member functions) eventually, making the overload less useful. ok, thanks for those feedbacks. François
Re: [PATCH] [i386] Recompute the frame layout less often
On 05/16/17 21:52, Bernd Edlinger wrote:
> The calls_eh_return and ix86_static_chain_on_stack may become
> known at a later time, but after reload it should not change any more.
> To be sure, I added an assertion at ix86_static_chain, which the
> regression test did not trigger, neither with -m64 nor with -m32.
>
Oops, excuse me, actually -m32 does trigger the assert, for instance:
FAIL: gcc.target/i386/pr67770.c (internal compiler error)
FAIL: gcc.target/i386/pr67770.c (test for excess errors)
Excess errors:
/home/ed/gnu/gcc-trunk/gcc/testsuite/gcc.target/i386/pr67770.c:25:3:
internal compiler error: in ix86_static_chain, at config/i386/i386.c:31481
0xecf71a ix86_static_chain
../../gcc-trunk/gcc/config/i386/i386.c:31481
0x7b33b2 df_get_entry_block_def_set
../../gcc-trunk/gcc/df-scan.c:3539
0x7bb0b6 df_scan_blocks()
../../gcc-trunk/gcc/df-scan.c:576
0x9bc46d do_reload
../../gcc-trunk/gcc/ira.c:5504
0x9bc46d execute
../../gcc-trunk/gcc/ira.c:5624
As it looks like ix86_static_chain_on_stack will definitely change
the frame layout, and that is probably something that should not
have happened. Without the assert it could be wrong code, right?
However, the following change would avoid the assertion:
if (fndecl == current_function_decl
&& !ix86_static_chain_on_stack)
{
gcc_assert (!reload_completed);
ix86_static_chain_on_stack = true;
}
At least in the test case above...
Thanks
Bernd.
[gomp4] Update libgomp documentation
This patch does two things:
1. Updates the libgomp documentation to reflect the recent OpenACC 2.5
changes.
2. Backports a texinfo patch to wrap the title of the libgomp manual
in the pdf. Without it, part of the title would get truncated out
of the page.
For the most part, the gomp-4_0-branch should support the OpenACC 2.5
API, with the notable exception of acc_memcpy_device. While the runtime
doesn't support that function yet, I've added a placeholder if it.
Arguably, I probably should have split the backport into a separate
patch. However, I think this only impacts libgomp. And I was tempted to
just to copy the complete texinfo.tex file from texinfo 6.3, like it was
last done in 2012. However, I wasn't sure if that would have required
any strange dependencies.
I've applied this patch to gomp-4_0-branch.
Cesar
2017-05-16 Cesar Philippidis
gcc/
* doc/include/texinfo.tex: Backport @title linewrap changes from
texinfo 6.3.
libgomp/
* libgomp.texi: Update OpenACC references to version 2.5. Add entries
for acc_memcpy_to_device_async, acc_memcpy_from_device_async,
acc_memcpy_device, acc_memcpy_device_async, acc_get_default_async,
acc_set_default_async.
diff --git a/gcc/doc/include/texinfo.tex b/gcc/doc/include/texinfo.tex
index a5a7b2b..943e868 100644
--- a/gcc/doc/include/texinfo.tex
+++ b/gcc/doc/include/texinfo.tex
@@ -3,7 +3,7 @@
% Load plain if necessary, i.e., if running under initex.
\expandafter\ifx\csname fmtname\endcsname\relax\input plain\fi
%
-\def\texinfoversion{2012-06-05.14}
+\def\texinfoversion{2017-05-16.12}
%
% Copyright 1985, 1986, 1988, 1990, 1991, 1992, 1993, 1994, 1995,
% 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006,
@@ -594,7 +594,7 @@
\def\:{\spacefactor=1000 }
% @* forces a line break.
-\def\*{\hfil\break\hbox{}\ignorespaces}
+\def\*{\unskip\hfil\break\hbox{}\ignorespaces}
% @/ allows a line break.
\let\/=\allowbreak
@@ -3262,6 +3262,20 @@ end
\finishedtitlepagetrue
}
+% Settings used for typesetting titles: no hyphenation, no indentation,
+% don't worry much about spacing, ragged right. This should be used
+% inside a \vbox, and fonts need to be set appropriately first. Because
+% it is always used for titles, nothing else, we call \rmisbold. \par
+% should be specified before the end of the \vbox, since a vbox is a group.
+%
+\def\raggedtitlesettings{%
+ \rmisbold
+ \hyphenpenalty=1
+ \parindent=0pt
+ \tolerance=5000
+ \ptexraggedright
+}
+
% Macros to be used within @titlepage:
\let\subtitlerm=\tenrm
@@ -3269,7 +3283,7 @@ end
\parseargdef\title{%
\checkenv\titlepage
- \leftline{\titlefonts\rmisbold #1}
+ \vbox{\titlefonts \raggedtitlesettings #1\par}%
% print a rule at the page bottom also.
\finishedtitlepagefalse
\vskip4pt \hrule height 4pt width \hsize \vskip4pt
@@ -5543,14 +5557,6 @@ end
% Define @majorheading, @heading and @subheading
-% NOTE on use of \vbox for chapter headings, section headings, and such:
-% 1) We use \vbox rather than the earlier \line to permit
-% overlong headings to fold.
-% 2) \hyphenpenalty is set to 1 because hyphenation in a
-% heading is obnoxious; this forbids it.
-% 3) Likewise, headings look best if no \parindent is used, and
-% if justification is not attempted. Hence \raggedright.
-
\def\majorheading{%
{\advance\chapheadingskip by 10pt \chapbreak }%
\parsearg\chapheadingzzz
@@ -5558,10 +5564,8 @@ end
\def\chapheading{\chapbreak \parsearg\chapheadingzzz}
\def\chapheadingzzz#1{%
- {\chapfonts \vbox{\hyphenpenalty=1\tolerance=5000
-\parindent=0pt\ptexraggedright
-\rmisbold #1\hfill}}%
- \bigskip \par\penalty 200\relax
+ \vbox{\chapfonts \raggedtitlesettings #1\par}%
+ \nobreak\bigskip \nobreak
\suppressfirstparagraphindent
}
@@ -5720,8 +5724,7 @@ end
%
% Typeset the actual heading.
\nobreak % Avoid page breaks at the interline glue.
-\vbox{\hyphenpenalty=1 \tolerance=5000 \parindent=0pt \ptexraggedright
- \hangindent=\wd0 \centerparametersmaybe
+\vbox{\raggedtitlesettings \hangindent=\wd0 \centerparametersmaybe
\unhbox0 #1\par}%
}%
\nobreak\bigskip % no page break after a chapter title
@@ -5743,18 +5746,18 @@ end
\def\setchapterstyle #1 {\csname CHAPF#1\endcsname}
%
\def\unnchfopen #1{%
-\chapoddpage {\chapfonts \vbox{\hyphenpenalty=1\tolerance=5000
- \parindent=0pt\ptexraggedright
- \rmisbold #1\hfill}}\bigskip \par\nobreak
+ \chapoddpage
+ \vbox{\chapfonts \raggedtitlesettings #1\par}%
+ \nobreak\bigskip\nobreak
}
\def\chfopen #1#2{\chapoddpage {\chapfonts
\vbox to 3in{\vfil \hbox to\hsize{\hfil #2} \hbox to\hsize{\hfil #1} \vfil}}%
\par\penalty 5000 %
}
\def\centerchfopen #1{%
-\chapoddpage {\chapfonts \vbox{\hyphenpenalty=1\tolerance=5000
- \parindent=0pt
- \hfill
Re: [PATCH] [i386] Recompute the frame layout less often
On 05/16/2017 12:19 PM, Ian Lance Taylor wrote: On Mon, May 15, 2017 at 10:00 PM, Daniel Santos wrote: Ian, would you mind looking at this please? A combination of my -mcall-ms2sysv-xlogues patch with Bernd's patch is causing problems when ix86_expand_split_stack_prologue() calls ix86_expand_call(). I don't have a lot of context here. I assume that ms2sysv is going to be used on Windows systems, where -fsplit-stack isn't really going to work anyhow, so I think it would probably be OK that reject that combination if it causes trouble. Sorry I wasn't more specific. This -mcall-ms2sysv-xlogues actually targets Wine, although they don't use -fsplit-stack. My patch set as-is is disabled when fsplit-stack is used, but during ix86_compute_frame_layout, which is too late in the case of -fsplit-stack. I think I should just change this to a sorry() in ix86_option_override_internal. Also, it's overkill for ix86_expand_split_stack_prologue to call ix86_expand_call. The call is always to __morestack, and __morestack is written in assembler, so we could use a simpler version of ix86_expand_call if that helps. In particular we can decide that __morestack doesn't clobber any unusual registers, if that is what is causing the problem. Ian Well aside from the conflict of the two patches, it just looks like it has the potential to generate clobbers where none are needed, but I'm having trouble actually *proving* that, so maybe I'm just wrong. Daniel
Re: Default std::vector default and move constructor
On Tue, 16 May 2017, François Dumont wrote: What is match.pd ? It is a file in gcc where we describe simple pattern-matching optimizations. In this case, IIRC, the missing transformations were * ptr + n == ptr + 1 --> n == 1 (we already do it if 1 is replaced by a variable or 0) * ((n/8)+1)*8 --> n+8 when the division is known to be exact -- Marc Glisse
Re: [PATCH] warn on mem calls modifying objects of non-trivial types (PR 80560)
On 05/16/2017 01:41 PM, Jason Merrill wrote: On Thu, May 11, 2017 at 12:23 PM, Martin Sebor wrote: The challenge with using memcpy or memset with class types is figuring out if it's being called to copy-construct a new object or assign a new value to an existing one. In general it's not possible to tell so the conservative assumption is that it's the latter. Because of that, relying on the trivially copyable property to determine whether it's safe to assign a new value to an object is not sufficient (or even necessary). The class must be at a minimum trivially assignable. But it turns out that even trivial assignability as defined by C++ isn't enough. A class with a const data member or a member of a reference type is considered "trivially assignable" but its copy assignment is deleted, and so it can't be assigned to. Calling memset or memcpy to write over an object of such a class can violate the const invariant or corrupt the reference, respectively. Yes, "trivially copyable" elides the differences between initialization and assignment context. I agree that it makes sense to check for a trivial assignment operator specifically. I guess we want a slightly stronger "trivially copyable" that also requires a non-deleted assignment operator. It seems to me that the relevant tests are: bcopy/memcpy/memmove want trivally copyable + non-deleted assignment. bzero/memset want trivial + non-deleted assignment. I think that's very close to what the patch does. bzero/memset: expects a trivial class with no private members and with a non-deleted trivial assignment. That looks the same as what you have above. bcopy/memcpy/memmove: expects the same plus trivially copyable, except that the class may be non-trivial if the source of the copy is any of void*, [signed or unsigned] char*, or a pointer to the class itself. In that case, the byte size must either be non-constant or a multiple of the size of the object, to help detect inadvertent partial copies. The test for class triviality is to detect misusing the functions to initialize (construct) an object of a class with a user-defined default ctor by copying bytes into it from an object of unrelated type (void* and char* are allowed for serialization). I did forget about bcopy. Let me add it. I'm still not convinced we need to consider standard-layout at all. I agree. The patch doesn't make use of is_standard_layout_p(). It defines its own helper called almost_std_layout_p() that combines trivial_type_p() with tests for non-public members, ignoring the requirement that all members of a derived standard layout class must be defined in the same base (or derived) class. Is there something you'd like to see done differently in the latest revision of the patch? https://gcc.gnu.org/ml/gcc-patches/2017-05/msg00976.html Martin
Re: [gomp4] Update libgomp documentation
On Tue, 16 May 2017, Cesar Philippidis wrote: > Arguably, I probably should have split the backport into a separate > patch. However, I think this only impacts libgomp. And I was tempted to > just to copy the complete texinfo.tex file from texinfo 6.3, like it was > last done in 2012. However, I wasn't sure if that would have required > any strange dependencies. texinfo.tex should be copied to trunk, from Texinfo SVN trunk, whenever there's a use for a new version of it (copying at any time while open for non-bug-fix changes is OK even if there isn't a specific use for a new version). -- Joseph S. Myers jos...@codesourcery.com
[PATCH] Fix PR middle-end/80775, -O3 produces ice in group_case_labels_stmt
The test case in PR80775 exposes a problem in handling two separate
case labels that lead to the same block that contains a call to
__builtin_unreachable(). The current code handles the first label
and deletes the associated edge/block, but trips up when we see the
second case label that now points to a removed block. This patch moves
the deletion of the unreachable case statement to after the merging
of consecutive case labels, which easily fixes the issue. It also has
a side benefit of reducing the number of calls to gimple_seq_unreachable_p()
when we have consecutive case labels that point to unreachable blocks.
This bootstrapped and regtested with no regressions on both powerpc64le-linux
and x86_64-linux. Is this ok for trunk?
Peter
gcc/
PR middle-end/80775
* tree-cfg.c: Move deletion of unreachable case statements to after
the merging of consecutive case labels.
gcc/testsuite/
PR middle-end/80775
* gcc.dg/pr80775.c: New test.
Index: gcc/tree-cfg.c
===
--- gcc/tree-cfg.c (revision 248119)
+++ gcc/tree-cfg.c (working copy)
@@ -1661,7 +1661,7 @@ void
group_case_labels_stmt (gswitch *stmt)
{
int old_size = gimple_switch_num_labels (stmt);
- int i, j, new_size = old_size;
+ int i, j, base_index, new_size = old_size;
basic_block default_bb = NULL;
default_bb = label_to_block (CASE_LABEL (gimple_switch_default_label
(stmt)));
@@ -1678,16 +1678,9 @@ group_case_labels_stmt (gswitch *stmt)
gcc_assert (base_case);
base_bb = label_to_block (CASE_LABEL (base_case));
- /* Discard cases that have the same destination as the default case
-or if their destination block is unreachable. */
- if (base_bb == default_bb
- || (EDGE_COUNT (base_bb->succs) == 0
- && gimple_seq_unreachable_p (bb_seq (base_bb
+ /* Discard cases that have the same destination as the default case. */
+ if (base_bb == default_bb)
{
- edge e;
- if (base_bb != default_bb
- && (e = find_edge (gimple_bb (stmt), base_bb)) != NULL)
- remove_edge_and_dominated_blocks (e);
gimple_switch_set_label (stmt, i, NULL_TREE);
i++;
new_size--;
@@ -1697,7 +1690,7 @@ group_case_labels_stmt (gswitch *stmt)
base_high = CASE_HIGH (base_case)
? CASE_HIGH (base_case)
: CASE_LOW (base_case);
- i++;
+ base_index = i++;
/* Try to merge case labels. Break out when we reach the end
of the label vector or when we cannot merge the next case
@@ -1723,6 +1716,18 @@ group_case_labels_stmt (gswitch *stmt)
else
break;
}
+
+ /* Discard cases that have an unreachable destination block. */
+ if (EDGE_COUNT (base_bb->succs) == 0
+ && gimple_seq_unreachable_p (bb_seq (base_bb)))
+ {
+ edge base_edge = find_edge (gimple_bb (stmt), base_bb);
+ if (base_edge != NULL)
+ remove_edge_and_dominated_blocks (base_edge);
+ gimple_switch_set_label (stmt, base_index, NULL_TREE);
+ new_size--;
+ i++;
+ }
}
/* Compress the case labels in the label vector, and adjust the
Index: gcc/testsuite/gcc.dg/pr80775.c
===
--- gcc/testsuite/gcc.dg/pr80775.c (nonexistent)
+++ gcc/testsuite/gcc.dg/pr80775.c (working copy)
@@ -0,0 +1,21 @@
+/* PR middle-end/80775 ICE: -O3 produces ice in group_case_labels_stmt. */
+/* { dg-do compile } */
+/* { dg-options "-O3" } */
+
+typedef struct { short a; } b;
+b c[10];
+int d, e, f, g, h;
+int
+i (void)
+{
+ f = 0;
+ for (; f < e; f++) {
+switch (g) {
+case 1:
+ d = 1;
+case 2:
+ c[2 + f].a = 1;
+}
+h += c[f].a;
+ }
+}
Re: [PATCH] warn on mem calls modifying objects of non-trivial types (PR 80560)
On 05/16/2017 08:41 PM, Jason Merrill wrote: > I agree that it makes sense to > check for a trivial assignment operator specifically. I guess we want > a slightly stronger "trivially copyable" that also requires a > non-deleted assignment operator. > > It seems to me that the relevant tests are: > > bcopy/memcpy/memmove want trivally copyable + non-deleted assignment. > bzero/memset want trivial + non-deleted assignment. > > I'm still not convinced we need to consider standard-layout at all. What do you think of warning for memset of types with references? Since NULL references are undefined behavior (N4659, [dcl.ref]/5), IMHO such code is quite smelly and most likely a sign of incomplete refactoring, not design. (My original intention for poisoning memset of standard-layout type in gdb was mainly as proxy/approximation for "type with references". Other properties that make a type non-standard-layout are not as interesting to me.) While at it, maybe the same reasoning would justify warn of memcpy/memset of types with const data members? memcpy of such types kind of sounds like a recipe for subtle breakage that could only be salvaged with std::launder. And if you know about that, you'll probably be copying objects of type T to/from raw byte/char storage, not to/from another T. Actually, now that I look at Martin's new patch, I see he's already warning about const data members and references, both memcpy and memset. I'm not super convinced on warning about memcpy of references (unlike memset), but I don't feel strongly against it either. I'd be fine (FWIW) with giving it a try and see what breaks out there. > +Wnon-trivial-memaccess > +C++ ObjC++ Var(warn_nontrival_memaccess) Warning LangEnabledBy(C++ ObjC++, > Wall) > +Warn for raw memory writes to objects of non-trivial types. May I suggest renaming the warning (and the description above) from -Wnon-trivial-memaccess to something else that avoids "trivial" in its name? Because it's no longer strictly about "trivial" in the standard C++ sense. The documentation talks about "The safe way", and "does not warn on safe calls", so maybe call it -Wunsafe-memaccess? (I spotted a couple typos in the new patch: "otherwse", "becase", btw.) Thanks, Pedro Alves
[PATCH,DWARF] AIX dwarf2out label fix
The AIX Assembler inserts the DWARF section lengths itself. dwarf2out.c previously has been modified to not emit the length on AIX. All well and good until GCC emits a label that it believes references the start of a DWARF section, but actually references an address _after_ the section length inserted by AIX. .dwsect 0x2 Ldebug_line0: .vbyte 2,0x4 This particular issue causes an incorrect offset for DW_AT_stmt_list. The following patch adjusts the reference to the label on AIX to subtract the size of the section length information, which makes GDB much happier. Bootstrapped on powerpc-ibm-aix7.2.0.0 Okay? Thanks, David * dwarf2out.c (dwarf2out_finish): Use a local copy of debug_line_section_label. On AIX, append an expression to subtract the size of the section length info. Index: dwarf2out.c === --- dwarf2out.c (revision 248131) +++ dwarf2out.c (working copy) @@ -29650,6 +29650,7 @@ dwarf2out_finish (const char *) comdat_type_node *ctnode; dw_die_ref main_comp_unit_die; unsigned char checksum[16]; + char dl_section_label[MAX_ARTIFICIAL_LABEL_BYTES]; /* Flush out any latecomers to the limbo party. */ flush_limbo_die_list (); @@ -29767,9 +29768,13 @@ dwarf2out_finish (const char *) } } + strcpy (dl_section_label, debug_line_section_label); + if (XCOFF_DEBUGGING_INFO) +strcat (dl_section_label, TARGET_64BIT ? "-12" : "-4"); + if (debug_info_level >= DINFO_LEVEL_TERSE) add_AT_lineptr (main_comp_unit_die, DW_AT_stmt_list, - debug_line_section_label); + dl_section_label); if (have_macinfo) add_AT_macptr (comp_unit_die (), @@ -29845,7 +29850,7 @@ dwarf2out_finish (const char *) if (debug_info_level >= DINFO_LEVEL_TERSE) add_AT_lineptr (ctnode->root_die, DW_AT_stmt_list, (!dwarf_split_debug_info - ? debug_line_section_label + ? dl_section_label : debug_skeleton_line_section_label)); output_comdat_type_unit (ctnode);
Re: [PATCH] warn on mem calls modifying objects of non-trivial types (PR 80560)
On 05/16/2017 04:48 PM, Pedro Alves wrote: On 05/16/2017 08:41 PM, Jason Merrill wrote: I agree that it makes sense to check for a trivial assignment operator specifically. I guess we want a slightly stronger "trivially copyable" that also requires a non-deleted assignment operator. It seems to me that the relevant tests are: bcopy/memcpy/memmove want trivally copyable + non-deleted assignment. bzero/memset want trivial + non-deleted assignment. I'm still not convinced we need to consider standard-layout at all. What do you think of warning for memset of types with references? Since NULL references are undefined behavior (N4659, [dcl.ref]/5), IMHO such code is quite smelly and most likely a sign of incomplete refactoring, not design. (My original intention for poisoning memset of standard-layout type in gdb was mainly as proxy/approximation for "type with references". Other properties that make a type non-standard-layout are not as interesting to me.) While at it, maybe the same reasoning would justify warn of memcpy/memset of types with const data members? memcpy of such types kind of sounds like a recipe for subtle breakage that could only be salvaged with std::launder. And if you know about that, you'll probably be copying objects of type T to/from raw byte/char storage, not to/from another T. Actually, now that I look at Martin's new patch, I see he's already warning about const data members and references, both memcpy and memset. I'm not super convinced on warning about memcpy of references (unlike memset), but I don't feel strongly against it either. I'd be fine (FWIW) with giving it a try and see what breaks out there. I did this because objects with references cannot be assigned to (the default copy assignment is deleted). So as a baseline rule, I made the warning trigger whenever a native assignment or copy isn't valid. In the IMO unlikely event that a memcpy over a reference is intended, the warning is easy to suppress. I expect calling memset on an object with a reference to almost certainly be a bug since there's no way to make such a reference usable. The only time it might be intentional is when someone tries to wipe out the storage before deleting the object in the storage (e.g., in a dtor). But that's a misuse as well because such calls are typically eliminated, much to many a security analyst's shock and horror. I'd like to eventually diagnose that too (though possibly under a different warning). I used a similar (though not exactly the same) rationale for warning for const members. They too cannot be assigned to, and letting memset or memcpy silently change them violates const-correctnes. It's also undefined and the immutability of such members an optimization opportunity waiting to be exploited. +Wnon-trivial-memaccess +C++ ObjC++ Var(warn_nontrival_memaccess) Warning LangEnabledBy(C++ ObjC++, Wall) +Warn for raw memory writes to objects of non-trivial types. May I suggest renaming the warning (and the description above) from -Wnon-trivial-memaccess to something else that avoids "trivial" in its name? Because it's no longer strictly about "trivial" in the standard C++ sense. The documentation talks about "The safe way", and "does not warn on safe calls", so maybe call it -Wunsafe-memaccess? I debated whether to rename things (not just the warning but also the function that implements it in GCC). Ultimately I decided it wasn't necessary because the rules seem close enough to be based on some notion of triviality and because no better name came to mind. -Wunsafe-memaccess might work. The one mild concern I have with it is that it could suggest it might do more than simple type checking (e.g., buffer overflow and what not). Let's see what Jason thinks. (I spotted a couple typos in the new patch: "otherwse", "becase", btw.) I'm a horrible typist. I'll proofread the patch again and fix them up before committing it. Martin
Re: [PATCH] [i386] Recompute the frame layout less often
On 05/16/2017 02:52 PM, Bernd Edlinger wrote:
I think I solved the problem with -fsplit-stack, I am not sure
if ix86_static_chain_on_stack might change after reload due to
final.c possibly calling targetm.calls.static_chain, but if that
is the case, that is an already pre-existing problem.
The goal of this patch is to make all decisions regarding the
frame layout before the reload pass, and to make sure that
the frame layout does not change unexpectedly it asserts
that the data that goes into the decision does not change
after reload_completed.
With the attached patch -fsplit-stack and the attribute ms_hook_prologue
is handed directly at the ix86_expand_call, because that data is
already known before expansion.
The calls_eh_return and ix86_static_chain_on_stack may become
known at a later time, but after reload it should not change any more.
To be sure, I added an assertion at ix86_static_chain, which the
regression test did not trigger, neither with -m64 nor with -m32.
I have bootstrapped the patch several times, and a few times I
encounterd a segfault in the garbage collection, but it did not
happen every time. Currently I think that is unrelated to this patch.
Bootstrapped and reg-tested on x86_64-pc-linux-gnu with -m64/-m32.
Is it OK for trunk?
Thanks
Bernd.
With as many formatting errors as I seem to have had, I would like to
fix those then you patch on top of that if you wouldn't mind terribly.
While gcc uses subversion, git-blame is still very helpful (then again,
since Uros committed it for me, I guess that's already off).
Index: gcc/config/i386/i386.c
===
--- gcc/config/i386/i386.c(revision 248031)
+++ gcc/config/i386/i386.c(working copy)
@@ -2425,7 +2425,9 @@ static int const x86_64_int_return_registers[4] =
/* Additional registers that are clobbered by SYSV calls. */
-unsigned const x86_64_ms_sysv_extra_clobbered_registers[12] =
+#define NUM_X86_64_MS_CLOBBERED_REGS 12
+static int const x86_64_ms_sysv_extra_clobbered_registers
+ [NUM_X86_64_MS_CLOBBERED_REGS] =
Is there a reason you're changing this unsigned to signed int? While
AX_REG and such are just preprocessor macros, everywhere else it seems
that register numbers are dealt with as unsigned ints.
@@ -2484,13 +2486,13 @@ class xlogue_layout {
needs to store registers based upon data in the
machine_function. */
HOST_WIDE_INT get_stack_space_used () const
{
-const struct machine_function &m = *cfun->machine;
-unsigned last_reg = m.call_ms2sysv_extra_regs + MIN_REGS - 1;
+const struct machine_function *m = cfun->machine;
+unsigned last_reg = m->call_ms2sysv_extra_regs + MIN_REGS - 1;
What is the reason for this change?
-gcc_assert (m.call_ms2sysv_extra_regs <= MAX_EXTRA_REGS);
+gcc_assert (m->call_ms2sysv_extra_regs <= MAX_EXTRA_REGS);
return m_regs[last_reg].offset
-+ (m.call_ms2sysv_pad_out ? 8 : 0)
-+ STUB_INDEX_OFFSET;
+ + (m->call_ms2sysv_pad_out ? 8 : 0)
+ + STUB_INDEX_OFFSET;
}
/* Returns the offset for the base pointer used by the stub. */
@@ -2532,7 +2534,7 @@ class xlogue_layout {
/* Lazy-inited cache of symbol names for stubs. */
char
m_stub_names[XLOGUE_STUB_COUNT][VARIANT_COUNT][STUB_NAME_MAX_LEN];
- static const struct xlogue_layout GTY(())
s_instances[XLOGUE_SET_COUNT];
+ static const struct GTY(()) xlogue_layout
s_instances[XLOGUE_SET_COUNT];
Hmm, during development I originally had C-style xlogue_layout as a
struct and later decided to make it a class and apparently forgot to
remove the "struct" here. None the less, it's bazaar that the GTY()
would go in between the "struct" and the "xlogue_layout." As I said
before, I don't fully understand how this GTY works. Can we just remove
the "struct" keyword?
Also, if the way I had it was wrong, (and resulted in garbage collection
not working right) then perhaps it was the cause of a problem I had with
caching symbol rtx objects. I could not get this to work because my
cached objects would somehow become stale and I've since removed that
code (from xlogue_layout::get_stub_rtx). (i.e., does GTY effect
lifespan of globals, TU statics and static C++ data members?)
/* Constructor for xlogue_layout. */
@@ -2639,11 +2643,11 @@ xlogue_layout::xlogue_layout (HOST_WIDE_INT
stack_
: m_hfp (hfp) , m_nregs (hfp ? 17 : 18),
m_stack_align_off_in (stack_align_off_in)
{
+ HOST_WIDE_INT offset = stack_align_off_in;
+ unsigned i, j;
+
memset (m_regs, 0, sizeof (m_regs));
memset (m_stub_names, 0, sizeof (m_stub_names));
-
- HOST_WIDE_INT offset = stack_align_off_in;
- unsigned i, j;
for (i = j = 0; i < MAX_REGS; ++i)
{
unsigned regno = REG_ORDER[i];
@@ -2662,11 +2666,12 @@ xlogue_layout::xlogue_layout (HOST_WIDE_INT
stack_
m_regs[j].regno= regno;
m_regs[j++].offset = offset - STUB_INDEX_OFFSET;
}
-gcc_assert (
[PATCH] Dump functions for verification failures
From: Andi Kleen
When a verification check fails it is useful to dump the current
function to the dump file, so it's easier to figure out what
actually went wrong.
Add function dumps for gimple or SSA verification failures.
Suggested by Jakub.
Passes bootstrap and testing on x86_64-linux
gcc/:
2017-05-16 Andi Kleen
* tree-cfg.c (verify_gimple_in_cfg): Dump function.
* tree-into-ssa.c (update_ssa): Dump function.
* tree-outof-ssa.c (eliminate_useless_phis): Dump function.
(rewrite_trees): Dump function.
---
gcc/tree-cfg.c | 6 +-
gcc/tree-into-ssa.c | 2 ++
gcc/tree-outof-ssa.c | 4
3 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/gcc/tree-cfg.c b/gcc/tree-cfg.c
index 7dbd0a8c247..05073906fbd 100644
--- a/gcc/tree-cfg.c
+++ b/gcc/tree-cfg.c
@@ -5279,7 +5279,11 @@ verify_gimple_in_cfg (struct function *fn, bool
verify_nothrow)
(&visited_stmts);
if (err || eh_error_found)
-internal_error ("verify_gimple failed");
+{
+ if (dump_file)
+ dump_function_to_file (fn->decl, dump_file, dump_flags);
+ internal_error ("verify_gimple failed");
+}
verify_histograms ();
timevar_pop (TV_TREE_STMT_VERIFY);
diff --git a/gcc/tree-into-ssa.c b/gcc/tree-into-ssa.c
index d4056373f31..de150b8e917 100644
--- a/gcc/tree-into-ssa.c
+++ b/gcc/tree-into-ssa.c
@@ -3387,6 +3387,8 @@ update_ssa (unsigned update_flags)
"renaming: ");
print_generic_expr (stderr, name, TDF_SLIM);
fprintf (stderr, "\n");
+ if (dump_file)
+ dump_function_to_file (cfun->decl, dump_file, dump_flags);
internal_error ("SSA corruption");
}
}
diff --git a/gcc/tree-outof-ssa.c b/gcc/tree-outof-ssa.c
index 0ce6c155bd3..8be0b1088df 100644
--- a/gcc/tree-outof-ssa.c
+++ b/gcc/tree-outof-ssa.c
@@ -821,6 +821,8 @@ eliminate_useless_phis (void)
print_generic_expr (stderr, arg, TDF_SLIM);
fprintf (stderr, "), but the result is :");
print_gimple_stmt (stderr, phi, 0, TDF_SLIM);
+ if (dump_file)
+ dump_function_to_file (cfun->decl, dump_file,
dump_flags);
internal_error ("SSA corruption");
}
}
@@ -880,6 +882,8 @@ rewrite_trees (var_map map)
print_generic_expr (stderr, arg, TDF_SLIM);
fprintf (stderr, "), but the result is not :");
print_gimple_stmt (stderr, phi, 0, TDF_SLIM);
+ if (dump_file)
+ dump_function_to_file (cfun->decl, dump_file,
dump_flags);
internal_error ("SSA corruption");
}
}
--
2.12.2
Re: Fix minor reorg.c bug affecting MIPS targets
Hi: commited as r248137. Thanks, paul. On Wed, May 17, 2017 at 2:46 AM, Toma Tabacu wrote: > From: Jeff Law >> On 05/16/2017 10:01 AM, Toma Tabacu wrote: >>> Hello Paul, >>> >>> You're seeing this problem because mips.exp can't handle -O* in dg-options. >>> The other tests in gcc.target/mips use a dg-skip-if to skip for -O0 and -O1 >>> instead of having -O2 in dg-options. >>> This is supposed to ensure that the tests are run for as many optimization >>> levels as possible. >>> >>> I believe that Matthew can confirm this. >> Feel free to remove the -O2. The most important bits are -mips2 and >> -msoft-float. If nobody does it shortly, I'll take care of it myself. >> >>jeff > > Sorry, I won't be able to commit the fix until tomorrow. > Thanks for taking care of this issue, though. > > Regards, > Toma Tabacu
[PATCH] Add -dB option to disable backtraces
From: Andi Kleen
When running creduce on an ICE substantial amounts of the total
CPU time go to backtrace_qsort() (sorting dwarf of the compiler) for
printing the backtrace of the ICE. When running a reduction we don't need the
backtrace. So add a -dB option to turn it off, and make reduction
a bit faster.
Passes bootstrap and testing on x86_64-linux
gcc/:
2017-05-16 Andi Kleen
* diagnostic.c (diagnostic_initialize): Set disable_backtrace to
false.
(diagnostic_action_after_output): Check disable_backtrace.
* diagnostic.h (struct diagnostic_context): Add
disable_backtrace.
* doc/invoke.texi (-dB): Document.
* opts.c (decode_d_option): Handle -dB.
---
gcc/diagnostic.c| 16 ++--
gcc/diagnostic.h| 7 +++
gcc/doc/invoke.texi | 6 ++
gcc/opts.c | 3 +++
4 files changed, 26 insertions(+), 6 deletions(-)
diff --git a/gcc/diagnostic.c b/gcc/diagnostic.c
index 158519606f8..bbac3f384d4 100644
--- a/gcc/diagnostic.c
+++ b/gcc/diagnostic.c
@@ -156,6 +156,7 @@ diagnostic_initialize (diagnostic_context *context, int
n_opts)
context->caret_chars[i] = '^';
context->show_option_requested = false;
context->abort_on_error = false;
+ context->disable_backtrace = false;
context->show_column = false;
context->pedantic_errors = false;
context->permissive = false;
@@ -500,13 +501,16 @@ diagnostic_action_after_output (diagnostic_context
*context,
case DK_ICE:
case DK_ICE_NOBT:
{
- struct backtrace_state *state = NULL;
- if (diag_kind == DK_ICE)
- state = backtrace_create_state (NULL, 0, bt_err_callback, NULL);
int count = 0;
- if (state != NULL)
- backtrace_full (state, 2, bt_callback, bt_err_callback,
- (void *) &count);
+ if (!context->disable_backtrace)
+ {
+ struct backtrace_state *state = NULL;
+ if (diag_kind == DK_ICE)
+ state = backtrace_create_state (NULL, 0, bt_err_callback, NULL);
+ if (state != NULL)
+ backtrace_full (state, 2, bt_callback, bt_err_callback,
+ (void *) &count);
+ }
if (context->abort_on_error)
real_abort ();
diff --git a/gcc/diagnostic.h b/gcc/diagnostic.h
index dbd1703e0ef..440b547c6da 100644
--- a/gcc/diagnostic.h
+++ b/gcc/diagnostic.h
@@ -120,6 +120,9 @@ struct diagnostic_context
/* True if we should raise a SIGABRT on errors. */
bool abort_on_error;
+ /* If true don't print backtraces for internal errors. */
+ bool disable_backtrace;
+
/* True if we should show the column number on diagnostics. */
bool show_column;
@@ -245,6 +248,10 @@ diagnostic_inhibit_notes (diagnostic_context * context)
#define diagnostic_abort_on_error(DC) \
(DC)->abort_on_error = true
+/* Don't print backtraces for internal errors. */
+#define diagnostic_disable_backtrace(DC) \
+ (DC)->disable_backtrace = true;
+
/* This diagnostic_context is used by front-ends that directly output
diagnostic messages without going through `error', `warning',
and similar functions. */
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 715830a1a43..677e78c7078 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -12889,6 +12889,12 @@ Produce all the dumps listed above.
@opindex dA
Annotate the assembler output with miscellaneous debugging information.
+@item -dB
+@opindex dB
+Do not print backtraces on compiler crashes. This speeds up reducing
+test cases for compiler crashes, because printing backtraces is relatively
+slow.
+
@item -dD
@opindex dD
Dump all macro definitions, at the end of preprocessing, in addition to
diff --git a/gcc/opts.c b/gcc/opts.c
index ffedb10f18f..0c1da107714 100644
--- a/gcc/opts.c
+++ b/gcc/opts.c
@@ -2593,6 +2593,9 @@ decode_d_option (const char *arg, struct gcc_options
*opts,
case 'a':
opts->x_flag_dump_all_passed = true;
break;
+ case 'B':
+ diagnostic_disable_backtrace (dc);
+ break;
default:
warning_at (loc, 0, "unrecognized gcc debugging option: %c", c);
--
2.12.2
[PATCH] Always print attributes when dumping tree
From: Andi Kleen
A tree type dump currently doesn't print the attributes. Since we have
so many now and they do many interesting things dumping them can be
useful. So dump them by default for tree type dumps.
Passes bootstrap and testing on x86_64-linux.
gcc/:
2017-05-16 Andi Kleen
* print-tree.c (print_node): Print all attributes.
---
gcc/print-tree.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/print-tree.c b/gcc/print-tree.c
index e0db2dfe82e..f9af02f4e42 100644
--- a/gcc/print-tree.c
+++ b/gcc/print-tree.c
@@ -485,7 +485,7 @@ print_node (FILE *file, const char *prefix, tree node, int
indent,
if (CODE_CONTAINS_STRUCT (code, TS_DECL_COMMON))
{
- print_node_brief (file, "attributes",
+ print_node (file, "attributes",
DECL_ATTRIBUTES (node), indent + 4);
if (code != PARM_DECL)
print_node_brief (file, "initial", DECL_INITIAL (node),
--
2.12.2
Re: [RFC PATCH, i386]: Enable post-reload compare elimination pass
On Fri, 12 May 2017, Jeff Law wrote: > On 05/11/2017 03:29 PM, Hans-Peter Nilsson wrote: > > The canonical order of insns affecting condition-codes has been > > discussed in the past too. > > > > I was then arguing that the compare should go last, i.e. > > (parallel [(set (reg) (op...)) > > (set (ccreg) (compare (op...) (const_int 0)))]) > > for simplicity of processing together with an alternative that > > clobbers (i.e. same location in the parallel), as the canonical > > order of clobbers in a parallel is that they always go last. > > (IIRC from that distant past, transforming a cc0 target to > > "ccreg" required at least three variants: the "naked" insn > > (pre-reload?), the parallel with a clobber of ccreg, and the > > actual use of ccreg; as above.) > > > > Anyway, people seem to drift towards the ccreg-last variant for (miswrite: ccreg-*first*, as opposed to the above) > > some reason or another every time this is brought up; this time > > it seems the single reason is that some existing pass expects or > > generates this, using the order that causes the minimal fallout. > > (Maybe it's the same pass...) Not sure that's a good base for > > decisions. > > > > Whatever you do in the end, *please document the canonical > > order* in the RTL documentation. > I think what's driving the decision is more a desire not to muck with x86 and > aarch64 and instead place the burden to change on the less popular ports. > > Though I must admit i prefer the cc setting last since that mirrors how we > typically do things with clobbers of the cc register. IOW. > But yes, we definitely should document the final canonical ordering. Is that about to also happen? I foresee in another half-a-dozen years, and *this* iteration is forgotten, someone bothered enough to argue eloquently coming around, doing rtl-level-maintenance, maybe a new pass (ok maybe not a *new RTL-pass* :) sees that order as wrong for the reason listed above, and does the legwork to switch the order around. It will be ok to change it again then, because the order just happened this time because of minimal-edit-reasons, right? Noone can argue that it was a thoughtful deliberate change that we bothered to document, to stay consistent? ;) brgds, H-P
Re: [PATCH] Add -dB option to disable backtraces
On Tue, May 16, 2017 at 7:16 PM, Andi Kleen wrote:
> From: Andi Kleen
>
> When running creduce on an ICE substantial amounts of the total
> CPU time go to backtrace_qsort() (sorting dwarf of the compiler) for
> printing the backtrace of the ICE. When running a reduction we don't need the
> backtrace. So add a -dB option to turn it off, and make reduction
> a bit faster.
The other thing which you could is strip the binaries. :)
j/k. I think this is a good patch and a good idea.
Thanks,
Andrew
>
> Passes bootstrap and testing on x86_64-linux
>
> gcc/:
>
> 2017-05-16 Andi Kleen
>
> * diagnostic.c (diagnostic_initialize): Set disable_backtrace to
> false.
> (diagnostic_action_after_output): Check disable_backtrace.
> * diagnostic.h (struct diagnostic_context): Add
> disable_backtrace.
> * doc/invoke.texi (-dB): Document.
> * opts.c (decode_d_option): Handle -dB.
> ---
> gcc/diagnostic.c| 16 ++--
> gcc/diagnostic.h| 7 +++
> gcc/doc/invoke.texi | 6 ++
> gcc/opts.c | 3 +++
> 4 files changed, 26 insertions(+), 6 deletions(-)
>
> diff --git a/gcc/diagnostic.c b/gcc/diagnostic.c
> index 158519606f8..bbac3f384d4 100644
> --- a/gcc/diagnostic.c
> +++ b/gcc/diagnostic.c
> @@ -156,6 +156,7 @@ diagnostic_initialize (diagnostic_context *context, int
> n_opts)
> context->caret_chars[i] = '^';
>context->show_option_requested = false;
>context->abort_on_error = false;
> + context->disable_backtrace = false;
>context->show_column = false;
>context->pedantic_errors = false;
>context->permissive = false;
> @@ -500,13 +501,16 @@ diagnostic_action_after_output (diagnostic_context
> *context,
> case DK_ICE:
> case DK_ICE_NOBT:
>{
> - struct backtrace_state *state = NULL;
> - if (diag_kind == DK_ICE)
> - state = backtrace_create_state (NULL, 0, bt_err_callback, NULL);
> int count = 0;
> - if (state != NULL)
> - backtrace_full (state, 2, bt_callback, bt_err_callback,
> - (void *) &count);
> + if (!context->disable_backtrace)
> + {
> + struct backtrace_state *state = NULL;
> + if (diag_kind == DK_ICE)
> + state = backtrace_create_state (NULL, 0, bt_err_callback, NULL);
> + if (state != NULL)
> + backtrace_full (state, 2, bt_callback, bt_err_callback,
> + (void *) &count);
> + }
>
> if (context->abort_on_error)
> real_abort ();
> diff --git a/gcc/diagnostic.h b/gcc/diagnostic.h
> index dbd1703e0ef..440b547c6da 100644
> --- a/gcc/diagnostic.h
> +++ b/gcc/diagnostic.h
> @@ -120,6 +120,9 @@ struct diagnostic_context
>/* True if we should raise a SIGABRT on errors. */
>bool abort_on_error;
>
> + /* If true don't print backtraces for internal errors. */
> + bool disable_backtrace;
> +
>/* True if we should show the column number on diagnostics. */
>bool show_column;
>
> @@ -245,6 +248,10 @@ diagnostic_inhibit_notes (diagnostic_context * context)
> #define diagnostic_abort_on_error(DC) \
>(DC)->abort_on_error = true
>
> +/* Don't print backtraces for internal errors. */
> +#define diagnostic_disable_backtrace(DC) \
> + (DC)->disable_backtrace = true;
> +
> /* This diagnostic_context is used by front-ends that directly output
> diagnostic messages without going through `error', `warning',
> and similar functions. */
> diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
> index 715830a1a43..677e78c7078 100644
> --- a/gcc/doc/invoke.texi
> +++ b/gcc/doc/invoke.texi
> @@ -12889,6 +12889,12 @@ Produce all the dumps listed above.
> @opindex dA
> Annotate the assembler output with miscellaneous debugging information.
>
> +@item -dB
> +@opindex dB
> +Do not print backtraces on compiler crashes. This speeds up reducing
> +test cases for compiler crashes, because printing backtraces is relatively
> +slow.
> +
> @item -dD
> @opindex dD
> Dump all macro definitions, at the end of preprocessing, in addition to
> diff --git a/gcc/opts.c b/gcc/opts.c
> index ffedb10f18f..0c1da107714 100644
> --- a/gcc/opts.c
> +++ b/gcc/opts.c
> @@ -2593,6 +2593,9 @@ decode_d_option (const char *arg, struct gcc_options
> *opts,
>case 'a':
> opts->x_flag_dump_all_passed = true;
> break;
> + case 'B':
> + diagnostic_disable_backtrace (dc);
> + break;
>
>default:
> warning_at (loc, 0, "unrecognized gcc debugging option: %c", c);
> --
> 2.12.2
>
Re: [PATCH] Add -dB option to disable backtraces
On Tue, May 16, 2017 at 7:16 PM, Andi Kleen wrote:
> From: Andi Kleen
>
> When running creduce on an ICE substantial amounts of the total
> CPU time go to backtrace_qsort() (sorting dwarf of the compiler) for
> printing the backtrace of the ICE. When running a reduction we don't need the
> backtrace. So add a -dB option to turn it off, and make reduction
> a bit faster.
Now let me comment on the patch itself because I think it can be
simplified a lot.
>
> Passes bootstrap and testing on x86_64-linux
>
> gcc/:
>
> 2017-05-16 Andi Kleen
>
> * diagnostic.c (diagnostic_initialize): Set disable_backtrace to
> false.
> (diagnostic_action_after_output): Check disable_backtrace.
> * diagnostic.h (struct diagnostic_context): Add
> disable_backtrace.
> * doc/invoke.texi (-dB): Document.
> * opts.c (decode_d_option): Handle -dB.
> ---
> gcc/diagnostic.c| 16 ++--
> gcc/diagnostic.h| 7 +++
> gcc/doc/invoke.texi | 6 ++
> gcc/opts.c | 3 +++
> 4 files changed, 26 insertions(+), 6 deletions(-)
>
> diff --git a/gcc/diagnostic.c b/gcc/diagnostic.c
> index 158519606f8..bbac3f384d4 100644
> --- a/gcc/diagnostic.c
> +++ b/gcc/diagnostic.c
> @@ -156,6 +156,7 @@ diagnostic_initialize (diagnostic_context *context, int
> n_opts)
> context->caret_chars[i] = '^';
>context->show_option_requested = false;
>context->abort_on_error = false;
> + context->disable_backtrace = false;
>context->show_column = false;
>context->pedantic_errors = false;
>context->permissive = false;
> @@ -500,13 +501,16 @@ diagnostic_action_after_output (diagnostic_context
> *context,
> case DK_ICE:
> case DK_ICE_NOBT:
>{
> - struct backtrace_state *state = NULL;
> - if (diag_kind == DK_ICE)
> - state = backtrace_create_state (NULL, 0, bt_err_callback, NULL);
> int count = 0;
> - if (state != NULL)
> - backtrace_full (state, 2, bt_callback, bt_err_callback,
> - (void *) &count);
> + if (!context->disable_backtrace)
> + {
> + struct backtrace_state *state = NULL;
> + if (diag_kind == DK_ICE)
Why not put && !context->disable_backtrace in this if statement
instead of wrapping the whole thing in an another if statement?
That is:
struct backtrace_state *state = NULL;
if (diag_kind == DK_ICE && !context->disable_backtrace)
state = backtrace_create_state (NULL, 0, bt_err_callback, NULL);
int count = 0;
if (state != NULL)
backtrace_full (state, 2, bt_callback, bt_err_callback,
(void *) &count);
Changing only one line and instead of many.
Thanks,
Andrew Pinski
> + state = backtrace_create_state (NULL, 0, bt_err_callback, NULL);
> + if (state != NULL)
> + backtrace_full (state, 2, bt_callback, bt_err_callback,
> + (void *) &count);
> + }
>
> if (context->abort_on_error)
> real_abort ();
> diff --git a/gcc/diagnostic.h b/gcc/diagnostic.h
> index dbd1703e0ef..440b547c6da 100644
> --- a/gcc/diagnostic.h
> +++ b/gcc/diagnostic.h
> @@ -120,6 +120,9 @@ struct diagnostic_context
>/* True if we should raise a SIGABRT on errors. */
>bool abort_on_error;
>
> + /* If true don't print backtraces for internal errors. */
> + bool disable_backtrace;
> +
>/* True if we should show the column number on diagnostics. */
>bool show_column;
>
> @@ -245,6 +248,10 @@ diagnostic_inhibit_notes (diagnostic_context * context)
> #define diagnostic_abort_on_error(DC) \
>(DC)->abort_on_error = true
>
> +/* Don't print backtraces for internal errors. */
> +#define diagnostic_disable_backtrace(DC) \
> + (DC)->disable_backtrace = true;
> +
> /* This diagnostic_context is used by front-ends that directly output
> diagnostic messages without going through `error', `warning',
> and similar functions. */
> diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
> index 715830a1a43..677e78c7078 100644
> --- a/gcc/doc/invoke.texi
> +++ b/gcc/doc/invoke.texi
> @@ -12889,6 +12889,12 @@ Produce all the dumps listed above.
> @opindex dA
> Annotate the assembler output with miscellaneous debugging information.
>
> +@item -dB
> +@opindex dB
> +Do not print backtraces on compiler crashes. This speeds up reducing
> +test cases for compiler crashes, because printing backtraces is relatively
> +slow.
> +
> @item -dD
> @opindex dD
> Dump all macro definitions, at the end of preprocessing, in addition to
> diff --git a/gcc/opts.c b/gcc/opts.c
> index ffedb10f18f..0c1da107714 100644
> --- a/gcc/opts.c
> +++ b/gcc/opts.c
> @@ -2593,6 +2593,9 @@ decode_d_option (const char *arg, struct gcc_options
> *opts,
>case 'a':
> opts->x_flag_dump_all_passed = true;
> break;
> + case 'B':
> + diagnostic_disable_backtrace (dc);
> + bre
Re: [PATCH] Add -dB option to disable backtraces
On 2017.05.16 at 19:16 -0700, Andi Kleen wrote: > From: Andi Kleen > > When running creduce on an ICE substantial amounts of the total > CPU time go to backtrace_qsort() (sorting dwarf of the compiler) for > printing the backtrace of the ICE. When running a reduction we don't need the > backtrace. So add a -dB option to turn it off, and make reduction > a bit faster. It is useful when reducing compiler segfaults, because here one should grep for a symbol in the backtrace to not end up with an unrelated crash. -- Markus
[patch, fortran] PR80741 [Regression 7/8] DTIO wrong code causes incorrect behaviour of namelist READ
Hi all,
When I first looked at this I thought the minor front end bobble was the
problem. That turns out to be unrelated but needed to be fixed in trans-io.c
The actual problem was that when I moved the last_char to the unit structure,
needed for DTIO, the value saved there persists across I/O operations so in the
case of the PR the REWIND was was working but the EOF character from the
preceding read was passed on.
I conservatively have reset the last_char in several places out of concern for
missing a code path on this.
Regression tested on x86_64. New test case attached.
OK for trunk and then back port to 7 in about a week?
Regards,
Jerry
2017-05-16 Jerry DeLisle
PR fortran/80741
* trans-io.c (transfer_namelist_element): Change check from
NULL_TREE to null_pointer_node.
2017-05-16 Jerry DeLisle
PR libgfortran/80741
* transfer.c (finalize_transfer): Reset last_char to 'empty'.
* file_pos.c (formatted_backspace): Likewise.
(st_endfile): Likewise.
(st_rewind): Likewise.
(st_flush): Likewise.
diff --git a/gcc/fortran/trans-io.c b/gcc/fortran/trans-io.c
index 1b70136f..c557c114 100644
--- a/gcc/fortran/trans-io.c
+++ b/gcc/fortran/trans-io.c
@@ -1756,7 +1756,7 @@ transfer_namelist_element (stmtblock_t * block, const char * var_name,
else
tmp = build_int_cst (gfc_charlen_type_node, 0);
- if (dtio_proc == NULL_TREE)
+ if (dtio_proc == null_pointer_node)
tmp = build_call_expr_loc (input_location,
iocall[IOCALL_SET_NML_VAL], 6,
dt_parm_addr, addr_expr, string,
diff --git a/libgfortran/io/file_pos.c b/libgfortran/io/file_pos.c
index 5af9619b..771d548e 100644
--- a/libgfortran/io/file_pos.c
+++ b/libgfortran/io/file_pos.c
@@ -82,7 +82,7 @@ formatted_backspace (st_parameter_filepos *fpp, gfc_unit *u)
goto io_error;
u->last_record--;
u->endfile = NO_ENDFILE;
-
+ u->last_char = EOF - 1;
return;
io_error:
@@ -322,6 +322,7 @@ st_endfile (st_parameter_filepos *fpp)
unit_truncate (u, stell (u->s), &fpp->common);
u->endfile = AFTER_ENDFILE;
+ u->last_char = EOF - 1;
if (0 == stell (u->s))
u->flags.position = POSITION_REWIND;
}
@@ -371,6 +372,7 @@ st_endfile (st_parameter_filepos *fpp)
if (u == NULL)
return;
u->endfile = AFTER_ENDFILE;
+ u->last_char = EOF - 1;
}
}
@@ -430,6 +432,7 @@ st_rewind (st_parameter_filepos *fpp)
u->current_record = 0;
u->strm_pos = 1;
u->read_bad = 0;
+ u->last_char = EOF - 1;
}
/* Update position for INQUIRE. */
u->flags.position = POSITION_REWIND;
@@ -458,6 +461,7 @@ st_flush (st_parameter_filepos *fpp)
fbuf_flush (u, u->mode);
sflush (u->s);
+ u->last_char = EOF - 1;
unlock_unit (u);
}
else
diff --git a/libgfortran/io/transfer.c b/libgfortran/io/transfer.c
index 928a448f..298b29e8 100644
--- a/libgfortran/io/transfer.c
+++ b/libgfortran/io/transfer.c
@@ -3977,7 +3977,7 @@ finalize_transfer (st_parameter_dt *dtp)
fbuf_seek (dtp->u.p.current_unit, 0, SEEK_END);
dtp->u.p.current_unit->saved_pos = 0;
-
+ dtp->u.p.current_unit->last_char = EOF - 1;
next_record (dtp, 1);
done:
! { dg-do run }
! PR80741 wrong code causes incorrect behaviour of namelist READ
program p
use, intrinsic :: iso_fortran_env, only: iostat_end
implicit none
integer :: x, y, ios, io
character(10) :: line
namelist /test/ x, y
x = 10
y = 10
ios = 0
io = 10
open(unit=io, status='scratch')
write(io, test)
write(io, *) 'done'
rewind(io)
x = 0
y = 0
read(io, test)
if (x.ne.10 .or. y.ne.10) call abort
!
read(io, *) line
if (line.ne.'done') call abort
!
read(io, *, iostat=ios) line
if (ios/=iostat_end) call abort
rewind(io)
x = 0
y = 0
read(io, test)
if (x.ne.10 .or. y.ne.10) call abort
read(io, *, iostat=ios) line
if (line.ne.'done') call abort
end
Re: [PATCH 0/3] Split off powerpcspe from rs6000 port
On 15/05/17 22:51, Segher Boessenkool wrote: -- This uses powerpc-*-rtems*spe*; do we want powerpcspe-*-rtems* instead? Or both? I guess it will be powerpcspe-*-rtems*, but we have to fix our build system in this case. Don't worry about RTEMS. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
[Patch, testsuite, committed] Fix bogus pr78886.c for avr
Hi,
The test declares malloc with an unsigned long parameter. This causes
a warning for avr, as it's size_t is only unsigned int.
Fixed by typdef'ing __SIZE_TYPE__ to size_t and using it in the malloc
function's declaration.
Committed as obvious.
Regards
Senthil
gcc/testsuite/ChangeLog
2017-05-17 Senthil Kumar Selvaraj
* gcc.dg/tree-ssa/pr78886.c: Use __SIZE_TYPE__ instead of
unsigned long.
Index: gcc/testsuite/gcc.dg/tree-ssa/pr78886.c
===
--- gcc/testsuite/gcc.dg/tree-ssa/pr78886.c (revision 248137)
+++ gcc/testsuite/gcc.dg/tree-ssa/pr78886.c (working copy)
@@ -1,7 +1,9 @@
/* { dg-do compile } */
/* { dg-options "-O2" } */
-void *malloc(unsigned long x);
+__extension__ typedef __SIZE_TYPE__ size_t;
+void *malloc(size_t x);
+
void foo(void)
{
volatile int i;
Re: [RFC PATCH, i386]: Enable post-reload compare elimination pass
On Wed, May 17, 2017 at 4:45 AM, Hans-Peter Nilsson wrote: >> But yes, we definitely should document the final canonical ordering. > > Is that about to also happen? > > I foresee in another half-a-dozen years, and *this* iteration is > forgotten, someone bothered enough to argue eloquently coming > around, doing rtl-level-maintenance, maybe a new pass (ok maybe > not a *new RTL-pass* :) sees that order as wrong for the reason > listed above, and does the legwork to switch the order around. > It will be ok to change it again then, because the order just > happened this time because of minimal-edit-reasons, right? > Noone can argue that it was a thoughtful deliberate change that > we bothered to document, to stay consistent? ;) The proposed doc patch is wiating for review at [1]. [1] https://gcc.gnu.org/ml/gcc-patches/2017-05/msg01073.html Uros.
Re: Make tree-ssa-strlen.c handle partial unterminated strings
Richard Sandiford writes:
> Jakub Jelinek writes:
>> Hi!
>>
>> Note the intent of the pass is to handle the most common cases, it is fine
>> if some cases that aren't common aren't handled, it is all about the extra
>> complexity vs. how much it helps on real-world code.
>
> OK.
>
>> On Sun, May 07, 2017 at 10:10:48AM +0100, Richard Sandiford wrote:
>>> I've got most of the way through a version that uses min_length instead.
>>> But one thing that the terminated flag allows that a constant min_length
>>> doesn't is:
>>>
>>> size_t
>>> f1 (char *a1)
>>> {
>>> size_t x = strlen (a1);
>>> char *a3 = a1 + x;
>>> a3[0] = '1'; // a1 length x + 1, unterminated (min length x + 1)
>>> a3[1] = '2'; // a1 length x + 2, unterminated (min length x + 2)
>>> a3[2] = '3'; // a1 length x + 3, unterminated (min length x + 3)
>>> a3[3] = 0;// a1 length x + 3, terminated
>>> return strlen (a1);
>>> }
>>>
>>> For the a3[3] = 0, we know a3's min_length is 3 and so it's obvious
>>> that we can convert its min_length to a length. But even if we allow
>>> a1's min_length to be nonconstant, it seems a bit risky to assume that
>>> we can convert its min_length to a length as well. It would only work
>>> if the min_lengths in related strinfos are kept in sync, whereas it
>>> ought to be safe to say that the minimum length of something is 0.
>>
>> And we have code for that. If verify_related_strinfos returns non-NULL,
>> we can adjust all the related strinfos that need adjusting.
>> See e.g. zero_length_string on how it uses that. It is just that we should
>> decide what is the acceptable complexity of the length/min_length
>> expressions (whether INTEGER_CST or SSA_NAME is enough, then the above
>> would not work, but is that really that important), or if we e.g. allow
>> SSA_NAME + INTEGER_CST in addition to that, or sum of 2 SSA_NAMEs, etc.).
>> I don't see how terminated vs. unterminated (which is misnamed anyway, it
>> means that it isn't known to be terminated, it might be terminated or not)
>> would help with that.
>
> The example above works with the flag because we already allow
> SSA_NAME + INTEGER_CST for the length field, thanks to:
>
> tree adj = NULL_TREE;
> if (oldlen == NULL_TREE)
> ;
> else if (integer_zerop (oldlen))
> adj = srclen;
> else if (TREE_CODE (oldlen) == INTEGER_CST
> || TREE_CODE (srclen) == INTEGER_CST)
> adj = fold_build2_loc (loc, MINUS_EXPR,
> TREE_TYPE (srclen), srclen,
> fold_convert_loc (loc, TREE_TYPE (srclen),
>oldlen));
> if (adj != NULL_TREE)
> adjust_related_strinfos (loc, dsi, adj);
>
> etc. So with a constant min_length we lose out (compared to the flag)
> by making min_length more restrictive.
>
> Like you say later, min_length is the number of characters that are
> known to be nonzero, and length is the number of characters that are
> known to be nonzero and followed by a zero, so even if we do relax the
> rules for min_length to match length, I think in almost all useful cases
> the length will be equal to the min_length or will be null (i.e. it'll
> act almost like a de facto flag).
How about the patch below? It renames "length" to "nonzero_chars"
and adds a "full_string_p" flag to indicate that the nonzero characters
are known to be followed by a zero. It keeps the current decisions
about which kinds of length/nonzero_chars expression are valid and
worth tracking. It also handles strings built up a character at
a time (unlike the original).
Tested on aarch64-linux-gnu and x86_64-linux-gnu.
Thanks,
Richard
2017-05-17 Richard Sandiford
gcc/
* tree-ssa-strlen.c (strinfo): Rename the length field to
nonzero_chars. Add a full_string_p field.
(compare_nonzero_chars, zero_length_string_p): New functions.
(get_addr_stridx): Add an offset_out parameter.
Use compare_nonzero_chars.
(get_stridx): Update accordingly. Use compare_nonzero_chars.
(new_strinfo): Update after above changes to strinfo.
(set_endptr_and_length): Set full_string_p.
(get_string_length): Update after above changes to strinfo.
(unshare_strinfo): Update call to new_strinfo.
(maybe_invalidate): Likewise.
(get_stridx_plus_constant): Change off to unsigned HOST_WIDE_INT.
Use compare_nonzero_chars and zero_string_p. Treat nonzero_chars
as a uhwi instead of an shwi. Update after above changes to
strinfo and new_strinfo.
(zero_length_string): Assert that chainsi contains full strings.
Use zero_length_string_p. Update call to new_strinfo.
(adjust_related_strinfos): Update after above changes to strinfo.
Copy full_string_p from origsi.
(adjust_last_stmt): Use zero_length_string_p.
(handle_builtin_strlen): Update after above changes
