[PING][PATCH][PR sanitizer/77631] Support separate debug info in libbacktrace
Hello everyone, this is a ping for that patch https://gcc.gnu.org/ml/gcc-patches/2017-05/msg01462.html Can someone please review that patch. Thanks.
RE: [PATCH] Match x86 family machine constraints section with constarints.md
Hi, Thank you very much for the answers. Can someone please commit this patch for me? Thanks, Sebastian -Original Message- From: Uros Bizjak [mailto:ubiz...@gmail.com] Sent: Wednesday, May 24, 2017 3:31 PM To: Sandra Loosemore Cc: Peryt, Sebastian ; gcc-patches@gcc.gnu.org; Koval, Julia ; kirill.yuk...@gmail.com Subject: Re: [PATCH] Match x86 family machine constraints section with constarints.md On Tue, May 23, 2017 at 5:33 PM, Sandra Loosemore wrote: > On 04/28/2017 03:30 AM, Peryt, Sebastian wrote: >> >> Hi, >> >> Thank you for your comments. I edited my patch accordingly. As for >> some of your doubts: >> - REX is the opcode prefix to access 64-bit register extensions >> introduced in IA-32e mode. >> - EVEX is the encoding prefix which applies to SIMD operating >> instructions operating on XMM, YMM and ZMM registers. It was >> introduced with AVX-512 instructions. >> - "number factor of four" that means that sources start in a multiple >> of 4 boundary. This is used for some of instructions. >> >> Also I'd like to add that this whole patch is strictly based on >> docstring parts of constraints that are present in >> config/i386/constraints.md but not in documentation (md.texi file). >> There is no new (new as in nonexistent in >> code) content. >> >> I'm also adding Kirill Yukhin to CC, because I believe he is the >> correct person that can catch any technical errors if any has slipped-in. > > > The grammar/markup/etc are OK now, but I can't comment on technical > correctness of the information. LGTM. Thanks, Uros.
Re: [libibery PATCH] Fix bootstrap
On May 25, 2017 3:22:18 AM GMT+02:00, Nathan Sidwell wrote: >On 05/24/2017 09:13 PM, Nathan Sidwell wrote: >> On 05/24/2017 08:56 PM, Nathan Sidwell wrote: >>> On 05/24/2017 08:34 PM, Nathan Sidwell wrote: We now warn on casts to T const. Applied as obvious to fix >bootstrap. >>> >>> And this fixes c-common.c >> >> And fix auto-profile.c > >and lto-streamer-out.c, sigh What's the reason to warn here?! Richard.
Re: [PATCH v2 3/N] Transform TDF_{lang,tree,ipa,rtl} to dump_kind enum.
On 05/12/2017 07:04 AM, 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. Just as an FYI, the addition of the user-defined constructor makes the class non-trivial and so unsafe to initialize by calling memset in C++ 11 and later. In C++ 98 that GCC is compiled with, the class is not a POD and so not safe to realloc (i.e., new objects must be brought to life by calling a constructor). I noticed this by testing my latest patch for the new -Wclass-memassign warning but I thought it might be worth noting here as well. + /* Constructor. */ + dump_file_info (); + + /* Constructor. */ + dump_file_info (const char *_suffix, const char *_swtch, dump_kind _dkind, + int _num); + Also, making the ctor constexpr and defining it in the .c file will trigger Clang -Wundefined-inline and makes the ctor unusable in other sources. AFAICS, there is no constexpr context where the constexpr ctor would be needed so I'm not sure I understand its purpose. Is it constexpr to allow the static initialization of dump_files[0]? (All the other elements of the array are dynamically initialized by calling the other, non-constexpr ctor so that doesn't seem like the answer.) Martin
Re: [PATCH] PR c++/80544 strip cv-quals from cast results
On Wed, May 24, 2017 at 8:07 PM, Andrew Pinski wrote: > On Wed, May 24, 2017 at 12:29 PM, Jonathan Wakely wrote: >> On 24/05/17 14:50 -0400, Jason Merrill wrote: >>> >>> On Wed, May 24, 2017 at 10:20 AM, Jonathan Wakely >>> wrote: On 23/05/17 16:26 -0400, Jason Merrill wrote: > > > On Tue, May 23, 2017 at 2:00 PM, Jonathan Wakely > wrote: >> >> >> On 19/05/17 15:14 -0400, Jason Merrill wrote: >>> >>> >>> >>> On Thu, Apr 27, 2017 at 12:59 PM, Jonathan Wakely >>> wrote: I also tried to add a warning like EDG's (see the PR) but it gave a false positive for direct-list-init of scoped enums (P0138R2, r240449) because that code goes through build_c_cast to perform the conversion, so looks like a cast to my new warning. >>> >>> >>> >>> >>> The enum init code could strip the cv-quals when calling build_c_cast >>> to avoid the warning. >> >> >> >> >> Thanks, that works. I don't think this warning fits under any existing >> option, so I'll add a new one. -Wuseless-cast-qual maybe? Or is that >> too close to -Wuseless-cast and -Wcast-qual and would cause confusion? > > > > -Wcast-rvalue-qual ? I realised that -Wignored-qualifiers is a good fit. That warns about ignored cv-qualifiers on return types, which is a very similar case. This patch adds a new function to conditionally warn and calls that from the build_*_cast functions after they produce a valid result. I originally put the warnings next to the cv_unqualified calls that strip the quals, but was getting duplicate warnings when build_cp_cast calls more than one of the build_*_cast_1 functions. This also removes the unnecessary check for reference types that Nathan pointed out. Tested x86_64-linux and powerpc64-linux. OK for trunk? >>> >>> +/* + Warns if the cast ignores cv-qualifiers on TYPE. + */ >>> >>> >>> The GCC sources don't put /* and */ on their own line. OK with that >>> change, thanks! >> >> >> OK, I'll also fix it on the maybe_warn_about_useless_cast function >> just above, which I copied :-) > > This change caused a bootstrap failure on aarch64-linux-gnu and > x86_64-linux-gnu: > In file included from ../../gcc/gcc/system.h:691:0, > from ../../gcc/gcc/read-rtl.c:31: > ../../gcc/gcc/read-rtl.c: In member function ‘const char* > md_reader::apply_iterator_to_string(const char*)’: > ../../gcc/gcc/../include/libiberty.h:722:38: error: type qualifiers > ignored on cast result type [-Werror=ignored-qualifiers] > # define alloca(x) __builtin_alloca(x) > ^ > ../../gcc/gcc/../include/libiberty.h:727:47: note: in expansion of > macro ‘alloca’ > char *const libiberty_nptr = (char *const) alloca (libiberty_len); \ >^~ > ../../gcc/gcc/read-rtl.c:380:21: note: in expansion of macro ‘ASTRDUP’ >base = p = copy = ASTRDUP (string); > ^~~ > > I know you did not touch libiberty.h but that is emitting an error. > Did you test your patch with a full bootstrap? I thought that was > recorded as being required now for C++ patches; I know a few years > back when the GCC was not compiling as C++, it was not required. Oh it looks like it was already fixed by revision 248442. Just my build automated build was not done for that timeframe. Thanks, Andrew > > Thanks, > Andrew > > >> >>
Re: [PATCH] PR c++/80544 strip cv-quals from cast results
On Wed, May 24, 2017 at 12:29 PM, Jonathan Wakely wrote: > On 24/05/17 14:50 -0400, Jason Merrill wrote: >> >> On Wed, May 24, 2017 at 10:20 AM, Jonathan Wakely >> wrote: >>> >>> On 23/05/17 16:26 -0400, Jason Merrill wrote: On Tue, May 23, 2017 at 2:00 PM, Jonathan Wakely wrote: > > > On 19/05/17 15:14 -0400, Jason Merrill wrote: >> >> >> >> On Thu, Apr 27, 2017 at 12:59 PM, Jonathan Wakely >> wrote: >>> >>> >>> >>> I also tried to add a warning like EDG's (see the PR) but it gave a >>> false positive for direct-list-init of scoped enums (P0138R2, >>> r240449) >>> because that code goes through build_c_cast to perform the >>> conversion, >>> so looks like a cast to my new warning. >> >> >> >> >> The enum init code could strip the cv-quals when calling build_c_cast >> to avoid the warning. > > > > > Thanks, that works. I don't think this warning fits under any existing > option, so I'll add a new one. -Wuseless-cast-qual maybe? Or is that > too close to -Wuseless-cast and -Wcast-qual and would cause confusion? -Wcast-rvalue-qual ? >>> >>> >>> >>> I realised that -Wignored-qualifiers is a good fit. That warns about >>> ignored cv-qualifiers on return types, which is a very similar case. >>> >>> This patch adds a new function to conditionally warn and calls that >>> from the build_*_cast functions after they produce a valid result. I >>> originally put the warnings next to the cv_unqualified calls that >>> strip the quals, but was getting duplicate warnings when build_cp_cast >>> calls more than one of the build_*_cast_1 functions. >>> >>> This also removes the unnecessary check for reference types that >>> Nathan pointed out. >>> >>> Tested x86_64-linux and powerpc64-linux. OK for trunk? >> >> >>> +/* >>> + Warns if the cast ignores cv-qualifiers on TYPE. >>> + */ >> >> >> The GCC sources don't put /* and */ on their own line. OK with that >> change, thanks! > > > OK, I'll also fix it on the maybe_warn_about_useless_cast function > just above, which I copied :-) This change caused a bootstrap failure on aarch64-linux-gnu and x86_64-linux-gnu: In file included from ../../gcc/gcc/system.h:691:0, from ../../gcc/gcc/read-rtl.c:31: ../../gcc/gcc/read-rtl.c: In member function ‘const char* md_reader::apply_iterator_to_string(const char*)’: ../../gcc/gcc/../include/libiberty.h:722:38: error: type qualifiers ignored on cast result type [-Werror=ignored-qualifiers] # define alloca(x) __builtin_alloca(x) ^ ../../gcc/gcc/../include/libiberty.h:727:47: note: in expansion of macro ‘alloca’ char *const libiberty_nptr = (char *const) alloca (libiberty_len); \ ^~ ../../gcc/gcc/read-rtl.c:380:21: note: in expansion of macro ‘ASTRDUP’ base = p = copy = ASTRDUP (string); ^~~ I know you did not touch libiberty.h but that is emitting an error. Did you test your patch with a full bootstrap? I thought that was recorded as being required now for C++ patches; I know a few years back when the GCC was not compiling as C++, it was not required. Thanks, Andrew > >
Re: Ipa function summary pass
Hi,
On mips64el target:
New Fail:
FAIL: gfortran.dg/pr48636.f90 -O scan-ipa-dump fnsummary "inline
hints: loop_iterations"
Paul
On Wed, May 24, 2017 at 4:47 PM, Christophe Lyon
wrote:
> Hi,
>
> On 23 May 2017 at 18:23, Jan Hubicka wrote:
>> Hi,
>> this patch finishes the breakup of ipa-inline and function analysis.
>> The analysis is now done by separate pass and I will work on cleaning
>> up the interfaces now.
>>
>> Honza
>>
>> * cgraphunit.c (symbol_table::process_new_functions): Update.
>> * ipa-fnsummary.c (pass_data_inline_parameters): Remove.
>> (inline_generate_summary): Rename to ...
>> (ipa_fn_summary_generate): ... this one.
>> (inline_read_summary): Rename to ...
>> (ipa_fn_summary_read): ... this one.
>> (inline_write_summary): Rename to ...
>> (ipa_fn_summary_write): ... this one.
>> (inline_free_summary): Rename to ...
>> (ipa_free_fn_summary): ... this one.
>> (pass_data_local_fn_summary, pass_local_fn_summary,
>> make_pass_local_fn_summary, pass_data_ipa_free_fn_summary,
>> pass_ipa_free_fn_summary, make_pass_ipa_free_fn_summary,
>> pass_data_ipa_fn_summary, pass_ipa_fn_summary,
>> make_pass_ipa_fn_summary): New.
>> * ipa-fnsummary.h (inline_generate_summary, inline_read_summary,
>> inline_write_summary, inline_free_summary): Remove.
>> (ipa_free_fn_summary) : New.
>> * ipa-inline.c (ipa_inline): Update.
>> (pass_ipa_inline): Do not generate summaries.
>> * ipa.c (pass_data_ipa_free_fn_summary, pass_ipa_free_fn_summary):
>> Remove.
>> * passes.def: Replace pass_inline_parameters by pass_local_fn_summary
>> and add pass_ipa_fn_summary.
>> * tree-pass.h (make_pass_ipa_fn_summary, make_pass_local_fn_summary):
>> New.
>> (make_pass_inline_parameters): Remove.
>>
>> * lto.c (do_whole_program_analysis): Replace inline_free_summary
>> by ipa_free_fn_summary.
>>
>> * gcc.dg/ipa/ctor-empty-1.c: Update template.
>> * gcc.dg/ipa/inline-5.c: Likewise.
>> * gfortran.dg/pr48636.f90: Likewise.
>> Index: cgraphunit.c
>> ===
>> --- cgraphunit.c(revision 248365)
>> +++ cgraphunit.c(working copy)
>> @@ -339,7 +339,7 @@ symbol_table::process_new_functions (voi
>> and splitting. This is redundant for functions added late.
>> Just throw away whatever it did. */
>> if (!summaried_computed)
>> - inline_free_summary ();
>> + ipa_free_fn_summary ();
>> }
>> else if (ipa_fn_summaries != NULL)
>> compute_fn_summary (node, true);
>> Index: ipa-fnsummary.c
>> ===
>> --- ipa-fnsummary.c (revision 248366)
>> +++ ipa-fnsummary.c (working copy)
>> @@ -2504,46 +2504,6 @@ compute_fn_summary_for_current (void)
>>return 0;
>> }
>>
>> -namespace {
>> -
>> -const pass_data pass_data_inline_parameters =
>> -{
>> - GIMPLE_PASS, /* type */
>> - "inline_param", /* name */
>> - OPTGROUP_INLINE, /* optinfo_flags */
>> - TV_INLINE_PARAMETERS, /* tv_id */
>> - 0, /* properties_required */
>> - 0, /* properties_provided */
>> - 0, /* properties_destroyed */
>> - 0, /* todo_flags_start */
>> - 0, /* todo_flags_finish */
>> -};
>> -
>> -class pass_inline_parameters : public gimple_opt_pass
>> -{
>> -public:
>> - pass_inline_parameters (gcc::context *ctxt)
>> -: gimple_opt_pass (pass_data_inline_parameters, ctxt)
>> - {}
>> -
>> - /* opt_pass methods: */
>> - opt_pass * clone () { return new pass_inline_parameters (m_ctxt); }
>> - virtual unsigned int execute (function *)
>> -{
>> - return compute_fn_summary_for_current ();
>> -}
>> -
>> -}; // class pass_inline_parameters
>> -
>> -} // anon namespace
>> -
>> -gimple_opt_pass *
>> -make_pass_inline_parameters (gcc::context *ctxt)
>> -{
>> - return new pass_inline_parameters (ctxt);
>> -}
>> -
>> -
>> /* Estimate benefit devirtualizing indirect edge IE, provided KNOWN_VALS,
>> KNOWN_CONTEXTS and KNOWN_AGGS. */
>>
>> @@ -3207,8 +3167,8 @@ ipa_fn_summary_t::insert (struct cgraph_
>>
>> /* Note function body size. */
>>
>> -void
>> -inline_generate_summary (void)
>> +static void
>> +ipa_fn_summary_generate (void)
>> {
>>struct cgraph_node *node;
>>
>> @@ -3226,7 +3186,7 @@ inline_generate_summary (void)
>>ipa_fn_summaries->enable_insertion_hook ();
>>
>>ipa_register_cgraph_hooks ();
>> - inline_free_summary ();
>> + ipa_free_fn_summary ();
>>
>>FOR_EACH_DEFINED_FUNCTION (node)
>> if (!node->alias)
>> @@ -3358,8 +3318,8 @@ inline_read_section (struct lto_file_dec
>> and inliner, so when ipa-cp is active, we don't need to write them
>> twice. */
>>
>> -void
>> -inline_read_summary (void)
>> +static voi
[PATCH rs6000] Addition fixes to BMI intrinsic test
Bill Seurer pointed out that building the BMI tests on a power8 but with
gcc built --with-cpu=power6 fails with link errors. The intrinsics
_pdep_u64/32 and _pext_u64/32 are guarded with #ifdef _ARCH_PWR7 as the
implementation uses bpermd and popcntd instructions introduced with
power7 (PowerISA-2.06).
But if the GCC is built --with-cpu=power6, the compiler is capable of
supporting -mcpu=power7 but will not generate bpermd/popcntd by default.
Then if some code them uses say _pext_u64 with -mcpu=power6 the
intrinsic is not not supported (needs power7) and so not defined.
The dg tests are guarded with dg-require-effective-target
powerpc_vsx_ok, This only tests if GCC and Binutils are capable of
generating vsx (and by extension PowerISA-2.06 bpermd and popcntd)
instructions.
In this case the result is the intrinsic functions are implicitly
defined as extern and cause a link failure. The solution is to guard the
test code with #ifdef _ARCH_PWR7 so that it does not attempt to use
instructions that are not there.
However for dg-compile test bmi2-pext64-1a.c we have no alternative to
add -mcpu=power7 to dg-options.
[gcc/testsuite]
2017-05-24 Steven Munroe
* gcc.target/powerpc/bmi2-pdep32-1.c [_ARCH_PWR7]: Prevent
implicit function for processors without bpermd instruction.
* gcc.target/powerpc/bmi2-pdep64-1.c: Likewise.
* gcc.target/powerpc/bmi2-pext32-1.c: Likewise.
* gcc.target/powerpc/bmi2-pext64-1.c: Likewise.
* gcc.target/powerpc/bmi2-pext64-1a.c: Add -mcpu=power7
to dg-option.
Index: gcc/testsuite/gcc.target/powerpc/bmi2-pdep64-1.c
===
--- gcc/testsuite/gcc.target/powerpc/bmi2-pdep64-1.c(revision 248381)
+++ gcc/testsuite/gcc.target/powerpc/bmi2-pdep64-1.c(working copy)
@@ -7,6 +7,7 @@
#include
#include "bmi2-check.h"
+#ifdef _ARCH_PWR7
__attribute__((noinline))
unsigned long long
calc_pdep_u64 (unsigned long long a, unsigned long long mask)
@@ -21,11 +22,13 @@ calc_pdep_u64 (unsigned long long a, unsigned long
}
return res;
}
+#endif /* _ARCH_PWR7 */
static
void
bmi2_test ()
{
+#ifdef _ARCH_PWR7
unsigned long long i;
unsigned long long src = 0xce7acce7acce7ac;
unsigned long long res, res_ref;
@@ -39,4 +42,5 @@ bmi2_test ()
if (res != res_ref)
abort ();
}
+#endif /* _ARCH_PWR7 */
}
Index: gcc/testsuite/gcc.target/powerpc/bmi2-pext64-1.c
===
--- gcc/testsuite/gcc.target/powerpc/bmi2-pext64-1.c(revision 248381)
+++ gcc/testsuite/gcc.target/powerpc/bmi2-pext64-1.c(working copy)
@@ -7,6 +7,7 @@
#include
#include "bmi2-check.h"
+#ifdef _ARCH_PWR7
__attribute__((noinline))
unsigned long long
calc_pext_u64 (unsigned long long a, unsigned long long mask)
@@ -22,10 +23,12 @@ calc_pext_u64 (unsigned long long a, unsigned long
return res;
}
+#endif /* _ARCH_PWR7 */
static void
bmi2_test ()
{
+#ifdef _ARCH_PWR7
unsigned long long i;
unsigned long long src = 0xce7acce7acce7ac;
unsigned long long res, res_ref;
@@ -39,4 +42,5 @@ bmi2_test ()
if (res != res_ref)
abort();
}
+#endif /* _ARCH_PWR7 */
}
Index: gcc/testsuite/gcc.target/powerpc/bmi2-pdep32-1.c
===
--- gcc/testsuite/gcc.target/powerpc/bmi2-pdep32-1.c(revision 248381)
+++ gcc/testsuite/gcc.target/powerpc/bmi2-pdep32-1.c(working copy)
@@ -7,6 +7,7 @@
#include
#include "bmi2-check.h"
+#ifdef _ARCH_PWR7
__attribute__((noinline))
unsigned
calc_pdep_u32 (unsigned a, int mask)
@@ -22,10 +23,12 @@ calc_pdep_u32 (unsigned a, int mask)
return res;
}
+#endif /* _ARCH_PWR7 */
static void
bmi2_test ()
{
+#ifdef _ARCH_PWR7
unsigned i;
unsigned src = 0xce7acc;
unsigned res, res_ref;
@@ -39,4 +42,5 @@ bmi2_test ()
if (res != res_ref)
abort();
}
+#endif /* _ARCH_PWR7 */
}
Index: gcc/testsuite/gcc.target/powerpc/bmi2-pext64-1a.c
===
--- gcc/testsuite/gcc.target/powerpc/bmi2-pext64-1a.c (revision 248381)
+++ gcc/testsuite/gcc.target/powerpc/bmi2-pext64-1a.c (working copy)
@@ -1,5 +1,5 @@
/* { dg-do compile } */
-/* { dg-options "-O3" } */
+/* { dg-options "-O3 -mcpu=power7" } */
/* { dg-require-effective-target lp64 } */
/* { dg-require-effective-target powerpc_vsx_ok } */
Index: gcc/testsuite/gcc.target/powerpc/bmi2-pext32-1.c
===
--- gcc/testsuite/gcc.target/powerpc/bmi2-pext32-1.c(revision 248381)
+++ gcc/testsuite/gcc.target/powerpc/bmi2-pext32-1.c(working copy)
@@ -7,6 +7,7 @@
#include
#include "bmi2-check.h"
+#ifdef _ARCH_PWR7
__attribute__((noinline))
unsigned
calc_pext_u32 (unsigned a, unsigned mask)
@@ -22,10 +23,12 @@ calc_pext_u32 (unsigned a, unsigned mask)
return res;
}
+#endif /* _ARCH_PWR7 *
Re: [libibery PATCH] Fix bootstrap
On 05/24/2017 09:13 PM, Nathan Sidwell wrote:
On 05/24/2017 08:56 PM, Nathan Sidwell wrote:
On 05/24/2017 08:34 PM, Nathan Sidwell wrote:
We now warn on casts to T const. Applied as obvious to fix bootstrap.
And this fixes c-common.c
And fix auto-profile.c
and lto-streamer-out.c, sigh
--
Nathan Sidwell
2017-05-24 Nathan Sidwell
* lto-streamer-in.c (lto_input_data_block): Adjust T const cast to
avoid warning.
Index: lto-streamer-in.c
===
--- lto-streamer-in.c (revision 248441)
+++ lto-streamer-in.c (working copy)
@@ -86,7 +86,7 @@ void
lto_input_data_block (struct lto_input_block *ib, void *addr, size_t length)
{
size_t i;
- unsigned char *const buffer = (unsigned char *const) addr;
+ unsigned char *const buffer = (unsigned char *) addr;
for (i = 0; i < length; i++)
buffer[i] = streamer_read_uchar (ib);
Re: [libibery PATCH] Fix bootstrap
On 05/24/2017 08:56 PM, Nathan Sidwell wrote:
On 05/24/2017 08:34 PM, Nathan Sidwell wrote:
We now warn on casts to T const. Applied as obvious to fix bootstrap.
And this fixes c-common.c
And fix auto-profile.c
nathan
--
Nathan Sidwell
2017-05-24 Nathan Sidwell
* auto-profile.c (afdo_propagate): Adjust T const cast to avoid
warning.
Index: auto-profile.c
===
--- auto-profile.c (revision 248441)
+++ auto-profile.c (working copy)
@@ -1377,7 +1377,7 @@ afdo_propagate (bb_set *annotated_bb, ed
FOR_ALL_BB_FN (bb, cfun)
{
bb->count = ((basic_block)bb->aux)->count;
-if (is_bb_annotated ((const basic_block)bb->aux, *annotated_bb))
+if (is_bb_annotated ((basic_block)bb->aux, *annotated_bb))
set_bb_annotated (bb, annotated_bb);
}
Re: [libibery PATCH] Fix bootstrap
On 05/24/2017 08:34 PM, Nathan Sidwell wrote:
We now warn on casts to T const. Applied as obvious to fix bootstrap.
And this fixes c-common.c
nathan
--
Nathan Sidwell
2017-05-24 Nathan Sidwell
* c=common.c (field_decl_cmp, resort_field_decl_cmp): Adjust T
const casts to avoid warning.
Index: c-common.c
===
--- c-common.c (revision 248441)
+++ c-common.c (working copy)
@@ -5866,8 +5866,8 @@ check_builtin_function_arguments (locati
int
field_decl_cmp (const void *x_p, const void *y_p)
{
- const tree *const x = (const tree *const) x_p;
- const tree *const y = (const tree *const) y_p;
+ const tree *const x = (const tree *) x_p;
+ const tree *const y = (const tree *) y_p;
if (DECL_NAME (*x) == DECL_NAME (*y))
/* A nontype is "greater" than a type. */
@@ -5892,8 +5892,8 @@ pointer operator in resort_data. */
static int
resort_field_decl_cmp (const void *x_p, const void *y_p)
{
- const tree *const x = (const tree *const) x_p;
- const tree *const y = (const tree *const) y_p;
+ const tree *const x = (const tree *) x_p;
+ const tree *const y = (const tree *) y_p;
if (DECL_NAME (*x) == DECL_NAME (*y))
/* A nontype is "greater" than a type. */
[libibery PATCH] Fix bootstrap
We now warn on casts to T const. Applied as obvious to fix bootstrap.
nathan
--
Nathan Sidwell
Index: ChangeLog
===
--- ChangeLog (revision 248441)
+++ ChangeLog (working copy)
@@ -1,3 +1,7 @@
+2017-05-24 Nathan Sidwell
+
+ * libiberty.h (ASTRDUP): Adjust cast to avoid warning.
+
2017-05-19 Eli Zaretskii
* environ.h: Add #ifndef guard.
Index: libiberty.h
===
--- libiberty.h (revision 248441)
+++ libiberty.h (working copy)
@@ -724,7 +724,7 @@ extern void *C_alloca (size_t) ATTRIBUTE
# define ASTRDUP(X) \
(__extension__ ({ const char *const libiberty_optr = (X); \
const unsigned long libiberty_len = strlen (libiberty_optr) + 1; \
- char *const libiberty_nptr = (char *const) alloca (libiberty_len); \
+ char *const libiberty_nptr = (char *) alloca (libiberty_len); \
(char *) memcpy (libiberty_nptr, libiberty_optr, libiberty_len); }))
#else
# define alloca(x) C_alloca(x)
[C++ PATCH] Friend decls
With pushdecl revamped, there's no need for do_friend to do some
checking with a local class friend. And therefore no need for the very
specialized lookup_name_innermost_nonclass_level.
push_local_binding will get some more cleanup soon.
Committed to trunk.
nathan
--
Nathan Sidwell
2017-05-24 Nathan Sidwell
cp/
* friend.c (do_friend): Remove check for existing decl.
* name-lookup.h (lookup_name_innermost_nonclass_level): Delete.
* name-lookup.c (push_local_binding): Directly look for binding.
(lookup_name_innermost_nonclass_level_1): Delete.
(lookup_name_innermost_nonclass_level): Delete.
testsuite/
* g++.dg/lookup/friend12.C: Adjust diagnostics.
* g++.dg/lookup/friend19.C: New.
* g++.dg/lookup/friend20.C: New.
Index: cp/friend.c
===
--- cp/friend.c (revision 248432)
+++ cp/friend.c (working copy)
@@ -608,25 +608,8 @@ do_friend (tree ctype, tree declarator,
is instantiated. */
decl = push_template_decl_real (decl, /*is_friend=*/true);
else if (current_function_decl)
- {
- /* This must be a local class. 11.5p11:
-
- If a friend declaration appears in a local class (9.8) and
- the name specified is an unqualified name, a prior
- declaration is looked up without considering scopes that
- are outside the innermost enclosing non-class scope. For a
- friend function declaration, if there is no prior
- declaration, the program is ill-formed. */
- tree t = lookup_name_innermost_nonclass_level (DECL_NAME (decl));
- if (t)
- decl = pushdecl (decl, /*is_friend=*/true);
- else
- {
- error ("friend declaration %qD in local class without "
- "prior declaration", decl);
- return error_mark_node;
- }
- }
+ /* pushdecl will check there's a local decl already. */
+ decl = pushdecl (decl, /*is_friend=*/true);
else
{
/* We can't use pushdecl, as we might be in a template
Index: cp/name-lookup.c
===
--- cp/name-lookup.c (revision 248432)
+++ cp/name-lookup.c (working copy)
@@ -2103,7 +2103,13 @@ push_local_binding (tree id, tree decl,
push_local_binding with a friend decl of a local class. */
b = innermost_nonclass_level ();
- if (lookup_name_innermost_nonclass_level (id))
+ cxx_binding *binding = NULL;
+ if (b->kind == sk_namespace)
+binding = find_namespace_binding (current_namespace, id);
+ else
+binding = find_local_binding (b, id);
+
+ if (binding)
{
/* Supplement the existing binding. */
if (!supplement_binding (IDENTIFIER_BINDING (id), decl))
@@ -5430,37 +5436,6 @@ lookup_type_scope (tree name, tag_scope
return ret;
}
-
-/* Similar to `lookup_name' but look only in the innermost non-class
- binding level. */
-
-static tree
-lookup_name_innermost_nonclass_level_1 (tree name)
-{
- cp_binding_level *b = innermost_nonclass_level ();
- cxx_binding *binding = NULL;
-
- if (b->kind == sk_namespace)
-binding = find_namespace_binding (current_namespace, name);
- else
-binding = find_local_binding (b, name);
-
- return binding ? binding->value : NULL_TREE;
-}
-
-/* Wrapper for lookup_name_innermost_nonclass_level_1. */
-
-tree
-lookup_name_innermost_nonclass_level (tree name)
-{
- tree ret;
- bool subtime = timevar_cond_start (TV_NAME_LOOKUP);
- ret = lookup_name_innermost_nonclass_level_1 (name);
- timevar_cond_stop (TV_NAME_LOOKUP, subtime);
- return ret;
-}
-
-
/* Returns true iff DECL is a block-scope extern declaration of a function
or variable. */
Index: cp/name-lookup.h
===
--- cp/name-lookup.h (revision 248432)
+++ cp/name-lookup.h (working copy)
@@ -310,7 +310,6 @@ extern tree get_namespace_binding (tree
extern void set_global_binding (tree id, tree val);
extern tree lookup_qualified_name (tree, tree, int, bool, /*hidden*/bool = false);
extern tree lookup_name_nonclass (tree);
-extern tree lookup_name_innermost_nonclass_level (tree);
extern bool is_local_extern (tree);
extern tree lookup_function_nonclass (tree, vec *, bool);
extern bool pushdecl_class_level (tree);
Index: testsuite/g++.dg/lookup/friend12.C
===
--- testsuite/g++.dg/lookup/friend12.C (revision 248422)
+++ testsuite/g++.dg/lookup/friend12.C (working copy)
@@ -2,9 +2,9 @@
void foo()
{
+ extern void bar (int); // not the bar we are looking for
struct A
{
-friend void bar(); // { dg-error "without prior declaration" }
+friend void bar(); // { dg-error "without prior local declaration" }
};
- bar(); // { dg-error "3:'bar' was not declared" }
}
Index: testsuite/g++.dg/lookup/friend19.C
===
--- testsuite/g++.dg/lookup/friend19.C (revision 0)
+++ testsuite/g++.dg/lookup/friend19.C (working copy)
@@ -0,0 +1,29 @@
[C++ PATCH] Sort Make-lang.in
Make-lang.in has a list ripe for sorting. So sorted. nathan -- Nathan Sidwell 2017-05-24 Nathan Sidwell * Make-lang.in (CXX_AND_OBJCXX_OBJS): Alphabetize. Index: Make-lang.in === --- Make-lang.in (revision 248432) +++ Make-lang.in (working copy) @@ -71,15 +71,22 @@ CXX_C_OBJS = attribs.o incpath.o \ $(C_COMMON_OBJS) $(CXX_TARGET_OBJS) # Language-specific object files for C++ and Objective C++. -CXX_AND_OBJCXX_OBJS = cp/call.o cp/decl.o cp/expr.o cp/pt.o cp/typeck2.o \ - cp/class.o cp/decl2.o cp/error.o cp/lex.o cp/parser.o cp/ptree.o cp/rtti.o \ - cp/typeck.o cp/cvt.o cp/except.o cp/friend.o cp/init.o cp/method.o \ - cp/search.o cp/semantics.o cp/tree.o cp/repo.o cp/dump.o cp/optimize.o \ - cp/mangle.o cp/cp-objcp-common.o cp/name-lookup.o cp/cxx-pretty-print.o \ - cp/cp-cilkplus.o \ - cp/cp-gimplify.o cp/cp-array-notation.o cp/lambda.o \ - cp/vtable-class-hierarchy.o cp/constexpr.o cp/cp-ubsan.o \ - cp/constraint.o cp/logic.o $(CXX_C_OBJS) +CXX_AND_OBJCXX_OBJS = \ + cp/call.o cp/class.o cp/constexpr.o cp/constraint.o \ + cp/cp-array-notation.o cp/cp-cilkplus.o cp/cp-gimplify.o \ + cp/cp-objcp-common.o cp/cp-ubsan.o \ + cp/cvt.o cp/cxx-pretty-print.o \ + cp/decl.o cp/decl2.o cp/dump.o \ + cp/error.o cp/except.o cp/expr.o \ + cp/friend.o cp/init.o \ + cp/lambda.o cp/lex.o cp/logic.o \ + cp/mangle.o cp/method.o \ + cp/name-lookup.o cp/optimize.o \ + cp/parser.o cp/pt.o cp/ptree.o \ + cp/repo.o cp/rtti.o \ + cp/search.o cp/semantics.o \ + cp/tree.o cp/typeck.o cp/typeck2.o \ + cp/vtable-class-hierarchy.o $(CXX_C_OBJS) ifeq ($(if $(wildcard ../stage_current),$(shell cat \ ../stage_current)),stageautofeedback)
[C++ PATCH] Overload cleanups
here are a few more cleanups from the modules branch.
firstl type_unknown_p had some historical baggage from when overloads
were tree lists. No need for that, and then why not make it inline?
is_overloaded_fn and friends are ripe for cleanup, and this does a
little of that. Remove some use of OVL_CURRENT, which I will be killing
soon.
Fixed up some formatting and inconsistency in cp-tree.h whilst there.
committed to trunk.
nathan
--
Nathan Sidwell
2017-05-24 Nathan Sidwell
* cp-tree.h (cp_free_lang_data): Add extern.
(ovl_skip_hidden, is_overloaded_fn, really_overloaded_fn): Add
ATTRIBUTE_PURE.
(type_unknown_p): Return bool, make inline, lose TREE_LIST check.
* typeck.c (type_unknown_p): Delete.
* tree.c (is_overloaded_fn): Use MAYBE_BASELINE_FUNCTIONS, adjust
overload management.
(dependent_name): Likewise.
(decl_anon_ns_mem_p): Simplify.
Index: cp/cp-tree.h
===
--- cp/cp-tree.h (revision 248423)
+++ cp/cp-tree.h (working copy)
@@ -6789,7 +6789,7 @@ extern tree finish_builtin_launder (loc
/* in tree.c */
extern int cp_tree_operand_length (const_tree);
extern int cp_tree_code_length (enum tree_code);
-void cp_free_lang_data (tree t);
+extern void cp_free_lang_data (tree t);
extern tree force_target_expr (tree, tree, tsubst_flags_t);
extern tree build_target_expr_with_type (tree, tree, tsubst_flags_t);
extern void lang_check_failed (const char *, int,
@@ -6811,7 +6811,8 @@ extern bool type_has_nontrivial_copy_ini
extern void maybe_warn_parm_abi (tree, location_t);
extern bool class_tmpl_impl_spec_p (const_tree);
extern int zero_init_p(const_tree);
-extern bool check_abi_tag_redeclaration (const_tree, const_tree, const_tree);
+extern bool check_abi_tag_redeclaration (const_tree, const_tree,
+ const_tree);
extern bool check_abi_tag_args (tree, tree);
extern tree strip_typedefs (tree, bool * = NULL);
extern tree strip_typedefs_expr (tree, bool * = NULL);
@@ -6852,10 +6853,11 @@ extern tree ovl_make(tree fn,
tree next = NULL_TREE);
extern tree ovl_insert(tree fn, tree maybe_ovl,
bool using_p = false);
-extern tree ovl_skip_hidden (tree);
+extern tree ovl_skip_hidden (tree) ATTRIBUTE_PURE;
extern tree lookup_add(tree fns, tree lookup);
extern void lookup_keep(tree lookup, bool keep);
-extern int is_overloaded_fn (tree);
+extern int is_overloaded_fn (tree) ATTRIBUTE_PURE;
+extern bool really_overloaded_fn (tree) ATTRIBUTE_PURE;
extern tree dependent_name (tree);
extern tree get_fns(tree) ATTRIBUTE_PURE;
extern tree get_first_fn (tree) ATTRIBUTE_PURE;
@@ -6876,7 +6878,6 @@ extern bool decl_anon_ns_mem_p (const_
extern tree lvalue_type(tree);
extern tree error_type(tree);
extern int varargs_function_p (const_tree);
-extern bool really_overloaded_fn (tree);
extern bool cp_tree_equal (tree, tree);
extern tree no_linkage_check (tree, bool);
extern void debug_binfo(tree);
@@ -6933,7 +6934,7 @@ extern tree require_complete_type_sfinae
extern tree complete_type (tree);
extern tree complete_type_or_else (tree, tree);
extern tree complete_type_or_maybe_complain (tree, tree, tsubst_flags_t);
-extern int type_unknown_p (const_tree);
+inline bool type_unknown_p (const_tree);
enum { ce_derived, ce_type, ce_normal, ce_exact };
extern bool comp_except_specs (const_tree, const_tree, int);
extern bool comptypes(tree, tree, int);
@@ -7311,6 +7312,12 @@ ovl_first (tree node)
return node;
}
+inline bool
+type_unknown_p (const_tree expr)
+{
+ return TREE_TYPE (expr) == unknown_type_node;
+}
+
/* -- end of C++ */
#endif /* ! GCC_CP_TREE_H */
Index: cp/typeck.c
===
--- cp/typeck.c (revision 248422)
+++ cp/typeck.c (working copy)
@@ -162,15 +162,6 @@ complete_type_or_else (tree type, tree v
return complete_type_or_maybe_complain (type, value, tf_warning_or_error);
}
-/* Return truthvalue of whether type of EXP is instantiated. */
-
-int
-type_unknown_p (const_tree exp)
-{
- return (TREE_CODE (exp) == TREE_LIST
- || TREE_TYPE (exp) == unknown_type_node);
-}
-
/* Return the common type of two parameter lists.
We assume that comptypes has already been done and returned 1;
Index: cp/tree.c
===
--- cp/tree.c (revision 248423)
+++ cp/tree.c (working copy)
@@ -2337,15 +2337,16 @@ is_overloaded_fn (tree x)
if (TREE_CODE (x) == OFFSET_REF
|| TREE_CODE (x) == COMPONENT_REF)
x = TREE_OPERAND (x, 1);
- if (BASELINK_P (x))
-x = BASELINK_FUNCTIONS (x);
+ x = MAYBE_BASELINK_FUNCTIONS (x);
if (TREE_CODE (x) == TEMPLATE_ID_EXPR)
x = TREE_OPERAND (x, 0);
- if (DECL_FUNCTION_TEMPLATE_P (OVL_CURRENT (x))
- || (TREE_CODE (x) == OVERLOAD && OVL_CHAIN (x)))
+
+ if (DECL_FUNCTION_TEMPLATE_P (OVL_FIRST (x))
+ || (TREE_CODE (x) == O
Re: [PATCH] add more detail to -Wconversion and -Woverflow (PR 80731)
On 05/24/2017 11:08 AM, Joseph Myers wrote:
On Wed, 17 May 2017, Martin Sebor wrote:
@@ -1036,31 +1079,76 @@ warnings_for_convert_and_check (location_t loc, tree
type, tree expr,
/* This detects cases like converting -129 or 256 to
unsigned char. */
if (!int_fits_type_p (expr, c_common_signed_type (type)))
- warning_at (loc, OPT_Woverflow,
- "large integer implicitly truncated to unsigned type");
+ {
+ if (cst)
+ warning_at (loc, OPT_Woverflow,
+ (TYPE_UNSIGNED (exprtype)
+? "conversion from %qT to %qT "
+"changes value from %qE to %qE"
+: "unsigned conversion from %qT to %qT "
+"changes value from %qE to %qE"),
+ exprtype, type, expr, result);
+ else
+ warning_at (loc, OPT_Woverflow,
+ (TYPE_UNSIGNED (exprtype)
+? "conversion from %qT to %qT "
+"changes the value of %qE"
+: "unsigned conversion from %qT to %qT "
+"changes the value of %qE"),
+ exprtype, type, expr);
+ }
You need to use G_() around both arguments to ?:, otherwise only one will
get extracted for translation.
diff --git a/gcc/testsuite/c-c++-common/pr68657-1.c
b/gcc/testsuite/c-c++-common/pr68657-1.c
index 84f3e54..33fdf86 100644
--- a/gcc/testsuite/c-c++-common/pr68657-1.c
+++ b/gcc/testsuite/c-c++-common/pr68657-1.c
@@ -5,14 +5,14 @@
void
f1 (void)
{
- unsigned int a = -5; /* { dg-error "negative integer implicitly converted to
unsigned type" } */
+ unsigned int a = -5; /* { dg-error "unsigned conversion from .int. to .unsigned
int. changes value from .-5. to .4294967291." } */
The more specific match would fail for targets with 16-bit int. You need
to keep it less specific in this test (if you want to test the more
specific text as well, another test could be added for that, restricted to
the int32 effective-target).
(The changes to Wconversion-real-integer-3.C and
Wconversion-real-integer2.C are OK in that those tests are restricted to
int32plus, although in theory 64-bit int would be an issue there.)
+ /* According to 6.3.1.3 of C11:
+ -3- Otherwise, the new type is signed and the value cannot be
+ represented in it; either the result is implementation-defined
+ or an implementation-defined signal is raised.
+
+ In GCC such conversios wrap and diagnosed by mentioning "overflow"
+ if the absolut value of the operand is in excess of the maximum of
+ the destination of type, and "conversion" otherwise, as follows: */
s/conversios/conversions/; s/absolut/absolute/
OK with those changes.
Thanks for the careful review! Done and committed in r248431.
Martin
Re: MinGW compilation warnings in libiberty's waitpid.c
Thanks. Committed!
Re: [PATCH] warn on mem calls modifying objects of non-trivial types (PR 80560)
On 05/24/2017 04:28 PM, Martin Sebor wrote:
Attached is an updated patch with the requested changes. I've
also renamed the option -Wclass-memaccess to avoid suggesting
that the warning focuses solely on non-trivial types, and
updated its wording and comments throughout to refer to value
initialization rather than default initialization. Retesting
exposed another problem recently introduced into dumplfile.c
so this revision of the patch also contains a fix for that.
Emacs wasn't done saving the patch so here's the latest one with
the dumpfile.c fix.
+/* Return true if class TYPE meets a relaxed definition of standard-layout.
+ In particular, the requirement that it "has all non-static data members
+ nd bit-fields in the class and its base classes first declared in the
+ same class" is not considered. */
+
+static bool
+almost_std_layout_p (tree type, tree *field)
It looks like this will only return false when trivial_type_p will also
return false, so its only real function is setting *field. Can we
remove it and instead make first_non_public_field recursive?
+case BUILT_IN_MEMSET:
+ if (!integer_zerop (args[1]))
+ {
+ /* Diagnose setting non-copy-assignable, non-trivial or non-
+standard layout objects (in that order, since the latter
+two are subsets of one another), to (potentially) non-zero
+bytes. Since the value of the bytes being written is unknown,
+suggest using assignment instead (if one exists). */
+ if (!trivassign)
+ warnfmt = G_("%qD writing to an object of type %#qT without "
+"trivial copy assignment");
+ else if (!trivial)
+ warnfmt = G_("%qD writing to an object of non-trivial "
+"type %#qT; use assignment instead");
Let's put the !trivial check first.
+ else if (!stdlayout)
+ warnfmt = G_("%qD writing to an object of non-standard-layout "
+"type %#qT; use assignment instead");
+ else if (fld)
+ {
+ const char *access = TREE_PRIVATE (fld) ? "private" : "protected";
+ warned = warning_at (loc, OPT_Wclass_memaccess,
+ "%qD writing to an object of type %#qT with "
+ "%qs member %qD; use assignment instead",
+ fndecl, desttype, access, fld);
+ }
+ else if (!zero_init_p (desttype))
+ warnfmt = G_("%qD writing to an object of type %#qT containing "
+"a pointer to data member; use assignment instead");
+
+ break;
+ }
+ /* Fall through. */
+
+case BUILT_IN_BZERO:
+ /* Similarly to the above, diagnose clearing non-trivial or non-
+standard layout objects, or objects of types with no assignmenmt. */
+ if (!trivassign)
+ warnfmt = (trivcopy
+ ? G_("%qD clearing an object of type %#qT without trivial "
+ "copy assignment; use copy constructor instead")
+ : G_("%qD clearing an object of type %#qT without trivial "
+ "copy assignment"));
+ else if (!trivial)
+ warnfmt = G_("%qD clearing an object of non-trivial type "
+"%#qT; use assignment or value-initialization instead");
Again, let's put the !trivial check first; then we don't need to check
trivcopy in the !trivassign branch.
+ else if (!stdlayout)
+ warnfmt = G_("%qD clearing an object of non-standard-layout type "
+"%#qT; use assignment or value-initialization instead");
+ else if (!zero_init_p (desttype))
+ warnfmt = G_("%qD clearing an object of type %#qT containing "
+"a pointer-to-member; use assignment or value-"
+"initialization instead");
+ break;
+
+case BUILT_IN_BCOPY:
+case BUILT_IN_MEMCPY:
+case BUILT_IN_MEMMOVE:
+case BUILT_IN_MEMPCPY:
+ /* Determine the type of the source object. */
+ srctype = (TREE_CODE (args[1]) == NOP_EXPR
+? TREE_OPERAND (args[1], 0) : args[1]);
+
+ srctype = TREE_TYPE (TREE_TYPE (srctype));
+
+ if (!trivassign)
+ warnfmt = (trivcopy
+ ? G_("%qD writing to an object of type %#qT without trivial "
+ "copy assignment; use copy constructor instead")
+ : G_("%qD writing to an object of type %#qT without trivial
"
+"copy assignment"));
+ else if (!trivially_copyable_p (desttype))
+ warnfmt = G_("%qD writing to an object of non-trivially-copyable type "
+"%#qT; use assignment or copy-initialization instead");
And here put the trivially-copyable test first, and drop checking
trivcopy in the !trivassign branch.
+ else if (!trivial
+ && !VOID_TYPE_P (srctype)
+
Re: [PATCH v2 04/N] Simplify usage of some TDF_* flags.
Hi Richi. That's a small reminder. I CCed Steven, but I guess if the TDF_COMMENT would be really important, it can be eventually added back. May I install the patch now? Thanks, Martin
Re: [PATCH] warn on mem calls modifying objects of non-trivial types (PR 80560)
Attached is an updated patch with the requested changes. I've
also renamed the option -Wclass-memaccess to avoid suggesting
that the warning focuses solely on non-trivial types, and
updated its wording and comments throughout to refer to value
initialization rather than default initialization. Retesting
exposed another problem recently introduced into dumplfile.c
so this revision of the patch also contains a fix for that.
Emacs wasn't done saving the patch so here's the latest one with
the dumpfile.c fix.
Martin
PR c++/80560 - warn on undefined memory operations involving non-trivial types
gcc/c-family/ChangeLog:
PR c++/80560
* c.opt (-Wclass-memaccess): New option.
gcc/cp/ChangeLog:
PR c++/80560
* call.c (first_non_public_field): New function.
(maybe_warn_class_memaccess): Same.
(build_cxx_call): Call it.
* cp-tree.h (has_trivial_assign, has_trivial_copy): Declare.
* method.c (has_trivial_assign, has_trivial_copy): Define.
gcc/ChangeLog:
PR c++/80560
* dumpfile.c (dump_register): Avoid calling memset to initialize
a class with a default ctor.
* gcc.c (struct compiler): Remove const qualification.
* genattrtab.c (gen_insn_reserv): Replace memset with initialization.
* hash-table.h: Ditto.
* ipa-cp.c (allocate_and_init_ipcp_value): Replace memset with
assignment.
* ipa-prop.c (ipa_free_edge_args_substructures): Ditto.
* omp-low.c (lower_omp_ordered_clauses): Replace memset with
default ctor.
* params.h (struct param_info): Make struct members non-const.
* tree-switch-conversion.c (emit_case_bit_tests): Replace memset
with default initialization.
* vec.h (vec_copy_construct, vec_default_construct): New helper
functions.
(vec::copy, vec::splice, vec::reserve): Replace memcpy
with vec_copy_construct.
(vect::quick_grow_cleared): Replace memset with default ctor.
(vect::vec_safe_grow_cleared, vec_safe_grow_cleared): Same.
* doc/invoke.texi (-Wclass-memaccess): Document.
libcpp/ChangeLog:
PR c++/80560
* line-map.c (line_maps::~line_maps): Avoid calling htab_delete
with a null pointer.
(linemap_init): Avoid calling memset on an object of a non-trivial
type.
libitm/ChangeLog:
PR c++/80560
* beginend.cc (GTM::gtm_thread::rollback): Avoid calling memset
on an object of a non-trivial type.
(GTM::gtm_transaction_cp::commit): Use assignment instead of memcpy
to copy an object.
* method-ml.cc (orec_iterator::reinit): Avoid -Wclass-memaccess.
gcc/testsuite/ChangeLog:
PR c++/80560
* g++.dg/Wclass-memaccess.C: New test.
diff --git a/gcc/c-family/c.opt b/gcc/c-family/c.opt
index 9ad2f6e..f777b8f 100644
--- a/gcc/c-family/c.opt
+++ b/gcc/c-family/c.opt
@@ -792,6 +792,10 @@ Wnon-template-friend
C++ ObjC++ Var(warn_nontemplate_friend) Init(1) Warning
Warn when non-templatized friend functions are declared within a template.
+Wclass-memaccess
+C++ ObjC++ Var(warn_class_memaccess) Warning LangEnabledBy(C++ ObjC++, Wall)
+Warn for unsafe raw memory writes to objects of class types.
+
Wnon-virtual-dtor
C++ ObjC++ Var(warn_nonvdtor) Warning LangEnabledBy(C++ ObjC++,Weffc++)
Warn about non-virtual destructors.
diff --git a/gcc/cp/call.c b/gcc/cp/call.c
index f14c0fa..8e9c583 100644
--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -8143,6 +8143,259 @@ build_over_call (struct z_candidate *cand, int flags, tsubst_flags_t complain)
return call;
}
+/* Return the DECL of the first non-public data member of class TYPE
+ or null if none can be found. */
+
+static tree
+first_non_public_field (tree type)
+{
+ if (!CLASS_TYPE_P (type))
+return NULL_TREE;
+
+ for (tree field = TYPE_FIELDS (type); field; field = DECL_CHAIN (field))
+{
+ if (TREE_CODE (field) != FIELD_DECL)
+ continue;
+ if (TREE_STATIC (field))
+ continue;
+ if (TREE_PRIVATE (field) || TREE_PROTECTED (field))
+ return field;
+}
+
+ return NULL_TREE;
+}
+
+/* Return true if class TYPE meets a relaxed definition of standard-layout.
+ In particular, the requirement that it "has all non-static data members
+ nd bit-fields in the class and its base classes first declared in the
+ same class" is not considered. */
+
+static bool
+almost_std_layout_p (tree type, tree *field)
+{
+ if (!CLASS_TYPE_P (type))
+return true;
+
+ if (!trivial_type_p (type))
+return false;
+
+ if (tree fld = first_non_public_field (type))
+if (!*field)
+ *field = fld;
+
+ tree binfo, base_binfo;
+
+ int i;
+
+ for (binfo = TYPE_BINFO (type), i = 0;
+ BINFO_BASE_ITERATE (binfo, i, base_binfo); i++)
+{
+ tree base = TREE_TYPE (base_binfo);
+
+ if (!almost_std_layout_p (base, field))
+ return false;
+}
+
+ return true;
+}
+
+/* Issue a warning on a call to the built-in function FNDECL if it is
+ a memory write whose destination is not an object of (something like)
+ trivial or standard layout type with a non-deleted assignment and copy
+ ctor. Detects const correctness violations, corrupting references,
+ virtual table pointers, and bypassing non-
Re: [PATCH] warn on mem calls modifying objects of non-trivial types (PR 80560)
On 05/21/2017 10:50 PM, Jason Merrill wrote: On Sun, May 21, 2017 at 7:59 PM, Martin Sebor wrote: On 05/19/2017 03:42 PM, Jason Merrill wrote: On Fri, May 19, 2017 at 4:07 PM, Martin Sebor wrote: On 05/19/2017 01:07 PM, Jason Merrill wrote: On Tue, May 16, 2017 at 5:39 PM, Martin Sebor wrote: On 05/16/2017 01:41 PM, Jason Merrill wrote: 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, That's the part that seems unnecessary. Why do we care about non-public members? Because modifying them breaks encapsulation. Not if you're clearing/copying the object as a whole. If I take a legacy struct, make some of its members private, and define accessors and modifiers to manipulate those members and maintain invariants between them, I will want to check and adjust all code that changes objects of the struct in ways that might violate the invariants. For a trivial type, worrying about invariants doesn't make sense to me, since default-initialization won't establish any invariants. And bzero or memset(0) will have the same effect as value-initialization (if zero_init_p (type); we probably want to check that). If you're going to establish invariants, I would expect you to write a default constructor, which would make the class non-trivial. Thanks for the zero_init_p pointer! Let me add that to the patch along with Pedro's suggestion to use the current C++ terminology, retest and resubmit. In most cases you're right that defining the default constructor is the way to go. There is are a couple of use cases where a ctor tends to be avoided: when objects the class need to be initialized statically, and where they need to be PODs. GCC itself relies on the latter (e.g., some of the vec templates), apparently because it stores them in unions. It doesn't look tome like these vec templates maintain much of an invariant of any kind, but they easily could. An example of the static initialization case is an atomic class (not necessarily std::atomic though I think this would apply to it as well). Its objects usually need to be statically default- initializable (without running any ctors) but then they must be explicitly initialized by some sort of an init call to be made valid, and their state can only be accessed and modified via member functions (and so their state is private). Modifying them by any other means, including by memset or memcpy, is undefined. What common use case are you concerned about that isn't more appropriately expressed using the generated default or copy constructor or assignment operator? None; I am concerned about focusing the warning on code that is actually likely to be problematic. Hopefully the above explanation resolves that concern. If not, please let me know. I still think that we shouldn't warn about zeroing out a non-standard-layout object when value-initialization would produce the exact same result. If you want to keep the almost_std_layout_p check for the non-zero memset case, that's fine. Attached is an updated patch with the requested changes. I've also renamed the option -Wclass-memaccess to avoid suggesting that the warning focuses solely on non-trivial types, and updated its wording and comments throughout to refer to value initialization rather than default initialization. Retesting exposed another problem recently introduced into dumplfile.c so this revision of the patch also contains a fix for that. Martin PR c++/80560 - warn on undefined memory operations involving non-trivial types gcc/c-family/ChangeLog: PR c++/80560 * c.opt (-Wclass-memaccess): New option. gcc/cp/ChangeLog: PR c++/80560 * call.c (first_non_public_field): New function. (maybe_warn_class_memaccess): Same. (build_cxx_call): Call it. * cp-tree.h (has_trivial_assign, has_trivial_copy): Declare. * method.c (has_trivial_assign, has_trivial_copy): Define. gcc/ChangeLog: PR c++/80560 * gcc.c (struct compiler): Remove const qualification. * genattrtab.c (gen_insn_reserv): Replace memset with initialization. * hash-table.h: Ditto. * ipa-cp.c (allocate_and_init_ipcp_value): Replace memset with assignment. * ipa-prop.c (ipa_free_edge_args_substructures): Ditto. * omp-low.c (lower_omp_ordered_clauses): Replace memset with default ctor. * params.h (struct param_info): Make struct members non-const. * tree-switch-conversion.c (emit_case_bit_tests): Replace memset with default initialization. * vec.h (vec_copy_construct, vec_default_construct): New helper functions. (vec::copy, vec::splice, vec::reserve): Replace memcpy with vec_copy_construct. (vect::quick_grow_cleared): Replace memset with default ctor. (vect::vec_safe_grow_cleared, vec_safe_grow_cleared): Same. * doc/invoke.texi (-Wclass-memaccess): Document. libcpp/ChangeLog: PR c++/80
Re: {PATCH] New C++ warning -Wcatch-value
On Mon, May 15, 2017 at 3:58 PM, Martin Sebor wrote: >> So how about the following then? I stayed with the catch part and added >> a parameter to the warning to let the user decide on the warnings she/he >> wants to get: -Wcatch-value=n. >> -Wcatch-value=1 only warns for polymorphic classes that are caught by >> value (to avoid slicing), -Wcatch-value=2 warns for all classes that >> are caught by value (to avoid copies). And finally -Wcatch-value=3 >> warns for everything not caught by reference to find typos (like pointer >> instead of reference) and bad coding practices. > > It seems reasonable to me. I'm not too fond of multi-level > warnings since few users take advantage of anything but the > default, but this case is simple and innocuous enough that > I don't think it can do harm. >> Bootstrapped and regtested on x86_64-pc-linux-gnu. >> OK for trunk? OK. >> If so, would it make sense to add -Wcatch-value=1 to -Wextra or even -Wall? >> I would do this in a seperate patch, becuase I haven't checked what that >> would mean for the testsuite. > > I can't think of a use case for polymorphic slicing that's not > harmful so unless there is a common one that escapes me, I'd say > -Wall. Agreed. But then you'll probably want to allow -Wno-catch-value to turn it off. Jason
Re: [config PATCH] --enable-languages
On 05/19/2017 10:59 AM, Nathan Sidwell wrote: --enable-languages=all confused me, because as RichardB said, 'it really means default'. So this patch does 2 things 1) allow --enable-languages=default to mean what =all does now. 2) change =all to mean all available languages. 2.1) jit is included in =all if -enable-host-shared is given. If you don't you get a warning that JIT's not included. If you're used to saying =all, then you'll get more languages with this patch than you used to. ok? FWIW, it took me a few broken bootstraps before I remembered that all didn't actually mean all but just some. I've since trained myself to spell out all the languages explicitly (in addition to typing all just to be safe) but I'm happy to see that I wasn't the only one shaking his head at the confusing misnomer. Thanks for fixing it! Martin
Re: [PATCH 0/3] Split off powerpcspe from rs6000 port
On Thu, May 18, 2017 at 11:30:11AM -0500, Segher Boessenkool wrote:
> On Mon, May 15, 2017 at 08:51:49PM +, Segher Boessenkool wrote:
> > As discussed before, here is a series to split powerpcspe from the
> > rs6000 port. This series does not yet make any real changes to either
> > port: it is a copy of rs6000/ to powerpcspe/, with some renames and
> > some necessary changes to the port file, and slightly more involved
> > changes to config.gcc .
> >
> > This was tested on powerpc64-linux {-m32,-m64}, and it was build-tested
> > on powerpc-linux-gnuspe (and the resulting compiler was tested to be
> > functional: it can build various Linux defconfigs for SPE systems).
>
> I am planning to commit this on monday, if I don't hear anything.
Done now, with the following changelog:
2017-05-24 Segher Boessenkool
* config/powerpcspe: New port. Files are copied from the rs6000
port, with "rs6000" in filenames replaced by "powerpcspe".
* config.gcc (powerpc*-*-*spe*): New.
(powerpc-*-eabispe*): Use ${cpu_type} instead of hardcoded pathnames.
(powerpc-*-rtems*spe*): New.
(powerpc*-*-linux*spe*): New.
(powerpc-wrs-vxworksspe): New.
(powerpc*-*-*, rs6000-*-*): Use ${cpu_type}.
(misc flags) [powerpc*-*-*, rs6000-*-*): Use ${cpu_type}.
* config.host (powerpc*-*-*spe*): New.
Re: [PATCH] PR c++/80544 strip cv-quals from cast results
On 24/05/17 14:50 -0400, Jason Merrill wrote:
On Wed, May 24, 2017 at 10:20 AM, Jonathan Wakely wrote:
On 23/05/17 16:26 -0400, Jason Merrill wrote:
On Tue, May 23, 2017 at 2:00 PM, Jonathan Wakely
wrote:
On 19/05/17 15:14 -0400, Jason Merrill wrote:
On Thu, Apr 27, 2017 at 12:59 PM, Jonathan Wakely
wrote:
I also tried to add a warning like EDG's (see the PR) but it gave a
false positive for direct-list-init of scoped enums (P0138R2, r240449)
because that code goes through build_c_cast to perform the conversion,
so looks like a cast to my new warning.
The enum init code could strip the cv-quals when calling build_c_cast
to avoid the warning.
Thanks, that works. I don't think this warning fits under any existing
option, so I'll add a new one. -Wuseless-cast-qual maybe? Or is that
too close to -Wuseless-cast and -Wcast-qual and would cause confusion?
-Wcast-rvalue-qual ?
I realised that -Wignored-qualifiers is a good fit. That warns about
ignored cv-qualifiers on return types, which is a very similar case.
This patch adds a new function to conditionally warn and calls that
from the build_*_cast functions after they produce a valid result. I
originally put the warnings next to the cv_unqualified calls that
strip the quals, but was getting duplicate warnings when build_cp_cast
calls more than one of the build_*_cast_1 functions.
This also removes the unnecessary check for reference types that
Nathan pointed out.
Tested x86_64-linux and powerpc64-linux. OK for trunk?
+/*
+ Warns if the cast ignores cv-qualifiers on TYPE.
+ */
The GCC sources don't put /* and */ on their own line. OK with that
change, thanks!
OK, I'll also fix it on the maybe_warn_about_useless_cast function
just above, which I copied :-)
diff --git a/gcc/cp/typeck.c b/gcc/cp/typeck.c
index ecc7190..b81d6c8 100644
--- a/gcc/cp/typeck.c
+++ b/gcc/cp/typeck.c
@@ -6655,9 +6655,7 @@ check_for_casting_away_constness (tree src_type, tree dest_type,
}
}
-/*
- Warns if the cast from expression EXPR to type TYPE is useless.
- */
+/* Warns if the cast from expression EXPR to type TYPE is useless. */
void
maybe_warn_about_useless_cast (tree type, tree expr, tsubst_flags_t complain)
{
@@ -6673,9 +6671,7 @@ maybe_warn_about_useless_cast (tree type, tree expr, tsubst_flags_t complain)
}
}
-/*
- Warns if the cast ignores cv-qualifiers on TYPE.
- */
+/* Warns if the cast ignores cv-qualifiers on TYPE. */
void
maybe_warn_about_cast_ignoring_quals (tree type, tsubst_flags_t complain)
{
Re: [PATCH] Try harder to fix recently introduced crashes in ggc_collect
On 05/24/2017 03:02 PM, Jason Merrill wrote: I think it would be premature to remove PCH from GCC 8. The Modules specification is far from stable, and moving current PCH users to Modules will take significant work (at least if we get something like the current draft rather than the relatively transparent scheme that clang uses). I agree. Although I now have function decls and inline function bodies working. Everything else is missing, and I know I'm not handling some things 'correctly'. nathan -- Nathan Sidwell
Re: [PATCH v2] Implement non-trivial std::random_device::entropy (PR libstdc++/67578)
On 23/05/17 17:15 +0100, Jonathan Wakely wrote: On 22/05/17 22:28 +0800, Xi Ruoyao wrote: The new patch is attached. Just merged the patches you sent and fixed the ChangeLog of gnu.ver and testsuite_abi.cc. (For fun: I had mistakenly attached the Vim .swp file of the patch and almost sent it. :-p) Ha, that *definitely* wouldnt' have applied, but I think I'd have noticed the reason sooner ;-) I've committed the patch now - thanks. @@ -334,6 +335,7 @@ compatible. GCC 5.1.0: GLIBCXX_3.4.21, CXXABI_1.3.9 GCC 6.1.0: GLIBCXX_3.4.22, CXXABI_1.3.10 GCC 7.1.0: GLIBCXX_3.4.23, CXXABI_1.3.11 +GCC 8.0.0: GLIBCXX_3.4.24, CXXABI_1.3.10 Oops, this should have been CXXABI_1.3.11, I fixed that before committing it. +if (static_cast(ent) > sizeof(result_type) * 8) + return static_cast(sizeof(result_type) * 8); After committing it I realised this should use __CHAR_BIT__ instead of hardcoding 8, which I'll fix shortly. Fixed with this patch. Tested powerpc64le-linux, committed to trunk. commit 26e91f1858aa054c28b521d86065966df4ba7099 Author: Jonathan Wakely Date: Wed May 24 17:41:34 2017 +0100 Use CHAR_BIT instead of assuming 8 bits * src/c++11/random.cc (random_device::_M_getentropy): Use __CHAR_BIT__ instead of fixed number of bits. diff --git a/libstdc++-v3/src/c++11/random.cc b/libstdc++-v3/src/c++11/random.cc index 5011cf2..ef17223 100644 --- a/libstdc++-v3/src/c++11/random.cc +++ b/libstdc++-v3/src/c++11/random.cc @@ -187,8 +187,9 @@ namespace std _GLIBCXX_VISIBILITY(default) if (ent < 0) return 0.0; -if (static_cast(ent) > sizeof(result_type) * 8) - return static_cast(sizeof(result_type) * 8); +const int max = sizeof(result_type) * __CHAR_BIT__; +if (ent > max) + ent = max; return static_cast(ent); #else
Re: [PATCH] PR c++/77306 - Unable to specify visibility for explicit template instantiations
On Sat, Apr 22, 2017 at 4:46 PM, James Abbatiello wrote:
> PR c++/77306
> * attribs.c (decl_attributes): Allow visibility attributes on explicit
> template instantiations.
> * gcc-family/c-attribs.c (handle_visibility_attribute): Likewise.
This doesn't seem sufficient; any members that have already been
instantiated will still have the default visibility. If you want to
go this way, you'll need to call reset_type_linkage when changing the
visibility of a type that's already defined.
Is there a reason you can't declare the visibility before the first
use of A, e.g.
extern template struct __attribute ((visibility("hidden"))) A;
followed later by
template class A;
?
Jason
Re: [patch] build xz (instead of bz2) compressed tarballs and diffs
On Tue, 23 May 2017, Matthias Klose wrote: > Looks like the copy of the script on gcc.gnu.org affects all active branches. Yeah, I just run into this myself (and scratched my had until I debugged this, admittedly quickly). > the May 23 GCC 5 snapshot was created successfully. Is this acceptable? Well, I guess it's a done deed. Probably a good idea to send a note to g...@gcc.gnu.org at least; I added the one below to our main page. Gerald Index: index.html === RCS file: /cvs/gcc/wwwdocs/htdocs/index.html,v retrieving revision 1.1053 diff -u -r1.1053 index.html --- index.html 9 May 2017 07:20:38 - 1.1053 +++ index.html 24 May 2017 19:08:02 - @@ -46,6 +46,10 @@ News +Weekly snapshots now use xz compression +[2017-05-24] +...instead of bzip2. + GCC 7.1 released [2017-05-02]
Re: C++ PATCH to add __integer_pack built-in for std::make_integer_sequence (c++/80396)
On Wed, May 24, 2017 at 02:47:08PM -0400, Jason Merrill wrote:
> On Wed, May 24, 2017 at 11:08 AM, Jakub Jelinek wrote:
> > On Wed, May 24, 2017 at 04:16:30PM +0200, Andreas Schwab wrote:
> >> FAIL: g++.dg/ext/integer-pack2.C -std=gnu++11 (test for excess errors)
> >> Excess errors:
> >> /daten/aranym/gcc/gcc-20170524/gcc/testsuite/g++.dg/ext/integer-pack2.C:10:48:
> >> error: overflow in constant expression [-fpermissive]
> >> /daten/aranym/gcc/gcc-20170524/gcc/testsuite/g++.dg/ext/integer-pack2.C:10:48:
> >> error: overflow in constant expression [-fpermissive]
> >
> > To be precise, it fails only on 32-bit targets.
>
> > If we at that point want some wider integer that when cast to int
> > is 0 (or small enough positive number?), shall we use something like
> > this, or say 1LL << (sizeof (int) * __CHAR_BIT__), or 2LL * INT_MIN,
> > something else?
>
> This is fine.
>
> > Do we need to include ? Or can we replace
> > INT_MAX with __INT_MAX__?
>
> __INT_MAX__ sounds good.
>
> > Not sure about that -2147483650 for 16-bit int targets (perhaps the test can
> > be guarded with int32 effective target).
>
> Yes, restricting the test to int32 seems like the easiest fix.
Ok, I've committed this (also add something to avoid failing on hypothetical
64-bit int 64-bit long long target). Tested for both -m32 and -m64 on
x86_64-linux.
2017-05-24 Jakub Jelinek
* g++.dg/ext/integer-pack2.C: Require int32 effective target.
Don't include limits.h.
(w): Conditionalize on long long wider than int. Use
1LL << (__SIZEOF_INT__ * __CHAR_BIT__) instead of
-9223372036854775808.
(x): Use __INT_MAX__ instead of INT_MAX.
--- gcc/testsuite/g++.dg/ext/integer-pack2.C.jj 2017-05-24 11:59:01.0
+0200
+++ gcc/testsuite/g++.dg/ext/integer-pack2.C2017-05-24 21:07:02.0
+0200
@@ -1,12 +1,12 @@
-// { dg-do compile { target c++11 } }
+// { dg-do compile { target { c++11 && int32 } } }
// { dg-options -w }
-#include
-
template struct integer_sequence { };
template
using make_integer_sequence = integer_sequence; //
{ dg-error "argument" }
-make_integer_sequence w;
-make_integer_sequence x;// { dg-message "required" }
+#if __SIZEOF_LONG_LONG__ > __SIZEOF_INT__
+make_integer_sequence w;
+#endif
+make_integer_sequence x; // { dg-message "required" }
make_integer_sequence y; // { dg-message "required" }
Jakub
Re: [PATCH] Try harder to fix recently introduced crashes in ggc_collect
On Wed, May 24, 2017 at 7:04 AM, Trevor Saunders wrote: > On Fri, May 19, 2017 at 10:10:23AM -0400, Nathan Sidwell wrote: >> On 05/19/2017 10:05 AM, Bernd Edlinger wrote: >> >> > hwi cannot be the root cause of the problem, >> > because it can only be long_integer_type_node >> > or long_long_integer_type_node, otherwise >> > an error would be triggered. >> >> that's the error I made with the static fns. PCH moves things around, so >> anything that can be streamed via PCH must be GTY marked. Also, I'm not >> sure if the current GC is a compacting GC (given PCH can compact things?) > > other than pch which I'm not sure about I'm pretty sure its not, and is > just basic mark and sweep. > > That said if modules can get merged for gcc 8 I'm very tempted to rm pch > now. I think it would be premature to remove PCH from GCC 8. The Modules specification is far from stable, and moving current PCH users to Modules will take significant work (at least if we get something like the current draft rather than the relatively transparent scheme that clang uses). Jason
[patch, fortran, committed] replace stdout with dumpfile in a few places
Hello world,
I just committed the attached patch as obvious.
Regards
Thomas
2017-05-24 Thomas Koenig
* dump-parse-tree.c (show_expr): Replace stdout
with dumpfile for showing values.
Index: dump-parse-tree.c
===
--- dump-parse-tree.c (Revision 247809)
+++ dump-parse-tree.c (Arbeitskopie)
@@ -422,7 +422,7 @@ show_expr (gfc_expr *p)
switch (p->ts.type)
{
case BT_INTEGER:
- mpz_out_str (stdout, 10, p->value.integer);
+ mpz_out_str (dumpfile, 10, p->value.integer);
if (p->ts.kind != gfc_default_integer_kind)
fprintf (dumpfile, "_%d", p->ts.kind);
@@ -436,7 +436,7 @@ show_expr (gfc_expr *p)
break;
case BT_REAL:
- mpfr_out_str (stdout, 10, 0, p->value.real, GFC_RND_MODE);
+ mpfr_out_str (dumpfile, 10, 0, p->value.real, GFC_RND_MODE);
if (p->ts.kind != gfc_default_real_kind)
fprintf (dumpfile, "_%d", p->ts.kind);
break;
@@ -449,7 +449,7 @@ show_expr (gfc_expr *p)
case BT_COMPLEX:
fputs ("(complex ", dumpfile);
- mpfr_out_str (stdout, 10, 0, mpc_realref (p->value.complex),
+ mpfr_out_str (dumpfile, 10, 0, mpc_realref (p->value.complex),
GFC_RND_MODE);
if (p->ts.kind != gfc_default_complex_kind)
fprintf (dumpfile, "_%d", p->ts.kind);
Re: [patch, fortran] Handle MATMUL(TRANSPOSE(A),B) in inline matmul
Hi Jerry, On 05/17/2017 02:41 PM, Thomas Koenig wrote: Hello world, after receiving no negative feedback on my RFC patch, I have deciced to submit the patch. The attached patch handles MATMUL(TRANSPOSE(A),B) in inlining matmul. Speed is a bit faster than the library version. Regression-tested. OK for trunk? OK and thanks for patch. Committed as rev. 248425. Thanks for the review! I am going to close PR 66094 now. Any other cases would be silly. With a vector v and a matrix a, matmul(transpose(a),v) can be replaced by matmul(v,a) matmul(v,transpose(a)) can be replaced by matmul(a,v) And as for matmul(transpose(a), transpose(b)), well... Regards Thomas
Re: [PATCH] PR c++/80544 strip cv-quals from cast results
On Wed, May 24, 2017 at 10:20 AM, Jonathan Wakely wrote: > On 23/05/17 16:26 -0400, Jason Merrill wrote: >> >> On Tue, May 23, 2017 at 2:00 PM, Jonathan Wakely >> wrote: >>> >>> On 19/05/17 15:14 -0400, Jason Merrill wrote: On Thu, Apr 27, 2017 at 12:59 PM, Jonathan Wakely wrote: > > > I also tried to add a warning like EDG's (see the PR) but it gave a > false positive for direct-list-init of scoped enums (P0138R2, r240449) > because that code goes through build_c_cast to perform the conversion, > so looks like a cast to my new warning. The enum init code could strip the cv-quals when calling build_c_cast to avoid the warning. >>> >>> >>> >>> Thanks, that works. I don't think this warning fits under any existing >>> option, so I'll add a new one. -Wuseless-cast-qual maybe? Or is that >>> too close to -Wuseless-cast and -Wcast-qual and would cause confusion? >> >> >> -Wcast-rvalue-qual ? > > > I realised that -Wignored-qualifiers is a good fit. That warns about > ignored cv-qualifiers on return types, which is a very similar case. > > This patch adds a new function to conditionally warn and calls that > from the build_*_cast functions after they produce a valid result. I > originally put the warnings next to the cv_unqualified calls that > strip the quals, but was getting duplicate warnings when build_cp_cast > calls more than one of the build_*_cast_1 functions. > > This also removes the unnecessary check for reference types that > Nathan pointed out. > > Tested x86_64-linux and powerpc64-linux. OK for trunk? > +/* > + Warns if the cast ignores cv-qualifiers on TYPE. > + */ The GCC sources don't put /* and */ on their own line. OK with that change, thanks! Jason
Re: C++ PATCH to add __integer_pack built-in for std::make_integer_sequence (c++/80396)
On Wed, May 24, 2017 at 11:08 AM, Jakub Jelinek wrote: > On Wed, May 24, 2017 at 04:16:30PM +0200, Andreas Schwab wrote: >> FAIL: g++.dg/ext/integer-pack2.C -std=gnu++11 (test for excess errors) >> Excess errors: >> /daten/aranym/gcc/gcc-20170524/gcc/testsuite/g++.dg/ext/integer-pack2.C:10:48: >> error: overflow in constant expression [-fpermissive] >> /daten/aranym/gcc/gcc-20170524/gcc/testsuite/g++.dg/ext/integer-pack2.C:10:48: >> error: overflow in constant expression [-fpermissive] > > To be precise, it fails only on 32-bit targets. > If we at that point want some wider integer that when cast to int > is 0 (or small enough positive number?), shall we use something like > this, or say 1LL << (sizeof (int) * __CHAR_BIT__), or 2LL * INT_MIN, > something else? This is fine. > Do we need to include ? Or can we replace > INT_MAX with __INT_MAX__? __INT_MAX__ sounds good. > Not sure about that -2147483650 for 16-bit int targets (perhaps the test can > be guarded with int32 effective target). Yes, restricting the test to int32 seems like the easiest fix. Jason
Re: MinGW compilation warnings in libiberty's waitpid.c
> From: DJ Delorie > Cc: gcc-patches@gcc.gnu.org, gdb-patc...@sourceware.org > Date: Tue, 23 May 2017 22:26:22 -0400 > > > Is there anything else I need to do about this part to get it solved > > in the upstream repository? > > A ChangeLog entry would be nice, so I don't have to write one ;-) Sure: 2017-05-24 Eli Zaretskii * libiberty/waitpid.c (wait) [__MINGW32__]: Define as a macro that calls _cwait, so that this function works on MinGW.
Re: [PATCH] add more detail to -Wconversion and -Woverflow (PR 80731)
On Wed, 17 May 2017, Martin Sebor wrote:
> @@ -1036,31 +1079,76 @@ warnings_for_convert_and_check (location_t loc, tree
> type, tree expr,
> /* This detects cases like converting -129 or 256 to
>unsigned char. */
> if (!int_fits_type_p (expr, c_common_signed_type (type)))
> - warning_at (loc, OPT_Woverflow,
> - "large integer implicitly truncated to unsigned type");
> + {
> + if (cst)
> + warning_at (loc, OPT_Woverflow,
> + (TYPE_UNSIGNED (exprtype)
> + ? "conversion from %qT to %qT "
> + "changes value from %qE to %qE"
> + : "unsigned conversion from %qT to %qT "
> + "changes value from %qE to %qE"),
> + exprtype, type, expr, result);
> + else
> + warning_at (loc, OPT_Woverflow,
> + (TYPE_UNSIGNED (exprtype)
> + ? "conversion from %qT to %qT "
> + "changes the value of %qE"
> + : "unsigned conversion from %qT to %qT "
> + "changes the value of %qE"),
> + exprtype, type, expr);
> + }
You need to use G_() around both arguments to ?:, otherwise only one will
get extracted for translation.
> diff --git a/gcc/testsuite/c-c++-common/pr68657-1.c
> b/gcc/testsuite/c-c++-common/pr68657-1.c
> index 84f3e54..33fdf86 100644
> --- a/gcc/testsuite/c-c++-common/pr68657-1.c
> +++ b/gcc/testsuite/c-c++-common/pr68657-1.c
> @@ -5,14 +5,14 @@
> void
> f1 (void)
> {
> - unsigned int a = -5; /* { dg-error "negative integer implicitly
> converted to unsigned type" } */
> + unsigned int a = -5; /* { dg-error "unsigned conversion from .int.
> to .unsigned int. changes value from .-5. to .4294967291." } */
The more specific match would fail for targets with 16-bit int. You need
to keep it less specific in this test (if you want to test the more
specific text as well, another test could be added for that, restricted to
the int32 effective-target).
(The changes to Wconversion-real-integer-3.C and
Wconversion-real-integer2.C are OK in that those tests are restricted to
int32plus, although in theory 64-bit int would be an issue there.)
> + /* According to 6.3.1.3 of C11:
> + -3- Otherwise, the new type is signed and the value cannot be
> + represented in it; either the result is implementation-defined
> + or an implementation-defined signal is raised.
> +
> + In GCC such conversios wrap and diagnosed by mentioning "overflow"
> + if the absolut value of the operand is in excess of the maximum of
> + the destination of type, and "conversion" otherwise, as follows: */
s/conversios/conversions/; s/absolut/absolute/
OK with those changes.
--
Joseph S. Myers
jos...@codesourcery.com
Re: [patch, fortran] Handle MATMUL(TRANSPOSE(A),B) in inline matmul
On 05/17/2017 02:41 PM, Thomas Koenig wrote: > Hello world, > > after receiving no negative feedback on my RFC patch, I have deciced > to submit the patch. > > The attached patch handles MATMUL(TRANSPOSE(A),B) in inlining matmul. > Speed is a bit faster than the library version. > > Regression-tested. OK for trunk? > OK and thanks for patch. Jerry
Re: [config PATCH] --enable-languages
On 05/24/2017 09:41 AM, Richard Biener wrote:
Ok. Did you check =all works with/without a host Ada compiler installed?
(warning but not including ada in the without case?)
I checked on a system lacking ada, but I do notice there is no warning,
which seems undesirable.
This patch tweaks things so that 'all' sets add_this_language to 'all'
and we can thus distinguish this mode of enabling it to explicitly
enabling it. in the 'all' case, if it's not permitted, you get a
warning. In the explicit case you'll get an error.
Thus:
configure: WARNING: GNAT is required to build ada
configure: WARNING: --enable-host-shared required to build jit
(you get the fuller JIT error when you explicitly try and enable it.)
I'll commit this version in a few days, if there are no objections.
nathan
--
Nathan Sidwell
2017-05-24 Nathan Sidwell
* configure.ac: Add --enable-languages=default to mean default and
make --enable-languages=all mean all supported languages.
* configure: Regenerated.
gcc/
* doc/invoke.texi (--enable-languages): Update documentation.
Index: configure
===
--- configure (revision 248422)
+++ configure (working copy)
@@ -556,7 +556,6 @@ enable_option_checking=no
ac_subst_vars='LTLIBOBJS
LIBOBJS
compare_exclusions
-host_shared
stage2_werror_flag
stage1_checking
stage1_cflags
@@ -645,6 +644,7 @@ get_gcc_base_ver
extra_host_zlib_configure_flags
extra_host_libiberty_configure_flags
stage1_languages
+host_shared
extra_linker_plugin_flags
extra_linker_plugin_configure_flags
islinc
@@ -781,6 +781,7 @@ enable_isl_version_check
enable_lto
enable_linker_plugin_configure_flags
enable_linker_plugin_flags
+enable_host_shared
enable_stage1_languages
enable_objc_gc
with_target_bdw_gc
@@ -796,7 +797,6 @@ with_build_time_tools
enable_maintainer_mode
enable_stage1_checking
enable_werror
-enable_host_shared
'
ac_precious_vars='build_alias
host_alias
@@ -1498,6 +1498,7 @@ Optional Features:
--enable-linker-plugin-flags=FLAGS
additional flags for configuring and building linker
plugins [none]
+ --enable-host-sharedbuild host code as shared libraries
--enable-stage1-languages[=all]
choose additional languages to build during stage1.
Mostly useful for compiler development
@@ -1515,7 +1516,6 @@ Optional Features:
choose additional checking for stage1 of the
compiler
--enable-werror enable -Werror in bootstrap stage2 and later
- --enable-host-sharedbuild host code as shared libraries
Optional Packages:
--with-PACKAGE[=ARG]use PACKAGE [ARG=yes]
@@ -6090,6 +6090,16 @@ fi
+# Enable --enable-host-shared.
+# Checked early to determine whether jit is an 'all' language
+# Check whether --enable-host-shared was given.
+if test "${enable_host_shared+set}" = set; then :
+ enableval=$enable_host_shared; host_shared=$enableval
+else
+ host_shared=no
+fi
+
+
# By default, C and C++ are the only stage 1 languages.
stage1_languages=,c,
@@ -6108,7 +6118,7 @@ if test -d ${srcdir}/gcc; then
enable_languages="${LANGUAGES}"
echo configure.ac: warning: setting LANGUAGES is deprecated, use --enable-languages instead 1>&2
else
- enable_languages=all
+ enable_languages=default
fi
else
if test x"${enable_languages}" = x ||
@@ -6160,6 +6170,7 @@ if test -d ${srcdir}/gcc; then
for other in ${lang_requires} ${lang_requires_boot_languages}; do
case ,${enable_languages}, in
*,$other,*) ;;
+ *,default,*) ;;
*,all,*) ;;
*,$language,*)
echo " \`$other' language required by \`$language'; enabling" 1>&2
@@ -6171,6 +6182,7 @@ if test -d ${srcdir}/gcc; then
if test "$other" != "c"; then
case ,${enable_stage1_languages}, in
*,$other,*) ;;
+ *,default,*) ;;
*,all,*) ;;
*)
case ,${enable_languages}, in
@@ -6208,7 +6220,7 @@ if test -d ${srcdir}/gcc; then
esac
fi
- missing_languages=`echo ",$enable_languages," | sed -e s/,all,/,/ -e s/,c,/,/ `
+ missing_languages=`echo ",$enable_languages," | sed -e s/,default,/,/ -e s/,all,/,/ -e s/,c,/,/ `
potential_languages=,c,
enabled_target_libs=
@@ -6240,30 +6252,37 @@ if test -d ${srcdir}/gcc; then
fi
add_this_lang=no
-case ,${enable_languages}, in
- *,${language},*)
-# Language was explicitly selected; include it
- # unless it is C, which is enabled by default.
- if test "$language" != "c"; then
+# C is always enabled, so no need to add it again
+if test "$language" != "c"; then
+ case ,${enable_languages}, in
+*,${language},*)
+ # Language was explicitly selected; include it
add_this_lang=yes
- fi
-;;
- *,all,*)
-
Re: [PATCH, ARM/AArch64] drop aarch32 support for falkor/qdf24xx
On 24/05/17 17:03, Jim Wilson wrote: > On Wed, May 24, 2017 at 8:17 AM, Richard Earnshaw (lists) > wrote: >> On 24/05/17 15:18, Jim Wilson wrote: >>> On Wed, May 24, 2017 at 6:56 AM, Richard Earnshaw (lists) >>> wrote: OK. does this need to go in the gcc-8 changes file? >>> >>> Falkor hasn't shipped yet. I'm dropping features that only existed in >>> preproduction NDA hardware, so there isn't anything end user visible, >>> and hence I don't think that it needs to be in the release notes. >>> >>> Jim >>> >> >> Fair enough, so what about a minimal back-port to GCC-7 that just >> disables the CPU name for aarch32? > > Not sure how to do that. If I remove the arm-cpus.in entry, then 5 > files get automatically regenerated. That leaves us with a few minor > inconsistencies in specs handling and multilibs which are harmless but > we may as well fix anyways. The only part of the patch that is > optional if the part which moves the qdf24xx_extra_costs array from > the arm dir to the aarch64 dir. So the minimal patch ends up being > half the size of the original patch, changing 9 of the original 11 > files, which isn't very minimal. > > Another option might be to just remove the documentation and leave the > code in, i.e. only apply the doc/invoke.texi patch. That would be a > small and safe patch. > > Jim > Certainly we should remove it from the documentation. That might be the best idea. I don't really regard the size of the changes to the auto-generated code as being relevant - if we put the generated code directly in the build directory and treated it like we do the output from gen*.c, then those changes would never be even noticed. R.
Re: C++ PATCH to -Wunused with C++17 structured bindings
On Wed, May 24, 2017 at 2:48 AM, Jakub Jelinek wrote: > On Tue, May 23, 2017 at 09:45:10PM -0400, Jason Merrill wrote: >> Someone on IRC complained that there was no way to suppress -Wunused >> on structured bindings. It seemed to me that the way the feature >> works, we shouldn't warn about the bindings individually; users need >> to give each of the subobjects a name even if they're only interested >> in using one of them. >> >> So this patch switches to tracking whether the underlying aggregate >> object as a whole is used; using one of the bindings will avoid any >> warning. >> >> This doesn't apply to tuple structured bindings, since in that case >> the bindings are actual variables rather than aliases to subobjects. > > So, shall we have even for the tuple structured bindings somewhere (in > lang_decl, such as adding struct lang_decl_decomp that would include > lang_decl_min?) the tree for the underlying artificial var decl? That would make sense. Jason
Re: SSA range class and removal of VR_ANTI_RANGEs
On May 24, 2017 5:38:53 PM GMT+02:00, Andrew MacLeod wrote: >On 05/24/2017 04:25 AM, Richard Biener wrote: >> > What's this overflow flag for anyway? > >The new on-demand range calculators do operations on ranges, and that >flag is set when a range calculation may have overflowed... which is of > >use when issuing warnings or deciding to not use a range. >ie given a made up example: > >signed char a,b; >a_1 = b_3 +10; >if (b_3 > 100) foo (a_1) > >on the true side we know b_3 has the range [101,127]. It also >calculates the range of a_1 as [111, 127][-128,-119] and sets the >overflow bit since the calculation of a_1 can overflow for some >elements >of the range of b_3.Anyone wanting to use the range can check the >overflow if its something they care about. The overflow stuff has not >been completely flushed out yet, but it is in place for the moment. we > >can decide down the road if it serves enough purpose to stick around, >or >needs expansion, or whatever. >> > > That said, I think it's the wrong approach to start mucking with >SSA > name associated ranges given they are supposed to be a cheap >storage > variant of what VRP computes. Start by making the VRP >machinery work > from on-demand-ranges. I do have some prototypes from > >last year or > the year before to do this -- the helpers VRP machinery >is already > generic enough if you make use of VRPs range type. > >well its also no longer just contained to VRP. This work is all driven >by the desire of other optimizations to access range information. Some > >have hacked their required bits into vrp, making vrp a sort of mini >optimization phase, others have attempted to leverage assert_exprs at >their point in time (not too successfully I think?) , others just live >with the lack of contextual range info after VRP... after looking at >it, >i decided trying to teach other optimizations about assert_expr in >order >to make their info available later was not something that seemed like a > >good long term solution. > >The most pressing matter was the desire for CFG sensitive range >information outside of VRP. Since assert_exprs are gone after VRP, we >loose the information on the branches of a diamond without a lot of >hackery. That's what my prototype does. I'll dig it out and will send it after public holidays tomorrow. I do not believe in duplicating all the range operations we have in VRP. Richard. The on-demand system is positioned to leave VRP as is for the > >moment, and allow passes outside of VRP to pick up the range info VRP >generated and refine that range based on branches. Once this is >working well, I'd have the confidence to then maybe go into VRP and try > >to replace the assert_exprs with the on demand system. This allows the >proving ground to be outside of VRP for just the passes which are >desperate for better ranges. This allows the on-demand system to be >tested, utilized, and various efficiencies explored without impacting >any optimizations negatively by trying to replace VRP up front and not >getting everything it does or consuming too much compilation time or >memory.. > >I'll shortly prepare the writeup for the on demand mechanism.. I'm >still >getting it working :-P >> > >>> More importantly, when the on-demand range work comes >online >it will end the proliferation of SSA_NAMES which carry ASSERT_EXPR > > information. We won't see the trail of new ssa_names the >ASSET_EXPR chains create. I suspect that will eliminate storing >global ranges and bits for most SSA names, which is likely to make > >this class a win regardless. >>> >>> Are you sure it is desirable to >recompute it in all cases, rather >>> than just use what you have >recorded and recompute what you don't >>> have computed yet? E.g. >various ranges come from if (cond) >>> __builtin_unreachable (); style >asserts, we do want to drop them >>> at some point and the only spot to > >keep that info afterwards is >>> SSA_NAME range info. >> >> >> I think >it will be desirable in most cases. The on-demand system >> does *not* > >use assert_exprs. It will make them mostly obsolete, >> and the goal >is to eventually eliminate them from the IL >> completely. > > They are > >not in the IL. They are only temporarily there during VRP > (not early > >VRP for example) to make VRP work as a SSA propagation > pass. > >right but a number of other optimization want the contextual >information >assert_expr's provide.. outside of VRP. so either we have to keep the >multitude of ssa_names that asset_exprs create in order to maintain the > >range info, either via copies or maintaining the assert_expr, or we do >something else. > >>> Most assert_exprs exist to provide ranges on sub-branches of the >> >CFG. These we are likely to be able to simply replace with the >> >on-demand mechanism. I suspect we'll find some cases where we find >> >its more useful to have a new global ssa_name
Re: [PATCH, ARM/AArch64] drop aarch32 support for falkor/qdf24xx
On Wed, May 24, 2017 at 8:17 AM, Richard Earnshaw (lists) wrote: > On 24/05/17 15:18, Jim Wilson wrote: >> On Wed, May 24, 2017 at 6:56 AM, Richard Earnshaw (lists) >> wrote: >>> OK. does this need to go in the gcc-8 changes file? >> >> Falkor hasn't shipped yet. I'm dropping features that only existed in >> preproduction NDA hardware, so there isn't anything end user visible, >> and hence I don't think that it needs to be in the release notes. >> >> Jim >> > > Fair enough, so what about a minimal back-port to GCC-7 that just > disables the CPU name for aarch32? Not sure how to do that. If I remove the arm-cpus.in entry, then 5 files get automatically regenerated. That leaves us with a few minor inconsistencies in specs handling and multilibs which are harmless but we may as well fix anyways. The only part of the patch that is optional if the part which moves the qdf24xx_extra_costs array from the arm dir to the aarch64 dir. So the minimal patch ends up being half the size of the original patch, changing 9 of the original 11 files, which isn't very minimal. Another option might be to just remove the documentation and leave the code in, i.e. only apply the doc/invoke.texi patch. That would be a small and safe patch. Jim
[C++ PATCH] Hidden name removal
Now that overloads are kept ordered, I can replace the existing
remove_hidden_names fn with ovl_skip_hidden.
The former works by scanning the overloads, then if it discovers a
hidden one, copying the list (from the beginning) omitting the hidden
ones. Now, overloads aren't usually huge, but this forces scanning on
every lookup, and is O(N^2), so bad. ovl_skip_hidden simply drops the
OVL_HIDDEN_P nodes at the start of an overload. Often doing nothing.
For extra badness, lookup_name_real was applying remove_hidden_names to
a result that had already had it run!
Applied to trunk.
nathan
--
Nathan Sidwell
2017-05-24 Nathan Sidwell
* cp-tree.h (ovl_skip_hidden): Declare.
* tree.c (ovl_skip_hidden): New.
* name-lookup.c (arg_assoc_namespace): Call ovl_skip_hidden.
(lookup_arg_dependent_1): Likewise.
(ambiguous_decl): Use DECL_HIDDEN_P, ovl_skip_hidden.
(hidden_name_p, remove_hidden_names): Delete.
(lookup_name_real_1): Do not strip hidden names.
* name-lookup.h (hidden_name_p, remove_hidden_names): Delete.
Index: cp/cp-tree.h
===
--- cp/cp-tree.h (revision 248422)
+++ cp/cp-tree.h (working copy)
@@ -6852,6 +6852,7 @@ extern tree ovl_make(tree fn,
tree next = NULL_TREE);
extern tree ovl_insert(tree fn, tree maybe_ovl,
bool using_p = false);
+extern tree ovl_skip_hidden (tree);
extern tree lookup_add(tree fns, tree lookup);
extern void lookup_keep(tree lookup, bool keep);
extern int is_overloaded_fn (tree);
Index: cp/name-lookup.c
===
--- cp/name-lookup.c (revision 248422)
+++ cp/name-lookup.c (working copy)
@@ -275,14 +275,10 @@ arg_assoc_namespace (struct arg_lookup *
if (!value)
return false;
+ value = ovl_skip_hidden (value);
+
for (; value; value = OVL_NEXT (value))
{
- /* We don't want to find arbitrary hidden functions via argument
- dependent lookup. We only want to find friends of associated
- classes, which we'll do via arg_assoc_class. */
- if (hidden_name_p (OVL_CURRENT (value)))
- continue;
-
if (add_function (k, OVL_CURRENT (value)))
return true;
}
@@ -630,7 +626,7 @@ lookup_arg_dependent_1 (tree name, tree
/* Remove any hidden friend functions from the list of functions
found so far. They will be added back by arg_assoc_class as
appropriate. */
- fns = remove_hidden_names (fns);
+ fns = ovl_skip_hidden (fns);
k.name = name;
k.args = args;
@@ -4347,7 +4343,7 @@ ambiguous_decl (struct scope_binding *ol
/* Copy the type. */
type = new_binding->type;
if (LOOKUP_NAMESPACES_ONLY (flags)
- || (type && hidden_name_p (type) && !(flags & LOOKUP_HIDDEN)))
+ || (type && !(flags & LOOKUP_HIDDEN) && DECL_HIDDEN_P (type)))
type = NULL_TREE;
/* Copy the value. */
@@ -4355,7 +4351,7 @@ ambiguous_decl (struct scope_binding *ol
if (val)
{
if (!(flags & LOOKUP_HIDDEN))
- val = remove_hidden_names (val);
+ val = ovl_skip_hidden (val);
if (val)
switch (TREE_CODE (val))
{
@@ -4465,59 +4461,6 @@ qualify_lookup (tree val, int flags)
return true;
}
-/* Given a lookup that returned VAL, decide if we want to ignore it or
- not based on DECL_ANTICIPATED. */
-
-bool
-hidden_name_p (tree val)
-{
- if (DECL_P (val)
- && DECL_LANG_SPECIFIC (val)
- && TYPE_FUNCTION_OR_TEMPLATE_DECL_P (val)
- && DECL_ANTICIPATED (val))
-return true;
- if (TREE_CODE (val) == OVERLOAD)
-{
- for (tree o = val; o; o = OVL_CHAIN (o))
- if (!hidden_name_p (OVL_FUNCTION (o)))
- return false;
- return true;
-}
- return false;
-}
-
-/* Remove any hidden declarations from a possibly overloaded set
- of functions. */
-
-tree
-remove_hidden_names (tree fns)
-{
- if (!fns)
-return fns;
-
- if (DECL_P (fns) && hidden_name_p (fns))
-fns = NULL_TREE;
- else if (TREE_CODE (fns) == OVERLOAD)
-{
- tree o;
-
- for (o = fns; o; o = OVL_NEXT (o))
- if (hidden_name_p (OVL_CURRENT (o)))
- break;
- if (o)
- {
- tree n = NULL_TREE;
-
- for (o = fns; o; o = OVL_NEXT (o))
- if (!hidden_name_p (OVL_CURRENT (o)))
- n = lookup_add (OVL_CURRENT (o), n);
- fns = n;
- }
-}
-
- return fns;
-}
-
/* Suggest alternatives for NAME, an IDENTIFIER_NODE for which name
lookup failed. Search through all available namespaces and print out
possible candidates. If no exact matches are found, and
@@ -5337,10 +5280,6 @@ lookup_name_real_1 (tree name, int prefe
if (!val)
val = unqualified_namespace_lookup (name, flags);
- /* Anticipated built-ins and friends aren't found by normal lookup. */
- if (val && !(flags & LOOKUP_HIDDEN))
-val = remove_hidden_names (val);
-
/* If we have a single function from a using decl, pull it out. */
if (val && TREE_CODE (val) == OVERLOAD && !really_overloaded_fn (val))
val = OVL_FUNCTION (val);
Inde
Re: SSA range class and removal of VR_ANTI_RANGEs
stlll bounced.. html must have snuck in somewhere, and the mailer sent it anyway -P trying again... On 05/24/2017 11:38 AM, Andrew MacLeod wrote: On 05/24/2017 04:25 AM, Richard Biener wrote: >> What's this overflow flag for anyway? The new on-demand range calculators do operations on ranges, and that flag is set when a range calculation may have overflowed... which is of use when issuing warnings or deciding to not use a range. ie given a made up example: signed char a,b; a_1 = b_3 +10; if (b_3 > 100) foo (a_1) on the true side we know b_3 has the range [101,127]. It also calculates the range of a_1 as [111, 127][-128,-119] and sets the overflow bit since the calculation of a_1 can overflow for some elements of the range of b_3.Anyone wanting to use the range can check the overflow if its something they care about. The overflow stuff has not been completely flushed out yet, but it is in place for the moment. we can decide down the road if it serves enough purpose to stick around, or needs expansion, or whatever. >> > That said, I think it's the wrong approach to start mucking with SSA > name associated ranges given they are supposed to be a cheap storage > variant of what VRP computes. Start by making the VRP machinery work > from on-demand-ranges. I do have some prototypes from last year or > the year before to do this -- the helpers VRP machinery is already > generic enough if you make use of VRPs range type. well its also no longer just contained to VRP. This work is all driven by the desire of other optimizations to access range information. Some have hacked their required bits into vrp, making vrp a sort of mini optimization phase, others have attempted to leverage assert_exprs at their point in time (not too successfully I think?) , others just live with the lack of contextual range info after VRP... after looking at it, i decided trying to teach other optimizations about assert_expr in order to make their info available later was not something that seemed like a good long term solution. The most pressing matter was the desire for CFG sensitive range information outside of VRP. Since assert_exprs are gone after VRP, we loose the information on the branches of a diamond without a lot of hackery. The on-demand system is positioned to leave VRP as is for the moment, and allow passes outside of VRP to pick up the range info VRP generated and refine that range based on branches. Once this is working well, I'd have the confidence to then maybe go into VRP and try to replace the assert_exprs with the on demand system. This allows the proving ground to be outside of VRP for just the passes which are desperate for better ranges. This allows the on-demand system to be tested, utilized, and various efficiencies explored without impacting any optimizations negatively by trying to replace VRP up front and not getting everything it does or consuming too much compilation time or memory.. I'll shortly prepare the writeup for the on demand mechanism.. I'm still getting it working :-P >> >>> More importantly, when the on-demand range work comes online it will end the proliferation of SSA_NAMES which carry ASSERT_EXPR information. We won't see the trail of new ssa_names the ASSET_EXPR chains create. I suspect that will eliminate storing global ranges and bits for most SSA names, which is likely to make this class a win regardless. >>> >>> Are you sure it is desirable to recompute it in all cases, rather >>> than just use what you have recorded and recompute what you don't >>> have computed yet? E.g. various ranges come from if (cond) >>> __builtin_unreachable (); style asserts, we do want to drop them >>> at some point and the only spot to keep that info afterwards is >>> SSA_NAME range info. >> >> >> I think it will be desirable in most cases. The on-demand system >> does *not* use assert_exprs. It will make them mostly obsolete, >> and the goal is to eventually eliminate them from the IL >> completely. > > They are not in the IL. They are only temporarily there during VRP > (not early VRP for example) to make VRP work as a SSA propagation > pass. right but a number of other optimization want the contextual information assert_expr's provide.. outside of VRP. so either we have to keep the multitude of ssa_names that asset_exprs create in order to maintain the range info, either via copies or maintaining the assert_expr, or we do something else. >> Most assert_exprs exist to provide ranges on sub-branches of the >> CFG. These we are likely to be able to simply replace with the >> on-demand mechanism. I suspect we'll find some cases where we find >> its more useful to have a new global ssa_name which carries >> information, but I expect the situation which requires that to be >> fairly rare. >> >> There will be a cycle where I have to identify cases we missing and >> catch those...
Re: [PATCH] Fix PR80754
On 05/17/2017 07:32 AM, Wilco Dijkstra wrote: When lra-remat rematerializes an instruction with a clobber, it checks that the clobber does not kill live registers. However it fails to check that the clobber also doesn't overlap with the destination register of the final rematerialized instruction. As a result it is possible to generate illegal instructions with the same hard register as the destination and a clobber. Fix this by also checking for overlaps with the destination register. Bootstrap OK on arm-linux-gnueabihf for ARM and Thumb-2, OK for commit? Wilco, thank you for working on the PR. The patch looks OK for me. You can commit it into the trunk and gcc7 branch.
Re: [PATCH, ARM/AArch64] drop aarch32 support for falkor/qdf24xx
On 24/05/17 15:18, Jim Wilson wrote: > On Wed, May 24, 2017 at 6:56 AM, Richard Earnshaw (lists) > wrote: >> OK. does this need to go in the gcc-8 changes file? > > Falkor hasn't shipped yet. I'm dropping features that only existed in > preproduction NDA hardware, so there isn't anything end user visible, > and hence I don't think that it needs to be in the release notes. > > Jim > Fair enough, so what about a minimal back-port to GCC-7 that just disables the CPU name for aarch32? R.
Re: C++ PATCH to add __integer_pack built-in for std::make_integer_sequence (c++/80396)
On Wed, May 24, 2017 at 04:16:30PM +0200, Andreas Schwab wrote:
> FAIL: g++.dg/ext/integer-pack2.C -std=gnu++11 (test for excess errors)
> Excess errors:
> /daten/aranym/gcc/gcc-20170524/gcc/testsuite/g++.dg/ext/integer-pack2.C:10:48:
> error: overflow in constant expression [-fpermissive]
> /daten/aranym/gcc/gcc-20170524/gcc/testsuite/g++.dg/ext/integer-pack2.C:10:48:
> error: overflow in constant expression [-fpermissive]
To be precise, it fails only on 32-bit targets.
If we at that point want some wider integer that when cast to int
is 0 (or small enough positive number?), shall we use something like
this, or say 1LL << (sizeof (int) * __CHAR_BIT__), or 2LL * INT_MIN,
something else? Do we need to include ? Or can we replace
INT_MAX with __INT_MAX__?
Not sure about that -2147483650 for 16-bit int targets (perhaps the test can
be guarded with int32 effective target).
2017-05-24 Jakub Jelinek
* g++.dg/ext/integer-pack2.C (w): Use -9223372036854775807LL - 1
instead of -9223372036854775808.
--- gcc/testsuite/g++.dg/ext/integer-pack2.C.jj 2017-05-24 11:59:01.0
+0200
+++ gcc/testsuite/g++.dg/ext/integer-pack2.C2017-05-24 16:24:18.341421124
+0200
@@ -7,6 +7,6 @@ template struct intege
template
using make_integer_sequence = integer_sequence; //
{ dg-error "argument" }
-make_integer_sequence w;
+make_integer_sequence w;
make_integer_sequence x;// { dg-message "required" }
make_integer_sequence y; // { dg-message "required" }
Jakub
Re: Reorganise machmode.h headers
Jeff Law writes: > On 11/16/2016 09:32 AM, Richard Sandiford wrote: >> Later patches will make machmode.h rely on wide-int.h and the >> new poly-int.h, so it needs to appear later in the coretypes.h >> include list. >> >> Previously machmode.h included insn-modes.h, which as well as >> the main mode enum contains configuration information like >> MAX_BITSIZE_MODE_ANY_INT. This still needs to come first, >> since files like wide-int.h depend on the configuration >> information. >> >> Similarly, later patches will make the auto-generated inline >> mode size functions use poly-int.h, so the patch splits them >> out into their own header file and includes it after the >> integer utilities. >> >> The patch also makes the generator files include machmode.h >> via coretypes.h. Previously they did it by more indirect means. >> >> Finally, the patch makes wide-int-print.h available via coretypes.h >> too. There didn't seem to be any reason to force only the print >> routines to be included directly, and it would be painful to extend >> that approach to the new polynomial integer classes. >> >> Tested on aarch64-linux-gnu and x86_64-linux-gnu. OK to install? >> >> Thanks, >> Richard >> >> >> [ This patch is part of the SVE series posted here: >> https://gcc.gnu.org/ml/gcc/2016-11/msg00030.html ] >> >> gcc/ >> 2016-11-16 Richard Sandiford >> Alan Hayward >> David Sherwood >> >> * Makefile.in (MACHMODE_H): Remove insn-modes.h >> (CORETYPES_H): New define. >> (MOSTLYCLEANFILES): Add insn-modes-inline.h. >> (insn-modes-inline.h, s-modes-inline-h): New rules. >> (generated_files): Add insn-modes-inline.h. >> (RTL_BASE_H, TREE_CORE_H): Use CORETYPES_H instead of coretypes.h. >> (build/gensupport.o, build/print-rtl.o, build/read-md.o): Likewise. >> (build/read-rtl.o, build/rtl.o, build/vec.o, build/hash-table.o) >> (build/inchash.o, build/gencondmd.o, build/genattr.o): Likewise. >> (build/genattr-common.o, build/genattrtab.o, build/genautomata.o) >> (build/gencheck.o, build/gencodes.o, build/genconditions.o): Likewise. >> (build/genconfig.o, build/genconstants.o, build/genemit.o): Likewise. >> (build/genenums.o, build/genextract.o, build/genflags.o): Likewise. >> (build/gentarget-def.o, build/genmddeps.o, build/genopinit.o) >> (build/genoutput.o, build/genpeep.o, build/genpreds.o): Likewise. >> (build/genrecog.o, build/genmddump.o, build/genmatch.o): Likewise. >> (build/gencfn-macros.o, build/gcov-iov.o): Likewise. >> * coretypes.h: Include everything up to real.h for generators. >> Include insn-modes.h first. Include wide-int-print.h after >> wide-int.h. Include insn-modes-inline.h and then machmode.h. >> * machmode.h: Don't include insn-modes.h here. >> * function-tests.c: Remove includes of signop.h, machmode.h, >> double-int.h and wide-int.h. >> * rtl.h: Likewise. >> * gcc-rich-location.c: Remove includes of machmode.h, double-int.h >> and wide-int.h. >> * optc-save-gen.awk: Likewise. >> * gencheck.c (BITS_PER_UNIT): Delete dummy definition. >> * godump.c: Remove include of wide-int-print.h. >> * pretty-print.h: Likewise. >> * wide-int-print.cc: Likewise. >> * wide-int.cc: Likewise. >> * hash-map-tests.c: Remove include of signop.h. >> * hash-set-tests.c: Likewise. >> * rtl-tests.c: Likewise. >> * mkconfig.sh: Remove include of machmode.h. >> * genmodes.c (emit_insn_modes_h): Split emission of inline functions >> into... >> (emit_insn_modes_inline_h): ...this new function. Emit the code >> into an insn-modes-inline.h header file, adding appropriate >> include guards and end comments. >> (emit_insn_modes_c_header): Remove include of machmode.h. >> (emit_min_insn_modes_c_header): Include coretypes.h rather than >> machmode.h. >> (main): Handle -i flag and call emit_insn_modes_inline_h when >> it is passed. > So I don't see anything here particularly problematical. My question is > whether or not there's anything significant to be gained to moving > forward with this kit, assuming the 67 piece kit is not likely to move > forward. > > I do think you'll need some tweaks to the contrib/header-tools which > know about the core headers and dependencies. Hopefully what's in there > is easy enough to figure out how to twiddle appropriately. OK, thanks for the pointer. I think this patch should do that. gcc-order-headers seems to have bitrotted a bit, since it gives: Traceback (most recent call last): File "../contrib/header-tools/gcc-order-headers", line 267, in process_known_dups () File "../contrib/header-tools/gcc-order-headers", line 101, in process_known_dups if dups[i] and "rtl.h" in dups[i]: KeyError: 'dumpfile.h' But the change itself looks obvious. Tested on aarch64-linux-gnu and x86_64-linux-gnu. Also tested by compiling one target
Re: [PATCH] rs6000: Fix for separate shrink-wrapping for fp (PR80860, PR80843)
On Tue, May 23, 2017 at 11:07:07AM +, Segher Boessenkool wrote:
> After my r248256, rs6000_components_for_bb allocates an sbitmap of size
> only 32 while it can use up to 64. This patch fixes it. It moves the
> n_components variable into the machine_function struct so that other
> hooks can use it.
>
> Tested on powerpc64-linux {-m32,-m64}. Will also test on AIX before
> committing.
This fixed the AIX problem (PR80860). I have committed this now.
Segher
Update libstdc++ baseline symbols (ia64, m68k)
Committed. Andreas. * config/abi/post/ia64-linux-gnu/baseline_symbols.txt: Update. * config/abi/post/m68k-linux-gnu/baseline_symbols.txt: Likewise. diff --git a/libstdc++-v3/config/abi/post/ia64-linux-gnu/baseline_symbols.txt b/libstdc++-v3/config/abi/post/ia64-linux-gnu/baseline_symbols.txt index 3b8dc79d98..0b166d5e2a 100644 --- a/libstdc++-v3/config/abi/post/ia64-linux-gnu/baseline_symbols.txt +++ b/libstdc++-v3/config/abi/post/ia64-linux-gnu/baseline_symbols.txt @@ -444,6 +444,7 @@ FUNC:_ZNKSt13basic_fstreamIwSt11char_traitsIwEE7is_openEv@GLIBCXX_3.4 FUNC:_ZNKSt13basic_istreamIwSt11char_traitsIwEE6gcountEv@@GLIBCXX_3.4 FUNC:_ZNKSt13basic_istreamIwSt11char_traitsIwEE6sentrycvbEv@@GLIBCXX_3.4 FUNC:_ZNKSt13basic_ostreamIwSt11char_traitsIwEE6sentrycvbEv@@GLIBCXX_3.4 +FUNC:_ZNKSt13random_device13_M_getentropyEv@@GLIBCXX_3.4.24 FUNC:_ZNKSt13runtime_error4whatEv@@GLIBCXX_3.4 FUNC:_ZNKSt14basic_ifstreamIcSt11char_traitsIcEE5rdbufEv@@GLIBCXX_3.4 FUNC:_ZNKSt14basic_ifstreamIcSt11char_traitsIcEE7is_openEv@@GLIBCXX_3.4.5 @@ -1329,6 +1330,7 @@ FUNC:_ZNSbIwSt11char_traitsIwESaIwEEC1EPKwRKS1_@@GLIBCXX_3.4 FUNC:_ZNSbIwSt11char_traitsIwESaIwEEC1EPKwmRKS1_@@GLIBCXX_3.4 FUNC:_ZNSbIwSt11char_traitsIwESaIwEEC1ERKS1_@@GLIBCXX_3.4 FUNC:_ZNSbIwSt11char_traitsIwESaIwEEC1ERKS2_@@GLIBCXX_3.4 +FUNC:_ZNSbIwSt11char_traitsIwESaIwEEC1ERKS2_mRKS1_@@GLIBCXX_3.4.23 FUNC:_ZNSbIwSt11char_traitsIwESaIwEEC1ERKS2_mm@@GLIBCXX_3.4 FUNC:_ZNSbIwSt11char_traitsIwESaIwEEC1ERKS2_mmRKS1_@@GLIBCXX_3.4 FUNC:_ZNSbIwSt11char_traitsIwESaIwEEC1ESt16initializer_listIwERKS1_@@GLIBCXX_3.4.11 @@ -1342,6 +1344,7 @@ FUNC:_ZNSbIwSt11char_traitsIwESaIwEEC2EPKwRKS1_@@GLIBCXX_3.4 FUNC:_ZNSbIwSt11char_traitsIwESaIwEEC2EPKwmRKS1_@@GLIBCXX_3.4 FUNC:_ZNSbIwSt11char_traitsIwESaIwEEC2ERKS1_@@GLIBCXX_3.4 FUNC:_ZNSbIwSt11char_traitsIwESaIwEEC2ERKS2_@@GLIBCXX_3.4 +FUNC:_ZNSbIwSt11char_traitsIwESaIwEEC2ERKS2_mRKS1_@@GLIBCXX_3.4.23 FUNC:_ZNSbIwSt11char_traitsIwESaIwEEC2ERKS2_mm@@GLIBCXX_3.4 FUNC:_ZNSbIwSt11char_traitsIwESaIwEEC2ERKS2_mmRKS1_@@GLIBCXX_3.4 FUNC:_ZNSbIwSt11char_traitsIwESaIwEEC2ESt16initializer_listIwERKS1_@@GLIBCXX_3.4.11 @@ -1580,6 +1583,7 @@ FUNC:_ZNSsC1EPKcRKSaIcE@@GLIBCXX_3.4 FUNC:_ZNSsC1EPKcmRKSaIcE@@GLIBCXX_3.4 FUNC:_ZNSsC1ERKSaIcE@@GLIBCXX_3.4 FUNC:_ZNSsC1ERKSs@@GLIBCXX_3.4 +FUNC:_ZNSsC1ERKSsmRKSaIcE@@GLIBCXX_3.4.23 FUNC:_ZNSsC1ERKSsmm@@GLIBCXX_3.4 FUNC:_ZNSsC1ERKSsmmRKSaIcE@@GLIBCXX_3.4 FUNC:_ZNSsC1ESt16initializer_listIcERKSaIcE@@GLIBCXX_3.4.11 @@ -1593,6 +1597,7 @@ FUNC:_ZNSsC2EPKcRKSaIcE@@GLIBCXX_3.4 FUNC:_ZNSsC2EPKcmRKSaIcE@@GLIBCXX_3.4 FUNC:_ZNSsC2ERKSaIcE@@GLIBCXX_3.4 FUNC:_ZNSsC2ERKSs@@GLIBCXX_3.4 +FUNC:_ZNSsC2ERKSsmRKSaIcE@@GLIBCXX_3.4.23 FUNC:_ZNSsC2ERKSsmm@@GLIBCXX_3.4 FUNC:_ZNSsC2ERKSsmmRKSaIcE@@GLIBCXX_3.4 FUNC:_ZNSsC2ESt16initializer_listIcERKSaIcE@@GLIBCXX_3.4.11 @@ -2232,6 +2237,7 @@ FUNC:_ZNSt15_List_node_base8transferEPS_S0_@@GLIBCXX_3.4 FUNC:_ZNSt15_List_node_base9_M_unhookEv@@GLIBCXX_3.4.14 FUNC:_ZNSt15__exception_ptr13exception_ptr4swapERS0_@@CXXABI_1.3.3 FUNC:_ZNSt15__exception_ptr13exception_ptrC1EMS0_FvvE@@CXXABI_1.3.3 +FUNC:_ZNSt15__exception_ptr13exception_ptrC1EPv@@CXXABI_1.3.11 FUNC:_ZNSt15__exception_ptr13exception_ptrC1ERKS0_@@CXXABI_1.3.3 FUNC:_ZNSt15__exception_ptr13exception_ptrC1Ev@@CXXABI_1.3.3 FUNC:_ZNSt15__exception_ptr13exception_ptrC2EMS0_FvvE@@CXXABI_1.3.3 @@ -2777,9 +2783,9 @@ FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE10_M_disposeEv@@GLIBCX FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE10_M_replaceEmmPKcm@@GLIBCXX_3.4.21 FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE10_S_compareEmm@@GLIBCXX_3.4.21 FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE11_M_capacityEm@@GLIBCXX_3.4.21 -FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_Alloc_hiderC1EPcOS3_@@GLIBCXX_3.4.21 +FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_Alloc_hiderC1EPcOS3_@@GLIBCXX_3.4.23 FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_Alloc_hiderC1EPcRKS3_@@GLIBCXX_3.4.21 -FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_Alloc_hiderC2EPcOS3_@@GLIBCXX_3.4.21 +FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_Alloc_hiderC2EPcOS3_@@GLIBCXX_3.4.23 FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_Alloc_hiderC2EPcRKS3_@@GLIBCXX_3.4.21 FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_M_constructEmc@@GLIBCXX_3.4.21 FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_M_constructIN9__gnu_cxx17__normal_iteratorIPKcS4_vT_SB_St20forward_iterator_tag@@GLIBCXX_3.4.21 @@ -2878,6 +2884,7 @@ FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEC1EPKcmRKS3_@@GLIBCXX_ FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEC1ERKS3_@@GLIBCXX_3.4.21 FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEC1ERKS4_@@GLIBCXX_3.4.21 FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEC1ERKS4_RKS3_@@GLIBCXX_3.4.21 +FUNC:_ZNSt7__cxx1112basic
Re: [0/67] Add wrapper classes for machine_modes
Jeff Law writes: > On 12/09/2016 05:48 AM, Richard Sandiford wrote: >> This series includes most of the changes in group C from: >> >> https://gcc.gnu.org/ml/gcc/2016-11/msg00033.html >> >> The idea is to add wrapper classes around machine_mode_enum >> for specific groups of modes, such as scalar integers, scalar floats, >> complex values, etc. This has two main benefits: one specific to SVE >> and one not. >> >> The SVE-specific benefit is that it helps to introduce the concept >> of variable-length vectors. To do that we need to change the size >> of a vector mode from being a known compile-time constant to being >> (possibly) a run-time invariant. We then need to do the same for >> unconstrained machine_modes, which might or might not be vectors. >> Introducing these new constrained types means that we can continue >> to treat them as having a constant size. >> >> The other benefit is that it uses static type checking to enforce >> conditions that are easily forgotten otherwise. The most common >> sources of problems seem to be: >> >> (a) using VOIDmode or BLKmode where a scalar integer was expected >> (e.g. when getting the number of bits in the value). >> >> (b) simplifying vector operations in ways that only make sense for >> scalars. >> >> The series helps with both of these, although we don't get the full >> benefit of (b) until variable-sized modes are introduced. >> >> I know of three specific cases in which the static type checking >> forced fixes for things that turned out to be real bugs (although >> we didn't know that at the time, otherwise we'd have posted patches). >> They were later fixed for trunk by: >> >>https://gcc.gnu.org/ml/gcc-patches/2016-07/msg01783.html >>https://gcc.gnu.org/ml/gcc-patches/2016-11/msg02983.html >>https://gcc.gnu.org/ml/gcc-patches/2016-11/msg02896.html >> >> The group C patches in ARM/sve-branch did slow compile time down a little. >> I've since taken steps to avoid that: >> >> - Make the tailcall pass handle aggregate parameters and return values >>(already in trunk). >> >> - Turn some of the new wrapper functions into inline functions. >> >> - Make all the machmode.h macros that used: >> >> __builtin_constant_p (M) ? foo_inline (M) : foo_array[M[ >> >>forward to an ALWAYS_INLINE function, so that (a) M is only evaluated >>once and (b) __builtin_constant_p is applied to a variable, and so is >>deferred until later passes. This helped the optimisation to fire in >>more cases and to continue firing when M is a class rather than a >>raw enum. >> >> - In a similar vein, make sure that conditions like: >> >> SImode == DImode >> >>are treated as builtin_constant_p by gencondmd, so that .md patterns >>with those conditions are dropped. >> >> With these changes the series is actually a very slight compile-time win. >> That might seem unlikely, but there are several possible reasons: >> >> 1. The machmode.h macro change above might allow more constant folding. >> >> 2. The series has a tendency to evaluate modes once, rather than >> continually fetching them from (sometimes quite deep) rtx nests. >> Refetching a mode is a particular problem if call comes between >> two uses, since the compiler then has to re-evaluate the whole thing. >> >> 3. The series introduces many uses of new SCALAR_*TYPE_MODE macros, >> as alternatives to TYPE_MODE. The new macros avoid the usual: >> >> (VECTOR_TYPE_P (TYPE_CHECK (NODE)) \ >>? vector_type_mode (NODE) : (NODE)->type_common.mode) >> >> and become direct field accesses in release builds. >> >> VECTOR_TYPE_P would be consistently false for these uses, >> but call-clobbered registers would usually be treated as clobbered >> by the condition as a whole. >> >> Maybe (3) is the most likely reason. >> >> I tested this by compiling the testsuite for: >> >> aarch64-linux-gnu alpha-linux-gnu arc-elf arm-linux-gnueabi >> arm-linux-gnueabihf avr-elf bfin-elf c6x-elf cr16-elf cris-elf >> epiphany-elf fr30-elf frv-linux-gnu ft32-elf h8300-elf >> hppa64-hp-hpux11.23 ia64-linux-gnu i686-pc-linux-gnu >> i686-apple-darwin iq2000-elf lm32-elf m32c-elf m32r-elf >> m68k-linux-gnu mcore-elf microblaze-elf mips-linux-gnu >> mipsisa64-linux-gnu mmix mn10300-elf moxie-rtems msp430-elf >> nds32le-elf nios2-linux-gnu nvptx-none pdp11 powerpc-linux-gnuspe >> powerpc-eabispe powerpc64-linux-gnu powerpc-ibm-aix7.0 rl78-elf >> rx-elf s390-linux-gnu s390x-linux-gnu sh-linux-gnu sparc-linux-gnu >> sparc64-linux-gnu sparc-wrs-vxworks spu-elf tilegx-elf tilepro-elf >> xstormy16-elf v850-elf vax-netbsdelf visium-elf x86_64-darwin >> x86_64-linux-gnu xtensa-elf >> >> and checking that there were no changes in assembly. Also tested >> in the normal way on aarch64-linux-gnu and x86_64-linux-gnu. >> >> The series depends on the already-posted: >> >>htt
Re: [PATCH] PR c++/80544 strip cv-quals from cast results
On 23/05/17 16:26 -0400, Jason Merrill wrote:
On Tue, May 23, 2017 at 2:00 PM, Jonathan Wakely wrote:
On 19/05/17 15:14 -0400, Jason Merrill wrote:
On Thu, Apr 27, 2017 at 12:59 PM, Jonathan Wakely
wrote:
I also tried to add a warning like EDG's (see the PR) but it gave a
false positive for direct-list-init of scoped enums (P0138R2, r240449)
because that code goes through build_c_cast to perform the conversion,
so looks like a cast to my new warning.
The enum init code could strip the cv-quals when calling build_c_cast
to avoid the warning.
Thanks, that works. I don't think this warning fits under any existing
option, so I'll add a new one. -Wuseless-cast-qual maybe? Or is that
too close to -Wuseless-cast and -Wcast-qual and would cause confusion?
-Wcast-rvalue-qual ?
I realised that -Wignored-qualifiers is a good fit. That warns about
ignored cv-qualifiers on return types, which is a very similar case.
This patch adds a new function to conditionally warn and calls that
from the build_*_cast functions after they produce a valid result. I
originally put the warnings next to the cv_unqualified calls that
strip the quals, but was getting duplicate warnings when build_cp_cast
calls more than one of the build_*_cast_1 functions.
This also removes the unnecessary check for reference types that
Nathan pointed out.
Tested x86_64-linux and powerpc64-linux. OK for trunk?
commit dddbdfbdc8de6565b45a6d794148dfe077d83d49
Author: Jonathan Wakely
Date: Wed May 24 14:09:36 2017 +0100
PR c++/80544 strip cv-quals from cast results
gcc/cp:
PR c++/80544
* tree.c (reshape_init): Use unqualified type for direct enum init.
* typeck.c (maybe_warn_about_cast_ignoring_quals): New.
(build_static_cast_1, build_reinterpret_cast_1): Strip cv-quals from
non-class destination types.
(build_const_cast_1): Strip cv-quals from destination types.
(build_static_cast, build_reinterpret_cast, build_const_cast)
(cp_build_c_cast): Add calls to maybe_warn_about_cast_ignoring_quals.
gcc/testsuite:
PR c++/80544
* g++.dg/expr/cast11.C: New test.
diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index afd47bb..3ff0130 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -6043,6 +6043,7 @@ reshape_init (tree type, tree init, tsubst_flags_t complain)
if (is_direct_enum_init (type, init))
{
tree elt = CONSTRUCTOR_ELT (init, 0)->value;
+ type = cv_unqualified (type);
if (check_narrowing (ENUM_UNDERLYING_TYPE (type), elt, complain))
return cp_build_c_cast (type, elt, tf_warning_or_error);
else
diff --git a/gcc/cp/typeck.c b/gcc/cp/typeck.c
index 13d90a6..ecc7190 100644
--- a/gcc/cp/typeck.c
+++ b/gcc/cp/typeck.c
@@ -6673,6 +6673,22 @@ maybe_warn_about_useless_cast (tree type, tree expr, tsubst_flags_t complain)
}
}
+/*
+ Warns if the cast ignores cv-qualifiers on TYPE.
+ */
+void
+maybe_warn_about_cast_ignoring_quals (tree type, tsubst_flags_t complain)
+{
+ if (warn_ignored_qualifiers
+ && complain & tf_warning
+ && !CLASS_TYPE_P (type)
+ && (cp_type_quals (type) & (TYPE_QUAL_CONST|TYPE_QUAL_VOLATILE)))
+{
+ warning (OPT_Wignored_qualifiers, "type qualifiers ignored on cast "
+ "result type");
+}
+}
+
/* Convert EXPR (an expression with pointer-to-member type) to TYPE
(another pointer-to-member type in the same hierarchy) and return
the converted expression. If ALLOW_INVERSE_P is permitted, a
@@ -6746,6 +6762,10 @@ build_static_cast_1 (tree type, tree expr, bool c_cast_p,
/* Save casted types in the function's used types hash table. */
used_types_insert (type);
+ /* A prvalue of non-class type is cv-unqualified. */
+ if (!CLASS_TYPE_P (type))
+type = cv_unqualified (type);
+
/* [expr.static.cast]
An lvalue of type "cv1 B", where B is a class type, can be cast
@@ -7035,7 +7055,10 @@ build_static_cast (tree type, tree expr, tsubst_flags_t complain)
if (valid_p)
{
if (result != error_mark_node)
- maybe_warn_about_useless_cast (type, expr, complain);
+ {
+ maybe_warn_about_useless_cast (type, expr, complain);
+ maybe_warn_about_cast_ignoring_quals (type, complain);
+ }
return result;
}
@@ -7108,6 +7131,10 @@ build_reinterpret_cast_1 (tree type, tree expr, bool c_cast_p,
/* Save casted types in the function's used types hash table. */
used_types_insert (type);
+ /* A prvalue of non-class type is cv-unqualified. */
+ if (!CLASS_TYPE_P (type))
+type = cv_unqualified (type);
+
/* [expr.reinterpret.cast]
An lvalue expression of type T1 can be cast to the type
"reference to T2" if an expression of type "pointer to T1" can be
@@ -7289,7 +7316,10 @@ build_reinterpret_cast (tree type, tree expr, tsubst_flags_t complain)
r = build_reinterpret_cast_1 (type, expr, /*c_cast_p=*/false,
/*valid_p=*/NULL, complain);
if (r != error_mark_node)
-maybe_warn_about_useless_cast (type, exp
Re: [PATCH, ARM/AArch64] drop aarch32 support for falkor/qdf24xx
On Wed, May 24, 2017 at 6:56 AM, Richard Earnshaw (lists) wrote: > OK. does this need to go in the gcc-8 changes file? Falkor hasn't shipped yet. I'm dropping features that only existed in preproduction NDA hardware, so there isn't anything end user visible, and hence I don't think that it needs to be in the release notes. Jim
Re: C++ PATCH to add __integer_pack built-in for std::make_integer_sequence (c++/80396)
FAIL: g++.dg/ext/integer-pack2.C -std=gnu++11 (test for excess errors) Excess errors: /daten/aranym/gcc/gcc-20170524/gcc/testsuite/g++.dg/ext/integer-pack2.C:10:48: error: overflow in constant expression [-fpermissive] /daten/aranym/gcc/gcc-20170524/gcc/testsuite/g++.dg/ext/integer-pack2.C:10:48: error: overflow in constant expression [-fpermissive] Andreas. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."
[testsuite, committed] Reinstate absolute line number in gcc.dg/cpp/19940712-1.c
Hi,
the line number refers to a line in a header file, so we want to keep
that absolute.
[ The absolute line numbers that we want to replace are the ones that
start failing once we add a line at the start of the file.
If an absolute line number refers to a header file, and we add a line at
the start of the including file, the test won't start to fail. However,
if we rewrite that line number to a relative one, and add a line at the
start of the including file, the test will start to fail. ]
Committed.
Thanks,
- Tom
Reinstate absolute line number in gcc.dg/cpp/19940712-1.c
2017-05-24 Tom de Vries
* gcc.dg/cpp/19940712-1.c: Reinstate absolute line number.
---
gcc/testsuite/gcc.dg/cpp/19940712-1.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/testsuite/gcc.dg/cpp/19940712-1.c b/gcc/testsuite/gcc.dg/cpp/19940712-1.c
index 7fd9b15..a79b2f5 100644
--- a/gcc/testsuite/gcc.dg/cpp/19940712-1.c
+++ b/gcc/testsuite/gcc.dg/cpp/19940712-1.c
@@ -2,7 +2,7 @@
/* PR 4713 */
/* dg.exp doesn't read the header files for magic comments. */
-/* { dg-error "unterminated comment" "" { target *-*-* } .-1 } */
+/* { dg-error "unterminated comment" "" { target *-*-* } 4 } */
/* { dg-error "unterminated comment" "header error" { target *-*-* } 8 } */
#include "19940712-1.h"
[PATCH, GCC/ARM] Fix typo in comment in arm_expand_prologue
Committed this obvious typo fix for a comment in arm_expand_prologue.
ChangeLog entry is as follows:
*** gcc/ChangeLog ***
2017-05-24 Thomas Preud'homme
* config/arm/arm.c (arm_expand_prologue): Fix typo in comment.
Best regards,
Thomas
diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index a465fc2b29f8ca4b0e5689c0c32025a5aa063e3a..62e4e89ef470a9f3fb2f751bea25c6711c29d6c9 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -21609,7 +21609,7 @@ arm_expand_prologue (void)
{
/* If no coprocessor registers are being pushed and we don't have
to worry about a frame pointer then push extra registers to
- create the stack frame. This is done is a way that does not
+ create the stack frame. This is done in a way that does not
alter the frame layout, so is independent of the epilogue. */
int n;
int frame;
Re: [PATCH, ARM/AArch64] drop aarch32 support for falkor/qdf24xx
On 12/05/17 03:43, Jim Wilson wrote: > Early steppings had aarch32 support, current steppings don't, so the > aarch32 support for falkor/qdf24xx needs to be dropped. This mostly > involves removing falkor/qdf24xx references from the arm port. The > qdf24xx_extra_costs structure moves from the arm port to the aarch64 > port. > > This was tested with aarch64-linux and armv8-linux bootstraps and make > checks. There were no regressions. Also verified by hand that the > -mcpu=falkor and -mqdf24xx options no longer work in the arm port but > still work in the aarch64 port. > > Jim > OK. does this need to go in the gcc-8 changes file? R.
Re: [PATCH 0/5 v3] Vect peeling cost model
On Wed, May 24, 2017 at 1:54 PM, Robin Dapp wrote: >> So what did actually change? I'd rather not diff the diffs. Can you >> provide an incremental change, aka p6 that would apply to the >> previous series instead? > > -p6.diff attached which also addresses Richard's remark regarding vf/2. > Note that this applies to the old series but the old series itself (-p3) > doesn't apply to trunk anymore (because of the change in > vect_enhance_data_refs_alignment). The series is ok. Thanks, Richard. > Regards > Robin > > -- > > gcc/ChangeLog: > > 2017-05-24 Robin Dapp > > * tree-vect-data-refs.c (vect_get_peeling_costs_all_drs): > Introduce unknown_misalignment parameter and remove vf. > (vect_peeling_hash_get_lowest_cost): > Pass unknown_misalignemtn parameter. > (vect_enhance_data_refs_alignment): > Fix unsupportable data ref treatment. >
Re: [PATCH v2 05/N] Add -fdump*-folding suboption.
On Wed, May 24, 2017 at 12:54 PM, Martin Liška wrote: > Hello. > > After discussions with Richi, I decided to end up with the transformation > and thus > I would like to apply the original patch on top of what was done. Probably > last change > should be that we should renumber TDF_* values to start from 1 << 0 and > holes in numbering > should be eliminated? Ok. Richard. > Thanks, > Martin
Re: [PATCH GCC8][31/33]Set range information for niter bound of vectorized loop
On Mon, May 22, 2017 at 7:13 PM, Bin.Cheng wrote: > On Fri, May 19, 2017 at 1:51 PM, Richard Biener > wrote: >> On Mon, May 15, 2017 at 5:58 PM, Bin.Cheng wrote: >>> On Thu, May 11, 2017 at 12:02 PM, Richard Biener >>> wrote: On Tue, Apr 18, 2017 at 12:54 PM, Bin Cheng wrote > Hi, > Based on vect_peeling algorithm, we know for sure that vectorized loop > must iterates at least once. > This patch sets range information for niter bounds of vectorized loop. > This helps niter analysis, > so iv elimination too. > Is it OK? niters_vector = force_gimple_operand (niters_vector, &stmts, true, var); gsi_insert_seq_on_edge_immediate (pe, stmts); + /* Peeling algorithm guarantees that vector loop bound is at least ONE, +we set range information to make niters analyzer's life easier. */ + if (TREE_CODE (niters_vector) == SSA_NAME) + set_range_info (niters_vector, VR_RANGE, build_int_cst (type, 1), + fold_build2 (RSHIFT_EXPR, type, +TYPE_MAX_VALUE (type), log_vf)); if all of niters_vector folds to an original SSA name then niters_vector after gimplification is not a new SSA name and thus you can't set range-info on it. Likewise for the other case where LOOP_VINFO_NITERS is just an SSA name. >>> Hi, >>> This is updated patch. It checks whether the result ssa name is newly >>> created tmp and only sets range information if so. >>> >>> Is it OK? >> >> A better way to check whether the SSA name is new is to see if 'stmts' >> filled by force_gimple_operand is non-empty. > Hi, > Here is updated patch checking empty gimple_seq. Is it OK? Ok. As a bonus you could have used wide-ints to feed set_range_info (not sure if wide_int_ref & allows you to pass '1' literally...) Richard. > Thanks, > bin >> >> Richard. >> >>> Thanks, >>> bin >>> >>> 2017-04-11 Bin Cheng >>> >>> * tree-vectorizer.h (vect_build_loop_niters): New parameter. >>> * tree-vect-loop-manip.c (vect_build_loop_niters): New parameter. >>> Set true to new parameter if new ssa variable is defined. >>> (vect_gen_vector_loop_niters): Refactor. Set range information >>> for the new vector loop bound variable. >>> (vect_do_peeling): Ditto. >>> Richard. > Thanks, > bin > 2017-04-11 Bin Cheng > > * tree-vect-loop-manip.c (vect_gen_vector_loop_niters): Refactor. > Set range information for vector loop bound variable. > (vect_do_peeling): Ditto.
Re: OpenACC 1.0 compatibility: acc_async_wait, acc_async_wait_all
Hi!
On Wed, 24 May 2017 13:58:12 +0200, Jakub Jelinek wrote:
> On Wed, May 24, 2017 at 01:47:34PM +0200, Thomas Schwinge wrote:
> > On Tue, 23 May 2017 13:17:26 +0200, Jakub Jelinek wrote:
> > > On Mon, May 22, 2017 at 07:42:38PM +0200, Thomas Schwinge wrote:
> > > > For OpenACC 1.0 compatibility, we need to provide the aliases
> > > > acc_async_wait, and acc_async_wait_all for acc_wait, and acc_wait_all,
> > > > respectively.
> >
> > > > OpenACC 1.0 compatibility: acc_async_wait, acc_async_wait_all
> > OK for trunk using "OACC_2.0.1" symbol version?
>
> Ok.
Thanks. Committed to trunk in r248413:
commit 0e1c776433f71834e5af2c9778a4f20bfb04f7f3
Author: tschwinge
Date: Wed May 24 13:25:01 2017 +
OpenACC 1.0 compatibility: acc_async_wait, acc_async_wait_all
libgomp/
* openacc.h (acc_async_wait, acc_async_wait_all): New prototypes.
* libgomp.map (OACC_2.0.1): Add these.
* oacc-async.c (acc_async_wait, acc_async_wait_all): New aliases
for "acc_wait", and "acc_wait_all", respectively.
* openacc.f90 (acc_async_wait, acc_async_wait_all): New interfaces
for "acc_wait", and "acc_wait_all", respectively.
* openacc_lib.h (acc_async_wait, acc_async_wait_all): Likewise.
* libgomp.texi (acc_wait, acc_wait_all): Update.
* testsuite/libgomp.oacc-c-c++-common/par-reduction-2.c: Update.
* testsuite/libgomp.oacc-fortran/par-reduction-2-1.f: New file.
* testsuite/libgomp.oacc-fortran/par-reduction-2-2.f: Likewise.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@248413
138bc75d-0d04-0410-961f-82ee72b054a4
---
libgomp/ChangeLog | 12 +
libgomp/libgomp.map| 2 +
libgomp/libgomp.texi | 7 ++-
libgomp/oacc-async.c | 22 +
libgomp/openacc.f90| 16 +-
libgomp/openacc.h | 2 +
libgomp/openacc_lib.h | 11 +
.../libgomp.oacc-c-c++-common/par-reduction-2.c| 9 ++--
.../libgomp.oacc-fortran/par-reduction-2-1.f | 57 ++
.../libgomp.oacc-fortran/par-reduction-2-2.f | 57 ++
10 files changed, 188 insertions(+), 7 deletions(-)
diff --git libgomp/ChangeLog libgomp/ChangeLog
index 55869d2..8adc10b 100644
--- libgomp/ChangeLog
+++ libgomp/ChangeLog
@@ -1,5 +1,17 @@
2017-05-24 Thomas Schwinge
+ * openacc.h (acc_async_wait, acc_async_wait_all): New prototypes.
+ * libgomp.map (OACC_2.0.1): Add these.
+ * oacc-async.c (acc_async_wait, acc_async_wait_all): New aliases
+ for "acc_wait", and "acc_wait_all", respectively.
+ * openacc.f90 (acc_async_wait, acc_async_wait_all): New interfaces
+ for "acc_wait", and "acc_wait_all", respectively.
+ * openacc_lib.h (acc_async_wait, acc_async_wait_all): Likewise.
+ * libgomp.texi (acc_wait, acc_wait_all): Update.
+ * testsuite/libgomp.oacc-c-c++-common/par-reduction-2.c: Update.
+ * testsuite/libgomp.oacc-fortran/par-reduction-2-1.f: New file.
+ * testsuite/libgomp.oacc-fortran/par-reduction-2-2.f: Likewise.
+
* openacc_lib.h (acc_pcopyin, acc_pcreate): Route to
acc_present_or_copyin and acc_present_or_create procedures,
respectively.
diff --git libgomp/libgomp.map libgomp/libgomp.map
index b43c6de..f9044ae 100644
--- libgomp/libgomp.map
+++ libgomp/libgomp.map
@@ -380,6 +380,8 @@ OACC_2.0 {
OACC_2.0.1 {
global:
+ acc_async_wait;
+ acc_async_wait_all;
acc_pcopyin;
acc_pcreate;
} OACC_2.0;
diff --git libgomp/libgomp.texi libgomp/libgomp.texi
index cc5ee1c..230720f 100644
--- libgomp/libgomp.texi
+++ libgomp/libgomp.texi
@@ -2095,12 +2095,15 @@ specified in @var{arg}.
@item @emph{C/C++}:
@multitable @columnfractions .20 .80
@item @emph{Prototype}: @tab @code{acc_wait(arg);}
+@item @emph{Prototype (OpenACC 1.0 compatibility)}: @tab
@code{acc_async_wait(arg);}
@end multitable
@item @emph{Fortran}:
@multitable @columnfractions .20 .80
@item @emph{Interface}: @tab @code{subroutine acc_wait(arg)}
@item @tab @code{integer(acc_handle_kind) arg}
+@item @emph{Interface (OpenACC 1.0 compatibility)}: @tab @code{subroutine
acc_async_wait(arg)}
+@item @tab
@code{integer(acc_handle_kind) arg}
@end multitable
@item @emph{Reference}:
@@ -2119,11 +2122,13 @@ This function waits for the completion of all
asynchronous operations.
@item @emph{C/C++}:
@multitable @columnfractions .20 .80
@item @emph{Prototype}: @tab @code{acc_wait_all(void);}
+@item @emph{Prototype (OpenACC 1.0 compatibility)}: @tab
@code{acc_async_wait_all(void);}
@end multitable
@item @emph{Fortran}:
@multitable @columnfractions .20 .80
-@item @emph{Interface}: @tab @cod
Re: Implementing OpenACC's Fortran module
Hi! On Wed, 24 May 2017 13:58:32 +0200, Jakub Jelinek wrote: > On Wed, May 24, 2017 at 01:34:50PM +0200, Thomas Schwinge wrote: > > Thus OK for trunk, as posted? > > Ok. Thanks. Committed to trunk in r248412: commit b70df2112de1c8fb9b448dc24e3a58055e4bbbdc Author: tschwinge Date: Wed May 24 13:23:55 2017 + Fortran OpenACC "openacc_lib.h": acc_pcopyin, acc_pcreate libgomp/ * openacc_lib.h (acc_pcopyin, acc_pcreate): Route to acc_present_or_copyin and acc_present_or_create procedures, respectively. * testsuite/libgomp.oacc-fortran/lib-32-1.f: Exercise these, and generally different variants of OpenACC Runtime Library functions. * testsuite/libgomp.oacc-fortran/lib-32-2.f: Likewise. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@248412 138bc75d-0d04-0410-961f-82ee72b054a4 --- libgomp/ChangeLog | 7 libgomp/openacc_lib.h | 42 --- libgomp/testsuite/libgomp.oacc-fortran/lib-32-1.f | 36 --- libgomp/testsuite/libgomp.oacc-fortran/lib-32-2.f | 26 +++--- 4 files changed, 42 insertions(+), 69 deletions(-) diff --git libgomp/ChangeLog libgomp/ChangeLog index af8c5ca..55869d2 100644 --- libgomp/ChangeLog +++ libgomp/ChangeLog @@ -1,5 +1,12 @@ 2017-05-24 Thomas Schwinge + * openacc_lib.h (acc_pcopyin, acc_pcreate): Route to + acc_present_or_copyin and acc_present_or_create procedures, + respectively. + * testsuite/libgomp.oacc-fortran/lib-32-1.f: Exercise these, and + generally different variants of OpenACC Runtime Library functions. + * testsuite/libgomp.oacc-fortran/lib-32-2.f: Likewise. + * testsuite/libgomp.oacc-fortran/lib-32-1.f: New file. * testsuite/libgomp.oacc-fortran/lib-32-2.f: Likewise. diff --git libgomp/openacc_lib.h libgomp/openacc_lib.h index 65f47a8..7818bd7 100644 --- libgomp/openacc_lib.h +++ libgomp/openacc_lib.h @@ -191,23 +191,9 @@ end interface interface acc_pcopyin -subroutine acc_pcopyin_32_h (a, len) - use iso_c_binding, only: c_int32_t - !GCC$ ATTRIBUTES NO_ARG_CHECK :: a - type (*), dimension (*) :: a - integer (c_int32_t) len -end subroutine - -subroutine acc_pcopyin_64_h (a, len) - use iso_c_binding, only: c_int64_t - !GCC$ ATTRIBUTES NO_ARG_CHECK :: a - type (*), dimension (*) :: a - integer (c_int64_t) len -end subroutine - -subroutine acc_pcopyin_array_h (a) - type (*), dimension (..), contiguous :: a - end subroutine +procedure :: acc_present_or_copyin_32_h +procedure :: acc_present_or_copyin_64_h +procedure :: acc_present_or_copyin_array_h end interface interface acc_create @@ -251,23 +237,9 @@ end interface interface acc_pcreate -subroutine acc_pcreate_32_h (a, len) - use iso_c_binding, only: c_int32_t - !GCC$ ATTRIBUTES NO_ARG_CHECK :: a - type (*), dimension (*) :: a - integer (c_int32_t) len -end subroutine - -subroutine acc_pcreate_64_h (a, len) - use iso_c_binding, only: c_int64_t - !GCC$ ATTRIBUTES NO_ARG_CHECK :: a - type (*), dimension (*) :: a - integer (c_int64_t) len -end subroutine - -subroutine acc_pcreate_array_h (a) - type (*), dimension (..), contiguous :: a - end subroutine +procedure :: acc_present_or_create_32_h +procedure :: acc_present_or_create_64_h +procedure :: acc_present_or_create_array_h end interface interface acc_copyout @@ -353,7 +325,7 @@ ! acc_map_data: Only available in C/C++ ! acc_unmap_data: Only available in C/C++ ! acc_deviceptr: Only available in C/C++ - ! acc_ostptr: Only available in C/C++ + ! acc_hostptr: Only available in C/C++ interface acc_is_present function acc_is_present_32_h (a, len) diff --git libgomp/testsuite/libgomp.oacc-fortran/lib-32-1.f libgomp/testsuite/libgomp.oacc-fortran/lib-32-1.f index 4606d77..177e4fb 100644 --- libgomp/testsuite/libgomp.oacc-fortran/lib-32-1.f +++ libgomp/testsuite/libgomp.oacc-fortran/lib-32-1.f @@ -20,8 +20,8 @@ SHARED_MEM = ACC_IS_PRESENT (H) - CALL ACC_PRESENT_OR_CREATE (H) - IF (.NOT. ACC_IS_PRESENT (H)) CALL ABORT + CALL ACC_PRESENT_OR_CREATE (H, INT (SIZEOF (H), 4)) + IF (.NOT. ACC_IS_PRESENT (H, INT (SIZEOF (H), 8))) CALL ABORT !$ACC PARALLEL LOOP DEFAULT (PRESENT) DO I = 1, N @@ -48,8 +48,7 @@ H(I) = I + 4 END DO -! CALL ACC_PCREATE (H) - CALL ACC_PRESENT_OR_CREATE (H) + CALL ACC_PCREATE (H, INT (SIZEOF (H), 4)) !$ACC PARALLEL LOOP DEFAULT (PRESENT) DO I = 1, N @@ -63,7 +62,7 @@ H(I) = I + 6 END
Re: [PATCH] Dump function on internal errors
On Mon, May 22, 2017 at 4:19 PM, Andi Kleen wrote:
> 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.
>
> v2: Updated version now using a hook in internal_error, and
> also prints the pass name and the dump file name.
>
> gcc/:
>
> 2017-05-21 Andi Kleen
>
> * diagnostic.c (internal_error): Call hook.
> (set_internal_error_hook): New function.
> * diagnostic.h: Add set_internal_error_hook.
> * passes.c: (pass_ice_hook): Add class to set
> internal_error_hook to dump functions.
> ---
> gcc/diagnostic.c | 18 ++
> gcc/diagnostic.h | 1 +
> gcc/passes.c | 21 +
> 3 files changed, 40 insertions(+)
>
> diff --git a/gcc/diagnostic.c b/gcc/diagnostic.c
> index 158519606f8..8d9caade60b 100644
> --- a/gcc/diagnostic.c
> +++ b/gcc/diagnostic.c
> @@ -33,6 +33,9 @@ along with GCC; see the file COPYING3. If not see
> #include "diagnostic-color.h"
> #include "edit-context.h"
> #include "selftest.h"
> +#include "tree.h"
> +#include "tree-pass.h"
> +#include "tree-cfg.h"
>
> #ifdef HAVE_TERMIOS_H
> # include
> @@ -1396,6 +1399,10 @@ fatal_error (location_t loc, const char *gmsgid, ...)
>gcc_unreachable ();
> }
>
> +/* Hook to call on internal errors. */
> +
> +static void (*internal_error_hook)();
> +
> /* An internal consistency check has failed. We make no attempt to
> continue. Note that unless there is debugging value to be had from
> a more specific message, or some other good reason, you should use
> @@ -1403,6 +1410,9 @@ fatal_error (location_t loc, const char *gmsgid, ...)
> void
> internal_error (const char *gmsgid, ...)
> {
> + if (internal_error_hook)
> +internal_error_hook ();
> +
>va_list ap;
>va_start (ap, gmsgid);
>rich_location richloc (line_table, input_location);
> @@ -1412,6 +1422,14 @@ internal_error (const char *gmsgid, ...)
>gcc_unreachable ();
> }
>
> +/* Call HOOK on internal errors. */
> +
> +void
> +set_internal_error_hook (void (*hook)())
> +{
> + internal_error_hook = hook;
> +}
> +
> /* Like internal_error, but no backtrace will be printed. Used when
> the internal error does not happen at the current location, but happened
> somewhere else. */
> diff --git a/gcc/diagnostic.h b/gcc/diagnostic.h
> index dbd1703e0ef..3d26a84ab44 100644
> --- a/gcc/diagnostic.h
> +++ b/gcc/diagnostic.h
> @@ -369,5 +369,6 @@ extern char *file_name_as_prefix (diagnostic_context *,
> const char *);
>
> extern char *build_message_string (const char *, ...) ATTRIBUTE_PRINTF_1;
>
> +extern void set_internal_error_hook (void (*)());
>
> #endif /* ! GCC_DIAGNOSTIC_H */
> diff --git a/gcc/passes.c b/gcc/passes.c
> index e7c5d194010..1bd92c8140a 100644
> --- a/gcc/passes.c
> +++ b/gcc/passes.c
> @@ -3040,4 +3040,25 @@ function_called_by_processed_nodes_p (void)
>return e != NULL;
> }
>
> +class pass_ice_hook {
> +
> + /* Print function to dump file on internal errors. */
> +
> + static void ice_hook() {
> +if (dump_file)
> + {
> + fprintf (stderr, "Dumping function to dump file %s for pass %s\n",
> +dump_file_name, current_pass->name);
> + dump_function_to_file (current_function_decl, dump_file, dump_flags);
> + }
> + }
> +
> + public:
> + pass_ice_hook() {
> +set_internal_error_hook (ice_hook);
> + }
> +};
> +
> +static pass_ice_hook pass_ice_hook;
current_pass might be NULL so you better do set_internal_error_hook when
we start executing passes (I detest global singletons to do such stuff anyway).
Otherwise looks reasonable to me.
Richard.
> +
> #include "gt-passes.h"
> --
> 2.12.2
>
Re: Translate libgomp.oacc-c-c++-common/lib-32.c into Fortran
Hi!
On Tue, 23 May 2017 13:08:22 +0200, Jakub Jelinek wrote:
> On Mon, May 22, 2017 at 04:29:51PM +0200, Thomas Schwinge wrote:
> > On Mon, 22 May 2017 16:26:48 +0200, I wrote:
> > > C/C++ OpenACC: acc_pcopyin, acc_pcreate
> >
> > > libgomp/
> > > [...]
> > > * testsuite/libgomp.oacc-c-c++-common/lib-38.c: Remove,
> > > merging
> > > its content into...
> > > * testsuite/libgomp.oacc-c-c++-common/lib-32.c: ... this file.
> > > Extend testing.
> >
> > ... which I then translated into two Fortran variants; OK for trunk?
> Ok.
Thanks. As posted, committed to trunk in r248411:
commit 4a5596a04ac52ae4df1347e7980e0d60fcd1e84b
Author: tschwinge
Date: Wed May 24 13:23:45 2017 +
Translate libgomp.oacc-c-c++-common/lib-32.c into Fortran
libgomp/
* testsuite/libgomp.oacc-fortran/lib-32-1.f: New file.
* testsuite/libgomp.oacc-fortran/lib-32-2.f: Likewise.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@248411
138bc75d-0d04-0410-961f-82ee72b054a4
---
libgomp/ChangeLog | 3 +
.../testsuite/libgomp.oacc-c-c++-common/lib-32.c | 1 +
libgomp/testsuite/libgomp.oacc-fortran/lib-32-1.f | 179 +
libgomp/testsuite/libgomp.oacc-fortran/lib-32-2.f | 173
4 files changed, 356 insertions(+)
diff --git libgomp/ChangeLog libgomp/ChangeLog
index 4a95755..af8c5ca 100644
--- libgomp/ChangeLog
+++ libgomp/ChangeLog
@@ -1,5 +1,8 @@
2017-05-24 Thomas Schwinge
+ * testsuite/libgomp.oacc-fortran/lib-32-1.f: New file.
+ * testsuite/libgomp.oacc-fortran/lib-32-2.f: Likewise.
+
* openacc.h (acc_pcopyin, acc_pcreate): Provide prototypes instead
of preprocessor definitions.
* libgomp.h (strong_alias): Guard by "#ifdef
diff --git libgomp/testsuite/libgomp.oacc-c-c++-common/lib-32.c
libgomp/testsuite/libgomp.oacc-c-c++-common/lib-32.c
index 6a9e995..1696fb6 100644
--- libgomp/testsuite/libgomp.oacc-c-c++-common/lib-32.c
+++ libgomp/testsuite/libgomp.oacc-c-c++-common/lib-32.c
@@ -1,4 +1,5 @@
/* acc_present_or_create, acc_present_or_copyin, etc. */
+/* See also Fortran variants in "../libgomp.oacc-fortran/lib-32*". */
#include
#include
diff --git libgomp/testsuite/libgomp.oacc-fortran/lib-32-1.f
libgomp/testsuite/libgomp.oacc-fortran/lib-32-1.f
new file mode 100644
index 000..4606d77
--- /dev/null
+++ libgomp/testsuite/libgomp.oacc-fortran/lib-32-1.f
@@ -0,0 +1,179 @@
+! ACC_PRESENT_OR_CREATE, ACC_PRESENT_OR_COPYIN, etc.
+! Variant of "../libgomp.oacc-c-c++-common/lib-32.c".
+! Variant using "openacc_lib.h".
+
+! { dg-do run }
+
+ PROGRAM MAIN
+ IMPLICIT NONE
+ INCLUDE "openacc_lib.h"
+
+ INTEGER, PARAMETER :: N = 1
+ INTEGER, ALLOCATABLE :: H(:)
+ INTEGER :: I
+ LOGICAL :: SHARED_MEM
+
+ ALLOCATE (H(N))
+ DO I = 1, N
+ H(I) = I + 0
+ END DO
+
+ SHARED_MEM = ACC_IS_PRESENT (H)
+
+ CALL ACC_PRESENT_OR_CREATE (H)
+ IF (.NOT. ACC_IS_PRESENT (H)) CALL ABORT
+
+!$ACC PARALLEL LOOP DEFAULT (PRESENT)
+ DO I = 1, N
+ H(I) = I + 1
+ END DO
+!$ACC END PARALLEL LOOP
+
+ DO I = 1, N
+ IF (H(I) .NE. I + MERGE (1, 0, SHARED_MEM)) CALL ABORT
+ H(I) = I + 2
+ END DO
+
+ CALL ACC_PRESENT_OR_CREATE (H)
+
+!$ACC PARALLEL LOOP DEFAULT (PRESENT)
+ DO I = 1, N
+ IF (H(I) .NE. I + MERGE (2, 1, SHARED_MEM)) CALL ABORT
+ H(I) = I + 3
+ END DO
+!$ACC END PARALLEL LOOP
+
+ DO I = 1, N
+ IF (H(I) .NE. I + MERGE (3, 2, SHARED_MEM)) CALL ABORT
+ H(I) = I + 4
+ END DO
+
+! CALL ACC_PCREATE (H)
+ CALL ACC_PRESENT_OR_CREATE (H)
+
+!$ACC PARALLEL LOOP DEFAULT (PRESENT)
+ DO I = 1, N
+ IF (H(I) .NE. I + MERGE (4, 3, SHARED_MEM)) CALL ABORT
+ H(I) = I + 5
+ END DO
+!$ACC END PARALLEL LOOP
+
+ DO I = 1, N
+ IF (H(I) .NE. I + MERGE (5, 4, SHARED_MEM)) CALL ABORT
+ H(I) = I + 6
+ END DO
+
+ CALL ACC_PRESENT_OR_COPYIN (H)
+
+!$ACC PARALLEL LOOP DEFAULT (PRESENT)
+ DO I = 1, N
+ IF (H(I) .NE. I + MERGE (6, 5, SHARED_MEM)) CALL ABORT
+ H(I) = I + 7
+ END DO
+!$ACC END PARALLEL LOOP
+
+ DO I = 1, N
+ IF (H(I) .NE. I + MERGE (7, 6, SHARED_MEM)) CALL ABORT
+ H(I) = I + 8
+ END DO
+
+! CALL ACC_PCOPYIN (H)
+ CALL ACC_PRESENT_OR_COPYIN (H)
+
+!$ACC PARALLEL LOOP DEFAULT (PRESENT)
+ DO I = 1, N
+ IF (H(I) .NE. I + MERGE (8, 7, SHARED_MEM)) CALL ABORT
+ H(I) = I + 9
+ END DO
+!$ACC END PARALLEL LOOP
+
+ DO I = 1, N
+ IF (H(I) .NE. I + MERGE (9, 8, SHARED_MEM)) CALL ABORT
+ H(I) = I + 10
+ END DO
+
+ CALL ACC_COPYOUT (H)
+ IF (.NOT. SHARED_MEM) THEN
+ IF (ACC_IS_PRESENT (H)) CALL ABORT
+ ENDIF
+
+ DO I = 1, N
+
Re: [config PATCH] --enable-languages
On Fri, May 19, 2017 at 6:59 PM, Nathan Sidwell wrote: > --enable-languages=all confused me, because as RichardB said, 'it really > means default'. So this patch does 2 things > 1) allow --enable-languages=default to mean what =all does now. > 2) change =all to mean all available languages. > 2.1) jit is included in =all if -enable-host-shared is given. If you don't > you get a warning that JIT's not included. > > If you're used to saying =all, then you'll get more languages with this > patch than you used to. > > ok? Ok. Did you check =all works with/without a host Ada compiler installed? (warning but not including ada in the without case?) Richard. > nathan > -- > Nathan Sidwell
Re: C/C++ OpenACC: acc_pcopyin, acc_pcreate
Hi! On Wed, 24 May 2017 13:20:54 +0200, Jakub Jelinek wrote: > On Wed, May 24, 2017 at 12:55:27PM +0200, Thomas Schwinge wrote: > > On Tue, 23 May 2017 13:07:15 +0200, Jakub Jelinek wrote: > > > new symbols should never be added to an existing symbol > > > version after a GCC version with that symbol version has been released. > > would you please remind me where this > > requirement is coming from? > > There are many reasons Thanks for the explanation! > one is e.g. that the dynamic linker uses the symbol > version names during library loading to verify the library satisfies the > needs of a binary or some other library; if you add further symbols into > existing symbol version, then it will be satisfied even by library that > doesn't provide the symbol (in the above case say acc_pcopyin), and you can > get a failure either much later (during relocation processing, with lazy > binding that can be much later), or not at all (with lazy binding and if > the function isn't called at all during the runtime of the program). Some might consider that a feature. ;-) > Another one is e.g. rpm uses symbol versions in dependencies, but only > those and not at the required/provided symbol granularity. So, if you > have acc_pcopyin@@OACC_2.0.1 and use it in some program, the program > will have a dependency on libgomp.so.1()(OACC_2.0.1) and thus you > automatically get the right library that provides it. If you add to an > existing symbol version, the dependency will be satisfied even for libraries > that don't provide it at all. Ah, yes, I see -- a fine reason. > All in all, symbol versions aren't there just for documentation purposes, > but serve various other roles, including the possibility to change ABI > of existing symbols, but not limited to that. Sure, I was aware of that specific use -- but that's not relevant to the case discussed here: a symbol's (non-)existence will always be detected reliably, whether lazily (see above), or at load time. That's where I had gotten the idea from that it's fine to use existing versions for these new symbols. (But you reminded me why it's better to use a new version here, too.) > The policy of not adding > new symbols into symbol versions that were already shipped in released > libraries is something that is strictly followed in glibc, gcc libraries > (I remember in libstdc++ a bug happened some years ago and some symbols > were unintentionally exported at an earlier version, which has been cured > by moving into a new symbol version and providing the old one just as an @ > (vs. @@) symver for compatibility only; e.g. the current libstdc++ check-abi > stuff verifies this stuff). > For more info see e.g. https://www.akkadia.org/drepper/symbol-versioning Yeah, thanks, I had read that a few years ago. > > But that will only redirect them at the user side. The intention here is > > The question is if the OpenACC standard allows that or not. Let's put it this way: it doesn't explicitly disallow that. > > to also care for users providing their own declarations instead of using > > , or using "dlsym", and so on -- quite "pathological", I know, > > but... > > OK for trunk using "OACC_2.0.1" symbol version? > > Ok. Thanks. As posted, committed to trunk in r248410: commit e4d15e02dfbaf61fb5655595423baaff4a345a60 Author: tschwinge Date: Wed May 24 13:23:34 2017 + C/C++ OpenACC: acc_pcopyin, acc_pcreate libgomp/ * openacc.h (acc_pcopyin, acc_pcreate): Provide prototypes instead of preprocessor definitions. * libgomp.h (strong_alias): Guard by "#ifdef HAVE_ATTRIBUTE_ALIAS". * oacc-mem.c: Provide "acc_pcreate" as alias for "acc_present_or_create", and "acc_pcopyin" as alias for "acc_present_or_copyin". * libgomp.map: New version "OACC_2.0.1". (OACC_2.0.1): Add "acc_pcopyin", and "acc_pcreate". * testsuite/libgomp.oacc-c-c++-common/lib-38.c: Remove, merging its content into... * testsuite/libgomp.oacc-c-c++-common/lib-32.c: ... this file. Extend testing. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@248410 138bc75d-0d04-0410-961f-82ee72b054a4 --- libgomp/ChangeLog | 14 ++ libgomp/libgomp.h | 5 +- libgomp/libgomp.map| 6 + libgomp/oacc-mem.c | 22 ++ libgomp/openacc.h | 7 +- .../testsuite/libgomp.oacc-c-c++-common/lib-32.c | 241 +++-- .../testsuite/libgomp.oacc-c-c++-common/lib-38.c | 64 -- 7 files changed, 272 insertions(+), 87 deletions(-) diff --git libgomp/ChangeLog libgomp/ChangeLog index 14e95ef..4a95755 100644 --- libgomp/ChangeLog +++ libgomp/ChangeLog @@ -1,5 +1,19 @@ 2017-05-24 Thomas Schwinge + * openacc.h (acc_pcopyin, acc_pcreate): Provide prot
Re: [PATCH] Match x86 family machine constraints section with constarints.md
On Tue, May 23, 2017 at 5:33 PM, Sandra Loosemore wrote: > On 04/28/2017 03:30 AM, Peryt, Sebastian wrote: >> >> Hi, >> >> Thank you for your comments. I edited my patch accordingly. As for some of >> your doubts: >> - REX is the opcode prefix to access 64-bit register extensions >> introduced in IA-32e mode. >> - EVEX is the encoding prefix which applies to SIMD operating instructions >> operating on XMM, YMM and ZMM registers. It was introduced with AVX-512 >> instructions. >> - "number factor of four" that means that sources start in a multiple of 4 >> boundary. This is used for some of instructions. >> >> Also I'd like to add that this whole patch is strictly based on docstring >> parts of constraints that are present in config/i386/constraints.md but not >> in documentation (md.texi file). There is no new (new as in nonexistent in >> code) content. >> >> I'm also adding Kirill Yukhin to CC, because I believe he is the correct >> person that can catch any technical errors if any has slipped-in. > > > The grammar/markup/etc are OK now, but I can't comment on technical > correctness of the information. LGTM. Thanks, Uros.
Re: [PATCH] Fix a SPARC -mcbcond compare-and-branch out of range failure.
Thanks for the review. On 05/24/2017 02:52 AM, Eric Botcazou wrote: OK for all active branches, but the ChangeLog entry should be something like: * config/sparc/sparc.md (length): Return the correct value for -mflat sibcalls to match output_sibcall. Will do. Note that we *never* use a pair of parentheses after function names. Noted for future reference. Thanks again, Sheldon
Re: [PATCH] Fix PR middle-end/80823, ICE: verify_flow_info failed
On 5/24/17 2:15 AM, Richard Biener wrote: > On May 23, 2017 7:46:59 PM GMT+02:00, Peter Bergner > wrote: >> gcc/ >> PR middle-end/80823 >> * tree-cfg.c (group_case_labels_stmt): Delete increment of "i"; >> >> gcc/testsuite/ >> PR middle-end/80823 >> * gcc.dg/pr80823.c: New test. > > OK. > Thanks, committed as revision 248408. Peter
Re: [PATCH] gcc::context creation
On 05/24/2017 07:57 AM, Jakub Jelinek wrote: The numbering is not to differentiate between dumps of the same name, that is done through numbered suffixes of the dump names, but to make the order of passes visible to the user and for sorted file listing to be provided in that order. So, rather than having lang files unnumbered, I think it is better to number them and just have a maximum of lang dumps and if some FE registers fewers, bump m_next_dump accordingly (create a hole). That is pretty much the standard behavior, if some dump is registered, but for whatever reason not dumped, you also get a hole. oh, ok. Seems fine to me. nathan -- Nathan Sidwell
Re: Implementing OpenACC's Fortran module
On Wed, May 24, 2017 at 01:34:50PM +0200, Thomas Schwinge wrote: > Thus OK for trunk, as posted? Ok. Jakub
Re: OpenACC 1.0 compatibility: acc_async_wait, acc_async_wait_all
On Wed, May 24, 2017 at 01:47:34PM +0200, Thomas Schwinge wrote: > Hi Jakub! > > On Tue, 23 May 2017 13:17:26 +0200, Jakub Jelinek wrote: > > On Mon, May 22, 2017 at 07:42:38PM +0200, Thomas Schwinge wrote: > > > For OpenACC 1.0 compatibility, we need to provide the aliases > > > acc_async_wait, and acc_async_wait_all for acc_wait, and acc_wait_all, > > > respectively. > > > > OpenACC 1.0 compatibility: acc_async_wait, acc_async_wait_all > > > All I've said about acc_pcopyin applies here too. > > Obviously. ;-) > > > Except that OACC_1.0 > > as symbol version might look like a good idea here. > > GCC never implemented OpenACC 1.0 but directly started with 2.0a, so I > would find it confusing to now starting using 1.0 versions for these > symbols specifically. > > OK for trunk using "OACC_2.0.1" symbol version? Ok. Jakub
Re: [PATCH] gcc::context creation
On Wed, May 24, 2017 at 07:44:49AM -0400, Nathan Sidwell wrote: > On 05/24/2017 06:57 AM, Jakub Jelinek wrote: > > > So, first question, where should we order the -fdump-lang-* dumps, shall > > they go before .original/.gimple/.nested, or in between .original and > > .gimple/.nested, or after those 3 (the last option looks just wrong to me)? > > I think the lang dumps should come first. > > > Shall the 3 standard dumps be registered like any others? > > I think they should move to the new dynamic registration. > Should 'original' become a lang dump? It would be great if the original dumping was able to use some FE specific printing, right now the *.original dump is often full of < > Shall the number of lang dumps affect the numbering, i.e. is it desirable > > that with C and C++ you get different numbers for *t.cfg dump, or *t.gimple? > > In many cases it would be better if the numbering was consistent between C > > and C++. > > I'm ambivalent on this. I can see why consistency might be desirable > though. I'd be fine with making the lang dumps unnumbered to achieve that > -- I don't see an obvious need for a language to have two dumps of the same > name. The numbering is not to differentiate between dumps of the same name, that is done through numbered suffixes of the dump names, but to make the order of passes visible to the user and for sorted file listing to be provided in that order. So, rather than having lang files unnumbered, I think it is better to number them and just have a maximum of lang dumps and if some FE registers fewers, bump m_next_dump accordingly (create a hole). That is pretty much the standard behavior, if some dump is registered, but for whatever reason not dumped, you also get a hole. Jakub
Re: [PATCH 0/5 v3] Vect peeling cost model
> So what did actually change? I'd rather not diff the diffs. Can you
> provide an incremental change, aka p6 that would apply to the
> previous series instead?
-p6.diff attached which also addresses Richard's remark regarding vf/2.
Note that this applies to the old series but the old series itself (-p3)
doesn't apply to trunk anymore (because of the change in
vect_enhance_data_refs_alignment).
Regards
Robin
--
gcc/ChangeLog:
2017-05-24 Robin Dapp
* tree-vect-data-refs.c (vect_get_peeling_costs_all_drs):
Introduce unknown_misalignment parameter and remove vf.
(vect_peeling_hash_get_lowest_cost):
Pass unknown_misalignemtn parameter.
(vect_enhance_data_refs_alignment):
Fix unsupportable data ref treatment.
*** /tmp/qBXCWe_tree-vect-data-refs.c 2017-05-24 13:44:37.939055376 +0200
--- gcc/tree-vect-data-refs.c 2017-05-24 13:44:12.039055376 +0200
***
*** 1239,1252
}
/* Get the costs of peeling NPEEL iterations checking data access costs
!for all data refs. */
static void
vect_get_peeling_costs_all_drs (struct data_reference *dr0,
unsigned int *inside_cost,
unsigned int *outside_cost,
stmt_vector_for_cost *body_cost_vec,
! unsigned int npeel, unsigned int vf)
{
gimple *stmt = DR_STMT (dr0);
stmt_vec_info stmt_info = vinfo_for_stmt (stmt);
--- 1239,1254
}
/* Get the costs of peeling NPEEL iterations checking data access costs
!for all data refs. If UNKNOWN_MISALIGNMENT is true, we assume DR0's
!misalignment will be zero after peeling. */
static void
vect_get_peeling_costs_all_drs (struct data_reference *dr0,
unsigned int *inside_cost,
unsigned int *outside_cost,
stmt_vector_for_cost *body_cost_vec,
! unsigned int npeel,
! bool unknown_misalignment)
{
gimple *stmt = DR_STMT (dr0);
stmt_vec_info stmt_info = vinfo_for_stmt (stmt);
***
*** 1274,1280
int save_misalignment;
save_misalignment = DR_MISALIGNMENT (dr);
! if (dr == dr0 && npeel == vf / 2)
SET_DR_MISALIGNMENT (dr, 0);
else
vect_update_misalignment_for_peel (dr, dr0, npeel);
--- 1276,1282
int save_misalignment;
save_misalignment = DR_MISALIGNMENT (dr);
! if (unknown_misalignment && dr == dr0)
SET_DR_MISALIGNMENT (dr, 0);
else
vect_update_misalignment_for_peel (dr, dr0, npeel);
***
*** 1305,1311
epilogue_cost_vec.create (2);
vect_get_peeling_costs_all_drs (elem->dr, &inside_cost, &outside_cost,
! &body_cost_vec, elem->npeel, 0);
outside_cost += vect_get_known_peeling_cost
(loop_vinfo, elem->npeel, &dummy,
--- 1307,1313
epilogue_cost_vec.create (2);
vect_get_peeling_costs_all_drs (elem->dr, &inside_cost, &outside_cost,
! &body_cost_vec, elem->npeel, false);
outside_cost += vect_get_known_peeling_cost
(loop_vinfo, elem->npeel, &dummy,
***
*** 1517,1522
--- 1519,1525
{
vec datarefs = LOOP_VINFO_DATAREFS (loop_vinfo);
struct loop *loop = LOOP_VINFO_LOOP (loop_vinfo);
+ enum dr_alignment_support supportable_dr_alignment;
struct data_reference *dr0 = NULL, *first_store = NULL;
struct data_reference *dr;
unsigned int i, j;
***
*** 1528,1533
--- 1531,1538
unsigned int npeel = 0;
bool one_misalignment_known = false;
bool one_misalignment_unknown = false;
+ bool one_dr_unsupportable = false;
+ struct data_reference *unsupportable_dr = NULL;
unsigned int vf = LOOP_VINFO_VECT_FACTOR (loop_vinfo);
unsigned possible_npeel_number = 1;
tree vectype;
***
*** 1599,1604
--- 1604,1610
&& !STMT_VINFO_GROUPED_ACCESS (stmt_info))
continue;
+ supportable_dr_alignment = vect_supportable_dr_alignment (dr, true);
do_peeling = vector_alignment_reachable_p (dr);
if (do_peeling)
{
***
*** 1637,1644
else
possible_npeel_number = vf / nelements;
! /* NPEEL_TMP is 0 when there is no misalignment, increment
! the peeling amount by one in order to ... */
if (DR_MISALIGNMENT (dr) == 0)
possible_npeel_number++;
}
--- 1643,1650
else
possible_npeel_number = vf / nelements;
! /* NPEEL_TMP is 0 when there is no misalignment, but also
! allow peeling NELEMENTS. */
if (DR_MISALIGNMENT (dr) == 0)
possible_npeel_number++;
}
***
*** 1684,1693
dr0 = dr;
}
if (!first_store && DR_IS_WRITE (dr))
first_store = dr;
-
- one_misalignment_unknown = true;
}
}
else
--- 1690,1707
dr0 = dr;
}
+ one_misalignment_unknown = true;
+
+ /* Check for data refs with unsupportable alignment that
+ can be peeled. */
+ if (!supportable_dr_alignment)
+
Re: OpenACC 1.0 compatibility: acc_async_wait, acc_async_wait_all
Hi Jakub!
On Tue, 23 May 2017 13:17:26 +0200, Jakub Jelinek wrote:
> On Mon, May 22, 2017 at 07:42:38PM +0200, Thomas Schwinge wrote:
> > For OpenACC 1.0 compatibility, we need to provide the aliases
> > acc_async_wait, and acc_async_wait_all for acc_wait, and acc_wait_all,
> > respectively.
> > OpenACC 1.0 compatibility: acc_async_wait, acc_async_wait_all
> All I've said about acc_pcopyin applies here too.
Obviously. ;-)
> Except that OACC_1.0
> as symbol version might look like a good idea here.
GCC never implemented OpenACC 1.0 but directly started with 2.0a, so I
would find it confusing to now starting using 1.0 versions for these
symbols specifically.
OK for trunk using "OACC_2.0.1" symbol version?
commit 5c0da4609b29a406601c2dd92f8dbff2f448bc1d
Author: Thomas Schwinge
Date: Wed May 24 12:49:19 2017 +0200
OpenACC 1.0 compatibility: acc_async_wait, acc_async_wait_all
libgomp/
* openacc.h (acc_async_wait, acc_async_wait_all): New prototypes.
* libgomp.map (OACC_2.0.1): Add these.
* oacc-async.c (acc_async_wait, acc_async_wait_all): New aliases
for "acc_wait", and "acc_wait_all", respectively.
* openacc.f90 (acc_async_wait, acc_async_wait_all): New interfaces
for "acc_wait", and "acc_wait_all", respectively.
* openacc_lib.h (acc_async_wait, acc_async_wait_all): Likewise.
* libgomp.texi (acc_wait, acc_wait_all): Update.
* testsuite/libgomp.oacc-c-c++-common/par-reduction-2.c: Update.
* testsuite/libgomp.oacc-fortran/par-reduction-2-1.f: New file.
* testsuite/libgomp.oacc-fortran/par-reduction-2-2.f: Likewise.
---
libgomp/libgomp.map| 2 +
libgomp/libgomp.texi | 7 ++-
libgomp/oacc-async.c | 22 +
libgomp/openacc.f90| 16 +-
libgomp/openacc.h | 2 +
libgomp/openacc_lib.h | 11 +
.../libgomp.oacc-c-c++-common/par-reduction-2.c| 9 ++--
.../libgomp.oacc-fortran/par-reduction-2-1.f | 57 ++
.../libgomp.oacc-fortran/par-reduction-2-2.f | 57 ++
9 files changed, 176 insertions(+), 7 deletions(-)
diff --git libgomp/libgomp.map libgomp/libgomp.map
index b43c6de..f9044ae 100644
--- libgomp/libgomp.map
+++ libgomp/libgomp.map
@@ -380,6 +380,8 @@ OACC_2.0 {
OACC_2.0.1 {
global:
+ acc_async_wait;
+ acc_async_wait_all;
acc_pcopyin;
acc_pcreate;
} OACC_2.0;
diff --git libgomp/libgomp.texi libgomp/libgomp.texi
index cc5ee1c..230720f 100644
--- libgomp/libgomp.texi
+++ libgomp/libgomp.texi
@@ -2095,12 +2095,15 @@ specified in @var{arg}.
@item @emph{C/C++}:
@multitable @columnfractions .20 .80
@item @emph{Prototype}: @tab @code{acc_wait(arg);}
+@item @emph{Prototype (OpenACC 1.0 compatibility)}: @tab
@code{acc_async_wait(arg);}
@end multitable
@item @emph{Fortran}:
@multitable @columnfractions .20 .80
@item @emph{Interface}: @tab @code{subroutine acc_wait(arg)}
@item @tab @code{integer(acc_handle_kind) arg}
+@item @emph{Interface (OpenACC 1.0 compatibility)}: @tab @code{subroutine
acc_async_wait(arg)}
+@item @tab
@code{integer(acc_handle_kind) arg}
@end multitable
@item @emph{Reference}:
@@ -2119,11 +2122,13 @@ This function waits for the completion of all
asynchronous operations.
@item @emph{C/C++}:
@multitable @columnfractions .20 .80
@item @emph{Prototype}: @tab @code{acc_wait_all(void);}
+@item @emph{Prototype (OpenACC 1.0 compatibility)}: @tab
@code{acc_async_wait_all(void);}
@end multitable
@item @emph{Fortran}:
@multitable @columnfractions .20 .80
-@item @emph{Interface}: @tab @code{subroutine acc_wait_async()}
+@item @emph{Interface}: @tab @code{subroutine acc_wait_all()}
+@item @emph{Interface (OpenACC 1.0 compatibility)}: @tab @code{subroutine
acc_async_wait_all()}
@end multitable
@item @emph{Reference}:
diff --git libgomp/oacc-async.c libgomp/oacc-async.c
index b68c84d..1334f99 100644
--- libgomp/oacc-async.c
+++ libgomp/oacc-async.c
@@ -70,6 +70,17 @@ acc_wait (int async)
thr->dev->openacc.async_wait_func (async);
}
+/* acc_async_wait is an OpenACC 1.0 compatibility name for acc_wait. */
+#ifdef HAVE_ATTRIBUTE_ALIAS
+strong_alias (acc_wait, acc_async_wait)
+#else
+void
+acc_async_wait (int async)
+{
+ acc_wait (async);
+}
+#endif
+
void
acc_wait_async (int async1, int async2)
{
@@ -92,6 +103,17 @@ acc_wait_all (void)
thr->dev->openacc.async_wait_all_func ();
}
+/* acc_async_wait_all is an OpenACC 1.0 compatibility name for acc_wait_all.
*/
+#ifdef HAVE_ATTRIBUTE_ALIAS
+strong_alias (acc_wait_all, acc_async_wait_all)
+#else
+void
+acc_async_wait_all (void)
+{
+ acc_wait_all ();
+}
+#endif
+
void
acc_wait_all_async (int async)
{
diff
Re: [PATCH] gcc::context creation
On 05/24/2017 06:57 AM, Jakub Jelinek wrote: So, first question, where should we order the -fdump-lang-* dumps, shall they go before .original/.gimple/.nested, or in between .original and .gimple/.nested, or after those 3 (the last option looks just wrong to me)? I think the lang dumps should come first. Shall the 3 standard dumps be registered like any others? I think they should move to the new dynamic registration. Should 'original' become a lang dump? Shall the number of lang dumps affect the numbering, i.e. is it desirable that with C and C++ you get different numbers for *t.cfg dump, or *t.gimple? In many cases it would be better if the numbering was consistent between C and C++. I'm ambivalent on this. I can see why consistency might be desirable though. I'd be fine with making the lang dumps unnumbered to achieve that -- I don't see an obvious need for a language to have two dumps of the same name. nathan -- Nathan Sidwell
Re: [Committed] S/390: Fix PR80725.
On Wed, May 24, 2017 at 01:38:01PM +0200, Andreas Krebbel wrote:
> No regressions on s390x. Applied to mainline.
> Ok for GCC 7 branch as well?
Ok, (though, you don't really need a permission for that, maintainers
can decide on backports to release branches themselves except when
the branches are frozen).
> 2017-05-24 Andreas Krebbel
>
> PR target/80725
> * config/s390/s390.c (s390_check_qrst_address): Check incoming
> address against address_operand predicate.
> * config/s390/s390.md ("*indirect_jump"): Swap alternatives.
>
> gcc/testsuite/ChangeLog:
>
> 2017-05-24 Andreas Krebbel
>
> * gcc.target/s390/pr80725.c: New test.
Jakub
[Committed] S/390: Fix PR80725.
No regressions on s390x. Applied to mainline.
Ok for GCC 7 branch as well?
Bye,
-Andreas-
gcc/ChangeLog:
2017-05-24 Andreas Krebbel
PR target/80725
* config/s390/s390.c (s390_check_qrst_address): Check incoming
address against address_operand predicate.
* config/s390/s390.md ("*indirect_jump"): Swap alternatives.
gcc/testsuite/ChangeLog:
2017-05-24 Andreas Krebbel
* gcc.target/s390/pr80725.c: New test.
---
gcc/config/s390/s390.c | 3 +++
gcc/config/s390/s390.md | 10 ++
gcc/testsuite/gcc.target/s390/pr80725.c | 26 ++
3 files changed, 35 insertions(+), 4 deletions(-)
create mode 100644 gcc/testsuite/gcc.target/s390/pr80725.c
diff --git a/gcc/config/s390/s390.c b/gcc/config/s390/s390.c
index c16391a..7be22d9 100644
--- a/gcc/config/s390/s390.c
+++ b/gcc/config/s390/s390.c
@@ -3102,6 +3102,9 @@ s390_check_qrst_address (char c, rtx op, bool lit_pool_ok)
struct s390_address addr;
bool decomposed = false;
+ if (!address_operand (op, GET_MODE (op)))
+return 0;
+
/* This check makes sure that no symbolic address (except literal
pool references) are accepted by the R or T constraints. */
if (s390_loadrelative_operand_p (op, NULL, NULL))
diff --git a/gcc/config/s390/s390.md b/gcc/config/s390/s390.md
index c9fd19a..cfae171 100644
--- a/gcc/config/s390/s390.md
+++ b/gcc/config/s390/s390.md
@@ -9660,14 +9660,16 @@
operands[0] = force_reg (Pmode, operands[0]);
})
+; The first constraint must be an "extra address constraint" in order
+; to trigger address reloading in LRA/reload
(define_insn "*indirect_jump"
[(set (pc)
- (match_operand 0 "address_operand" "a,ZR"))]
+ (match_operand 0 "address_operand" "ZR,a"))]
""
"@
- br\t%0
- b\t%a0"
- [(set_attr "op_type" "RR,RX")
+ b\t%a0
+ br\t%0"
+ [(set_attr "op_type" "RX,RR")
(set_attr "type" "branch")
(set_attr "atype" "agen")
(set_attr "cpu_facility" "*")])
diff --git a/gcc/testsuite/gcc.target/s390/pr80725.c
b/gcc/testsuite/gcc.target/s390/pr80725.c
new file mode 100644
index 000..4a402c4
--- /dev/null
+++ b/gcc/testsuite/gcc.target/s390/pr80725.c
@@ -0,0 +1,26 @@
+/* Regression test for PR/80725. */
+
+/* { dg-do compile } */
+/* { dg-options "-O2 -march=zEC12" } */
+
+int a, e;
+const char b;
+char c;
+const int d;
+void bar (short);
+
+void
+foo (int x, int y)
+{
+ long f = d;
+ short g = 0;
+ while (e)
+while (a < x)
+ {
+ if (y)
+ goto *d;
+ g = b | b + g;
+ bar (g);
+ c = (char) (long) foo;
+ }
+}
--
2.9.1
Re: Implementing OpenACC's Fortran module
Hi Jakub!
On Tue, 23 May 2017 13:12:00 +0200, Jakub Jelinek wrote:
> On Mon, May 22, 2017 at 05:23:25PM +0200, Thomas Schwinge wrote:
> > --- libgomp/openacc_lib.h
> > +++ libgomp/openacc_lib.h
> > @@ -191,23 +191,9 @@
> >end interface
> >
> >interface acc_pcopyin
> > -subroutine acc_pcopyin_32_h (a, len)
> > - use iso_c_binding, only: c_int32_t
> > - !GCC$ ATTRIBUTES NO_ARG_CHECK :: a
> > - type (*), dimension (*) :: a
> > - integer (c_int32_t) len
> > -end subroutine
> > -
> > -subroutine acc_pcopyin_64_h (a, len)
> > - use iso_c_binding, only: c_int64_t
> > - !GCC$ ATTRIBUTES NO_ARG_CHECK :: a
> > - type (*), dimension (*) :: a
> > - integer (c_int64_t) len
> > -end subroutine
> > -
> > -subroutine acc_pcopyin_array_h (a)
> > - type (*), dimension (..), contiguous :: a
> > - end subroutine
> > +procedure :: acc_present_or_copyin_32_h
> > +procedure :: acc_present_or_copyin_64_h
> > +procedure :: acc_present_or_copyin_array_h
> >end interface
>
> My Fortran knowledge is limited
Same here. ;-)
> does this actually provide
> the interfaces of those procedures (what arguments they have
> and other their properties)
This ("procedure" instead of "subroutine") is actually what "openacc.f90"
is using in the same context, and upon having inspected (already back in
April) the "-fdump-fortran-original" output for the new
"libgomp.oacc-fortran/lib-32-1.f" test case, this seemed to do the right
things. And, comparing that to the "openacc.f90" case
("libgomp.oacc-fortran/lib-32-2.f" test case with "USE OPENACC"), the
only difference in "-fdump-fortran-original" output relevant to this
issue here are (expected) additional "USE-ASSOC(openacc)" attributes.
> or shall it instead use
> subroutine acc_present_or_copyin_32_h (a, len)
> ...
> end subroutine
> etc. there?
Apparently not. These "subroutine"s have already declared above (for
"acc_present_or_copyin" proper), and if declaring them again here, we
get:
Error: Symbol 'acc_present_or_copyin_32_h' at (1) already has an explicit
interface
[...]
Thus OK for trunk, as posted?
Grüße
Thomas
[C++ PATCH] Hidden functions
We have functions that are invisible to (most) name lookups:
1) anticipated builtins -- these only become visible once declared, but
we need to know they match a builtin.
2) friends injected into namespace scope from a class definition.
This patch teaches the overload object about them with a new
OVL_HIDDEN_P marker (so we can just look at the overload node), and more
importantly it keeps them at the start of the overload list. That'll
make removing them from lookup results much simpler (a future patch).
Because of the ordering constraint, revealing a node is no longer so
simple. We may have to delete and reinsert it. Thus a check after
duplicate_decls discovers we're (re-)declaring a previously hidden decl.
The new testcases are to do with such unhiding. anticipated builtins
are always "C" functions, we need to do the check about extern "C"
declarations matching.
nathan
--
Nathan Sidwell
2017-05-24 Nathan Sidwell
gcc/cp/
* cp-tree.h (OVL_HIDDEN_P): New.
(ovl_iterator::hidden_p, ovl_iterator::reveal_node): New.
(ovl_iterator::reveal_node): Declare.
* tree.c (ovl_copy): Copy OVL_HIDDEN_P.
(ovl_insert): Order on hiddenness.
(ovl_iterator::reveal_node): New.
* name-lookup.c (anticipated_builtin_p): New.
(supplement_binding_1): Use it.
(set_local_extern_decl_linkage): Use hidden_p.
(do_pushdecl): Deal with unhiding a hidden decl, use
anticipated_builtin_p.
(do_nonmember_using_decl): Use anticipated_decl_p.
(lookup_name_real_1): Use DECL_HIDDEN_P.
gcc/testsuite/
* g++.dg/lookup/extern-c-hidden.C: New.
* g++.dg/lookup/extern-redecl1.C: New.
Index: cp/cp-tree.h
===
--- cp/cp-tree.h (revision 248387)
+++ cp/cp-tree.h (working copy)
@@ -378,6 +378,7 @@ extern GTY(()) tree cp_global_trees[CPTI
REF_PARENTHESIZED_P (in COMPONENT_REF, INDIRECT_REF, SCOPE_REF)
AGGR_INIT_ZERO_FIRST (in AGGR_INIT_EXPR)
CONSTRUCTOR_MUTABLE_POISON (in CONSTRUCTOR)
+ OVL_HIDDEN_P (in OVERLOAD)
3: (TREE_REFERENCE_EXPR) (in NON_LVALUE_EXPR) (commented-out).
ICS_BAD_FLAG (in _CONV)
FN_TRY_BLOCK_P (in TRY_BLOCK)
@@ -659,6 +660,8 @@ typedef struct ptrmem_cst * ptrmem_cst_t
/* If set, this was imported in a using declaration. */
#define OVL_USING_P(NODE) TREE_LANG_FLAG_1 (OVERLOAD_CHECK (NODE))
+/* If set, this overload is a hidden decl. */
+#define OVL_HIDDEN_P(NODE) TREE_LANG_FLAG_2 (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. */
@@ -729,15 +732,26 @@ class ovl_iterator
{
return TREE_CODE (ovl) == OVERLOAD && OVL_USING_P (ovl);
}
+ bool hidden_p () const
+ {
+return TREE_CODE (ovl) == OVERLOAD && OVL_HIDDEN_P (ovl);
+ }
+
+ public:
tree remove_node (tree head)
{
return remove_node (head, ovl);
}
+ tree reveal_node (tree head)
+ {
+return reveal_node (head, ovl);
+ }
private:
- /* We make this a static function to avoid the address of the
+ /* We make these static functions to avoid the address of the
iterator escaping the local context. */
static tree remove_node (tree head, tree node);
+ static tree reveal_node (tree ovl, tree node);
};
/* Iterator over a (potentially) 2 dimensional overload, which is
Index: cp/name-lookup.c
===
--- cp/name-lookup.c (revision 248387)
+++ cp/name-lookup.c (working copy)
@@ -1077,6 +1077,26 @@ strip_using_decl (tree decl)
return decl;
}
+/* Return true if OVL is an overload for an anticipated builtin. */
+
+static bool
+anticipated_builtin_p (tree ovl)
+{
+ if (TREE_CODE (ovl) != OVERLOAD)
+return false;
+
+ if (!OVL_HIDDEN_P (ovl))
+return false;
+
+ tree fn = OVL_FUNCTION (ovl);
+ gcc_checking_assert (DECL_ANTICIPATED (fn));
+
+ if (DECL_HIDDEN_FRIEND_P (fn))
+return false;
+
+ return true;
+}
+
/* BINDING records an existing declaration for a name in the current scope.
But, DECL is another declaration for that same identifier in the
same scope. This is the `struct stat' hack whereby a non-typedef
@@ -1131,9 +1151,7 @@ supplement_binding_1 (cxx_binding *bindi
|| target_bval == error_mark_node
/* If TARGET_BVAL is anticipated but has not yet been
declared, pretend it is not there at all. */
- || (TREE_CODE (target_bval) == FUNCTION_DECL
- && DECL_ANTICIPATED (target_bval)
- && !DECL_HIDDEN_FRIEND_P (target_bval)))
+ || anticipated_builtin_p (target_bval))
binding->value = decl;
else if (TREE_CODE (target_bval) == TYPE_DECL
&& DECL_ARTIFICIAL (target_bval)
@@ -1803,7 +1821,7 @@ set_local_extern_decl_linkage (tree decl
loc_value = NULL_TREE;
for (ovl_iterator iter (loc_value); iter; ++iter)
- if (!DECL_HIDDEN_P (*iter)
+ if (!iter.hidden_p ()
&& (TREE_STATIC (*iter) || DECL
Re: [PATCH] gcc::context creation
On Wed, May 24, 2017 at 12:57:28PM +0200, Jakub Jelinek wrote:
> So, first question, where should we order the -fdump-lang-* dumps, shall
> they go before .original/.gimple/.nested, or in between .original and
> .gimple/.nested, or after those 3 (the last option looks just wrong to me)?
> Shall the 3 standard dumps be registered like any others?
> Shall the number of lang dumps affect the numbering, i.e. is it desirable
> that with C and C++ you get different numbers for *t.cfg dump, or *t.gimple?
> In many cases it would be better if the numbering was consistent between C
> and C++.
If we wanted to order the dumps .original, .gimple, .nested, then 0-n *l.*
dumps, then the rest, then something like the following would work.
But I don't think we want to order .gimple before the *l.* dumps, and I'd
appreciate stable dump offsets between languages, so one can
./cc1 -fdump-tree-all 1.c
./cc1plus -fdump-tree-all 2.c
and diff -up {1,2}.c.074t.whatever instead of figuring out what different
numbers they have.
2017-05-24 Jakub Jelinek
* dumpfile.c (dump_files): Use num 1, 2, 3 instead of 3, 4, 5
for .original, .gimple and .nested.
(FIRST_AUTO_NUMBERED_DUMP): Increase to 4.
--- gcc/dumpfile.c.jj 2017-05-22 20:49:02.0 +0200
+++ gcc/dumpfile.c 2017-05-24 12:30:17.205182094 +0200
@@ -73,10 +73,10 @@ static struct dump_file_info dump_files[
dump_file_info (".cgraph", "ipa-cgraph", DK_ipa, 0),
dump_file_info (".type-inheritance", "ipa-type-inheritance", DK_ipa, 0),
dump_file_info (".ipa-clones", "ipa-clones", DK_ipa, 0),
- dump_file_info (".original", "tree-original", DK_tree, 3),
- dump_file_info (".gimple", "tree-gimple", DK_tree, 4),
- dump_file_info (".nested", "tree-nested", DK_tree, 5),
-#define FIRST_AUTO_NUMBERED_DUMP 3
+ dump_file_info (".original", "tree-original", DK_tree, 1),
+ dump_file_info (".gimple", "tree-gimple", DK_tree, 2),
+ dump_file_info (".nested", "tree-nested", DK_tree, 3),
+#define FIRST_AUTO_NUMBERED_DUMP 4
dump_file_info (NULL, "lang-all", DK_lang, 0),
dump_file_info (NULL, "tree-all", DK_tree, 0),
Jakub
Re: C/C++ OpenACC: acc_pcopyin, acc_pcreate
On Wed, May 24, 2017 at 12:55:27PM +0200, Thomas Schwinge wrote:
> Hi Jakub!
>
> On Tue, 23 May 2017 13:07:15 +0200, Jakub Jelinek wrote:
> > On Mon, May 22, 2017 at 04:26:48PM +0200, Thomas Schwinge wrote:
> > > In , we currently describe acc_pcopyin, acc_pcreate as "old
> > > names", but they're not "old" but really "alternative names", with the
> > > intention to provide them at symbol level, not via "#define"s.
>
> > > * libgomp.map (OACC_2.0): Add "acc_pcopyin", and
> > > "acc_pcreate".
> >
> > > --- libgomp/libgomp.map
> > > +++ libgomp/libgomp.map
> > > @@ -335,6 +335,7 @@ OACC_2.0 {
>
> > > acc_present_or_copyin;
> > > + acc_pcopyin;
>
> > > acc_present_or_create;
> > > + acc_pcreate;
>
> > This is just wrong, new symbols should never be added to an existing symbol
> > version after a GCC version with that symbol version has been released.
> > You can add it into OACC_2.0.1, or OACC_1.0, or whatever else, but certainly
> > not into OACC_2.0.
>
> I certainly have no problem using a new "OACC_2.0.1" symbol version
> instead of "OACC_2.0", but would you please remind me where this
> requirement is coming from?
There are many reasons, one is e.g. that the dynamic linker uses the symbol
version names during library loading to verify the library satisfies the
needs of a binary or some other library; if you add further symbols into
existing symbol version, then it will be satisfied even by library that
doesn't provide the symbol (in the above case say acc_pcopyin), and you can
get a failure either much later (during relocation processing, with lazy
binding that can be much later), or not at all (with lazy binding and if
the function isn't called at all during the runtime of the program).
Another one is e.g. rpm uses symbol versions in dependencies, but only
those and not at the required/provided symbol granularity. So, if you
have acc_pcopyin@@OACC_2.0.1 and use it in some program, the program
will have a dependency on libgomp.so.1()(OACC_2.0.1) and thus you
automatically get the right library that provides it. If you add to an
existing symbol version, the dependency will be satisfied even for libraries
that don't provide it at all.
All in all, symbol versions aren't there just for documentation purposes,
but serve various other roles, including the possibility to change ABI
of existing symbols, but not limited to that. The policy of not adding
new symbols into symbol versions that were already shipped in released
libraries is something that is strictly followed in glibc, gcc libraries
(I remember in libstdc++ a bug happened some years ago and some symbols
were unintentionally exported at an earlier version, which has been cured
by moving into a new symbol version and providing the old one just as an @
(vs. @@) symver for compatibility only; e.g. the current libstdc++ check-abi
stuff verifies this stuff).
For more info see e.g. https://www.akkadia.org/drepper/symbol-versioning
> But that will only redirect them at the user side. The intention here is
The question is if the OpenACC standard allows that or not.
> to also care for users providing their own declarations instead of using
> , or using "dlsym", and so on -- quite "pathological", I know,
> but...
>
> OK for trunk using "OACC_2.0.1" symbol version?
Ok.
> commit 30118ce81354e72e5f32f9ae0ee0f9ef4361747a
> Author: Thomas Schwinge
> Date: Wed May 24 12:49:04 2017 +0200
>
> C/C++ OpenACC: acc_pcopyin, acc_pcreate
>
> libgomp/
> * openacc.h (acc_pcopyin, acc_pcreate): Provide prototypes instead
> of preprocessor definitions.
> * libgomp.h (strong_alias): Guard by "#ifdef
> HAVE_ATTRIBUTE_ALIAS".
> * oacc-mem.c: Provide "acc_pcreate" as alias for
> "acc_present_or_create", and "acc_pcopyin" as alias for
> "acc_present_or_copyin".
> * libgomp.map: New version "OACC_2.0.1".
> (OACC_2.0.1): Add "acc_pcopyin", and "acc_pcreate".
> * testsuite/libgomp.oacc-c-c++-common/lib-38.c: Remove, merging
> its content into...
> * testsuite/libgomp.oacc-c-c++-common/lib-32.c: ... this file.
> Extend testing.
Jakub
Re: [PATCH] Try harder to fix recently introduced crashes in ggc_collect
On Fri, May 19, 2017 at 10:10:23AM -0400, Nathan Sidwell wrote: > On 05/19/2017 10:05 AM, Bernd Edlinger wrote: > > > hwi cannot be the root cause of the problem, > > because it can only be long_integer_type_node > > or long_long_integer_type_node, otherwise > > an error would be triggered. > > that's the error I made with the static fns. PCH moves things around, so > anything that can be streamed via PCH must be GTY marked. Also, I'm not > sure if the current GC is a compacting GC (given PCH can compact things?) other than pch which I'm not sure about I'm pretty sure its not, and is just basic mark and sweep. That said if modules can get merged for gcc 8 I'm very tempted to rm pch now. Trev > > nathan > -- > Nathan Sidwell
[PATCH v2 05/N] Add -fdump*-folding suboption.
Hello.
After discussions with Richi, I decided to end up with the transformation and
thus
I would like to apply the original patch on top of what was done. Probably last
change
should be that we should renumber TDF_* values to start from 1 << 0 and holes
in numbering
should be eliminated?
Thanks,
Martin
>From d0cab884035be37e5ceab54384611830661fdd9f Mon Sep 17 00:00:00 2001
From: marxin
Date: Wed, 24 May 2017 10:32:42 +0200
Subject: [PATCH] Add -fdump*-folding suboption.
gcc/ChangeLog:
2017-05-24 Martin Liska
* dumpfile.c: Add TDF_FOLDING.
* dumpfile.h (enum dump_kind): Likewise.
* genmatch.c (dt_simplify::gen_1): Use it.
---
gcc/dumpfile.c | 1 +
gcc/dumpfile.h | 1 +
gcc/genmatch.c | 2 +-
3 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/gcc/dumpfile.c b/gcc/dumpfile.c
index 13a711345b4..903d879e784 100644
--- a/gcc/dumpfile.c
+++ b/gcc/dumpfile.c
@@ -118,6 +118,7 @@ static const struct dump_option_value_info dump_options[] =
{"enumerate_locals", TDF_ENUMERATE_LOCALS},
{"scev", TDF_SCEV},
{"gimple", TDF_GIMPLE},
+ {"folding", TDF_FOLDING},
{"optimized", MSG_OPTIMIZED_LOCATIONS},
{"missed", MSG_MISSED_OPTIMIZATION},
{"note", MSG_NOTE},
diff --git a/gcc/dumpfile.h b/gcc/dumpfile.h
index a1e4720156d..abb4d93a93b 100644
--- a/gcc/dumpfile.h
+++ b/gcc/dumpfile.h
@@ -92,6 +92,7 @@ enum dump_kind
#define TDF_SCEV (1 << 24) /* Dump SCEV details. */
#define TDF_COMMENT (1 << 25) /* Dump lines with prefix ";;" */
#define TDF_GIMPLE (1 << 26) /* Dump in GIMPLE FE syntax */
+#define TDF_FOLDING (1 << 27) /* Dump folding details. */
#define MSG_OPTIMIZED_LOCATIONS (1 << 27) /* -fopt-info optimized sources */
#define MSG_MISSED_OPTIMIZATION (1 << 28) /* missed opportunities */
#define MSG_NOTE (1 << 29) /* general optimization info */
diff --git a/gcc/genmatch.c b/gcc/genmatch.c
index 2c3183b25af..f20e39f9158 100644
--- a/gcc/genmatch.c
+++ b/gcc/genmatch.c
@@ -3191,7 +3191,7 @@ dt_simplify::gen_1 (FILE *f, int indent, bool gimple, operand *result)
}
}
- fprintf_indent (f, indent, "if (dump_file && (dump_flags & TDF_DETAILS)) "
+ fprintf_indent (f, indent, "if (dump_file && (dump_flags & TDF_FOLDING)) "
"fprintf (dump_file, \"Applying pattern ");
output_line_directive (f,
result ? result->location : s->match->location, true);
--
2.12.2
[PATCH] [ARC] Fix tst_movb pattern.
From: claziss
The tst_movb pattern is missing guarding when spitting.
gcc/
2017-05-24 Claudiu Zissulescu
* config/arc/arc.md (tst_movb): Add guard when splitting.
testsuite/
2017-05-24 Claudiu Zissulescu
* gcc.target/arc/pr9001195952.c: New test.
---
gcc/config/arc/arc.md | 2 +-
gcc/testsuite/gcc.target/arc/pr9001195952.c | 11 +++
2 files changed, 12 insertions(+), 1 deletion(-)
create mode 100755 gcc/testsuite/gcc.target/arc/pr9001195952.c
diff --git a/gcc/config/arc/arc.md b/gcc/config/arc/arc.md
index e78abaa..d5510ae 100644
--- a/gcc/config/arc/arc.md
+++ b/gcc/config/arc/arc.md
@@ -863,7 +863,7 @@ archs4xd, archs4xd_slow"
(clobber (match_scratch:SI 3 "=X,X,X,X,X,X,Rrq,Rrq,c"))]
"TARGET_NPS_BITOPS"
"movb.f.cl %3,%1,%p2,%p2,%s2"
- "reload_completed
+ "TARGET_NPS_BITOPS && reload_completed
&& (extract_constrain_insn_cached (insn), (which_alternative & ~1) != 6)"
[(set (match_dup 0) (match_dup 4))])
diff --git a/gcc/testsuite/gcc.target/arc/pr9001195952.c
b/gcc/testsuite/gcc.target/arc/pr9001195952.c
new file mode 100755
index 000..252438d
--- /dev/null
+++ b/gcc/testsuite/gcc.target/arc/pr9001195952.c
@@ -0,0 +1,11 @@
+/* { dg-do compile } */
+/* { dg-skip-if "" { ! { clmcpu } } } */
+/* { dg-options "-mcpu=archs -Os -w -fpic" } */
+
+/* tst_movb split pattern is wrong for anything else than NPS
+ chip. */
+__bswap_32___bsx() {
+ int a = __builtin_bswap32(__bswap_32___bsx);
+ if (a & 1048575)
+zlog_warn();
+}
--
1.9.1
Re: [PATCH] gcc::context creation
On Thu, May 18, 2017 at 11:08:51AM -0400, Nathan Sidwell wrote: > On 05/16/2017 11:26 AM, Nathan Sidwell wrote: > > This patch breaks apart the creation of the pass manager from > > gcc::context's ctor. This will allow us to register additional dumps > ... https://gcc.gnu.org/ml/gcc-patches/2017-05/msg01295.html > > This patch builds upon the context creation patch (this diff includes it), > to implement a new LANG_HOOK_REGISTER_DUMPS language hook. I call it > between creating the dump manager and instantiating the optimization passes. > > The patch then uses the hook to move the current -fdump-class-hierarchy > option into the C++ FE entirely, removing TDI_class and associated handling > from dumpfile and c-family/c-opts.c. The option gets renamed to > -fdump-lang-class in the process. > > Obviously -fdump-translation-unit is the next candidate, and possibly > -fdump-tree-original. This breaks the dump numbering. On some simple source file with some OpenMP pragmas in it, with C and -fopenmp -fdump-tree-all I'm getting (so unless one knows the order of passes, the indexes and file order no longer reveal the actual pass sequence): 1.c.003t.omplower 1.c.003t.original 1.c.004t.gimple 1.c.004t.lower 1.c.007t.eh 1.c.008t.cfg 1.c.009t.ompexp ... The right order is .original, .gimple, then (not included) .nested, then .omplower, .lower, etc. With C++ -fopenmp -fdump-tree-all I'm getting: 1.c.003t.original 1.c.004t.gimple 1.c.005t.omplower 1.c.006t.lower 1.c.008t.ehopt 1.c.009t.eh ... which is slightly better, but there is no space for e.g. the .nested dump. With -fopenmp -fdump-tree-all -fdump-lang-all and C++ I'm getting 1.c.003t.original 1.c.004l.raw 1.c.004t.gimple 1.c.005t.omplower 1.c.006t.lower 1.c.008t.ehopt 1.c.009t.eh ... so there is a number clash in between the raw and gimple dumps in addition to the nested vs. omplower. So, first question, where should we order the -fdump-lang-* dumps, shall they go before .original/.gimple/.nested, or in between .original and .gimple/.nested, or after those 3 (the last option looks just wrong to me)? Shall the 3 standard dumps be registered like any others? Shall the number of lang dumps affect the numbering, i.e. is it desirable that with C and C++ you get different numbers for *t.cfg dump, or *t.gimple? In many cases it would be better if the numbering was consistent between C and C++. Jakub
Re: C/C++ OpenACC: acc_pcopyin, acc_pcreate
Hi Jakub!
On Tue, 23 May 2017 13:07:15 +0200, Jakub Jelinek wrote:
> On Mon, May 22, 2017 at 04:26:48PM +0200, Thomas Schwinge wrote:
> > In , we currently describe acc_pcopyin, acc_pcreate as "old
> > names", but they're not "old" but really "alternative names", with the
> > intention to provide them at symbol level, not via "#define"s.
> > * libgomp.map (OACC_2.0): Add "acc_pcopyin", and "acc_pcreate".
>
> > --- libgomp/libgomp.map
> > +++ libgomp/libgomp.map
> > @@ -335,6 +335,7 @@ OACC_2.0 {
> > acc_present_or_copyin;
> > + acc_pcopyin;
> > acc_present_or_create;
> > + acc_pcreate;
> This is just wrong, new symbols should never be added to an existing symbol
> version after a GCC version with that symbol version has been released.
> You can add it into OACC_2.0.1, or OACC_1.0, or whatever else, but certainly
> not into OACC_2.0.
I certainly have no problem using a new "OACC_2.0.1" symbol version
instead of "OACC_2.0", but would you please remind me where this
requirement is coming from?
> Another option is just to use something like glibc's sys/cdefs.h
> __REDIRECT_NTH macro (including the __USER_LABEL_PREFIX__ stuff)
> and just declare those functions as having the asm name of the corresponding
> alias. The openacc.h header is for use with GCC only anyway, right?
But that will only redirect them at the user side. The intention here is
to also care for users providing their own declarations instead of using
, or using "dlsym", and so on -- quite "pathological", I know,
but...
OK for trunk using "OACC_2.0.1" symbol version?
commit 30118ce81354e72e5f32f9ae0ee0f9ef4361747a
Author: Thomas Schwinge
Date: Wed May 24 12:49:04 2017 +0200
C/C++ OpenACC: acc_pcopyin, acc_pcreate
libgomp/
* openacc.h (acc_pcopyin, acc_pcreate): Provide prototypes instead
of preprocessor definitions.
* libgomp.h (strong_alias): Guard by "#ifdef
HAVE_ATTRIBUTE_ALIAS".
* oacc-mem.c: Provide "acc_pcreate" as alias for
"acc_present_or_create", and "acc_pcopyin" as alias for
"acc_present_or_copyin".
* libgomp.map: New version "OACC_2.0.1".
(OACC_2.0.1): Add "acc_pcopyin", and "acc_pcreate".
* testsuite/libgomp.oacc-c-c++-common/lib-38.c: Remove, merging
its content into...
* testsuite/libgomp.oacc-c-c++-common/lib-32.c: ... this file.
Extend testing.
---
libgomp/libgomp.h | 5 +-
libgomp/libgomp.map| 6 +
libgomp/oacc-mem.c | 22 ++
libgomp/openacc.h | 7 +-
.../testsuite/libgomp.oacc-c-c++-common/lib-32.c | 241 +++--
.../testsuite/libgomp.oacc-c-c++-common/lib-38.c | 64 --
6 files changed, 258 insertions(+), 87 deletions(-)
diff --git libgomp/libgomp.h libgomp/libgomp.h
index 1769a48..940b5b8 100644
--- libgomp/libgomp.h
+++ libgomp/libgomp.h
@@ -1060,8 +1060,6 @@ extern void gomp_set_nest_lock_25 (omp_nest_lock_25_t *)
__GOMP_NOTHROW;
extern void gomp_unset_nest_lock_25 (omp_nest_lock_25_t *) __GOMP_NOTHROW;
extern int gomp_test_nest_lock_25 (omp_nest_lock_25_t *) __GOMP_NOTHROW;
-# define strong_alias(fn, al) \
- extern __typeof (fn) al __attribute__ ((alias (#fn)));
# define omp_lock_symver(fn) \
__asm (".symver g" #fn "_30, " #fn "@@OMP_3.0"); \
__asm (".symver g" #fn "_25, " #fn "@OMP_1.0");
@@ -1085,6 +1083,9 @@ extern int gomp_test_nest_lock_25 (omp_nest_lock_25_t *)
__GOMP_NOTHROW;
#endif
#ifdef HAVE_ATTRIBUTE_ALIAS
+# define strong_alias(fn, al) \
+ extern __typeof (fn) al __attribute__ ((alias (#fn)));
+
# define ialias_ulpialias_str1(__USER_LABEL_PREFIX__)
# define ialias_str1(x)ialias_str2(x)
# define ialias_str2(x)#x
diff --git libgomp/libgomp.map libgomp/libgomp.map
index 4d42c42..b43c6de 100644
--- libgomp/libgomp.map
+++ libgomp/libgomp.map
@@ -378,6 +378,12 @@ OACC_2.0 {
acc_set_cuda_stream;
};
+OACC_2.0.1 {
+ global:
+ acc_pcopyin;
+ acc_pcreate;
+} OACC_2.0;
+
GOACC_2.0 {
global:
GOACC_data_end;
diff --git libgomp/oacc-mem.c libgomp/oacc-mem.c
index 2df2202..ff3ed49 100644
--- libgomp/oacc-mem.c
+++ libgomp/oacc-mem.c
@@ -514,12 +514,34 @@ acc_present_or_create (void *h, size_t s)
return present_create_copy (FLAG_PRESENT | FLAG_CREATE, h, s);
}
+/* acc_pcreate is acc_present_or_create by a different name. */
+#ifdef HAVE_ATTRIBUTE_ALIAS
+strong_alias (acc_present_or_create, acc_pcreate)
+#else
+void *
+acc_pcreate (void *h, size_t s)
+{
+ return acc_present_or_create (h, s);
+}
+#endif
+
void *
acc_present_or_copyin (void *h, size_t s)
{
return present_create_copy (FLAG_PRESENT | FLAG_CREATE | FLAG_COPY, h, s);
}
+/* acc_pcopyin is acc_present_or_copyin by a different name. */
+#ifdef HAVE_ATTRIBUTE_ALIAS
+strong_alias (acc_present_or_copyin,
Re: [PATCH GCC][3/6]Fix PR80815 by handling negative DR_STEPs in runtime alias check
"Bin.Cheng" writes:
> On Tue, May 23, 2017 at 6:53 PM, Richard Sandiford
> wrote:
>> AIUI, the reason the old code mishandled negative steps was that the
>> associated segment lengths were stored as sizetype and so looked like
>> big unsigned values. Those values therefore satisfied tree_fits_uhwi_p
>> even though they were semantically negative. Is that right?
> Yes, and the undesired wrapping behavior when such large unsigned hwi
> is involved in computation. But I think there are possible leaks in
> the code even after this patch, as embedded below.
>>
>> Assuming yes, and quoting the change as a context diff...
>>
>>> diff --git a/gcc/tree-data-ref.c b/gcc/tree-data-ref.c
>>> index a5f8c1c..f0799d9 100644
>>> *** a/gcc/tree-data-ref.c
>>> --- b/gcc/tree-data-ref.c
>>> ***
>>> *** 1259,1264
>>> --- 1259,1273
>>> != tree_int_cst_compare (DR_STEP (dr_a2->dr), size_zero_node))
>>> continue;
>>>
>>> + bool neg_step
>>> + = (tree_int_cst_compare (DR_STEP (dr_a1->dr), size_zero_node) <
>>> 0);
>>> +
>>> + /* DR_A1 and DR_A2 must have the same step if it's negative. */
>>> + if (neg_step
>>> + && tree_int_cst_compare (DR_STEP (dr_a1->dr),
>>> +DR_STEP (dr_a2->dr)) != 0)
>>> + continue;
>>> +
>>
>> [Why do they need to be the same step?]
> There are two reasons. First is to simplify diff computation between
> dr_a1 and dr_a2, otherwise we need to adjust diff for negative steps.
What kind of adjustment would be needed? Could you give an example?
> And wrapping behavior needs to be handled when adjusting diff with
> steps. The second reason is not fully handled in this patch. We now
> only set merged segment length to MAX only when both dr_a1->seg_len
> and dr_a2->seg_len are constant, as below:
> + if (tree_fits_uhwi_p (dr_a1->seg_len)
> + && tree_fits_uhwi_p (dr_a2->seg_len))
> +new_seg_len
> + = size_int (MAX (tree_to_uhwi (dr_a1->seg_len),
> + diff + tree_to_uhwi (dr_a2->seg_len)));
> + else
> +new_seg_len
> + = size_binop (PLUS_EXPR, dr_a2->seg_len, size_int (diff));
> In fact, we should do this for else branch too. with different steps,
> it is still possible that dr_a1-seg_len > dr_a2->seg_len + diff. Here
> I only restrict it to negative DR_STEP. Patch updated with
> explanation in comment.
>>
>>> /* Make sure dr_a1 starts left of dr_a2. */
>>> if (tree_int_cst_lt (DR_INIT (dr_a2->dr), DR_INIT (dr_a1->dr)))
>>> std::swap (*dr_a1, *dr_a2);
>>> ***
>>> *** 1266,1325
>>> bool do_remove = false;
>>> unsigned HOST_WIDE_INT diff
>>> = (tree_to_shwi (DR_INIT (dr_a2->dr))
>>> !- tree_to_shwi (DR_INIT (dr_a1->dr)));
>>>
>>> ! /* If the left segment does not extend beyond the start of the
>>> ! right segment the new segment length is that of the right
>>> ! plus the segment distance. */
>>> ! if (tree_fits_uhwi_p (dr_a1->seg_len)
>>> ! && compare_tree_int (dr_a1->seg_len, diff) <= 0)
>>> {
>>> ! dr_a1->seg_len = size_binop (PLUS_EXPR, dr_a2->seg_len,
>>> !size_int (diff));
>>> ! do_remove = true;
>>> }
>>> ! /* Generally the new segment length is the maximum of the
>>> ! left segment size and the right segment size plus the distance.
>>> ! ??? We can also build tree MAX_EXPR here but it's not clear this
>>> ! is profitable. */
>>> ! else if (tree_fits_uhwi_p (dr_a1->seg_len)
>>> !&& tree_fits_uhwi_p (dr_a2->seg_len))
>>> ! {
>>> ! unsigned HOST_WIDE_INT seg_len_a1 = tree_to_uhwi
>>> (dr_a1->seg_len);
>>> ! unsigned HOST_WIDE_INT seg_len_a2 = tree_to_uhwi
>>> (dr_a2->seg_len);
>>> ! dr_a1->seg_len = size_int (MAX (seg_len_a1, diff + seg_len_a2));
>>> ! do_remove = true;
>>> ! }
>>> ! /* Now we check if the following condition is satisfied:
>>>
>>> ! DIFF - SEGMENT_LENGTH_A < SEGMENT_LENGTH_B
>>>
>>> ! where DIFF = DR_A2_INIT - DR_A1_INIT. However,
>>> ! SEGMENT_LENGTH_A or SEGMENT_LENGTH_B may not be constant so we
>>> ! have to make a best estimation. We can get the minimum value
>>> ! of SEGMENT_LENGTH_B as a constant, represented by MIN_SEG_LEN_B,
>>> ! then either of the following two conditions can guarantee the
>>> ! one above:
>>>
>>> ! 1: DIFF <= MIN_SEG_LEN_B
>>> ! 2: DIFF - SEGMENT_LENGTH_A < MIN_SEG_LEN_B */
>>> ! else
>>> {
>>> ! unsigned HOST_WIDE_INT min_seg_len_b
>>> ! = (tree_fits_uhwi_p (dr_b1->seg_len)
>>> !? tree_to_uhwi (dr_b1->seg_len)
>>> !: factor);
>>>
>>> if (diff <= m
Re: [PATCH GCC][3/6]Fix PR80815 by handling negative DR_STEPs in runtime alias check
On Tue, May 23, 2017 at 6:53 PM, Richard Sandiford
wrote:
> AIUI, the reason the old code mishandled negative steps was that the
> associated segment lengths were stored as sizetype and so looked like
> big unsigned values. Those values therefore satisfied tree_fits_uhwi_p
> even though they were semantically negative. Is that right?
Yes, and the undesired wrapping behavior when such large unsigned hwi
is involved in computation. But I think there are possible leaks in
the code even after this patch, as embedded below.
>
> Assuming yes, and quoting the change as a context diff...
>
>> diff --git a/gcc/tree-data-ref.c b/gcc/tree-data-ref.c
>> index a5f8c1c..f0799d9 100644
>> *** a/gcc/tree-data-ref.c
>> --- b/gcc/tree-data-ref.c
>> ***
>> *** 1259,1264
>> --- 1259,1273
>> != tree_int_cst_compare (DR_STEP (dr_a2->dr), size_zero_node))
>> continue;
>>
>> + bool neg_step
>> + = (tree_int_cst_compare (DR_STEP (dr_a1->dr), size_zero_node) < 0);
>> +
>> + /* DR_A1 and DR_A2 must have the same step if it's negative. */
>> + if (neg_step
>> + && tree_int_cst_compare (DR_STEP (dr_a1->dr),
>> +DR_STEP (dr_a2->dr)) != 0)
>> + continue;
>> +
>
> [Why do they need to be the same step?]
There are two reasons. First is to simplify diff computation between
dr_a1 and dr_a2, otherwise we need to adjust diff for negative steps.
And wrapping behavior needs to be handled when adjusting diff with
steps. The second reason is not fully handled in this patch. We now
only set merged segment length to MAX only when both dr_a1->seg_len
and dr_a2->seg_len are constant, as below:
+ if (tree_fits_uhwi_p (dr_a1->seg_len)
+ && tree_fits_uhwi_p (dr_a2->seg_len))
+new_seg_len
+ = size_int (MAX (tree_to_uhwi (dr_a1->seg_len),
+ diff + tree_to_uhwi (dr_a2->seg_len)));
+ else
+new_seg_len
+ = size_binop (PLUS_EXPR, dr_a2->seg_len, size_int (diff));
In fact, we should do this for else branch too. with different steps,
it is still possible that dr_a1-seg_len > dr_a2->seg_len + diff. Here
I only restrict it to negative DR_STEP. Patch updated with
explanation in comment.
>
>> /* Make sure dr_a1 starts left of dr_a2. */
>> if (tree_int_cst_lt (DR_INIT (dr_a2->dr), DR_INIT (dr_a1->dr)))
>> std::swap (*dr_a1, *dr_a2);
>> ***
>> *** 1266,1325
>> bool do_remove = false;
>> unsigned HOST_WIDE_INT diff
>> = (tree_to_shwi (DR_INIT (dr_a2->dr))
>> !- tree_to_shwi (DR_INIT (dr_a1->dr)));
>>
>> ! /* If the left segment does not extend beyond the start of the
>> ! right segment the new segment length is that of the right
>> ! plus the segment distance. */
>> ! if (tree_fits_uhwi_p (dr_a1->seg_len)
>> ! && compare_tree_int (dr_a1->seg_len, diff) <= 0)
>> {
>> ! dr_a1->seg_len = size_binop (PLUS_EXPR, dr_a2->seg_len,
>> !size_int (diff));
>> ! do_remove = true;
>> }
>> ! /* Generally the new segment length is the maximum of the
>> ! left segment size and the right segment size plus the distance.
>> ! ??? We can also build tree MAX_EXPR here but it's not clear this
>> ! is profitable. */
>> ! else if (tree_fits_uhwi_p (dr_a1->seg_len)
>> !&& tree_fits_uhwi_p (dr_a2->seg_len))
>> ! {
>> ! unsigned HOST_WIDE_INT seg_len_a1 = tree_to_uhwi
>> (dr_a1->seg_len);
>> ! unsigned HOST_WIDE_INT seg_len_a2 = tree_to_uhwi
>> (dr_a2->seg_len);
>> ! dr_a1->seg_len = size_int (MAX (seg_len_a1, diff + seg_len_a2));
>> ! do_remove = true;
>> ! }
>> ! /* Now we check if the following condition is satisfied:
>>
>> ! DIFF - SEGMENT_LENGTH_A < SEGMENT_LENGTH_B
>>
>> ! where DIFF = DR_A2_INIT - DR_A1_INIT. However,
>> ! SEGMENT_LENGTH_A or SEGMENT_LENGTH_B may not be constant so we
>> ! have to make a best estimation. We can get the minimum value
>> ! of SEGMENT_LENGTH_B as a constant, represented by MIN_SEG_LEN_B,
>> ! then either of the following two conditions can guarantee the
>> ! one above:
>>
>> ! 1: DIFF <= MIN_SEG_LEN_B
>> ! 2: DIFF - SEGMENT_LENGTH_A < MIN_SEG_LEN_B */
>> ! else
>> {
>> ! unsigned HOST_WIDE_INT min_seg_len_b
>> ! = (tree_fits_uhwi_p (dr_b1->seg_len)
>> !? tree_to_uhwi (dr_b1->seg_len)
>> !: factor);
>>
>> if (diff <= min_seg_len_b
>> || (tree_fits_uhwi_p (dr_a1->seg_len)
>> ! && diff - tree_to_uhwi (dr_a1->seg_len) < min_seg_len_b))
>> {
>> ! dr_a1->seg_len = size_binop (PLUS_EXPR
Re: Relax VIEW_CONVERT_EXPR - CONVERT_EXPR combination
On Sun, May 21, 2017 at 11:21 PM, Marc Glisse wrote: > Hello, > > SRA uses char when scalarizing bool, and we end up with > > _6 = u_1(D) == 0.0; > _7 = (unsigned char) _6; > _3 = VIEW_CONVERT_EXPR<_Bool>(_7); > > which we currently do not simplify. I am not completely sure what happens > with types whose precision does not cover their size, I hope this is safe. Hmm, if zero-extension is safe so should sign-extension, no? Because if size != precision then both can actually change bits outside of the precision? I realize zero-extension is "safer" in some sense as the extended value is the same for all precisions. Thus OK. thanks, Richard. > Bootstrap+testsuite on powerpc64le-unknown-linux-gnu. > > 2017-05-22 Marc Glisse > > gcc/ > * match.pd (view_convert (convert@0 @1)): Handle zero-extension. > > gcc/testsuite/ > * gcc.dg/tree-ssa/vce-1.c: New file. > > -- > Marc Glisse
Re: signed multiplication for pointer offsets
On Sun, May 21, 2017 at 9:45 PM, Marc Glisse wrote: > Hello, > > when we have a double*p, computing p+n, we multiply n by 8 (size of double) > then add it to p. According to the comment just below the modified lines in > the attached patch, the multiplication is supposed to happen in a signed > type. However, that does not match the current code which uses sizetype. > This is causing missed optimizations, for instance, when comparing p+m and > p+n, we might end up comparing 8*m to 8*n, which is not the same as > comparing m and n if overflow can happen. > > I tried this patch to see how much breaks. And actually, not that much does. > There are a few fragile testcases that want to match "q_. " but it is now > "q_10 ", or they expect 3 simplifications and get 5 (same final code). One > was confused by a cast in the middle of x+cst1+cst2. A couple were hit by > the lack of CSE between (x+1)*8, x*8+8, and some variants with casts in the > middle, but that's already an issue without the patch. A few vectorization > testcases failed because SCEV did not recognize a simple increment of a > variable with NOP casts in the middle, that would be worth fixing. The patch > actually fixed another vectorization testcase. > > I guess it would help if pointer_plus switched to a signed second argument, > to be consistent with this and reduce the number of casts. Yes. In fact the pointer-plus offset is to be interpreted as signed anyway so that it uses unsigned sizetype was a bad decision back in time. Bin tried to fix this last year but I'm not sure what came of his experiments. > I am not proposing the patch as is, but is this the direction we want to > follow, or should I just fix the comment to match what the code does? I think I tried this at some point and I don't remember the result. I did that in the context of the even more ambitious attempt to make pointer-plus take either sizetype or ssizetype typed offsets... The standard doesn't actually talk about what type to perform the multiplication in but given we effectively restrict objects to the size of half of the address space due to ptrdiff_t limitations using either a signed or unsigned type should work. Richard. > -- > Marc Glisse
Re: Ipa function summary pass
Hi,
On 23 May 2017 at 18:23, Jan Hubicka wrote:
> Hi,
> this patch finishes the breakup of ipa-inline and function analysis.
> The analysis is now done by separate pass and I will work on cleaning
> up the interfaces now.
>
> Honza
>
> * cgraphunit.c (symbol_table::process_new_functions): Update.
> * ipa-fnsummary.c (pass_data_inline_parameters): Remove.
> (inline_generate_summary): Rename to ...
> (ipa_fn_summary_generate): ... this one.
> (inline_read_summary): Rename to ...
> (ipa_fn_summary_read): ... this one.
> (inline_write_summary): Rename to ...
> (ipa_fn_summary_write): ... this one.
> (inline_free_summary): Rename to ...
> (ipa_free_fn_summary): ... this one.
> (pass_data_local_fn_summary, pass_local_fn_summary,
> make_pass_local_fn_summary, pass_data_ipa_free_fn_summary,
> pass_ipa_free_fn_summary, make_pass_ipa_free_fn_summary,
> pass_data_ipa_fn_summary, pass_ipa_fn_summary,
> make_pass_ipa_fn_summary): New.
> * ipa-fnsummary.h (inline_generate_summary, inline_read_summary,
> inline_write_summary, inline_free_summary): Remove.
> (ipa_free_fn_summary) : New.
> * ipa-inline.c (ipa_inline): Update.
> (pass_ipa_inline): Do not generate summaries.
> * ipa.c (pass_data_ipa_free_fn_summary, pass_ipa_free_fn_summary):
> Remove.
> * passes.def: Replace pass_inline_parameters by pass_local_fn_summary
> and add pass_ipa_fn_summary.
> * tree-pass.h (make_pass_ipa_fn_summary, make_pass_local_fn_summary):
> New.
> (make_pass_inline_parameters): Remove.
>
> * lto.c (do_whole_program_analysis): Replace inline_free_summary
> by ipa_free_fn_summary.
>
> * gcc.dg/ipa/ctor-empty-1.c: Update template.
> * gcc.dg/ipa/inline-5.c: Likewise.
> * gfortran.dg/pr48636.f90: Likewise.
> Index: cgraphunit.c
> ===
> --- cgraphunit.c(revision 248365)
> +++ cgraphunit.c(working copy)
> @@ -339,7 +339,7 @@ symbol_table::process_new_functions (voi
> and splitting. This is redundant for functions added late.
> Just throw away whatever it did. */
> if (!summaried_computed)
> - inline_free_summary ();
> + ipa_free_fn_summary ();
> }
> else if (ipa_fn_summaries != NULL)
> compute_fn_summary (node, true);
> Index: ipa-fnsummary.c
> ===
> --- ipa-fnsummary.c (revision 248366)
> +++ ipa-fnsummary.c (working copy)
> @@ -2504,46 +2504,6 @@ compute_fn_summary_for_current (void)
>return 0;
> }
>
> -namespace {
> -
> -const pass_data pass_data_inline_parameters =
> -{
> - GIMPLE_PASS, /* type */
> - "inline_param", /* name */
> - OPTGROUP_INLINE, /* optinfo_flags */
> - TV_INLINE_PARAMETERS, /* tv_id */
> - 0, /* properties_required */
> - 0, /* properties_provided */
> - 0, /* properties_destroyed */
> - 0, /* todo_flags_start */
> - 0, /* todo_flags_finish */
> -};
> -
> -class pass_inline_parameters : public gimple_opt_pass
> -{
> -public:
> - pass_inline_parameters (gcc::context *ctxt)
> -: gimple_opt_pass (pass_data_inline_parameters, ctxt)
> - {}
> -
> - /* opt_pass methods: */
> - opt_pass * clone () { return new pass_inline_parameters (m_ctxt); }
> - virtual unsigned int execute (function *)
> -{
> - return compute_fn_summary_for_current ();
> -}
> -
> -}; // class pass_inline_parameters
> -
> -} // anon namespace
> -
> -gimple_opt_pass *
> -make_pass_inline_parameters (gcc::context *ctxt)
> -{
> - return new pass_inline_parameters (ctxt);
> -}
> -
> -
> /* Estimate benefit devirtualizing indirect edge IE, provided KNOWN_VALS,
> KNOWN_CONTEXTS and KNOWN_AGGS. */
>
> @@ -3207,8 +3167,8 @@ ipa_fn_summary_t::insert (struct cgraph_
>
> /* Note function body size. */
>
> -void
> -inline_generate_summary (void)
> +static void
> +ipa_fn_summary_generate (void)
> {
>struct cgraph_node *node;
>
> @@ -3226,7 +3186,7 @@ inline_generate_summary (void)
>ipa_fn_summaries->enable_insertion_hook ();
>
>ipa_register_cgraph_hooks ();
> - inline_free_summary ();
> + ipa_free_fn_summary ();
>
>FOR_EACH_DEFINED_FUNCTION (node)
> if (!node->alias)
> @@ -3358,8 +3318,8 @@ inline_read_section (struct lto_file_dec
> and inliner, so when ipa-cp is active, we don't need to write them
> twice. */
>
> -void
> -inline_read_summary (void)
> +static void
> +ipa_fn_summary_read (void)
> {
>struct lto_file_decl_data **file_data_vec = lto_get_file_decl_data ();
>struct lto_file_decl_data *file_data;
> @@ -3419,8 +3379,8 @@ write_ipa_call_summary (struct output_bl
> Jump functions are shared among ipa-cp and inliner, so when ipa-cp is
> active, we don't need to
Re: Allow some NOP conversions in (X+CST1)+CST2 in match.pd
On Sun, May 21, 2017 at 9:22 PM, Marc Glisse wrote: > Hello, > > generalizing a bit one transformation, to avoid a regression with another > patch I am working on. Handling conversions always gets messy :-( It would > have been easier to stick to scalars and wide_int, but since the existing > transformation handles vectors, I didn't want to regress. The pattern looks a bit unwieldly now ;) I pondered a bit but couldn't really find a better way to handle things. Thus, ok. Richard. > Bootstrap+testsuite on powerpc64le-unknown-linux-gnu. > > 2017-05-22 Marc Glisse > > gcc/ > * match.pd ((A +- CST1) +- CST2): Allow some conversions. > * tree.c (drop_tree_overflow): Handle COMPLEX_CST and VECTOR_CST. > > gcc/testsuite/ > * gcc.dg/tree-ssa/addadd.c: New file. > > -- > Marc Glisse
Fix pessimistic DImode handling in combine.c:make_field_assignment
The make_field_assignment code: src = force_to_mode (src, mode, GET_MODE_PRECISION (mode) >= HOST_BITS_PER_WIDE_INT ? HOST_WIDE_INT_M1U : (HOST_WIDE_INT_1U << len) - 1, 0); would ignore the field length len for DImode, even though DImode can be handled using HWIs. I think the code should be testing len instead. The patch was originally part of the SVE machine_mode series. Retesting showed that it changed the asm output on powerpc for a few tests, so I thought it should go in separately. Each test change seemed to be an improvement. Tested on aarch64-linux-gnu and x86_64-linux-gnu. I no longer have access to the compile farm to test on the powerpc boxes there. Thanks, Richard 2017-05-24 Richard Sandiford gcc/ * combine.c (make_field_assignment): Check len rather than the mode precision when calling force_to_mode. Index: gcc/combine.c === --- gcc/combine.c 2017-05-03 08:46:32.777861592 +0100 +++ gcc/combine.c 2017-05-24 09:25:25.170351268 +0100 @@ -9634,7 +9634,7 @@ make_field_assignment (rtx x) other, pos), dest); src = force_to_mode (src, mode, - GET_MODE_PRECISION (mode) >= HOST_BITS_PER_WIDE_INT + len >= HOST_BITS_PER_WIDE_INT ? HOST_WIDE_INT_M1U : (HOST_WIDE_INT_1U << len) - 1, 0);
Re: SSA range class and removal of VR_ANTI_RANGEs
..On Tue, May 23, 2017 at 5:24 PM, Andrew MacLeod wrot
> On 05/23/2017 10:54 AM, Jakub Jelinek wrote:
>>
>> On Tue, May 23, 2017 at 10:38:44AM -0400, Andrew MacLeod wrote:
>>>
>>> As follow on work we have discussed an interface which would be able to
>>> calculate a bitmask (for either zeros or ones) from a range and vice
>>> versa..
>>
>> Sometimes the range vs. nonzero_bits info is redundant, you can compute
>> one from the other or vice versa without any information loss, but in many
>> cases it is not redundant, you can have e.g. known zero least significant
>> or
>> some middle bits, or the range boundaries are not powers of two or powers
>> of
>> two - 1. The point is that with the coexistence of both it can be
>> gradually
>> improved, first you e.g. find some range, then CCP can use the
>> corresponding
>> nonzero_bits knowledge from that range in bitwise mask propagation, then
>> you
>> notice some other bits are known to be zero, perhaps from that adjust the
>> value range again if possible, ...
>
>
> Right, but we do only need to store both for those cases which we are
> actually refining the info. and via a central manager of the information it
> can know when that is a thing to do and do it. I also hope to ad some of
> the bit inormation ot the on demand system.. tat'll come later tho.I
> simply maintain that the vast majority of ssa_names are unlikely to need
> both, not that we never need both. This seems like statistics that
> shouldn't be too hard to find with some simple looking at the data at the
> end of compilation or various passes.
>
>>
>>> why don't we actually try measuring it and see if it is noticeable? and
>>> if
>>> it is, where the issues really are. You really think we have relevant
>>> range
>>> info for 50% of the ssa_names in a program? Id be surprised. Again,
>>> thats
>>> something we should probably measure and see whats typical. the range
>>> table
>>> should only be used when we can refine the global range to something
>>> other
>>> than range_for_type().
>>
>> I'm not used to build firefox and various other large C++ projects with
>> LTO
>> regularly, so it would be harder for me to get that stuff working and
>> measure it, but I think e.g. Honza or Martin L. do that often and could
>> provide hints on what is needed to test that, then we can have exact
>> numbers.
>
> that seems reasonable. I think we ought to look at the low hanging fruit
> for making it more efficient to start with before hassling them or that..
> unless it is trivial. It would be useful t have input from "heavy"
> application users if there is any/much impact.
>>>
>>> We can also change the representation of the range to be 2 ranges like it
>>> is
>>
>> Well, the current representation is just 1 range (2 numbers) + 1 extra
>> number for the nonzero_bits bitmask.
>
>
> oh yeah,right but anti range is evil. Its worth losing a little bit of
> memory to get rid of that, imo :-)
Well, anti-ranges are "evil" for actual working with ranges. They are nice
for optimizing the storage requirements though.
As I'm replying late I'll add that yes, it does make a difference in memory
use. We've seen this with IPA VRP info eating up 1 GB extra memory
for firefox so we optimized it to use trailing wide-ints. So ..
+#define MAX_RANGES 6
...
+class GTY(()) irange
+{
...
+ public:
+ tree type;
+ wide_int bounds[MAX_RANGES];
is definitely a no-go. type is also redundant. Making 'n' a size_t is stupid.
Please apply some more common sense here...
We need to really think about making this a bit more flexible than just handling
integer ranges, eventually tracking non-zero bits as well.
So first of all I'd suggest to make MAX_RANGES a template parameter
so we can eventually use the same representation in both the VRP lattice,
the SSA name info and the basic range ops (I see you re-implemented all
of those rather than refactoring the VRP ones which would have benefited
most from "getting rid of anti-ranges").
What's this overflow flag for anyway?
That said, I think it's the wrong approach to start mucking with SSA name
associated ranges given they are supposed to be a cheap storage variant
of what VRP computes. Start by making the VRP machinery work from
on-demand-ranges. I do have some prototypes from last year or the year
before to do this -- the helpers VRP machinery is already generic enough
if you make use of VRPs range type.
>>
>>> More importantly, when the on-demand range work comes online it will end
>>> the
>>> proliferation of SSA_NAMES which carry ASSERT_EXPR information. We won't
>>> see the trail of new ssa_names the ASSET_EXPR chains create. I suspect
>>> that
>>> will eliminate storing global ranges and bits for most SSA names, which
>>> is
>>> likely to make this class a win regardless.
>>
>> Are you sure it is desirable to recompute it in all cases, rather than
>> just
>> use what you have recorded and recompute what you don't have computed yet?
>> E.g. vari
Fix var-tracking for special record parameters passed indirectly
var-tracking doesn't track structures and arrays as a whole because it cannot
track values for multiple-part variables, but it has a special provision for
Ada fat pointer types, which are structures with integral mode containing a
pair of pointers and are pervasive in the language (see param-[123].c in the
guality testsuite). This works fine e.g. on x86 or x86-64, but not on SPARC
or Visium which pass these structures indirectly as per their ABI.
Tested on x86_64-suse-linux and visium-elf, applied on mainline as obvious.
2017-05-24 Eric Botcazou
* var-tracking.c (track_expr_p): Do not return 0 for tracked record
parameters passed indirectly.
--
Eric BotcazouIndex: var-tracking.c
===
--- var-tracking.c (revision 248140)
+++ var-tracking.c (working copy)
@@ -5220,8 +5220,9 @@ track_expr_p (tree expr, bool need_rtl)
if (decl_rtl && MEM_P (decl_rtl))
{
/* Do not track structures and arrays. */
- if (GET_MODE (decl_rtl) == BLKmode
- || AGGREGATE_TYPE_P (TREE_TYPE (realdecl)))
+ if ((GET_MODE (decl_rtl) == BLKmode
+ || AGGREGATE_TYPE_P (TREE_TYPE (realdecl)))
+ && !tracked_record_parameter_p (realdecl))
return 0;
if (MEM_SIZE_KNOWN_P (decl_rtl)
&& MEM_SIZE (decl_rtl) > MAX_VAR_PARTS)
Re: SSA range class and removal of VR_ANTI_RANGEs
On Tue, May 23, 2017 at 12:48 PM, Aldy Hernandez wrote:
> Howdy!
>
> For Andrew's upcoming on-demand range work I have created a range class for
> use in his engine. Currently, the range class is only for SSA integers, but
> there is no reason why we couldn't adapt this for RTL or non-integer types
> at a later time.
>
> The class can live outside of his work, as can be demonstrated by the
> attached patch. With it, I was able to rewrite the post-VRP range
> information to use this class and get rid of VR_ANTI_RANGE throughout the
> compiler. A VR_ANTI_RANGE of ~[5,10] becomes [-MIN,4][11,+MAX].
>
> The internal structure of VRP is unchanged. I have only changed the outward
> facing structures.
>
> A good example of how much cleaner using an actual range rather than
> VR_ANTI_RANGEs is the change to get_size_range() in the attached patch. We
> remove an assortment of contortions into:
>
> + /* Remove negative numbers from the range. */
> + irange positives;
> + range_positives (&positives, exptype, allow_zero ? 0 : 1);
> + if (positives.Intersect (*ir))
> +{
> + /* Remove the unknown parts of a multi-range.
> +This will transform [5,10][20,MAX] into [5,10]. */
> + if (positives.num_ranges () > 1
> + && positives.upper_bound () == wide_int (TYPE_MAX_VALUE
> (exptype)))
> + positives.remove_range (positives.num_ranges () - 1);
> +
> + range[0] = wide_int_to_tree (exptype, positives.lower_bound ());
> + range[1] = wide_int_to_tree (exptype, positives.upper_bound ());
> +}
> + else
> +{
> + /* If removing the negative numbers didn't give us anything
> +back, the entire range was negative. Leave things as they
> +were, and let the caller sort it out. */
> + range[0] = wide_int_to_tree (exptype, min);
> + range[1] = wide_int_to_tree (exptype, max);
> }
>
> A few notes:
>
> 1. There are still two uses of VR_ANTI_RANGEs left after this patch: ip-cp.c
> and ipa-prop.c. I didn't look too hard at these two passes, as they are
> using `struct value_range' which should only have been used *before* VRP
> finishes. I can work on this as a follow-up.
So my ultimate goal was to somehow make the range operations in VRP
(union, intersect, unary and binary ops) have an API that can be easily
used with both the internal VRP lattice ranges and the SSA name associated
ranges. Now that we have C++ we could either use some kind of adaptors
or make them templates -- or something else.
> 2. I have not included ChangeLog entries, as I would hate to write them, and
> have the API or significant things change from under me as part of the
> review. I can certainly cobble the ChangeLog entries as soon as/if we agree
> that this is an acceptable approach.
>
> 3. There are lots of unit tests to maintain sanity. The cast ones in
> particular will definitely need refinement as Andrew's work stresses the
> class.
>
> The attached patch passes bootstrap and tests.
>
> I have also benchmarked an assortment of .ii files (from a previous
> bootstrap) with no noticeable difference in -O2 compilation time. So, I
> would prefer to tackle any micro-optimizations either as a follow-up or if
> it actually becomes noticeable--. Yeah, yeah, I know. Wishful thinking ;-).
+ // If we will overflow, don't bother. This will handle unsigned
+ // underflow which doesn't set the overflow bit.
+ //
+ // Note: Perhaps all these &ovf checks are unecessary since we
+ // are manually checking for overflow with the if() below.
no multi-line // comments please. What's wrong with /* ... */?
+// Convert the current range in place into a range of type NEW_TYPE.
+// The type of the original range is changed to the new type.
+
+void
+irange::cast (tree new_type)
+{
+ if (!n)
so this duplicates VRP unary op with NOP/CONVERT_EXPR.
+void
+irange::Union (wide_int x, wide_int y)
+{
why capital U?
>
> Fire away!
> Aldy
>
> p.s. Please refer any comments as to why we need the class, or why we need
> on-demand range information to Andrew :-P.
Re: [PATCH] Prevent extract_muldiv from introducing an overflow (PR sanitizer/80800)
On Fri, 19 May 2017, Alexander Monakov wrote: > On Fri, 19 May 2017, Joseph Myers wrote: > > On Fri, 19 May 2017, Alexander Monakov wrote: > > > (to be precise, if the multiplication is done in a signed type and the > > > middle > > > constant factor was a negated power of two, the sign change needs to > > > remain: > > > > > > a * -4 * b * 2 > > > > > > needs to be transformed to > > > > > > a * -1 * b * 8 ) > > > > Shouldn't that only be the case if the middle constant was -1 and the > > outer constant was 1? If a * -4 * b is INT_MIN, a * b won't overflow and > > so a * b * -8 should be a safe transformation. > > Indeed, I should have considered the situation more carefully. Thank you for > the correction. Feel free to sumbit a patch improving the situation (as said, preferably not in extract_muldiv). Or open an enhancement bugreport refering to the above constraints. Richard.
Re: [PATCH][www] Deprecate MPX for GCC 7
On Tue, 23 May 2017, Jeff Law wrote: > On 05/23/2017 06:50 AM, Richard Biener wrote: > > > > Appearantly we forgot to officially deprecate MPX in GCC 7 changes.html. > > > > The following adds the missing note. > > > > Ok? > > > > Thanks, > > Richard. > > > > 2017-05-23 Richard Biener > > > > * gcc-7/changes.html: Deprecate MPX. > I don't recall deprecating MPX. I do recall deprecating Cilk+. Ok, maybe I misremember. > There's certainly folks at Intel fixing MPX related issues for GCC. Sure. But bootstrap with MPX is broken since forever and I don't see anybody using the feature -- plus it's maintainance burden is quite higher than Cilk+. Well. Let's keep it in mind then for GCC 8 deprecation. Disclaimer: I was asked if we can remove it right now because of its impact on cgraph code. Richard.
