[PING] [PATCH] [AArch64, NEON] Fix testcases add by r218484
Hi, This is a ping for: https://gcc.gnu.org/ml/gcc-patches/2014-12/msg01328.html OK for the trunk? Thanks.
[committed] Partial libsanitizer aarch64 fix (PR sanitizer/64435)
Hi! I've committed following cherry-pick from upstream. It is not a fully solution for that PR, but does not hurt and let us move to other libsanitizer build failures on aarch64 (and with those fixed/worked around just to find out that asan doesn't work at all on aarch64). 2015-01-19 Jakub Jelinek PR sanitizer/64435 * sanitizer_common/sanitizer_platform_limits_posix.cc: Cherry pick upstream r223925. --- libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc (revision 223924) +++ libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc (revision 223925) @@ -1005,8 +1005,12 @@ CHECK_SIZE_AND_OFFSET(__sysctl_args, new CHECK_TYPE_SIZE(__kernel_uid_t); CHECK_TYPE_SIZE(__kernel_gid_t); + +#if !defined(__aarch64__) CHECK_TYPE_SIZE(__kernel_old_uid_t); CHECK_TYPE_SIZE(__kernel_old_gid_t); +#endif + CHECK_TYPE_SIZE(__kernel_off_t); CHECK_TYPE_SIZE(__kernel_loff_t); CHECK_TYPE_SIZE(__kernel_fd_set); Jakub
Re: [PING] [PATCH] Fix parameters of __tsan_vptr_update
On Fri, Jan 16, 2015 at 8:42 PM, Bernd Edlinger
wrote:
> Hi,
>
> On Fri, 16 Jan 2015 21:25:42, Dmitry Vyukov wrote:
>>
>> This is just a copy from llvm repo, right?
>> Looks good to me.
>>
>
> Thanks.
>
> Yes I found these test case in the llvm tree, and just adapted them
> to work in the gcc test suite.
>
> However, here is a small tweak in the positive test:
> That is we now use a tsan-invisible barrier_wait function
> instead of the not very reliable sleep(1).
>
> barrier_wait is bypassing the tsan interceptor, because
> it is accessed with dlsym (dlopen ("libpthread.so.0", RTLD_LAZY),
> "pthread_barrier_wait").
+Kostya
Hi Bernd,
Yes, that email is marked in my inbox. Sorry for not answering earlier.
I can't really make my mind on this. I would mildly prefer sleep's (if
they work reliably!).
Kostya, please chime in. This is equivalent to StealthNotification
that we used in old data-race-test test suite:
https://code.google.com/p/data-race-test/source/browse/trunk/unittest/test_utils.h#134
Kostya, you had experience with both approaches. What are you thoughts on this?
StealthNotification definitely makes tests faster and more reliable. I
can't really come up with any objective downsides.
>> On Fri, Jan 16, 2015 at 10:17 AM, Bernd Edlinger
>> wrote:
>>> Hi,
>>>
>>>
>>> I think I should ping for this patch now:
>>> https://gcc.gnu.org/ml/gcc-patches/2015-01/msg00599.html
>>>
>>> note that by mistake the change log referenced sanitizer.c instead of
>>> sanitizer.def, consider that fixed on my local copy.
>>>
>>>
>>> Thanks
>>> Bernd.
>>>
>>>
Date: Sun, 11 Jan 2015 14:15:54 +0100
Hi,
On Sun, 4 Jan 2015 14:54:56, Bernd Edlinger wrote:
>
> Hi Jakub,
>
>
> I think I have found a reasonable test case, see the attached patch file.
> The use case is: a class that destroys an owned thread in the destructor.
> The destructor sets the vptr again to thread::vptr but this should
> _not_ trigger a diagnostic message, when the vptr does not really change.
>
> Jakub, this is another test case where the TREE_READONLY prevents
> the tsan instrumentation. So I had first to install your patch:
>
> https://gcc.gnu.org/ml/gcc-patches/2014-12/msg01432.html
>
> ... to see the test case fail without my patch.
>
that has been installed in the meantime.
> The patch installs cleanly on 4.9 and 4.8, however the 4.8 branch
> has no tsan tests, so I would leave the test case away for 4.8.
>
I found, 4.8 does not have BT_FN_VOID_PTR_PTR, and no tsan tests
at all, so it is probably not worth the effort.
> Boot-strapped and regression-tested on x86_64-linux-gnu
> OK for trunk and 4.9 + 4.8 branches?
>
>
> Thanks
> Bernd.
>
>
I found some test cases in the clang tree, about the __tsan_vptr_update.
So I thought I should use these instead of inventing new ones.
Attached you'll find an updated patch with one positive and one negative
test for vptr races.
Tested with x86_64-linux-gnu.
OK for trunk and 4.9 after a while?
Thanks
Bernd.
>>>
>
Re: [PATCH] Fix sporadic failure in g++.dg/tsan/aligned_vs_unaligned_race.C
Long story short. Tsan has a logical data race the core of data race detection algorithm. The race is not a bug, but a deliberate design decision that makes tsan considerably faster. So ironically, if the race memory accesses happen almost simultaneously, tsan can miss the race. Thus we have sleeps. Sleeps vs barrier is being discussed in the "Fix parameters of __tsan_vptr_update" thread. I would really like to keep llvm and gcc tests in sync as much as possible. On Fri, Jan 9, 2015 at 6:36 PM, Jakub Jelinek wrote: > On Fri, Jan 09, 2015 at 04:32:47PM +0100, Bernd Edlinger wrote: >> Hi, >> >> On Thu, 8 Jan 2015 22:27:26, Jakub Jelinek wrote: >> >> Any objections to approving it now? >> > >> > LGTM. >> > >> > Jakub >> >> would it be OK to apply this patch also to the 4.9 testsuite, >> except for c-c++-common/tsan/bitfield_race.c and >> g++.dg/tsan/aligned_vs_unaligned_race.C of course? > > Yes, but please give Dmitry some time to respond. > > Jakub
[PING ^ 4] [RFC PATCH, AARCH64] Add support for -mlong-calls option
Patch ping: https://gcc.gnu.org/ml/gcc-patches/2014-11/msg02258.html Any comments, Richard? Thanks.
Re: [PING] [PATCH] Fix parameters of __tsan_vptr_update
On Mon, Jan 19, 2015 at 12:43:39PM +0400, Dmitry Vyukov wrote: > Hi Bernd, > > Yes, that email is marked in my inbox. Sorry for not answering earlier. > > I can't really make my mind on this. I would mildly prefer sleep's (if > they work reliably!). Sleeps by definition should not be reliable, not to mention that they waste testing time. > Kostya, please chime in. This is equivalent to StealthNotification > that we used in old data-race-test test suite: > https://code.google.com/p/data-race-test/source/browse/trunk/unittest/test_utils.h#134 > Kostya, you had experience with both approaches. What are you thoughts on > this? > StealthNotification definitely makes tests faster and more reliable. I > can't really come up with any objective downsides. Jakub
Re: [Patch, AArch64, testsuite] PR63971: Revert test_frame_* patch.
On Thu, Jan 15, 2015 at 8:18 AM, Mike Stump wrote: > On Jan 14, 2015, at 3:50 AM, Tejas Belagod wrote: >> As agreed here (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63971), please >> can I reverse Andrew's patch >> out(https://gcc.gnu.org/ml/gcc-patches/2014-11/msg02916.html)? > > Ok. > > Unless someone objects to a reversion like this, when the author of a patch > says it should be reverted… that’s all the approval it needs, though, people > can always ask for a review for any reason they want. And now this reversal needs to be reverted. Because the conditional compare optimization went back in. I figured the optimization would go back in and that is why I did not act on reverting my patch that fast. The conditional compare patch went in a day after this reversal went in ;). Thanks, Andrew
GCC 5 Status Report (2015-01-19), Trunk in Stage 4
Status == The trunk is now in "Stage 4" which means it is open for regression and documentation fixes only, like if it were a release branch. Please concentrate on getting P1 bugs fixed and provide help in confirming and analyzing UNCONFIRMED bugs. For non-primary, non-secondary targets important bugs are not flagged with high priority - instead target maintainers have to ensure themselves that the GCC 5 release will be in proper shape for them (same applies to non-C/C++ frontends and runtime). Please also make sure to mark bugs as regressions if appropriate, always filling out the known-to-work and known-to-fail fields. Quality Data Priority # Change from last report --- --- P1 32- 7 P2 97- 1 P3 32- 16 --- --- Total 161- 24 Previous Report === https://gcc.gnu.org/ml/gcc/2015-01/msg00032.html
Re: [PATCH] Re: Stage 3 RFC: using "jit" for ahead-of-time compilation
On Fri, Jan 16, 2015 at 7:47 PM, David Malcolm wrote: > On Thu, 2015-01-15 at 22:50 +0100, Richard Biener wrote: >> On January 15, 2015 9:05:59 PM CET, David Malcolm >> wrote: >> >Release managers: given that this only touches the jit, and that the >> >jit >> >is off by default, any objections if I go ahead and commit this? >> >It's a late-breaking feature, but the jit as a whole is new, and >> >I think the following is a big win, so I'd like to proceed with this in >> >stage 3 (i.e. in the next 24 hours). There are docs and testcases. >> > >> >New jit API entrypoint: gcc_jit_context_compile_to_file >> > >> >This patch adds a way to use libgccjit for ahead-of-time compilation. >> >I noticed that given the postprocessing steps the jit has to take to >> >turn the .s file into in-memory code (invoke driver to convert to >> >a .so and then dlopen), that it's not much of a leap to support >> >compiling the .s file into objects, dynamic libraries, and executables. >> > >> >Doing so seems like a big win from a feature standpoint: people with >> >pre-existing frontend code who want a backend can then plug in >> >libgccjit >> >and have a compiler, without needing to write it as a GCC frontend, or >> >use LLVM. >> >> Note that you should make them aware of our runtime license with >> respect to the eligible compilation process. Which means this is not >> a way to implement proprietary front ends. >> >> Richard. > > IANAL, but as I understand things, the runtime license is an additional > grant of rights that covers certain components of GCC that bear the GCC > Runtime Library Exception, allowing them to be used in certain > additional ways beyond regular GPLv3-compliance. > > libgccjit doesn't have that exception; it's GPLv3. > > Perhaps an argument could be made for libgccjit to have the exception, > if the FSF think that that would better serve the FSF's mission; right > now, I'm merely trying to provide a technical means to modularity. > > Assuming the above is correct, anything linked against it needs to be > GPLv3-compatible. Hence any such frontend linked against libgccjit > would need to be GPLv3-compatible. > > Attached is a patch (on top of the proposed one below), to clarify the > wording in the new tutorial a little, to remind people that such linking > needs to be license-compatible (without actually spelling out what the > license is, though it's visible at the top of the public header file, > libgccjit.h, as GPLv3 or later without the runtime library exception). > > Are the combined patches OK by you? Yes. Thanks, Richard. > Thanks > Dave > > >> >"jit" becomes something of a misnomer for this use-case. >> > >> >As an experiment, I used this technique to add a compiler for the >> >language I'll refer to as "brainf" (ahem), and wrote this up for the >> >libgccjit tutorial (it's all in the patch); prebuilt HTML can be seen >> >at: >> >https://dmalcolm.fedorapeople.org/gcc/libgccjit-api-docs-wip/intro/tutorial05.html >> > >> >The main things that are missing are: >> > * specifying libraries to link against (Uli had some ideas about this) >> > * cross-compilation support (needs some deeper work, especially the >> >test suite, so deferrable to gcc 6, I guess) >> >but the feature is useful with the patch as-is. >> > >> >The new test cases take jit.sum's # of expected passes >> >from 7514 to 7571. >> > >> >gcc/jit/ChangeLog: >> > * docs/cp/topics/results.rst: Rename to... >> > * docs/cp/topics/compilation.rst: ...this, and add section on >> > ahead-of-time compilation. >> > * docs/cp/topics/index.rst: Update for renaming of results.rst >> > to compilation.rst. >> > * docs/examples/emit-alphabet.bf: New file, a sample "brainf" >> > script. >> > * docs/examples/tut05-bf.c: New file, implementing a compiler >> > for "brainf". >> > * docs/internals/test-hello-world.exe.log.txt: Update to reflect >> > changes to logger output. >> > * docs/intro/index.rst: Add tutorial05.rst >> > * docs/intro/tutorial05.rst: New file. >> > * docs/topics/results.rst: Rename to... >> > * docs/topics/compilation.rst: ...this, and add section on >> > ahead-of-time compilation. >> > * docs/topics/index.rst: Update for renaming of results.rst to >> > compilation.rst. >> > * jit-playback.c (gcc::jit::playback::context::compile): Convert >> > return type from result * to void. Move the code to convert to >> > dso and dlopen the result to a new pure virtual "postprocess" >> > method. >> > (gcc::jit::playback::compile_to_memory::compile_to_memory): New >> > function. >> > (gcc::jit::playback::compile_to_memory::postprocess): New >> > function, based on playback::context::compile. >> > (gcc::jit::playback::compile_to_file::compile_to_file): New >> > function. >> > (gcc::jit::playback::compile_to_file::postprocess): New function. >> > (gcc::jit::playback::compile_to_file::copy_file): New function. >> > (gcc:
Re: [PATCH, CHKP] [always_inline 1/2] Allow inlining for not instrumented calls to always_inline functions
2015-01-16 19:58 GMT+03:00 Jeff Law : > On 01/16/15 04:04, Ilya Enkovich wrote: >> >> Hi, >> >> Currently compiler emits an error in case of not instrumented call to >> instrumented alwyas_inline function. It happens because when we inline >> there is only instrumented version of function available and we don't inline >> thunks. This patch solves the problem by split of thunk production pass >> into two passes. The first one removes all functions we don't have to >> inline. The other one does the rest after local optimizations. >> >> Bootstrapped and checked on x86_64-unknown-linux-gnu. This patch causes >> fault in chkp-strchr.c test and also breaks instrumented bootstrap. Both >> are due to problem in SRA fixed by the next patch. OK for trunk? >> >> Thanks, >> Ilya >> -- >> gcc/ >> >> 2015-01-16 Ilya Enkovich >> >> * ipa-chkp.c (chkp_produce_thunks): Add early param. > > to support splitting of thunk production. Do not remove bodies of > "always_inline" functions. > > Is that an accurate representation of what changed? > > >> (pass_data_ipa_chkp_early_produce_thunks): New. >> (pass_ipa_chkp_early_produce_thunks): New. >> (pass_ipa_chkp_produce_thunks::execute): Adjust to new >> chkp_produce_thunks signature. >> (make_pass_ipa_chkp_early_produce_thunks): New. >> * passes.def (pass_ipa_chkp_early_produce_thunks): New. >> (pass_ipa_chkp_produce_thunks): Move after local optimizations. >> * tree-pass.h (make_pass_ipa_chkp_early_produce_thunks): New. >> >> gcc/testsuite/ >> >> 2015-01-16 Ilya Enkovich >> >> * gcc.target/i386/chkp-always_inline.c: New. > > With the updated ChangeLog, this is fine. > > jeff > Thanks for review! Here is a committed ChangeLog. Ilya -- gcc/ 2015-01-19 Ilya Enkovich * ipa-chkp.c (chkp_produce_thunks): Add early param to split thunks production into two passes. Keep 'always_inline' function bodies after the first pass. (pass_data_ipa_chkp_early_produce_thunks): New. (pass_ipa_chkp_early_produce_thunks): New. (pass_ipa_chkp_produce_thunks::execute): Adjust to new chkp_produce_thunks signature. (make_pass_ipa_chkp_early_produce_thunks): New. * passes.def (pass_ipa_chkp_early_produce_thunks): New. (pass_ipa_chkp_produce_thunks): Move after local optimizations. * tree-pass.h (make_pass_ipa_chkp_early_produce_thunks): New. gcc/testsuite/ 2015-01-19 Ilya Enkovich * gcc.target/i386/chkp-always_inline.c: New.
Re: [PATCH][ARM] FreeBSD arm support, EABI, v2
On 17/01/15 15:18, Gerald Pfeifer wrote: On Friday 2015-01-09 15:24, Andreas Tobler wrote: Committed. (r219388) Thanks. Can this also go into the GCC 4.9 branch? That is (and will be for a while) the latest release stream and the patch is pretty much isolated to FreeBSD. Also a note for the release note perhaps? Kyrill Gerald
Re: Use static chain and libffi for Go closures
Ian Lance Taylor writes:
> @@ -83,7 +83,7 @@
> #else /* !defined(USE_LIBFFI_CLOSURES) */
>
> void
> -makeFuncFFI(const struct __go_func_type *ftyp, ffi_go_closure *impl)
> +makeFuncFFI(const struct __go_func_type *ftyp, void *impl)
> {
>runtime_panicstring ("libgo built without FFI does not support "
> "reflect.MakeFunc");
../../../libgo/go/reflect/makefunc_ffi_c.c: In function ‘makeFuncFFI’:
../../../libgo/go/reflect/makefunc_ffi_c.c:86:42: error: unused parameter
‘ftyp’ [-Werror=unused-parameter]
makeFuncFFI(const struct __go_func_type *ftyp, void *impl)
^
../../../libgo/go/reflect/makefunc_ffi_c.c:86:54: error: unused parameter
‘impl’ [-Werror=unused-parameter]
makeFuncFFI(const struct __go_func_type *ftyp, void *impl)
^
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."
Re: [PATCH][AArch64] Improve bit-test-branch pattern to avoid unnecessary register clobber
On 14/01/15 22:59, Richard Henderson wrote:
On 12/15/2014 07:36 AM, Jiong Wang wrote:
+ char buf[64];
+ uint64_t val = ((uint64_t) 1) << UINTVAL (operands[1]);
+ sprintf (buf, "tst\t%%0, %"PRId64, val);
+ output_asm_insn (buf, operands);
+ return "\t%l2";
Better to simply modify the operand, as in
operands[1] = GEN_INT (HOST_WIDE_INT_1U << UINTVAL (operands[1]));
return "tst\t%0, %1\;\t%l2";
thanks, fixed.
ok for trunk ?
gcc/
2015-01-19 Ramana radhakrishnanramana.radhakrish...@arm.com
Jiong wangjiong.w...@arm.com
* config/aarch64/aarch64.md (tb1): Clobber CC reg instead of
scratch reg.
(cb1): Likewise.
* config/aarch64/iterators.md (bcond): New define_code_attr.
diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/aarch64.md
index 597ff8c..1e00396 100644
--- a/gcc/config/aarch64/aarch64.md
+++ b/gcc/config/aarch64/aarch64.md
@@ -466,13 +466,17 @@
(const_int 0))
(label_ref (match_operand 2 "" ""))
(pc)))
- (clobber (match_scratch:DI 3 "=r"))]
+ (clobber (reg:CC CC_REGNUM))]
""
- "*
- if (get_attr_length (insn) == 8)
-return \"ubfx\\t%3, %0, %1, #1\;\\t%3, %l2\";
- return \"\\t%0, %1, %l2\";
- "
+ {
+if (get_attr_length (insn) == 8)
+ {
+ operands[1] = GEN_INT (HOST_WIDE_INT_1U << UINTVAL (operands[1]));
+ return "tst\t%0, %1\;\t%l2";
+ }
+else
+ return "\t%0, %1, %l2";
+ }
[(set_attr "type" "branch")
(set (attr "length")
(if_then_else (and (ge (minus (match_dup 2) (pc)) (const_int -32768))
@@ -486,13 +490,21 @@
(const_int 0))
(label_ref (match_operand 1 "" ""))
(pc)))
- (clobber (match_scratch:DI 2 "=r"))]
+ (clobber (reg:CC CC_REGNUM))]
""
- "*
- if (get_attr_length (insn) == 8)
-return \"ubfx\\t%2, %0, , #1\;\\t%2, %l1\";
- return \"\\t%0, , %l1\";
- "
+ {
+if (get_attr_length (insn) == 8)
+ {
+ char buf[64];
+ uint64_t val = ((uint64_t ) 1)
+ << (GET_MODE_SIZE (mode) * BITS_PER_UNIT - 1);
+ sprintf (buf, "tst\t%%0, %"PRId64, val);
+ output_asm_insn (buf, operands);
+ return "\t%l1";
+ }
+else
+ return "\t%0, , %l1";
+ }
[(set_attr "type" "branch")
(set (attr "length")
(if_then_else (and (ge (minus (match_dup 1) (pc)) (const_int -32768))
diff --git a/gcc/config/aarch64/iterators.md b/gcc/config/aarch64/iterators.md
index 7dd3917..bd144f9 100644
--- a/gcc/config/aarch64/iterators.md
+++ b/gcc/config/aarch64/iterators.md
@@ -823,6 +823,9 @@
(smax "s") (umax "u")
(smin "s") (umin "u")])
+;; Emit conditional branch instructions.
+(define_code_attr bcond [(eq "beq") (ne "bne") (lt "bne") (ge "beq")])
+
;; Emit cbz/cbnz depending on comparison type.
(define_code_attr cbz [(eq "cbz") (ne "cbnz") (lt "cbnz") (ge "cbz")])
diff --git a/gcc/testsuite/gcc.target/aarch64/long_range_bit_test_branch_1.c b/gcc/testsuite/gcc.target/aarch64/long_range_bit_test_branch_1.c
new file mode 100644
index 000..d4782e9
--- /dev/null
+++ b/gcc/testsuite/gcc.target/aarch64/long_range_bit_test_branch_1.c
@@ -0,0 +1,166 @@
+int dec (int);
+
+#define CASE_ENTRY(n) \
+ case n: \
+sum = a / n; \
+sum = sum * (n - 1); \
+sum = dec (sum); \
+sum = sum / (n + 1); \
+sum = dec (sum); \
+sum = sum / (n + 2); \
+sum = dec (sum); \
+sum = sum / (n + 3); \
+sum = dec (sum); \
+sum = sum / (n + 4); \
+sum = dec (sum); \
+sum = sum / (n + 5); \
+sum = dec (sum); \
+sum = sum / (n + 6); \
+sum = dec (sum); \
+sum = sum / (n + 7); \
+sum = dec (sum); \
+sum = sum / (n + 8); \
+sum = dec (sum); \
+sum = sum / (n + 9); \
+sum = dec (sum); \
+sum = sum / (n + 10); \
+sum = dec (sum); \
+sum = sum / (n + 11); \
+sum = dec (sum); \
+sum = sum / (n + 12); \
+sum = dec (sum); \
+sum = sum / (n + 13); \
+sum = dec (sum); \
+sum = sum / (n + 14); \
+sum = dec (sum); \
+sum = sum / (n + 15); \
+sum = dec (sum); \
+sum = sum / (n + 16); \
+sum = dec (sum); \
+sum = sum / (n + 17); \
+sum = dec (sum); \
+sum = sum / (n + 18); \
+sum = dec (sum); \
+sum = sum / (n + 19); \
+sum = dec (sum); \
+sum = sum / (n + 20); \
+sum = dec (sum); \
+sum = sum / (n + 21); \
+sum = dec (sum); \
+sum = sum / (n + 22); \
+sum = dec (sum); \
+sum = sum / (n + 23); \
+sum = dec (sum); \
+sum = sum / (n + 24); \
+sum = dec (sum); \
+sum = sum / (n + 25); \
+sum = dec (sum); \
+sum = sum / (n + 26); \
+sum = dec (sum); \
+sum = sum / (n + 27); \
+sum = dec (sum); \
+sum = sum / (n + 28); \
+sum = dec (sum); \
+sum = sum / (n + 29); \
+sum = dec (sum); \
+sum = sum / (n + 30); \
+sum = dec (sum); \
+sum = sum / (n + 31); \
+break;
+
+int
+cbranch (int a, int b, int c, int d, long long addend)
+{
+ long long sum;
+ if (a & 0x2)
+{
+start:
+ sum = b * c;
+ sum = sum + b +
Re: [PATCH][AArch64] Improve bit-test-branch pattern to avoid unnecessary register clobber
On Mon, Jan 19, 2015 at 10:28:47AM +, Jiong Wang wrote: > On 14/01/15 22:59, Richard Henderson wrote: > >On 12/15/2014 07:36 AM, Jiong Wang wrote: > >>+ char buf[64]; > >>+ uint64_t val = ((uint64_t) 1) << UINTVAL (operands[1]); > >>+ sprintf (buf, "tst\t%%0, %"PRId64, val); > >>+ output_asm_insn (buf, operands); > >>+ return "\t%l2"; > >Better to simply modify the operand, as in > > > > operands[1] = GEN_INT (HOST_WIDE_INT_1U << UINTVAL (operands[1])); > > return "tst\t%0, %1\;\t%l2"; > > thanks, fixed. > > ok for trunk ? > > gcc/ > > 2015-01-19 Ramana radhakrishnanramana.radhakrish...@arm.com >Jiong wangjiong.w...@arm.com That is not the right name/email format for ChangeLog entries. > --- /dev/null > +++ b/gcc/testsuite/gcc.target/aarch64/long_range_bit_test_branch_1.c What is aarch64 specific on the testcase? Best would be to turn into into an executable testcase (add __attribute__((noinline, noclone)) to dec and define somehow, perhaps with asm volatile with "memory" clobber in it) to check that it also works fine at runtime, but even if you don't, putting it into gcc.c-torture/compile/ might be preferrable over putting it into aarch64 specific dir. Jakub
Re: [PATCH] Fix PR64535 - increase emergency EH buffers via a new allocator
On Mon, 12 Jan 2015, Richard Biener wrote:
>
> This "fixes" PR64535 by changing the fixed object size emergency pool
> to a variable EH object size (but fixed arena size) allocator. Via
> combining the dependent and non-dependent EH arenas this should allow
> around 600 bad_alloc throws in OOM situations on x86_64-linux
> compared to the current 64 which should provide some headroom to
> the poor souls using EH to communicate OOM in a heavily threaded
> enviroment.
>
> Bootstrapped and tested on x86_64-unknown-linux-gnu (with the #if 1
> as in the patch below, forcing the use of the allocator).
>
> Comments? Ok with only the #else path retained?
I've changed C-style comments to C++-style ones and made the arena
allocation dynamic instead of using a static buffer. Other that this
the patch is pretty much unchanged.
> What about the buffer size - we're now free to choose sth that
> doesn't depend on the size of INT_MAX (previously required for
> old allocator bitmap)?
I've left it to reproduce exactly the old combined buffer size
of emergency_buffer and dependents_buffer. It comes out around
72kB on x86_64-linux. With dynamic allocation it should only
consume virtual memory (the pages are only touched when first used),
so eventually we can even increase it more on 64bit targets.
Still the defines could get some cleanup - I suppose 64k on
a 64bit ptr_mode target, 32k on a 32bit ptr_mode target and
1k on a non-threaded target is reasonable.
Unfortunately I couldn't get an answer of whether throwing
bad_alloc from a throw where we can't allocate an exception
is a) valid or b) even required by the standard ('throw' isn't
listed as 'allocation function' - also our EH allocators are
marked as throw(), so such change would change the ABI...).
> With the cost of some more members I can make the allocator more
> generic (use a constructor with a arena and a arena size parameter)
> and we may move it somewhere public under __gnu_cxx? But eventually
> boost has something like this anyway.
Didn't explore this - it doesn't really match the STL allocator interface
and imposes overhead even over an implementation class (STL allocators
know the size of the objects they free).
I'm re-bootstrapping / testing with the cosmetic changes I did and
with EH allocation not forced to go through the emergency pool
(I've done that in previous bootstraps / tests to get the pool code
exercised).
Any comments? We have a customer that runs into the issue that 64
bad_alloc exceptions are not enough for them (yes, they require bad_alloc
to work when thrown in a massive quantity from threads). Other
solutions for this would include to simply wait and re-try (with possibly
deadlocking if no progress is made) to artificially throttling
bad_alloc allocations from the EH emergency pool (identify it by
size, sleep some time inside the lock).
CCing rth who implemented the existing code.
Thanks,
Richard.
2015-01-12 Richard Biener
PR libstdc++/64535
* libsupc++/eh_alloc.cc: Include new.
(bitmask_type): Remove.
(one_buffer): Likewise.
(emergency_buffer): Likewise.
(emergency_used): Likewise.
(dependents_buffer): Likewise.
(dependents_used): Likewise.
(class pool): New custom fixed-size arena, variable size object
allocator.
(emergency_pool): New global.
(__cxxabiv1::__cxa_allocate_exception): Use new emergency_pool.
(__cxxabiv1::__cxa_free_exception): Likewise.
(__cxxabiv1::__cxa_allocate_dependent_exception): Likewise.
(__cxxabiv1::__cxa_free_dependent_exception): Likewise.
Index: libstdc++-v3/libsupc++/eh_alloc.cc
===
*** libstdc++-v3/libsupc++/eh_alloc.cc.orig 2015-01-19 10:54:57.201633535
+0100
--- libstdc++-v3/libsupc++/eh_alloc.cc 2015-01-19 11:32:29.48154 +0100
***
*** 34,39
--- 34,40
#include
#include "unwind-cxx.h"
#include
+ #include
#if _GLIBCXX_HOSTED
using std::free;
*** using namespace __cxxabiv1;
*** 72,99
# define EMERGENCY_OBJ_COUNT 4
#endif
- #if INT_MAX == 32767 || EMERGENCY_OBJ_COUNT <= 32
- typedef unsigned int bitmask_type;
- #else
- #if defined (_GLIBCXX_LLP64)
- typedef unsigned long long bitmask_type;
- #else
- typedef unsigned long bitmask_type;
- #endif
- #endif
! typedef char one_buffer[EMERGENCY_OBJ_SIZE] __attribute__((aligned));
! static one_buffer emergency_buffer[EMERGENCY_OBJ_COUNT];
! static bitmask_type emergency_used;
! static __cxa_dependent_exception dependents_buffer[EMERGENCY_OBJ_COUNT];
! static bitmask_type dependents_used;
! namespace
! {
! // A single mutex controlling emergency allocations.
! __gnu_cxx::__mutex emergency_mutex;
}
extern "C" void *
--- 73,239
# define EMERGENCY_OBJ_COUNT 4
#endif
+ namespace
+ {
+ // A fixed-size heap, variable size object allocator
+ class pool
+
Re: [PATCH][AArch64] Improve bit-test-branch pattern to avoid unnecessary register clobber
On 19/01/15 10:34, Jakub Jelinek wrote:
On Mon, Jan 19, 2015 at 10:28:47AM +, Jiong Wang wrote:
On 14/01/15 22:59, Richard Henderson wrote:
On 12/15/2014 07:36 AM, Jiong Wang wrote:
+ char buf[64];
+ uint64_t val = ((uint64_t) 1) << UINTVAL (operands[1]);
+ sprintf (buf, "tst\t%%0, %"PRId64, val);
+ output_asm_insn (buf, operands);
+ return "\t%l2";
Better to simply modify the operand, as in
operands[1] = GEN_INT (HOST_WIDE_INT_1U << UINTVAL (operands[1]));
return "tst\t%0, %1\;\t%l2";
thanks, fixed.
ok for trunk ?
gcc/
2015-01-19 Ramana radhakrishnanramana.radhakrish...@arm.com
Jiong wangjiong.w...@arm.com
That is not the right name/email format for ChangeLog entries.
--- /dev/null
+++ b/gcc/testsuite/gcc.target/aarch64/long_range_bit_test_branch_1.c
What is aarch64 specific on the testcase? Best would be to turn into into
an executable testcase (add __attribute__((noinline, noclone)) to dec and
define somehow, perhaps with asm volatile with "memory" clobber in it)
to check that it also works fine at runtime, but even if you don't, putting
it into gcc.c-torture/compile/ might be preferrable over putting it into
aarch64 specific dir.
Jakub
Jakub,
Thanks for review. As I have written in the initial email, the testcase
included in the patch
is for reproduce/record purpose only. I do not plan to commit it. it could
verify the long branch situation,
while because of the code is quite big, it takes a couple of seconds to
compile, so will not commit it.
change log updated
2015-01-19 Ramana Radhakrishnan
Jiong Wang
gcc/
* config/aarch64/aarch64.md (tb1): Clobber CC reg instead of
scratch reg.
(cb1): Likewise.
* config/aarch64/iterators.md (bcond): New define_code_attr.
diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/aarch64.md
index 597ff8c..1e00396 100644
--- a/gcc/config/aarch64/aarch64.md
+++ b/gcc/config/aarch64/aarch64.md
@@ -466,13 +466,17 @@
(const_int 0))
(label_ref (match_operand 2 "" ""))
(pc)))
- (clobber (match_scratch:DI 3 "=r"))]
+ (clobber (reg:CC CC_REGNUM))]
""
- "*
- if (get_attr_length (insn) == 8)
-return \"ubfx\\t%3, %0, %1, #1\;\\t%3, %l2\";
- return \"\\t%0, %1, %l2\";
- "
+ {
+if (get_attr_length (insn) == 8)
+ {
+ operands[1] = GEN_INT (HOST_WIDE_INT_1U << UINTVAL (operands[1]));
+ return "tst\t%0, %1\;\t%l2";
+ }
+else
+ return "\t%0, %1, %l2";
+ }
[(set_attr "type" "branch")
(set (attr "length")
(if_then_else (and (ge (minus (match_dup 2) (pc)) (const_int -32768))
@@ -486,13 +490,21 @@
(const_int 0))
(label_ref (match_operand 1 "" ""))
(pc)))
- (clobber (match_scratch:DI 2 "=r"))]
+ (clobber (reg:CC CC_REGNUM))]
""
- "*
- if (get_attr_length (insn) == 8)
-return \"ubfx\\t%2, %0, , #1\;\\t%2, %l1\";
- return \"\\t%0, , %l1\";
- "
+ {
+if (get_attr_length (insn) == 8)
+ {
+ char buf[64];
+ uint64_t val = ((uint64_t ) 1)
+ << (GET_MODE_SIZE (mode) * BITS_PER_UNIT - 1);
+ sprintf (buf, "tst\t%%0, %"PRId64, val);
+ output_asm_insn (buf, operands);
+ return "\t%l1";
+ }
+else
+ return "\t%0, , %l1";
+ }
[(set_attr "type" "branch")
(set (attr "length")
(if_then_else (and (ge (minus (match_dup 1) (pc)) (const_int -32768))
diff --git a/gcc/config/aarch64/iterators.md b/gcc/config/aarch64/iterators.md
index 7dd3917..bd144f9 100644
--- a/gcc/config/aarch64/iterators.md
+++ b/gcc/config/aarch64/iterators.md
@@ -823,6 +823,9 @@
(smax "s") (umax "u")
(smin "s") (umin "u")])
+;; Emit conditional branch instructions.
+(define_code_attr bcond [(eq "beq") (ne "bne") (lt "bne") (ge "beq")])
+
;; Emit cbz/cbnz depending on comparison type.
(define_code_attr cbz [(eq "cbz") (ne "cbnz") (lt "cbnz") (ge "cbz")])
diff --git a/gcc/testsuite/gcc.target/aarch64/long_range_bit_test_branch_1.c b/gcc/testsuite/gcc.target/aarch64/long_range_bit_test_branch_1.c
new file mode 100644
index 000..d4782e9
--- /dev/null
+++ b/gcc/testsuite/gcc.target/aarch64/long_range_bit_test_branch_1.c
@@ -0,0 +1,166 @@
+int dec (int);
+
+#define CASE_ENTRY(n) \
+ case n: \
+sum = a / n; \
+sum = sum * (n - 1); \
+sum = dec (sum); \
+sum = sum / (n + 1); \
+sum = dec (sum); \
+sum = sum / (n + 2); \
+sum = dec (sum); \
+sum = sum / (n + 3); \
+sum = dec (sum); \
+sum = sum / (n + 4); \
+sum = dec (sum); \
+sum = sum / (n + 5); \
+sum = dec (sum); \
+sum = sum / (n + 6); \
+sum = dec (sum); \
+sum = sum / (n + 7); \
+sum = dec (sum); \
+sum = sum / (n + 8); \
+sum = dec (sum); \
+sum = sum / (n + 9); \
+sum = dec (sum); \
+sum = sum / (n + 10); \
+sum = dec (sum); \
+sum = sum / (n + 11); \
+sum = dec (sum); \
+sum = sum / (n + 12); \
+sum = dec (sum); \
+sum = sum / (n + 13); \
+sum = dec (sum); \
+sum = sum / (n +
Re: [PATCH][AArch64] Improve bit-test-branch pattern to avoid unnecessary register clobber
> What is aarch64 specific on the testcase? The number of if-then-else's required to get the compiler to generate branch sequences rather than the tbnz instruction. Ramana
Re: [patch] powerpc-vxworksmils port, variant of powerpc-vxworksae
Hi Gerald, > this feels a little too small for an announcement on our home > page, but would you mind adding something to gcc-5/changes.html? Sure. > (Or suggest some wording for that page and I'll take care.) Something like the attached patch ? wwwdocs/htdocs/gcc-5/ * changes.html (Operating Systems section): Mention support of VxWorks MILS. mils-changes.diff Description: Binary data
Re: [PATCH][AArch64] Improve bit-test-branch pattern to avoid unnecessary register clobber
On Mon, Jan 19, 2015 at 10:52:14AM +, Ramana Radhakrishnan wrote: > > What is aarch64 specific on the testcase? > > > The number of if-then-else's required to get the compiler to generate > branch sequences rather than the tbnz instruction. That doesn't mean the same testcase couldn't be tested on other targets and perhaps find bugs in there. That said, if the testcase is too expensive to compile (several seconds is ok, minutes is not), then perhaps it shouldn't be included at all, or should be guarded with run_expensive_tests target. Jakub
Re: [RFC][PATCH 2/3] Propagate and save value ranges wrapped information
On Sat, 17 Jan 2015, Kugan wrote: > > This patch propagate value range wrapps attribute and save this to > SSA_NAME. diff --git a/gcc/tree-vrp.c b/gcc/tree-vrp.c index 9b7695d..832c35d 100644 --- a/gcc/tree-vrp.c +++ b/gcc/tree-vrp.c @@ -103,6 +103,9 @@ struct value_range_d tree min; tree max; + /* Set to true if values in this value range could wrapp. */ + bool is_wrapped; + /* Set of SSA names whose value ranges are equivalent to this one. This set is only valid when TYPE is VR_RANGE or VR_ANTI_RANGE. */ bitmap equiv; I can't make sense of this description (wrap with one p as well). I assume you mean that the expression that has this value-range assigned has an operation that may have wrapped? (a value can't wrap) You need to specify how is_wrapped behaves for range union and intersect operations and which operations can wrap. I miss an overall description of these patches as to a) why you need this information and b) why it helps. It's now also too late and thus you have plenty of time until stage1 starts again. Thanks, Richard. > Thanks, > Kugan > > gcc/ChangeLog: > > 2015-01-16 Kugan Vivekanandarajah > > * builtins.c (determine_block_size): Use new definition of >get_range_info. > * gimple-pretty-print.c (dump_ssaname_info): Dump new wrapped info. > * internal-fn.c (get_range_pos_neg): Use new definition of >get_range_info. > (get_min_precision): Likewise. > * tree-ssa-copy.c (fini_copy_prop): Use new definition of >duplicate_ssa_range_info. > * tree-ssa-loop-im.c > (move_computations_dom_walker::before_dom_children): Likewise. > * tree-ssa-pre.c (eliminate_dom_walker::before_dom_children): Likewise. > * tree-ssa-loop-niter.c (determine_value_range): Use new definition. > * tree-ssanames.c (set_range_info): Save wrapped information. > (get_range_info): Retrive wrapped information. > (set_nonzero_bits): Set wrapped info. > (duplicate_ssa_name_range_info): Likewise. > (duplicate_ssa_name_fn): Likewise. > * tree-ssanames.h: (set_range_info): Update definition. > (get_range_info): Ditto. > * tree-vect-patterns.c (vect_recog_divmod_pattern): Use new > declaration get_range_info. > * tree-vrp.c (struct value_range_d): Add wrapped field. > (set_value_range): Calculate and add wrapped field. > (set_and_canonicalize_value_range): Likewise. > (copy_value_range): Likewise. > (set_value_range_to_value): Likewise. > (set_value_range_to_nonnegative): Likewise. > (set_value_range_to_nonnull): Likewise. > (set_value_range_to_truthvalue): Likewise. > (abs_extent_range): Likewise. > (get_value_range): Return wrapped info. > (update_value_range): Save wrapped info. > (extract_range_from_assert): Extract and update wrapped info. > (extract_range_from_ssa_name): Likewise. > (vrp_int_const_binop): Likewise. > (extract_range_from_multiplicative_op_1): Likewise. > (extract_range_from_binary_expr_1): Likewise. > (extract_range_from_binary_expr): Likewise. > (extract_range_from_unary_expr_1): Likewise. > (extract_range_from_comparison): Likewise. > (extract_range_basic): Likewise. > (adjust_range_with_scev): Likewise. > (dump_value_range): Dump wrapped info. > (remove_range_assertions): Update parameters. > (vrp_intersect_ranges_1): Propagate wrapped info. > (vrp_meet_1): Likewise. > (vrp_visit_phi_node): Save wrapped info to SSA. > (vrp_finalize): Likewise. > * tree.h (SSA_NAME_ANTI_RANGE_P): Remove. > (SSA_NAME_RANGE_OVF_P): New. > > gcc/testsuite/ChangeLog: > > 2015-01-16 Kugan Vivekanandarajah > > * gcc.dg/tree-ssa/vrp92.c: Update scanned pattern. > > -- Richard Biener SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham Norton HRB 21284 (AG Nuernberg)
RE: [PATCH, Aarch64] Add FMA steering pass for Cortex-A57
> From: Andrew Pinski [mailto:pins...@gmail.com] > Sent: Friday, January 16, 2015 6:03 PM > > > > +/* Defined in config/aarch64/fma_steering.c. */ > > + > > +void > > +aarch64_register_fma_steering (void); > > > This is really bad form. Can you add a header file for this > declaration and maybe future declarations too? > Maybe called aarch64-internal.h and include this header file both in > aarch64.c and fma_steering.c. Hi Andrew, cortex-a57-fma-steering.c is really meant to be autosufficient with aarch64_register_fma_steering being the only interface which is why I thought it was not worth the trouble. Now I'm not saying I'm against it as it do make this interface more explicit. I'm currently about to take a plane but I'll change it as soon as I arrive at work. Best regards, Thomas
Re: libgo patch committed: Update to Go 1.4
Ian Lance Taylor writes: > On Thu, Jan 15, 2015 at 8:30 AM, Rainer Orth > wrote: >> >> Apart from that, bootstrap fails in gotools: due to the use of >> -static-libgo, all commands there fail to link since the socket >> functions are missing. It seems like $LIBS from libgo needs to be added >> somewhere, but I'm unsure how best to handle this. To make any progress >> at all, I've just manually added -lsocket -lnsl to gotools/Makefile >> (AM_LDFLAGS). > > I also don't know what the best way is to handle this. For now I've > just added a configure test to check whether the libraries are needed. > Based on the libgo build, as far as I can tell, no other libraries > should be needed. While this is true for Solaris 11, Solaris 10 needs librt for nanosleep, sched_yield and the sem_* functions. The following patch copies the corresponding libgo test and allows gotools to build even on Solaris 10. Rainer diff --git a/gotools/Makefile.am b/gotools/Makefile.am --- a/gotools/Makefile.am +++ b/gotools/Makefile.am @@ -108,11 +108,11 @@ bin_PROGRAMS = go$(EXEEXT) gofmt$(EXEEXT libexecsub_PROGRAMS = cgo$(EXEEXT) go$(EXEEXT): $(go_cmd_go_files) zdefaultcc.go $(LIBGODEP) - $(GOLINK) $(go_cmd_go_files) zdefaultcc.go $(NET_LIBS) + $(GOLINK) $(go_cmd_go_files) zdefaultcc.go $(LIBS) $(NET_LIBS) gofmt$(EXEEXT): $(go_cmd_gofmt_files) $(LIBGODEP) - $(GOLINK) $(go_cmd_gofmt_files) $(NET_LIBS) + $(GOLINK) $(go_cmd_gofmt_files) $(LIBS) $(NET_LIBS) cgo$(EXEEXT): $(go_cmd_cgo_files) zdefaultcc.go $(LIBGODEP) - $(GOLINK) $(go_cmd_cgo_files) zdefaultcc.go $(NET_LIBS) + $(GOLINK) $(go_cmd_cgo_files) zdefaultcc.go $(LIBS) $(NET_LIBS) else diff --git a/gotools/configure.ac b/gotools/configure.ac --- a/gotools/configure.ac +++ b/gotools/configure.ac @@ -79,6 +79,10 @@ AC_CACHE_CHECK([for socket libraries], g NET_LIBS="$gotools_cv_lib_sockets" AC_SUBST(NET_LIBS) +dnl Test if -lrt is required for sched_yield and/or nanosleep. +AC_SEARCH_LIBS([sched_yield], [rt]) +AC_SEARCH_LIBS([nanosleep], [rt]) + AC_CONFIG_FILES(Makefile) AC_OUTPUT -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [PATCH] [AArch64, NEON] Fix testcases add by r218484
On 16 December 2014 at 11:26, Yangfei (Felix) wrote: > The v3 patch attached fixed this minor issue. Thanks. > +2014-12-13 Felix Yang > + Haijian Zhang > + > + * gcc.target/aarch64/advsimd-intrinsics/compute-ref-data.h > + (buffer_float64x2, buffer_pad_float64x2): New helper variables. > + * gcc.target/aarch64/advsimd-intrinsics/arm-neon-ref.h (hfloat64_t, > + result_float64x2, expected_hfloat64x2): New helper type, variable and > + declaration. > + (buffer_float64x2, buffer_pad_float64x2): New helper variables. > + * gcc.target/aarch64/advsimd-intrinsics/vfma.c: Don't run on target > + without the FMA feature and exclude test for vfmaq_f64 on arm*-*-*. > + * gcc.target/aarch64/advsimd-intrinsics/vfms.c: Don't run on target > + without the FMA feature and exclude test for vfmsq_f64 on arm*-*-*. > + * gcc.target/aarch64/advsimd-intrinsics/vfma_n.c: Don't run on > arm*-*-* > + and target without the FMA feature. This is OK /Marcus
Re: [PATCH][AArch64] PR 64448: Combine ((x ^ y) & m) ^ x into bsl/bif instruction
On 16 January 2015 at 16:54, Kyrill Tkachov wrote: > 2014-01-16 Kyrylo Tkachov > > PR target/64448 > * config/aarch64/aarch64-simd.md (aarch64_simd_bsl_internal): > Match xor-and-xor RTL pattern. OK /Marcus
Re: [Patch, AArch64, testsuite] PR63971: Revert test_frame_* patch.
On 19/01/15 08:53, Andrew Pinski wrote:
On Thu, Jan 15, 2015 at 8:18 AM, Mike Stump wrote:
On Jan 14, 2015, at 3:50 AM, Tejas Belagod wrote:
As agreed here (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63971), please can
I reverse Andrew's patch
out(https://gcc.gnu.org/ml/gcc-patches/2014-11/msg02916.html)?
Ok.
Unless someone objects to a reversion like this, when the author of a patch
says it should be reverted… that’s all the approval it needs, though, people
can always ask for a review for any reason they want.
And now this reversal needs to be reverted. Because the conditional
compare optimization went back in. I figured the optimization would
go back in and that is why I did not act on reverting my patch that
fast. The conditional compare patch went in a day after this reversal
went in ;).
Yes, now committed r219838 as obvious.
Thanks,
Tejas.
diff --git a/gcc/testsuite/gcc.target/aarch64/test_frame_1.c
b/gcc/testsuite/gcc.target/aarch64/test_frame_1.c
index 5b3c0ab..b270bae 100644
--- a/gcc/testsuite/gcc.target/aarch64/test_frame_1.c
+++ b/gcc/testsuite/gcc.target/aarch64/test_frame_1.c
@@ -14,6 +14,6 @@ t_frame_pattern (test1, 200, )
t_frame_run (test1)
/* { dg-final { scan-assembler-times "str\tx30, \\\[sp, -\[0-9\]+\\\]!" 2 } }
*/
-/* { dg-final { scan-assembler-times "ldr\tx30, \\\[sp\\\], \[0-9\]+" 3 } } */
+/* { dg-final { scan-assembler-times "ldr\tx30, \\\[sp\\\], \[0-9\]+" 2 } } */
/* { dg-final { cleanup-saved-temps } } */
diff --git a/gcc/testsuite/gcc.target/aarch64/test_frame_2.c
b/gcc/testsuite/gcc.target/aarch64/test_frame_2.c
index 6ec4088..59a089c 100644
--- a/gcc/testsuite/gcc.target/aarch64/test_frame_2.c
+++ b/gcc/testsuite/gcc.target/aarch64/test_frame_2.c
@@ -15,6 +15,6 @@ t_frame_run (test2)
/* { dg-final { scan-assembler-times "stp\tx19, x30, \\\[sp, -\[0-9\]+\\\]!" 1
} } */
-/* { dg-final { scan-assembler-times "ldp\tx19, x30, \\\[sp\\\], \[0-9\]+" 2 }
} */
+/* { dg-final { scan-assembler-times "ldp\tx19, x30, \\\[sp\\\], \[0-9\]+" 1 }
} */
/* { dg-final { cleanup-saved-temps } } */
diff --git a/gcc/testsuite/gcc.target/aarch64/test_frame_4.c
b/gcc/testsuite/gcc.target/aarch64/test_frame_4.c
index ebfb290..d717862 100644
--- a/gcc/testsuite/gcc.target/aarch64/test_frame_4.c
+++ b/gcc/testsuite/gcc.target/aarch64/test_frame_4.c
@@ -14,6 +14,6 @@ t_frame_pattern (test4, 400, "x19")
t_frame_run (test4)
/* { dg-final { scan-assembler-times "stp\tx19, x30, \\\[sp, -\[0-9\]+\\\]!" 1
} } */
-/* { dg-final { scan-assembler-times "ldp\tx19, x30, \\\[sp\\\], \[0-9\]+" 2 }
} */
+/* { dg-final { scan-assembler-times "ldp\tx19, x30, \\\[sp\\\], \[0-9\]+" 1 }
} */
/* { dg-final { cleanup-saved-temps } } */
diff --git a/gcc/testsuite/gcc.target/aarch64/test_frame_6.c
b/gcc/testsuite/gcc.target/aarch64/test_frame_6.c
index b5ea7ee..b66ce09 100644
--- a/gcc/testsuite/gcc.target/aarch64/test_frame_6.c
+++ b/gcc/testsuite/gcc.target/aarch64/test_frame_6.c
@@ -15,6 +15,6 @@ t_frame_pattern (test6, 700, )
t_frame_run (test6)
/* { dg-final { scan-assembler-times "str\tx30, \\\[sp, -\[0-9\]+\\\]!" 2 } }
*/
-/* { dg-final { scan-assembler-times "ldr\tx30, \\\[sp\\\], \[0-9\]+" 3 } } */
+/* { dg-final { scan-assembler-times "ldr\tx30, \\\[sp\\\], \[0-9\]+" 2 } } */
/* { dg-final { cleanup-saved-temps } } */
diff --git a/gcc/testsuite/gcc.target/aarch64/test_frame_7.c
b/gcc/testsuite/gcc.target/aarch64/test_frame_7.c
index daa1f42..22576c4 100644
--- a/gcc/testsuite/gcc.target/aarch64/test_frame_7.c
+++ b/gcc/testsuite/gcc.target/aarch64/test_frame_7.c
@@ -15,6 +15,6 @@ t_frame_pattern (test7, 700, "x19")
t_frame_run (test7)
/* { dg-final { scan-assembler-times "stp\tx19, x30, \\\[sp, -\[0-9\]+\\\]!" 1
} } */
-/* { dg-final { scan-assembler-times "ldp\tx19, x30, \\\[sp\\\], \[0-9\]+" 2 }
} */
+/* { dg-final { scan-assembler-times "ldp\tx19, x30, \\\[sp\\\], \[0-9\]+" 1 }
} */
/* { dg-final { cleanup-saved-temps } } */
[PATCH] Fix scheduling undeterminism from sorting with DEBUG_INSNs
Hi, Even though I have bootstrapped and tested the autoprefetch patch before checking it in, I missed the -mcpu=cortex-a15 setting, so I bootstrapped without autoprefetch model being active. Turning the autoprefetch on revealed an interesting bootstrap miscompare problem. I'm sorry I didn't spot this before checking in autoprefetch patch. The bug this patch fixes was latent since introduction of DEBUG_INSNs. It can be reproduced on, at least, ia64, and, I believe, most other targets too. The bug can't cause wrong code, and only affects code "sameness" with and without debugging information enabled. The underlying problem is that the order in which elements of ready_list are compared matters to the final result. This is because rank_for_schedule sorting heuristic establishes a partial order on the set of instructions, and it can happen that with 3 instructions A, B and C: A>B, B>C, C>A. In this situation the order in which qsort compares the elements affects the final result, it can be either ABC or BCA or CAB. Presence or absence of DEBUG_INSNs in the ready list can change the comparison order, and cause slightly different instruction schedules. I have thought what the best fix is, and it seems unrealistic to convert rank_for_schedule into a absolute-order heuristic without sacrificing its performance. The solution that I propose (and that the patch implements) is to sort DEBUG_INSNs separately from normal insns. If DEBUG_INSNs are present in the ready_list, sort the DEBUG_INSNs only among themselves, while preserving order of the normal insns. Once there are no DEBUG_INSNs in the ready list, sort using the rank_for_schedule heuristic, just as when we would when compiling without debug info. Bootstrapped and regtested on arm-linux-gnueabihf/cortex-a15. OK to commit? Thank you, -- Maxim Kuvyrkov www.linaro.org 0001-Fix-scheduling-undeterminism-from-sorting-with-DEBUG.patch Description: Binary data
Re: [Patch, libstdc++/64649] Fix regex_traits::lookup_collatename and regex_traits::lookup_classname
On 17/01/15 23:09 -0800, Tim Shen wrote:
Bootstrapped and tested in trunk, but I guess it'll fit 4.9 branch
well. I'll do another test for 4.9 if it's appropriate to commit.
Thanks!
--
Regards,
Tim Shen
PR libstdc++/64649
* include/bits/regex.tcc (regex_traits<>::lookup_collatename,
regex_traits<>::lookup_classname): Conform forward iterator constrain
for lookup_collatename lookup_classname.
I think this is clearer:
* include/bits/regex.tcc (regex_traits<>::lookup_collatename,
regex_traits<>::lookup_classname): Support forward iterators.
* testsuite/28_regex/traits/char/lookup_classname.cc: New testcases.
* testsuite/28_regex/traits/char/lookup_collatename.cc: New testcase.
+ string __s(__first, __last);
This assumes the _ForwardIterator value_type is char, or safely
convertible to char. If I'm reading the standard correctly
regex_traits should be able to accept an iterator range
referring to wide chars, e.g.
std::forward_list l{L't', L'i', L'l', L'd', L'e'};
std::regex_traits{}.lookup_collatename(l.begin(), l.end())
Maybe it's OK, because all the elements of __collatename use ASCII
chars which have the same value as wide chars? (Probably not true for
all locales).
Your change is definitely an improvement and good enough for now
(maybe we should leave the Bugzilla PR open, with a note about the
wide char issue, and deal with it after stage4).
OK for trunk - thanks.
Re: [Patch, libstdc++/64584, libstdc++/64585] Clear basic_regex after imbue and make assign exception tolerant
On 17/01/15 16:06 -0800, Tim Shen wrote: On Fri, Jan 16, 2015 at 4:12 AM, Jonathan Wakely wrote: In that case, why bother using a unique_ptr initially, if it will just have to allocate a shared_ptr control block later anyway? It's better to use make_shared to reduce the number of allocations, isn't it? Yes you are right, I didn't notice that shared_ptr<_NFA> can be implicitly converted to shared_ptr. Fixed. OK for trunk and 4.9 - thanks.
Re: [patch] Add and last pieces of C++11 std::lib
On 16/01/15 23:38 +, Jonathan Wakely wrote:
This defines the C++11 header and adds the wstring_convert
and wbuffer_convert utilities.
I've discovered that wasn't the last piece of the C++11 library, there
were new constructors taking std::string added to std::locale and all
the std::xxx_byname facets.
It would be fixed by the attached patch (tested on x86_64-linux with
old and new std::string), but we're in stage4 now so I'm not
committing it yet.
commit 977b94ddcf8218efa0318f69b3a2cc5b5d9eb5be
Author: Jonathan Wakely
Date: Sun Jan 18 16:41:28 2015 +
Add C++11 std::string constructors for locales and facets.
* config/abi/pre/gnu.ver: Export new constructors.
* include/bits/codecvt.h (codecvt_byname): Add string constructor.
(codecvt_byname, codecvt_byname): Define explicit
specializations and declare explicit instantiations.
* include/bits/locale_classes.h (locale, collate_byname): Add string
constructors.
* include/bits/locale_facets.h (ctype_byname, numpunct_byname):
Likewise.
* include/bits/locale_facets_nonio.h (time_get_byname,
time_put_byname, moneypunct_byname, messages_byname): Likewise.
* src/c++11/codecvt.cc (codecvt_byname,
codecvt_byname): Define explicit instantiations.
* src/c++11/locale-inst.cc (time_put_byname, codecvt_byname):
Instantiate string constructors.
(ctype_byname): Define string constructor.
* testsuite/22_locale/codecvt_byname/1.cc: New.
* testsuite/22_locale/collate_byname/1.cc: New.
* testsuite/22_locale/ctype_byname/2.cc: New.
* testsuite/22_locale/messages_byname/1.cc: New.
* testsuite/22_locale/moneypunct_byname/1.cc: New.
* testsuite/22_locale/numpunct_byname/1.cc: New.
diff --git a/libstdc++-v3/config/abi/pre/gnu.ver b/libstdc++-v3/config/abi/pre/gnu.ver
index d23306e..61024bd 100644
--- a/libstdc++-v3/config/abi/pre/gnu.ver
+++ b/libstdc++-v3/config/abi/pre/gnu.ver
@@ -64,8 +64,10 @@ GLIBCXX_3.4 {
# std::char_traits;
# std::c[i-z]*;
std::c[i-n]*;
+# std::collate;
+# std::collate_byname;
# std::condition_variable;
- std::co[^n]*;
+ std::co[^ln]*;
std::c[p-s]*;
std::cu[^r]*;
# std::current_exception
@@ -527,6 +529,14 @@ GLIBCXX_3.4 {
# std::use_facet
_ZSt9use_facetIS*;
+# std::collate
+_ZNSt7collateI[cw]*;
+_ZNKSt7collateI[cw]*;
+
+# std::collate_byname
+_ZNSt14collate_bynameI[cw]EC[12]EPKc?*;
+_ZNSt14collate_bynameI[cw]ED*;
+
# std::ctype
_ZNKSt5ctypeIcE8*;
_ZNKSt5ctypeIcE9*;
@@ -538,7 +548,8 @@ GLIBCXX_3.4 {
_ZNSt10ctype_base[56][ac-z]*;
# std::ctype_byname
-_ZNSt12ctype_bynameI[cw]*;
+_ZNSt12ctype_bynameI[cw]EC[12]EPKc?*;
+_ZNSt12ctype_bynameI[cw]ED*;
# std::num_get
_ZNKSt7num_getI[cw]St19istreambuf_iteratorI[cw]St11char_traitsI[cw]EEE[2-9]*;
@@ -573,7 +584,8 @@ GLIBCXX_3.4 {
_ZNKSt8time_put*;
# std::time_put_byname
-_ZNSt15time_put_byname*;
+_ZNSt15time_put_bynameI[cw]*EC[12]EPKc?*;
+_ZNSt15time_put_bynameI[cw]*ED[012]Ev;
# std::numeric_limits
_ZNSt21__numeric_limits_base[5-9]*;
@@ -1780,6 +1792,25 @@ GLIBCXX_3.4.21 {
_ZNSt25__codecvt_utf8_utf16_base*;
_ZT[ISV]St25__codecvt_utf8_utf16_base*;
+# new string ctors for _byname facets
+_ZNSt12ctype_bynameI[cw]EC[1-5]ERKSsm;
+_ZNSt14codecvt_bynameI[cw]c11__mbstate_tEC[1-5]ERKSsm;
+_ZNSt15messages_bynameI[cw]EC[1-5]ERKSsm;
+_ZNSt15numpunct_bynameI[cw]EC[1-5]ERKSsm;
+_ZNSt15time_get_bynameI[cw]St19istreambuf_iteratorI[cw]St11char_traitsI[cw]EEEC[1-5]ERKSsm;
+_ZNSt15time_put_bynameI[cw]St19ostreambuf_iteratorI[cw]St11char_traitsI[cw]EEEC[1-5]ERKSsm;
+_ZNSt17moneypunct_bynameI[cw]Lb0EEC[1-5]ERKSsm;
+_ZNSt17moneypunct_bynameI[cw]Lb1EEC[1-5]ERKSsm;
+
+_ZNSt12ctype_bynameI[cw]EC[1-5]ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEm;
+_ZNSt14codecvt_bynameI[cw]c11__mbstate_tEC[1-5]ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEm;
+_ZNSt15time_put_bynameI[cw]St19ostreambuf_iteratorI[cw]St11char_traitsI[cw]EEEC[1-5]ERKNSt7__cxx1112basic_stringIcS2_SaIcEEEm;
+_ZNSt7__cxx1115messages_bynameI[cw]EC[1-5]ERKNS_12basic_stringIcSt11char_traitsIcESaIcEEEm;
+_ZNSt7__cxx1115numpunct_bynameI[cw]EC[1-5]ERKNS_12basic_stringIcSt11char_traitsIcESaIcEEEm;
+_ZNSt7__cxx1115time_get_bynameI[cw]St19istreambuf_iteratorI[cw]St11char_traitsI[cw]EEEC[1-5]ERKNS_12basic_stringIcS3_SaIcEEEm;
+_ZNSt7__cxx1117moneypunct_bynameI[cw]Lb0EEC[1-5]ERKNS_12basic_stringIcSt11char_traitsIcESaIcEEEm;
+_ZNSt7__cxx1117moneypunct_bynameI[cw]Lb1EEC[1-5]ERKNS_12basic_stringIcSt11char_traitsIcESaIcEEEm;
+
} GLIBCXX_3.4.20;
diff --git a/libstdc++-v3/include/bits/codecvt.h b/libstdc++-v3/include/bits/codecvt.h
index a6e59b5..c76215f 100644
--- a/libstdc++-v3/include/bits/codecvt.h
+++ b/libstdc++-v3/include/bits/codecvt.h
@@ -594,11 +594,55 @@ _GLIBCXX_BEGIN_NAMESPACE_VERS
Re: [[ARM/AArch64][testsuite] 03/36] Add vmax, vmin, vhadd, vhsub and vrhadd tests.
On 16 January 2015 at 17:52, Christophe Lyon wrote: >> OK provided, as per the previous couple, that we don;t regression or >> introduce new fails on aarch64[_be] or aarch32. > > This patch shows failures on aarch64 and aarch64_be for vmax and vmin > when the input is -NaN. > It's a corner case, and my reading of the ARM ARM is that the result > should the same as on aarch32. > I haven't had time to look at it in more details though. > So, not OK? They should have the same behaviour in aarch32 and aarch64. Did you test on HW or a model? /Marcus
Re: [patch] Add and last pieces of C++11 std::lib
On Mon, Jan 19, 2015 at 01:27:17PM +, Jonathan Wakely wrote: > On 16/01/15 23:38 +, Jonathan Wakely wrote: > >This defines the C++11 header and adds the wstring_convert > >and wbuffer_convert utilities. > > I've discovered that wasn't the last piece of the C++11 library, there > were new constructors taking std::string added to std::locale and all > the std::xxx_byname facets. > > It would be fixed by the attached patch (tested on x86_64-linux with > old and new std::string), but we're in stage4 now so I'm not > committing it yet. If it is the only missing C++11 part, or close to that, I think it would be still ok for trunk now. Jakub
Re: [[ARM/AArch64][testsuite] 05/36] Add vldX_dup test.
On 16 January 2015 at 18:12, Christophe Lyon wrote: > On 16 January 2015 at 16:20, Tejas Belagod wrote: >> On 13/01/15 15:18, Christophe Lyon wrote: >>> >>> >>> * gcc.target/aarch64/advsimd-intrinsics/vldX_dup.c: New file. >>> > Thanks, I should mention that this test fails on aarch64_be, because > of pending Alan's patches. > OK, thanks /Marcus
Re: [PATCH] Fix scheduling undeterminism from sorting with DEBUG_INSNs
On Mon, 19 Jan 2015, Maxim Kuvyrkov wrote: > The underlying problem is that the order in which elements of ready_list are > compared matters to the final result. This is because rank_for_schedule > sorting heuristic establishes a partial order on the set of instructions, > and it can happen that with 3 instructions A, B and C: A>B, B>C, C>A. In > this situation the order in which qsort compares the elements affects the > final result, it can be either ABC or BCA or CAB. > > Presence or absence of DEBUG_INSNs in the ready list can change the > comparison order, and cause slightly different instruction schedules. Could you please provide a bit more detail here? Looking at rank_for_schedule, I see that it considers insn pairs when at least one of them is DEBUG_INSN, first. Debug insns are always moved to front, sorted within themselves by luid, and not considered in the rest of rank_for_schedule. I don't see how rank_for_schedule with DEBUG_INSN can arrive at a A < B < C < A situation. (btw, nitpicking, a "partial order" is when incomparable pairs are possible (i.e. none of A == B, A < B, B < A is true), a "total order" is when all pairs are comparable, and when you can have A < B < C < A, it's not a mathematical order relation) Thanks. Alexander
Re: [[ARM/AArch64][testsuite] 06/36] Add vmla and vmls tests.
On 13 January 2015 at 15:18, Christophe Lyon wrote: > > * gcc.target/aarch64/advsimd-intrinsics/vmlX.inc: New file. > * gcc.target/aarch64/advsimd-intrinsics/vmla.c: New file. > * gcc.target/aarch64/advsimd-intrinsics/vmls.c: New file. OK with the the vmlx poly ops dropped /M
Re: [[ARM/AArch64][testsuite] 07/36] Add vmla_lane and vmls_lane tests.
On 13 January 2015 at 15:18, Christophe Lyon wrote: > > * gcc.target/aarch64/advsimd-intrinsics/vmlX_lane.inc: New file. > * gcc.target/aarch64/advsimd-intrinsics/vmla_lane.c: New file. > * gcc.target/aarch64/advsimd-intrinsics/vmls_lane.c: New file. OK with Tejas' comment addressed. /Marcus
Re: [AArch64/GCC] PR64304, miscompilation with -mgeneral-regs-only
On 16 January 2015 at 11:17, Jiong Wang wrote: > exactly, thanks, we should use FAIL although DONE and FAIL work the same in > this scenario. > > I checked their definition, FAIL always return the initial value of _val > which is NULL, > while DONE stop and return generated insns which for this pattern happen to > be NULL also. that > explain why it's not exposed by testing. > > > #define FAIL return (end_sequence (), _val) > #define DONE return (_val = get_insns (), end_sequence (), _val) It seems rather odd to me that DONE behaves in this way. Your patch is OK with DONE switched to FAIL. /Marcus
Re: [PATCH] Fix scheduling undeterminism from sorting with DEBUG_INSNs
On Jan 19, 2015, at 4:34 PM, Alexander Monakov wrote: > On Mon, 19 Jan 2015, Maxim Kuvyrkov wrote: >> The underlying problem is that the order in which elements of ready_list are >> compared matters to the final result. This is because rank_for_schedule >> sorting heuristic establishes a partial order on the set of instructions, >> and it can happen that with 3 instructions A, B and C: A>B, B>C, C>A. In >> this situation the order in which qsort compares the elements affects the >> final result, it can be either ABC or BCA or CAB. >> >> Presence or absence of DEBUG_INSNs in the ready list can change the >> comparison order, and cause slightly different instruction schedules. > > Could you please provide a bit more detail here? Looking at > rank_for_schedule, I see that it considers insn pairs when at least one of > them is DEBUG_INSN, first. Debug insns are always moved to front, sorted > within themselves by luid, and not considered in the rest of > rank_for_schedule. I don't see how rank_for_schedule with DEBUG_INSN can > arrive at a A < B < C < A situation. In A < B < C < A case all A, B and C are normal instructions. It is a pre-existing condition. When compiling without debug information we have ready list "A, B, C". When compiling with debug information, we have ready list "A, B, C, D" where "D" is DEBUG_INSN. Because we now have 4 elements to sort instead of 3, qsort can choose a different order of comparison _among_ A, B and C. Since order of comparison matters (due to pre-existing condition of A < B < C < D) we can get a differently-sorted list. > > (btw, nitpicking, a "partial order" is when incomparable pairs are possible > (i.e. none of A == B, A < B, B < A is true), a "total order" is when all > pairs are comparable, and when you can have A < B < C < A, it's not a > mathematical order relation) You've got good grades in the Uni, didn't you :-). -- Maxim Kuvyrkov www.linaro.org
Re: [[ARM/AArch64][testsuite] 10/36] Add vmlal and vmlsl tests.
On 13 January 2015 at 15:18, Christophe Lyon wrote: > * gcc.target/aarch64/advsimd-intrinsics/vmlXl.inc: New file. > * gcc.target/aarch64/advsimd-intrinsics/vmlal.c: New file. > * gcc.target/aarch64/advsimd-intrinsics/vmlsl.c: New file. OK /Marcus
Re: [[ARM/AArch64][testsuite] 08/36] Add vtrn tests. Refactor vzup and vzip tests.
On 16 January 2015 at 18:10, Christophe Lyon wrote: > On 16 January 2015 at 16:58, Tejas Belagod wrote: >> On 13/01/15 15:18, Christophe Lyon wrote: >>> * gcc.target/aarch64/advsimd-intrinsics/vshuffle.inc: New file. >>> * gcc.target/aarch64/advsimd-intrinsics/vtrn.c: New file. >>> * gcc.target/aarch64/advsimd-intrinsics/vuzp.c: Use code from >>> vshuffle.inc. >>> * gcc.target/aarch64/advsimd-intrinsics/vzip.c: Use code from >>> vshuffle.inc. >> >> LGTM. >> > Thanks, I should mention that the new vtrn test fails on aarch64_be > (like vzip and vuzp), because of pending Alan's patches to fix > aarch64_be load/stores. > So strictly speaking this patch show new fails. > OK /Marcus
Re: [[ARM/AArch64][testsuite] 11/36] Add vmlal_lane and vmlsl_lane tests.
On 13 January 2015 at 15:18, Christophe Lyon wrote: > * gcc.target/aarch64/advsimd-intrinsics/vmlXl_lane.inc: New file. > * gcc.target/aarch64/advsimd-intrinsics/vmlal_lane.c: New file. > * gcc.target/aarch64/advsimd-intrinsics/vmlsl_lane.c: New file. OK /Marcus
Re: [[ARM/AArch64][testsuite] 12/36] Add vmlal_n and vmlsl_n tests.
On 13 January 2015 at 15:18, Christophe Lyon wrote: > * gcc.target/aarch64/advsimd-intrinsics/vmlXl_n.inc: New file. > * gcc.target/aarch64/advsimd-intrinsics/vmlal_n.c: New file. > * gcc.target/aarch64/advsimd-intrinsics/vmlsl_n.c: New file. OK /Marcus
Re: [[ARM/AArch64][testsuite] 14/36] Add vqdmlal and vqdmlsl tests.
On 13 January 2015 at 15:18, Christophe Lyon wrote: > * gcc.target/aarch64/advsimd-intrinsics/vqdmlXl.inc: New file. > * gcc.target/aarch64/advsimd-intrinsics/vqdmlal.c: New file. > * gcc.target/aarch64/advsimd-intrinsics/vqdmlsl.c: New file. OK /Marcus
Re: [[ARM/AArch64][testsuite] 15/36] Add vqdmlal_lane and vqdmlsl_lane tests.
On 13 January 2015 at 15:18, Christophe Lyon wrote: > * gcc.target/aarch64/advsimd-intrinsics/vqdmlXl_lane.inc: New file. > * gcc.target/aarch64/advsimd-intrinsics/vqdmlal_lane.c: New file. > * gcc.target/aarch64/advsimd-intrinsics/vqdmlsl_lane.c: New file. OK /Marcus
Re: [[ARM/AArch64][testsuite] 16/36] Add vqdmlal_n and vqdmlsl_n tests.
On 13 January 2015 at 15:18, Christophe Lyon wrote: > * gcc.target/aarch64/advsimd-intrinsics/vqdmlXl_n.inc: New file. > * gcc.target/aarch64/advsimd-intrinsics/vqdmlal_n.c: New file. > * gcc.target/aarch64/advsimd-intrinsics/vqdmlsl_n.c: New file. OK /Marcus
Re: [[ARM/AArch64][testsuite] 18/36] Add vsli_n and vsri_n tests.
On 16 January 2015 at 18:06, Tejas Belagod wrote:
>> +
>> +void vsri_extra(void)
>> +{
>> +/* Test cases with maximum shift amount (this amount is different
>> + * from vsli. */
>> +
>
>
> Nit. Comment Formatting. Similarly, few other places.
>
> Otherwise, LGTM.
>
> Tejas.
>
w.r.t the unbalanced parenthesis then fair point. This suite of tests
has numerous gnu style inconsistencies. Given that Christophe is
importing a pre-existing body of code and that this is in testsuite it
seemed unreasonable to insist on a reformat. Christophe, fix up the
unbalanced parenthesis and this is OK. /Marcus
Re: [[ARM/AArch64][testsuite] 19/36] Add vsubl tests, put most of the code in common with vaddl in vXXXl.inc.
On 13 January 2015 at 15:18, Christophe Lyon wrote: > * gcc.target/aarch64/advsimd-intrinsics/vXXXl.inc: New file. > * gcc.target/aarch64/advsimd-intrinsics/vsubl.c: New file. > * gcc.target/aarch64/advsimd-intrinsics/vaddl.c: Use code from > vXXXl.inc. OK /Marcus
Re: [[ARM/AArch64][testsuite] 20/36] Add vsubw tests, putting most of the code in common with vaddw through vXXWw.inc
On 13 January 2015 at 15:18, Christophe Lyon wrote: > * gcc.target/aarch64/advsimd-intrinsics/vXXXw.inc: New file. > * gcc.target/aarch64/advsimd-intrinsics/vsubw.c: New file. > * gcc.target/aarch64/advsimd-intrinsics/vaddw.c: Use code from > vXXXw.inc. OK /Marcus
Re: [[ARM/AArch64][testsuite] 22/36] Add vmovn tests.
On 13 January 2015 at 15:18, Christophe Lyon wrote: > * gcc.target/aarch64/advsimd-intrinsics/vmovn.c: New file. OK /Marcus
Re: [PATCH, libstdc++] PR libstdc++/64656
On 19/01/15 02:48 +0200, Ville Voutilainen wrote:
Minor additions:
- add a comment to the #endif for the c++14 #if
- fix the doc comments to talk about reverse iterators
Thanks, I like the new comments more.
This passes the testsuite.
Posted during stage3 so OK for trunk.
diff --git a/libstdc++-v3/include/bits/range_access.h
b/libstdc++-v3/include/bits/range_access.h
index fa18aa2..a5a511c 100644
--- a/libstdc++-v3/include/bits/range_access.h
+++ b/libstdc++-v3/include/bits/range_access.h
@@ -33,7 +33,7 @@
#pragma GCC system_header
#if __cplusplus >= 201103L
-
+#include
namespace std _GLIBCXX_VISIBILITY(default)
{
_GLIBCXX_BEGIN_NAMESPACE_VERSION
@@ -97,6 +97,131 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
end(_Tp (&__arr)[_Nm])
{ return __arr + _Nm; }
+#if __cplusplus >= 201402L
+ /**
+ * @brief Return an iterator pointing to the first element of
+ * the const container.
+ * @param __cont Container.
+ */
+ template
+inline constexpr auto
The 'inline' is redundant with 'constexpr' but harmless.
I notice we are missing the 'constexpr' that C++14 adds to the
existing begin/end functions for arrays, so I'm committing this
slightly changed version. I added _GLIBCXX14_CONSTEXPR to the
existing begin() and end() functions for arrays, and changed the new
test to use VERIFY instead of assert and to use the functions in
constant expressions.
Tested x86_64-linux and committed to trunk.
commit a19707d5d6ed6f93ea8ac613f6a1f35c0c996f90
Author: Jonathan Wakely
Date: Mon Jan 19 13:42:32 2015 +
2015-01-19 Ville Voutilainen
Jonathan Wakely
* include/bits/range_access.h (begin, end): Use _GLIBCXX14_CONSTEXPR
on overloads for arrays.
(cbegin, cend, rbegin, rend, crbegin, crend): New.
* testsuite/24_iterators/range_access_cpp14.cc: New.
diff --git a/libstdc++-v3/include/bits/range_access.h b/libstdc++-v3/include/bits/range_access.h
index fa18aa2..510c0b1 100644
--- a/libstdc++-v3/include/bits/range_access.h
+++ b/libstdc++-v3/include/bits/range_access.h
@@ -33,7 +33,7 @@
#pragma GCC system_header
#if __cplusplus >= 201103L
-
+#include
namespace std _GLIBCXX_VISIBILITY(default)
{
_GLIBCXX_BEGIN_NAMESPACE_VERSION
@@ -83,7 +83,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
* @param __arr Array.
*/
template
-inline _Tp*
+inline _GLIBCXX14_CONSTEXPR _Tp*
begin(_Tp (&__arr)[_Nm])
{ return __arr; }
@@ -93,10 +93,135 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
* @param __arr Array.
*/
template
-inline _Tp*
+inline _GLIBCXX14_CONSTEXPR _Tp*
end(_Tp (&__arr)[_Nm])
{ return __arr + _Nm; }
+#if __cplusplus >= 201402L
+ /**
+ * @brief Return an iterator pointing to the first element of
+ * the const container.
+ * @param __cont Container.
+ */
+ template
+inline constexpr auto
+cbegin(const _Container& __cont) noexcept(noexcept(std::begin(__cont)))
+ -> decltype(std::begin(__cont))
+{ return std::begin(__cont); }
+
+ /**
+ * @brief Return an iterator pointing to one past the last element of
+ * the const container.
+ * @param __cont Container.
+ */
+ template
+inline constexpr auto
+cend(const _Container& __cont) noexcept(noexcept(std::end(__cont)))
+ -> decltype(std::end(__cont))
+{ return std::end(__cont); }
+
+ /**
+ * @brief Return a reverse iterator pointing to the last element of
+ * the container.
+ * @param __cont Container.
+ */
+ template
+inline auto
+rbegin(_Container& __cont) -> decltype(__cont.rbegin())
+{ return __cont.rbegin(); }
+
+ /**
+ * @brief Return a reverse iterator pointing to the last element of
+ * the const container.
+ * @param __cont Container.
+ */
+ template
+inline auto
+rbegin(const _Container& __cont) -> decltype(__cont.rbegin())
+{ return __cont.rbegin(); }
+
+ /**
+ * @brief Return a reverse iterator pointing one past the first element of
+ * the container.
+ * @param __cont Container.
+ */
+ template
+inline auto
+rend(_Container& __cont) -> decltype(__cont.rend())
+{ return __cont.rend(); }
+
+ /**
+ * @brief Return a reverse iterator pointing one past the first element of
+ * the const container.
+ * @param __cont Container.
+ */
+ template
+inline auto
+rend(const _Container& __cont) -> decltype(__cont.rend())
+{ return __cont.rend(); }
+
+ /**
+ * @brief Return a reverse iterator pointing to the last element of
+ * the array.
+ * @param __arr Array.
+ */
+ template
+inline reverse_iterator<_Tp*>
+rbegin(_Tp (&__arr)[_Nm])
+{ return reverse_iterator<_Tp*>(__arr + _Nm); }
+
+ /**
+ * @brief Return a reverse iterator pointing one past the first element of
+ * the array.
+ * @param __arr Array.
+ */
+ template
+inline reverse_iterator<_Tp*>
+rend(_Tp (&__ar
[PATCH] Fix PR64313
This fixes PR64313 - the match-and-simplify machinery has a hard
time re-doing the "magic" trick of re-using builtins in the matched IL
and thus fails to generate calls to builtins that are not marked
as builtin_decl_implicit_p.
The following patch fixes this by remembering whether the user
has declared a builtin in a new per-builtin flag and recognizing
explicit uses (in ADDR_EXPRs which catches calls and address-takens)
during gimplification. For explicitely used builtins the compiler
can generate them implicitely (well, not 100% true - the semantics
do not have to agree unless the identifier is reserved, sth we can't
check easily).
This is an approach that follows that of the STPCPY case right next
to the place this patch patches the frontends, just a little bit less
aggressive in requiring an explicit use of the builtin.
No attempt is done to preserve (and merge) this through LTO - builtins
are streamed by simply streaming DECL_FUNCTION_CODE which makes doing
this a bit hard(er). The gcc.dg/torture/builtin-explog-1.c testcase
was failing on bare-metal targets and is fixed with the patch below
already during early optimizations.
An alternative to fix the regression is to remove the very few
builtin simplification patterns from match.pd and/or restore
the folding code in builtins.c. The issue would then need to
be revisited during the next stage1 (where I can look into how to
deal with this with LTO - but 'implicit_p' is also not transitioned
properly if you combine for example a C89 input and C99 input - lto1
defaults all of flag_isoc{94,99,11} to zero and uses the C family
builtins.def way of initialization, so the LTO issue is certainly
pre-existing).
Ok for trunk now?
Bootstrap and regtest is running on x86_64-unknown-linux-gnu.
Thanks,
Richard.
2015-01-19 Richard Biener
PR middle-end/64313
* tree-core.h (builtin_info, builtin_info_type): Turn from
an object with two arrays into an array of an object with
decl and two flags, implicit_p and declared_p.
* tree.h (builtin_decl_explicit, builtin_decl_implicit,
set_builtin_decl, set_builtin_decl_implicit_p,
builtin_decl_explicit_p, builtin_decl_implicit_p): Adjust.
(set_builtin_decl_declared_p, builtin_decl_declared_p): New functions.
* builtins.c (builtin_info): Adjust.
* gimplify.c (gimplify_addr_expr): References to builtins
that have been declared by the user makes them eligible for
use by the compiler. Call set_builtin_decl_implicit_p on them.
c/
* c-decl.c (merge_decls): Call set_builtin_decl_declared_p
for builtins the user declared correctly.
cp/
* decl.c (duplicate_decls): Call set_builtin_decl_declared_p
for builtins the user declared correctly.
Index: gcc/tree.h
===
*** gcc/tree.h.orig 2015-01-19 14:51:26.175142267 +0100
--- gcc/tree.h 2015-01-19 15:11:48.602099942 +0100
*** builtin_decl_explicit (enum built_in_fun
*** 4606,4612
{
gcc_checking_assert (BUILTIN_VALID_P (fncode));
! return builtin_info.decl[(size_t)fncode];
}
/* Return the tree node for an implicit builtin function or NULL. */
--- 4606,4612
{
gcc_checking_assert (BUILTIN_VALID_P (fncode));
! return builtin_info[(size_t)fncode].decl;
}
/* Return the tree node for an implicit builtin function or NULL. */
*** builtin_decl_implicit (enum built_in_fun
*** 4616,4625
size_t uns_fncode = (size_t)fncode;
gcc_checking_assert (BUILTIN_VALID_P (fncode));
! if (!builtin_info.implicit_p[uns_fncode])
return NULL_TREE;
! return builtin_info.decl[uns_fncode];
}
/* Set explicit builtin function nodes and whether it is an implicit
--- 4616,4625
size_t uns_fncode = (size_t)fncode;
gcc_checking_assert (BUILTIN_VALID_P (fncode));
! if (!builtin_info[uns_fncode].implicit_p)
return NULL_TREE;
! return builtin_info[uns_fncode].decl;
}
/* Set explicit builtin function nodes and whether it is an implicit
*** set_builtin_decl (enum built_in_function
*** 4633,4640
gcc_checking_assert (BUILTIN_VALID_P (fncode)
&& (decl != NULL_TREE || !implicit_p));
! builtin_info.decl[ufncode] = decl;
! builtin_info.implicit_p[ufncode] = implicit_p;
}
/* Set the implicit flag for a builtin function. */
--- 4633,4641
gcc_checking_assert (BUILTIN_VALID_P (fncode)
&& (decl != NULL_TREE || !implicit_p));
! builtin_info[ufncode].decl = decl;
! builtin_info[ufncode].implicit_p = implicit_p;
! builtin_info[ufncode].declared_p = false;
}
/* Set the implicit flag for a builtin function. */
*** set_builtin_decl_implicit_p (enum built_
*** 4645,4653
size_t uns_fncode = (size_t)fncode;
gcc_checking_assert (BUILTIN_VALID_P (fncode)
!
Re: [PATCH] Workaround -Wmaybe-uninitialized false positives during profiledbootstrap
On 01/15/2015 12:35 PM, Richard Biener wrote:
On Thu, Jan 15, 2015 at 12:29 PM, Jakub Jelinek wrote:
On Thu, Jan 15, 2015 at 12:17:44PM +0100, Richard Biener wrote:
On Thu, Jan 15, 2015 at 12:10 PM, Jakub Jelinek wrote:
Hi!
I ran into -Werror=maybe-uninitialized errors during profiledbootstrap
(../configure --enable-languages=c,c++ --enable-checking=release;
make -j16 profiledboostrap) before I hit a miscompilation I'm going to file.
Is this ok for trunk, or do we want to work around them differently?
I wonder if we can arrange profiledbootstrap to use --disable-werror
unless --enable-werror is specified explicitely... Similarly useful
if we could do a similar thing from non-standard build-configs...
For non-standard ones I'm ok, but I've always hoped that profiledbootstrap
is considered standard. It certainly worked fine with -Werror at least
for us in gcc 4.[4-9].
Indeed it did (with release checking at least).
I also wonder if we shouldn't simply fix the uninit pass ...
If it is possible, sure, but it isn't always the case.
We could also just use type var = var; if that is the way to avoid
the warnings and not generate extra code.
Is that portable though? (legal C, not subject to other compilers
that it might be "hineous"...)
Anyway, I guess the patch is ok if you add a comment after the inits
/* initialize to avoid warnings with profiledbootstrap */
or similar. Otherwise people might be tempted to remove the
init again (or wonder why it is there) as it works in regular bootstrap.
Thanks,
Richard.
Jakub
Hello.
There's a bunch of another places that emit false positives. With following
patch,
I am able to run profiledbootstrap on x86_64-linux-pc and ppc64-linux-pc.
Ready for trunk?
Thanks,
Martin
>From 53c21661d2371c513b5940ee534b89044c066d2a Mon Sep 17 00:00:00 2001
From: mliska
Date: Mon, 19 Jan 2015 13:30:53 +0100
Subject: [PATCH] Remove false positives for warnings that break LTO profiled
bootstrap.
gcc/ChangeLog:
2015-01-19 Martin Liska
* tree.h (tree_vec_elt_check): Workaround -Wstrict-overflow
false positive during profiledbootstrap.
gcc/fortran/ChangeLog:
2015-01-19 Martin Liska
* decl.c (attr_decl1): Workaround -Wmaybe-uninitialized
false positive during profiledbootstrap by initializing them.
* matchexp.c (match_mult_operand): Likewise.
* module.c (write_atom): Likewise.
(read_module): Likewise.
---
gcc/fortran/decl.c | 5 -
gcc/fortran/matchexp.c | 4 +++-
gcc/fortran/module.c | 9 +++--
gcc/tree.h | 7 +++
4 files changed, 21 insertions(+), 4 deletions(-)
diff --git a/gcc/fortran/decl.c b/gcc/fortran/decl.c
index 2a200fc..cc35c65 100644
--- a/gcc/fortran/decl.c
+++ b/gcc/fortran/decl.c
@@ -6391,7 +6391,10 @@ attr_decl1 (void)
{
char name[GFC_MAX_SYMBOL_LEN + 1];
gfc_array_spec *as;
- gfc_symbol *sym;
+
+ /* Workaround -Wmaybe-uninitialized false positive during
+ profiledbootstrap by initializing them. */
+ gfc_symbol *sym = NULL;
locus var_locus;
match m;
diff --git a/gcc/fortran/matchexp.c b/gcc/fortran/matchexp.c
index ec07dfc..fc35c8c 100644
--- a/gcc/fortran/matchexp.c
+++ b/gcc/fortran/matchexp.c
@@ -258,7 +258,9 @@ match_add_op (void)
static match
match_mult_operand (gfc_expr **result)
{
- gfc_expr *e, *exp, *r;
+ /* Workaround -Wmaybe-uninitialized false positive during
+ profiledbootstrap by initializing them. */
+ gfc_expr *e = NULL, *exp, *r;
locus where;
match m;
diff --git a/gcc/fortran/module.c b/gcc/fortran/module.c
index c47489a..4cfc0e2 100644
--- a/gcc/fortran/module.c
+++ b/gcc/fortran/module.c
@@ -1536,7 +1536,10 @@ static void
write_atom (atom_type atom, const void *v)
{
char buffer[20];
- int i, len;
+
+ /* Workaround -Wmaybe-uninitialized false positive during
+ profiledbootstrap by initializing them. */
+ int i = 0, len;
const char *p;
switch (atom)
@@ -4908,7 +4911,9 @@ read_module (void)
const char *p;
char name[GFC_MAX_SYMBOL_LEN + 1];
int i;
- int ambiguous, j, nuse, symbol;
+ /* Workaround -Wmaybe-uninitialized false positive during
+ profiledbootstrap by initializing them. */
+ int ambiguous = 0, j, nuse, symbol = 0;
pointer_info *info, *q;
gfc_use_rename *u = NULL;
gfc_symtree *st;
diff --git a/gcc/tree.h b/gcc/tree.h
index 4f83b38..03a8303 100644
--- a/gcc/tree.h
+++ b/gcc/tree.h
@@ -3050,6 +3050,11 @@ tree_int_cst_elt_check (tree __t, int __i,
return &CONST_CAST_TREE (__t)->int_cst.val[__i];
}
+/* Workaround -Wstrict-overflow false positive during profiledbootstrap. */
+
+#pragma GCC diagnostic push
+#pragma GCC diagnostic ignored "-Wstrict-overflow"
+
inline tree *
tree_vec_elt_check (tree __t, int __i,
const char *__f, int __l, const char *__g)
@@ -3061,6 +3066,8 @@ tree_vec_elt_check (tree __t, int __i,
return &CONST_CAST_TREE (__t)->vec.a[__i];
}
+#pragma GCC diagnostic pop
+
inline tree *
omp_clause_elt_check (tree __t, int __i,
[PATCH] rs6000, jit: Unbreak libgccjit on ppc (rs6000_output_function_epilogue)
rs6000_output_function_epilogue performs a series of string comparisons on language_string, with a gcc_unreachable (); if the language_string is unrecognized. This leads to failure of any attempt to use libgccjit on rs6000, since jit/dummy-frontend.c has: #define LANG_HOOKS_NAME "libgccjit" The attached patch adds support for this lang hook name, using 0 for the language type. Takes jit.sum from: # of expected passes1417 # of unexpected failures30 to: # of expected passes3428 # of unexpected failures6 (am investigating the other failures) OK for trunk? gcc/ChangeLog * config/rs6000/rs6000.c (rs6000_output_function_epilogue): Support the JIT by using 0 as the language type. --- gcc/config/rs6000/rs6000.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c index 80fcd65..d076656 100644 --- a/gcc/config/rs6000/rs6000.c +++ b/gcc/config/rs6000/rs6000.c @@ -25491,11 +25491,12 @@ rs6000_output_function_epilogue (FILE *file, use language_string. C is 0. Fortran is 1. Pascal is 2. Ada is 3. C++ is 9. Java is 13. Objective-C is 14. Objective-C++ isn't assigned -a number, so for now use 9. LTO and Go aren't assigned numbers +a number, so for now use 9. LTO, Go and JIT aren't assigned numbers either, so for now use 0. */ if (lang_GNU_C () || ! strcmp (language_string, "GNU GIMPLE") - || ! strcmp (language_string, "GNU Go")) + || ! strcmp (language_string, "GNU Go") + || ! strcmp (language_string, "libgccjit")) i = 0; else if (! strcmp (language_string, "GNU F77") || ! strcmp (language_string, "GNU Fortran")) -- 1.8.1.4
[Patch, Fortran, OOP] PR 64230: [4.9/5 Regression] Invalid memory reference in a compiler-generated finalizer for allocatable component
Hi,
this is a second patch dealing with finalization-related regressions,
after the one I submitted yesterday
(https://gcc.gnu.org/ml/fortran/2015-01/msg00109.html), which btw is
also still waiting for review ...
This patch fixes an invalid memory reference inside the finalizer
routine (at runtime), which apparently was caused by dereferencing a
pointer without checking if it's NULL. I simply insert a call to
ASSOCIATED.
I also rename two different runtime variables, which were both called
'ptr', to 'ptr1' and 'ptr2', just to make it easier to distinguish
them in the dump.
I also have the feeling the a lot of what is being done in
generate_finalization_wrapper and finalize_component (including my
changes) is a bit laborious. Some helper functions might be useful to
make all that code generation a bit more readable and less verbose. I
may attack this in a follow-up patch.
This one regtests cleanly on x86_64-unknown-linux-gnu. Ok for trunk and 4.9?
Cheers,
Janus
2015-01-19 Janus Weil
PR fortran/64230
* class.c (finalize_component): New argument 'sub_ns'. Insert code to
check if 'expr' is associated.
(generate_finalization_wrapper): Rename 'ptr' symbols to 'ptr1' and
'ptr2'. Pass 'sub_ns' to finalize_component.
2015-01-19 Janus Weil
PR fortran/64230
* gfortran.dg/class_allocate_18.f90: Extended.
Index: gcc/fortran/class.c
===
--- gcc/fortran/class.c (Revision 219840)
+++ gcc/fortran/class.c (Arbeitskopie)
@@ -881,7 +881,8 @@ comp_is_finalizable (gfc_component *comp)
static void
finalize_component (gfc_expr *expr, gfc_symbol *derived, gfc_component *comp,
- gfc_symbol *stat, gfc_symbol *fini_coarray, gfc_code **code)
+ gfc_symbol *stat, gfc_symbol *fini_coarray, gfc_code **code,
+ gfc_namespace *sub_ns)
{
gfc_expr *e;
gfc_ref *ref;
@@ -950,15 +951,32 @@ finalize_component (gfc_expr *expr, gfc_symbol *de
dealloc->ext.alloc.list->expr = e;
dealloc->expr1 = gfc_lval_expr_from_sym (stat);
+ gfc_code *cond = gfc_get_code (EXEC_IF);
+ cond->block = gfc_get_code (EXEC_IF);
+ cond->block->expr1 = gfc_get_expr ();
+ cond->block->expr1->expr_type = EXPR_FUNCTION;
+ gfc_get_sym_tree ("associated", sub_ns, &cond->block->expr1->symtree,
false);
+ cond->block->expr1->symtree->n.sym->attr.flavor = FL_PROCEDURE;
+ cond->block->expr1->symtree->n.sym->attr.intrinsic = 1;
+ cond->block->expr1->symtree->n.sym->result =
cond->block->expr1->symtree->n.sym;
+ gfc_commit_symbol (cond->block->expr1->symtree->n.sym);
+ cond->block->expr1->ts.type = BT_LOGICAL;
+ cond->block->expr1->ts.kind = gfc_default_logical_kind;
+ cond->block->expr1->value.function.isym = gfc_intrinsic_function_by_id
(GFC_ISYM_ASSOCIATED);
+ cond->block->expr1->value.function.actual = gfc_get_actual_arglist ();
+ cond->block->expr1->value.function.actual->expr = gfc_copy_expr (expr);
+ cond->block->expr1->value.function.actual->next = gfc_get_actual_arglist
();
+ cond->block->next = dealloc;
+
if (block)
- block->next = dealloc;
+ block->next = cond;
else if (*code)
{
- (*code)->next = dealloc;
+ (*code)->next = cond;
(*code) = (*code)->next;
}
else
- (*code) = dealloc;
+ (*code) = cond;
}
else if (comp->ts.type == BT_DERIVED
&& comp->ts.u.derived->f2k_derived
@@ -994,7 +1012,8 @@ finalize_component (gfc_expr *expr, gfc_symbol *de
gfc_component *c;
for (c = comp->ts.u.derived->components; c; c = c->next)
- finalize_component (e, comp->ts.u.derived, c, stat, fini_coarray, code);
+ finalize_component (e, comp->ts.u.derived, c, stat, fini_coarray, code,
+ sub_ns);
gfc_free_expr (e);
}
}
@@ -1927,7 +1946,7 @@ generate_finalization_wrapper (gfc_symbol *derived
{
gfc_finalizer *fini, *fini_elem = NULL;
- gfc_get_symbol ("ptr", sub_ns, &ptr);
+ gfc_get_symbol ("ptr1", sub_ns, &ptr);
ptr->ts.type = BT_DERIVED;
ptr->ts.u.derived = derived;
ptr->attr.flavor = FL_VARIABLE;
@@ -2051,7 +2070,7 @@ generate_finalization_wrapper (gfc_symbol *derived
if (!ptr)
{
- gfc_get_symbol ("ptr", sub_ns, &ptr);
+ gfc_get_symbol ("ptr2", sub_ns, &ptr);
ptr->ts.type = BT_DERIVED;
ptr->ts.u.derived = derived;
ptr->attr.flavor = FL_VARIABLE;
@@ -2100,7 +2119,7 @@ generate_finalization_wrapper (gfc_symbol *derived
continue;
finalize_component (gfc_lval_expr_from_sym (ptr), derived, comp,
- stat, fini_coarray, &block);
+ stat, fini_coarray, &block, sub_ns);
if (!last_code->block->next)
last_code->block->next = block;
}
! { dg-do run }
! { dg-
[Patch ARM] PR target/64532
While looking at PR target/64532- I realized we haven't documented all
the register constraints. I'm not documenting the other immediate
constraints as it is not clear to me how much of that is actually useful
yet and I don't have the time this afternoon to clean this up.
Built documentation and looked at it.
Applied.
Ramana
Ramana Radhakrishnan
PR target/64532
* doc/md.texi (ARM Constraints): Document register constraints.
diff --git a/gcc/doc/md.texi b/gcc/doc/md.texi
index 7bc7842..0050ba7 100644
--- a/gcc/doc/md.texi
+++ b/gcc/doc/md.texi
@@ -1800,8 +1800,30 @@ Any const_double value.
@item ARM family---@file{config/arm/constraints.md}
@table @code
+
+@item h
+In Thumb state, the core registers @code{r8}-@code{r15}.
+
+@item k
+The stack pointer register.
+
+@item l
+In Thumb State the core registers @code{r0}-@code{r7}. In ARM state this
+is an alias for the @code{r} constraint.
+
+@item t
+VFP floating-point registers @code{s0}-@code{s31}. Used for 32 bit values.
+
@item w
-VFP floating-point register
+VFP floating-point registers @code{d0}-@code{d31} and the appropriate
+subset @code{d0}-@code{d15} based on command line options.
+Used for 64 bit values only. Not valid for Thumb1.
+
+@item y
+The iWMMX co-processor registers.
+
+@item z
+The iWMMX GR registers.
@item G
The floating-point constant 0.0
Re: [PATCH 01/10] rs6000: Clobber XER[CA] in all user asm statements
On Mon, Jan 19, 2015 at 01:53:06AM -0500, Hans-Peter Nilsson wrote: > On Mon, 8 Dec 2014, Segher Boessenkool wrote: > > > A lot of old user code clobbers the carry bit without telling the compiler > > about it. This used to just work, because the compiler never used the bit > > outside of a single RTL instruction. But that will change. Let's clobber > > the carry bit in every asm; this isn't very expensive. > > There's also the option of clobbering it only if it's not > explicitly mentioned in the asm, say with a singleton > regclass, see cris_md_asm_clobbers. It's a fixed register. The register class we have for it complains about inconsistent operand constraints whenever you try to use it (since at least 4.7, and it would never have worked: the compiler used to clobber the carry reg implicitly all over the place, so you could never use the register class safely). I'll remove the register class next stage1. Thanks for bringing it to attention. Cheers, Segher
Re: [patch] powerpc-vxworksmils port, variant of powerpc-vxworksae
On Monday 2015-01-19 11:56, Olivier Hainque wrote: > Something like the attached patch ? > > wwwdocs/htdocs/gcc-5/ > > * changes.html (Operating Systems section): Mention support > of VxWorks MILS. This looks sweet, thank you! Gerald
Re: [PATCH 7/8] Model cache auto-prefetcher in scheduler
On 16/01/15 15:06, Maxim Kuvyrkov wrote: > @@ -1874,7 +1889,8 @@ const struct tune_params arm_cortex_a15_tune = >true, true, /* Prefer 32-bit encodings. > */ >true, /* Prefer Neon for > stringops. */ >8, /* Maximum insns to inline > memset. */ > - ARM_FUSE_NOTHING /* Fuseable pairs of > instructions. */ > + ARM_FUSE_NOTHING, /* Fuseable pairs of > instructions. */ > + max_insn_queue_index + 1 /* Sched L2 autopref depth. */ > }; Hmm, two issues here: 1) This requires a static constructor for the tuning table entry (since the value of max_insn_queue_index has to be looked up at run time. 2) Doesn't this mean that the depth of searching will depend on properties of the automata rather than some machine specific values (so that potentially adding or removing unrelated scheduler rules could change the behaviour of the compiler)? In general, how should someone tuning the compiler for this parameter select a value that isn't one of (-1, m_i_q_d+1)? R.
Re: [PATCH] Fix sporadic failure in g++.dg/tsan/aligned_vs_unaligned_race.C
On Jan 19, 2015, at 12:47 AM, Dmitry Vyukov wrote: > Long story short. Tsan has a logical data race the core of data race > detection algorithm. The race is not a bug, but a deliberate design > decision that makes tsan considerably faster. Could you please quantify that for us? Also, what lockless update method did you use? Did you try atomic increment? On my machine, they are as cheap as stores; can’t imagine they could be slow at all. If the latency and bandwidth of atomic increment is identical to store, would the costs be any higher than using a store to update the tsan data? A proper port of tsan to my machine would make use of atomic increment. I consider it a simple matter to sequence the thread termination and the output routine to ensure that all the updates in the threads happen before the output routine runs. The output routine strikes me as slow, and thread termination strikes me as slow, so taking a little extra time there seems reasonable. Was the excessive cost you saw due to the termination costs? > So ironically, if the race memory accesses happen almost simultaneously, tsan > can miss the > race. > Thus we have sleeps. I’ve not seen a reason why the test suite should randomly fail. The gcc test suite does not. Could you explain why the llvm test suite does? Surely you know that sleep is not a synchronization primitive? > Sleeps vs barrier is being discussed in the "Fix parameters of > __tsan_vptr_update" thread. When finished, let us know the outcome. To date, I’ve not seen any compelling reason to have the core of tsan be other than deterministic and the test suite other than deterministic. I’d love to see the backing for such a decision. > I would really like to keep llvm and gcc tests in sync as much as possible. Excellent, from my perspective, that would mean that you make the llvm test suite deterministic.
Re: [[ARM/AArch64][testsuite] 23/36] Add vmul_lane tests.
On 13 January 2015 at 15:18, Christophe Lyon wrote: > * gcc.target/aarch64/advsimd-intrinsics/vmul_lane.c: New file. > OK /Marcus
Re: [[ARM/AArch64][testsuite] 24/36] Add vmul_n tests.
On 13 January 2015 at 15:18, Christophe Lyon wrote: > * gcc.target/aarch64/advsimd-intrinsics/vmul_n.c: New file. OK /Marcus
Re: [[ARM/AArch64][testsuite] 25/36] Add vmull tests.
On 13 January 2015 at 15:18, Christophe Lyon wrote: > * gcc.target/aarch64/advsimd-intrinsics/vmull.c: New file. OK /Marcus
Re: [[ARM/AArch64][testsuite] 26/36] Add vmull_lane tests.
On 13 January 2015 at 15:18, Christophe Lyon wrote: > * gcc.target/aarch64/advsimd-intrinsics/vmull_lane.c: New file. OK /Marcus
Re: [[ARM/AArch64][testsuite] 27/36] Add vmull_n tests.
On 13 January 2015 at 15:18, Christophe Lyon wrote: > * gcc.target/aarch64/advsimd-intrinsics/vmull_n.c: New file. OK /Marcus
Re: [PATCH] Fix PR64535 - increase emergency EH buffers via a new allocator
On 19/01/15 11:33 +0100, Richard Biener wrote:
On Mon, 12 Jan 2015, Richard Biener wrote:
This "fixes" PR64535 by changing the fixed object size emergency pool
to a variable EH object size (but fixed arena size) allocator. Via
combining the dependent and non-dependent EH arenas this should allow
around 600 bad_alloc throws in OOM situations on x86_64-linux
compared to the current 64 which should provide some headroom to
the poor souls using EH to communicate OOM in a heavily threaded
enviroment.
Bootstrapped and tested on x86_64-unknown-linux-gnu (with the #if 1
as in the patch below, forcing the use of the allocator).
I see only the #else part is kept now - that was what I was going to
suggest.
Unfortunately I couldn't get an answer of whether throwing
bad_alloc from a throw where we can't allocate an exception
is a) valid or b) even required by the standard ('throw' isn't
listed as 'allocation function' - also our EH allocators are
marked as throw(), so such change would change the ABI...).
I'll ask the C++ committee.
With the cost of some more members I can make the allocator more
generic (use a constructor with a arena and a arena size parameter)
and we may move it somewhere public under __gnu_cxx? But eventually
boost has something like this anyway.
Didn't explore this - it doesn't really match the STL allocator interface
and imposes overhead even over an implementation class (STL allocators
know the size of the objects they free).
Yeah, I don't think there's any advantage complicating this type to
make it usable as an STL allocator - it does what it's designed to do
and that's fine.
I'm re-bootstrapping / testing with the cosmetic changes I did and
with EH allocation not forced to go through the emergency pool
(I've done that in previous bootstraps / tests to get the pool code
exercised).
Any comments? We have a customer that runs into the issue that 64
bad_alloc exceptions are not enough for them (yes, they require bad_alloc
to work when thrown in a massive quantity from threads). Other
solutions for this would include to simply wait and re-try (with possibly
deadlocking if no progress is made) to artificially throttling
bad_alloc allocations from the EH emergency pool (identify it by
size, sleep some time inside the lock).
CCing rth who implemented the existing code.
I don't have any better ideas for fixing the issue, so it's approved
by me. Unless rth comes back with something else please go ahead and
check it in.
Re: [PATCH] Workaround -Wmaybe-uninitialized false positives during profiledbootstrap
On Mon, Jan 19, 2015 at 03:44:20PM +0100, Martin Liška wrote: > There's a bunch of another places that emit false positives. With following > patch, > I am able to run profiledbootstrap on x86_64-linux-pc and ppc64-linux-pc. I don't know what we consider standard and where we allow warnings and thus require --disable-werror, so will defer to Richard. > --- a/gcc/tree.h > +++ b/gcc/tree.h > @@ -3050,6 +3050,11 @@ tree_int_cst_elt_check (tree __t, int __i, >return &CONST_CAST_TREE (__t)->int_cst.val[__i]; > } > > +/* Workaround -Wstrict-overflow false positive during profiledbootstrap. */ > + > +#pragma GCC diagnostic push > +#pragma GCC diagnostic ignored "-Wstrict-overflow" Just I wonder if this shouldn't be guarded by GCC_VERSION >= something that actually supports those. > + > inline tree * > tree_vec_elt_check (tree __t, int __i, > const char *__f, int __l, const char *__g) > @@ -3061,6 +3066,8 @@ tree_vec_elt_check (tree __t, int __i, >return &CONST_CAST_TREE (__t)->vec.a[__i]; > } > > +#pragma GCC diagnostic pop > + > inline tree * > omp_clause_elt_check (tree __t, int __i, >const char *__f, int __l, const char *__g) Jakub
[patch] libstdc++/64650 add bad_optional_access default constructor
The Library Fundamentals TS says
std::experimental::bad_optional_access should have a default
constructor, but we only support construction from strings.
This removes the unused and non-standard std::string constructor and
adds the required default constructor.
Tested x86_64-linux, *not* committed.
commit a3012f752e52870c9d257187a3c43e9fc2873892
Author: Jonathan Wakely
Date: Sun Jan 18 16:52:07 2015 +
PR libstdc++/64650
* include/experimental/optional (bad_optional_access): Add default
constructor.
* testsuite/experimental/optional/requirements.cc: Test for default
constructor.
diff --git a/libstdc++-v3/include/experimental/optional b/libstdc++-v3/include/experimental/optional
index 206b945..811235b 100644
--- a/libstdc++-v3/include/experimental/optional
+++ b/libstdc++-v3/include/experimental/optional
@@ -110,9 +110,9 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
class bad_optional_access : public logic_error
{
public:
-// XXX Should not be inline
-explicit bad_optional_access(const string& __arg) : logic_error(__arg) { }
+bad_optional_access() : logic_error("bad optional access") { }
+// XXX This constructor is non-standard. Should not be inline
explicit bad_optional_access(const char* __arg) : logic_error(__arg) { }
virtual ~bad_optional_access() noexcept = default;
diff --git a/libstdc++-v3/testsuite/experimental/optional/requirements.cc b/libstdc++-v3/testsuite/experimental/optional/requirements.cc
index e83975a..531b6ca 100644
--- a/libstdc++-v3/testsuite/experimental/optional/requirements.cc
+++ b/libstdc++-v3/testsuite/experimental/optional/requirements.cc
@@ -23,6 +23,9 @@
#include
+using std::experimental::bad_optional_access;
+static_assert( std::is_default_constructible::value, "" );
+
struct trivially_destructible
{
trivially_destructible() = delete;
Re: [PING] [PATCH] Fix parameters of __tsan_vptr_update
On Jan 19, 2015, at 12:43 AM, Dmitry Vyukov wrote: > I can't really make my mind on this. I would mildly prefer sleep's (if > they work reliably!). Let me state it more forcefully. sleeps are not now, nor in the history of computing ever been a synchronization primitive, except for hard real time systems. If they were, you would be able to cite a paper that uses them. If I am wrong, I’d welcome a cite. Any failure of sleep to work is a indication that that system is not a real time system, and the entirety of the gcc test suite is non-real time code (unless someone snuck some in while I wasn’t watching). Only a synchronization primitive can make the test cases deterministic, therefore, sleep can never be used as a syntonization primitive in the gcc test suite. > Kostya, you had experience with both approaches. What are you thoughts on > this? > StealthNotification definitely makes tests faster and more reliable. To me, reliability isn’t a continuum for the gcc test suite. It is binary. It is, or, is not reliable and deterministic. The standard for the gcc test suite is to be realible and deterministic. > can't really come up with any objective downsides. Nor I.
Re: [PATCH][AArch64] Use target builtin instead of __builtin_sqrt for vsqrt_f64
On Mon, Jan 12, 2015 at 05:30:46PM +, Andrew Pinski wrote: > On Mon, Jan 12, 2015 at 7:52 AM, Kyrill Tkachov > wrote: > > Hi all, > > > > As raised in https://gcc.gnu.org/ml/gcc-patches/2014-12/msg01237.html and > > discussed in that thread, using __builtin_sqrt for vsqrt_f64 may end up in a > > call to the library sqrt at -O0. To avoid that this patch uses a target > > builtin for sqrt on DF mode and uses that to implement the intrinsic. > > > > With this patch I don't see sqrt calls being created at -O0 on a large > > arm_neon.h testcase where they were generated before. > > aarch64-none-elf testing and the intrinsics testsuite in particular are > > clean. > > Ok for trunk? > > Maybe have a target fold which folds this into sqrt if -fno-math-errno > is supplied. This might be useful the -ffast-math case. > Maybe also fold it when a constant is supplied too. Given that we are now in Stage 4, I'd rather see this fixed for GCC 5.0 in the way Kyrill proposed than languishing on a TODO list. Though an IOU ticket on bugzilla for the missed optimization seems a good idea to me. Unless Kyrill already has something in the works to address your comment, this looks like the right short-term solution to me (Though Marcus/Richard will have to approve it). Thanks, James > > 2015-01-12 Kyrylo Tkachov > > > > * config/aarch64/aarch64-simd-builtins.def (sqrt): Use BUILTIN_VDQF_DF. > > * config/aarch64/arm_neon.h (vsqrt_f64): Use __builtin_aarch64_sqrtdf > > instead of __builtin_sqrt. >
Re: [[ARM/AArch64][testsuite] 03/36] Add vmax, vmin, vhadd, vhsub and vrhadd tests.
On 19 January 2015 at 14:29, Marcus Shawcroft wrote: > On 16 January 2015 at 17:52, Christophe Lyon > wrote: > >>> OK provided, as per the previous couple, that we don;t regression or >>> introduce new fails on aarch64[_be] or aarch32. >> >> This patch shows failures on aarch64 and aarch64_be for vmax and vmin >> when the input is -NaN. >> It's a corner case, and my reading of the ARM ARM is that the result >> should the same as on aarch32. >> I haven't had time to look at it in more details though. >> So, not OK? > > They should have the same behaviour in aarch32 and aarch64. Did you > test on HW or a model? > I ran the tests on qemu for aarch32 and aarch64-linux, and on the foundation model for aarch64*-elf. > /Marcus
Re: [PATCH][AArch64] Use target builtin instead of __builtin_sqrt for vsqrt_f64
On 19/01/15 15:44, James Greenhalgh wrote: On Mon, Jan 12, 2015 at 05:30:46PM +, Andrew Pinski wrote: On Mon, Jan 12, 2015 at 7:52 AM, Kyrill Tkachov wrote: Hi all, As raised in https://gcc.gnu.org/ml/gcc-patches/2014-12/msg01237.html and discussed in that thread, using __builtin_sqrt for vsqrt_f64 may end up in a call to the library sqrt at -O0. To avoid that this patch uses a target builtin for sqrt on DF mode and uses that to implement the intrinsic. With this patch I don't see sqrt calls being created at -O0 on a large arm_neon.h testcase where they were generated before. aarch64-none-elf testing and the intrinsics testsuite in particular are clean. Ok for trunk? Maybe have a target fold which folds this into sqrt if -fno-math-errno is supplied. This might be useful the -ffast-math case. Maybe also fold it when a constant is supplied too. Given that we are now in Stage 4, I'd rather see this fixed for GCC 5.0 in the way Kyrill proposed than languishing on a TODO list. Though an IOU ticket on bugzilla for the missed optimization seems a good idea to me. Unless Kyrill already has something in the works to address your comment, this looks like the right short-term solution to me (Though Marcus/Richard will have to approve it). Sorry, this slipped through the cracks. I agree with James. A missed-optimization issue on bugzilla would be helpful to keep track of this. Kyrill Thanks, James 2015-01-12 Kyrylo Tkachov * config/aarch64/aarch64-simd-builtins.def (sqrt): Use BUILTIN_VDQF_DF. * config/aarch64/arm_neon.h (vsqrt_f64): Use __builtin_aarch64_sqrtdf instead of __builtin_sqrt.
Re: [PATCH] Fix scheduling undeterminism from sorting with DEBUG_INSNs
On Jan 19, 2015, at 5:41 AM, Maxim Kuvyrkov wrote: > In A < B < C < A case all A, B and C are normal instructions. It is a > pre-existing condition. When compiling without debug information we have > ready list "A, B, C". When compiling with debug information, we have ready > list "A, B, C, D" where "D" is DEBUG_INSN. Because we now have 4 elements to > sort instead of 3, qsort can choose a different order of comparison _among_ > A, B and C. Not when the uid is mixed in it cannot. :-)
Re: [PATCH] toplev.c: Process the failure when read fails for random_seed
On 12/31/2014 06:26 AM, Joseph Myers wrote: > On Mon, 29 Dec 2014, Chen Gang S wrote: > >> And in honest, this year what I have done is really not quite well, next >> year I should be improved: should scanning Bugzilla and try to fix the >> existing issues (just like another members' suggestions to me). > > Note that for any substantial patches you'll need to complete the > copyright assignment paperwork (I don't see you listed in copyright.list > at present). > Excuse me, I am not quite familiar with the related working flow, at present, I finished assignment paperwork for binutils and gdb, and I am one of write after approval member for binutils and gdb. Do you mean I need follow the same working flow for gcc, just as for the binutils and gdb? (or only post my assignment is OK?). If possible, please provide more related details for it. I shall follow. Thanks. -- Open, share, and attitude like air, water, and life which God blessed.
[PATCH] Fix PR64664
Hello.
Following patch correctly handles filtered removed items, where we forgot
to check that a cgraph node is deleted or not. Apart from that, logic
in the function was rewritten and is much more understandable what's going on.
Tested on x86_64-linux-pc.
Ready for installation?
Thanks,
Martin
>From 3f1d52424d01e7a76b127bf91bdaa04077371d30 Mon Sep 17 00:00:00 2001
From: mliska
Date: Mon, 19 Jan 2015 14:28:50 +0100
Subject: [PATCH] Fix PR64664.
gcc/ChangeLog:
2015-01-19 Martin Liska
* ipa-icf.c (sem_item_optimizer::filter_removed_items):
Handle safe potentially removed nodes during filtering.
---
gcc/ipa-icf.c | 47 +++
1 file changed, 19 insertions(+), 28 deletions(-)
diff --git a/gcc/ipa-icf.c b/gcc/ipa-icf.c
index 0ac01a9..449d552 100644
--- a/gcc/ipa-icf.c
+++ b/gcc/ipa-icf.c
@@ -1652,40 +1652,31 @@ sem_item_optimizer::filter_removed_items (void)
{
sem_item *item = m_items[i];
- if (item->type == FUNC
- && !opt_for_fn (item->decl, flag_ipa_icf_functions))
- {
- remove_item (item);
- continue;
- }
-
- if (!flag_ipa_icf_variables && item->type == VAR)
- {
+ if (m_removed_items_set.contains (item->node))
+{
remove_item (item);
continue;
- }
-
- bool no_body_function = false;
+}
if (item->type == FUNC)
- {
+{
cgraph_node *cnode = static_cast (item)->get_node ();
- no_body_function = in_lto_p && (cnode->alias || cnode->body_removed);
- }
-
- if(!m_removed_items_set.contains (m_items[i]->node)
- && !no_body_function)
- {
- if (item->type == VAR || (!DECL_CXX_CONSTRUCTOR_P (item->decl)
-&& !DECL_CXX_DESTRUCTOR_P (item->decl)))
- {
- filtered.safe_push (m_items[i]);
- continue;
- }
- }
-
- remove_item (item);
+ bool no_body_function = in_lto_p && (cnode->alias || cnode->body_removed);
+ if (no_body_function || !opt_for_fn (item->decl, flag_ipa_icf_functions)
+ || DECL_CXX_CONSTRUCTOR_P (item->decl)
+ || DECL_CXX_DESTRUCTOR_P (item->decl))
+ remove_item (item);
+ else
+ filtered.safe_push (item);
+}
+ else /* VAR. */
+{
+ if (!flag_ipa_icf_variables)
+ remove_item (item);
+ else
+ filtered.safe_push (item);
+}
}
/* Clean-up of released semantic items. */
--
2.1.2
Re: [patch] powerpc-vxworksmils port, variant of powerpc-vxworksae
> On Jan 19, 2015, at 16:06 , Gerald Pfeifer wrote: > This looks sweet, thank you! My pleasure, just checked-in. Thanks for your note and feedback :-)
[patch] libstdc++/64658 define std::atomic_init()
We declare atomic_init() but then never define it, I assume that's
just an accident.
Although the standard says this function is non-atomic, the simplest
fix at this stage is just to do an atomic store (when we get to stage
1 again I'd like to make the function a friend of std::__atomic_base<>
so it can set the private member variable directly as a simple
non-atomic assignment).
Tested x86_64-linux, *not* committed to trunk.
commit 061dd1a073ef4646727a3f29dfa3169a760757b3
Author: Jonathan Wakely
Date: Sun Jan 18 17:40:17 2015 +
PR libstdc++/64658
* include/std/atomic (atomic_init): Define.
* testsuite/29_atomics/atomic/64658.cc: New.
diff --git a/libstdc++-v3/include/std/atomic b/libstdc++-v3/include/std/atomic
index 43cf4f3..1a17427 100644
--- a/libstdc++-v3/include/std/atomic
+++ b/libstdc++-v3/include/std/atomic
@@ -921,11 +921,13 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
template
inline void
-atomic_init(atomic<_ITp>* __a, _ITp __i) noexcept;
+atomic_init(atomic<_ITp>* __a, _ITp __i) noexcept
+{ __a->store(__i, memory_order_relaxed); }
template
inline void
-atomic_init(volatile atomic<_ITp>* __a, _ITp __i) noexcept;
+atomic_init(volatile atomic<_ITp>* __a, _ITp __i) noexcept
+{ __a->store(__i, memory_order_relaxed); }
template
inline void
diff --git a/libstdc++-v3/testsuite/29_atomics/atomic/64658.cc b/libstdc++-v3/testsuite/29_atomics/atomic/64658.cc
new file mode 100644
index 000..64739e0
--- /dev/null
+++ b/libstdc++-v3/testsuite/29_atomics/atomic/64658.cc
@@ -0,0 +1,29 @@
+// Copyright (C) 2015 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library. This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+// GNU General Public License for more details.
+
+// You should have received a copy of the GNU General Public License along
+// with this library; see the file COPYING3. If not see
+//
[C++ PATCH, RFC] PR c++/63959, continued
When I patched the triviality test for volatile types, I missed two cases:
1) volatile members in a class should make the class non-trivial.
2) a volatile class type should itself be non-trivial.
(based on [basic.types]/9, [class]/6, [class.copy]/12 and [class.copy]/25)
I haven't completed testing this yet, I still need to run the full testsuite
to make sure there are no regressions. I'm not sure whether this
can go into gcc5, since we're at stage 4.
/cp
2015-01-19 Ville Voutilainen
PR c++/63959
* class.c (check_field_decls): If any field is volatile, make
the class type have complex copy/move operations.
* tree.c (trivially_copyable_p): Check CP_TYPE_VOLATILE_P for
class types too.
/testsuite
2015-01-19 Ville Voutilainen
PR c++/63959
* g++.dg/ext/is_trivially_constructible1.C: Adjust.
diff --git a/gcc/cp/class.c b/gcc/cp/class.c
index edb87fe..529a2bf 100644
--- a/gcc/cp/class.c
+++ b/gcc/cp/class.c
@@ -3717,6 +3717,16 @@ check_field_decls (tree t, tree *access_decls,
if (DECL_INITIAL (x) && cxx_dialect < cxx14)
CLASSTYPE_NON_AGGREGATE (t) = true;
+ /* If any field is volatile, the structure type has complex copy
+and move operations. */
+ if (CP_TYPE_VOLATILE_P (type))
+ {
+ TYPE_HAS_COMPLEX_COPY_ASSIGN (t) = 1;
+ TYPE_HAS_COMPLEX_MOVE_ASSIGN (t) = 1;
+ TYPE_HAS_COMPLEX_COPY_CTOR (t) = 1;
+ TYPE_HAS_COMPLEX_MOVE_CTOR (t) = 1;
+ }
+
/* If any field is const, the structure type is pseudo-const. */
if (CP_TYPE_CONST_P (type))
{
diff --git a/gcc/cp/tree.c b/gcc/cp/tree.c
index 80f2ce6..169b796 100644
--- a/gcc/cp/tree.c
+++ b/gcc/cp/tree.c
@@ -3211,7 +3211,8 @@ trivially_copyable_p (const_tree t)
&& (!TYPE_HAS_COPY_ASSIGN (t)
|| !TYPE_HAS_COMPLEX_COPY_ASSIGN (t))
&& !TYPE_HAS_COMPLEX_MOVE_ASSIGN (t)
- && TYPE_HAS_TRIVIAL_DESTRUCTOR (t));
+ && TYPE_HAS_TRIVIAL_DESTRUCTOR (t)
+ && !CP_TYPE_VOLATILE_P (t));
else
return !CP_TYPE_VOLATILE_P (t) && scalarish_type_p (t);
}
diff --git a/gcc/testsuite/g++.dg/ext/is_trivially_constructible1.C
b/gcc/testsuite/g++.dg/ext/is_trivially_constructible1.C
index a5bac7b..35ef1f1 100644
--- a/gcc/testsuite/g++.dg/ext/is_trivially_constructible1.C
+++ b/gcc/testsuite/g++.dg/ext/is_trivially_constructible1.C
@@ -39,5 +39,16 @@ SA(!__is_trivially_copyable(volatile int));
struct E1 {const int val;};
SA(__is_trivially_copyable(E1));
+SA(!__is_trivially_copyable(volatile E1));
struct E2 {int& val;};
SA(__is_trivially_copyable(E2));
+struct E3 {volatile int val;};
+SA(!__is_trivially_copyable(E3));
+struct E4 {A a;};
+SA(!__is_trivially_copyable(volatile E4));
+struct E5 {volatile A a;};
+SA(!__is_trivially_copyable(E5));
+SA(!__is_trivially_copyable(volatile E5));
+struct E6 : A {};
+SA(__is_trivially_copyable(E6));
+SA(!__is_trivially_copyable(volatile E6));
Re: [[ARM/AArch64][testsuite] 31/36] Add vqdmulh tests.
On 13 January 2015 at 15:18, Christophe Lyon wrote: > * gcc.target/aarch64/advsimd-intrinsics/vqdmulh.c: New file. OK /Marcus
Re: [[ARM/AArch64][testsuite] 32/36] Add vqdmulh_lane tests.
On 13 January 2015 at 15:18, Christophe Lyon wrote: > * gcc.target/aarch64/advsimd-intrinsics/vqdmulh_lane.c: New file. OK /Marcus
Re: [[ARM/AArch64][testsuite] 33/36] Add vqdmulh_n tests.
On 13 January 2015 at 15:18, Christophe Lyon wrote: > * gcc.target/aarch64/advsimd-intrinsics/vqdmulh_n.c: New file. OK /Marcus
Re: [[ARM/AArch64][testsuite] 34/36] Add vqdmull tests.
On 13 January 2015 at 15:18, Christophe Lyon wrote: > * gcc.target/aarch64/advsimd-intrinsics/vqdmull.c: New file. OK /Marcus
Re: [[ARM/AArch64][testsuite] 35/36] Add vqdmull_lane tests.
On 13 January 2015 at 15:18, Christophe Lyon wrote: > * gcc.target/aarch64/advsimd-intrinsics/vqdmull_lane.c: New file. OK /Marcus
Re: [[ARM/AArch64][testsuite] 36/36] Add vqdmull_n tests.
On 13 January 2015 at 15:18, Christophe Lyon wrote: > * gcc.target/aarch64/advsimd-intrinsics/vqdmull_n.c: New file. OK /Marcus
Re: [[ARM/AArch64][testsuite] 00/36] More Neon intrinsics tests.
On 13 January 2015 at 15:17, Christophe Lyon wrote: > This patch series is a follow-up of the conversion of my existing > testsuite into DejaGnu. It does not yet cover all the tests I wrote, > but I chose to post this set to have a chance to have it accepted > before stage 4. I will have 35 more files to convert after this set. Christophe, can you respin 9,13,17,21,28,29,30 to address Tejas' comments? Thanks /Marcus
Re: [[ARM/AArch64][testsuite] 03/36] Add vmax, vmin, vhadd, vhsub and vrhadd tests.
On 19 January 2015 at 15:43, Christophe Lyon wrote: > On 19 January 2015 at 14:29, Marcus Shawcroft > wrote: >> On 16 January 2015 at 17:52, Christophe Lyon >> wrote: >> OK provided, as per the previous couple, that we don;t regression or introduce new fails on aarch64[_be] or aarch32. >>> >>> This patch shows failures on aarch64 and aarch64_be for vmax and vmin >>> when the input is -NaN. >>> It's a corner case, and my reading of the ARM ARM is that the result >>> should the same as on aarch32. >>> I haven't had time to look at it in more details though. >>> So, not OK? >> >> They should have the same behaviour in aarch32 and aarch64. Did you >> test on HW or a model? >> > I ran the tests on qemu for aarch32 and aarch64-linux, and on the > foundation model for aarch64*-elf. Leave this one out until we understand why it fails. /Marcus
[patch] [C++14] Implement N3657: heterogeneous lookup in associative containers.
This is the last missing piece of the C++14 library, as proposed in
http://www.open-std.org/JTC1/sc22/wg21/docs/papers/2013/n3657.htm
Tested x86_64-linux, *not* committed.
commit 99d7d1ebce9f290220966e138ef9b9e741878917
Author: Jonathan Wakely
Date: Mon Jan 19 17:05:34 2015 +
Implement N3657: heterogeneous lookup in associative containers.
* include/bits/stl_map.h (map::find<>, map::count<>,
map::lower_bound<>, map::upper_bound<>, map::equal_range<>): New
member function templates to perform heterogeneous lookup.
* include/bits/stl_multimap.h (multimap::find<>, multimap::count<>,
multimap::lower_bound<>, multimap::upper_bound<>,
multimap::equal_range<>): Likewise.
* include/bits/stl_multiset.h (multiset::find<>, multiset::count<>,
multiset::lower_bound<>, multiset::upper_bound<>,
multiset::equal_range<>): Likewise.
* include/bits/stl_set.h (set::find<>, set::count<>,
set::lower_bound<>, set::upper_bound<>, set::equal_range<>): Likewise.
* include/bits/stl_tree.h (_Rb_tree::_S_lower_bound_tr,
_Rb_tree::_S_upper_bound_tr, _Rb_tree::_M_find_tr,
_Rb_tree::_M_count_tr, _Rb_tree::_M_lower_bound_tr,
_Rb_tree::_M_upper_bound_tr, _Rb_tree::_M_equal_range_tr): Likewise.
* testsuite/23_containers/map/operations/2.cc: New.
* testsuite/23_containers/multimap/operations/2.cc: New.
* testsuite/23_containers/multiset/operations/2.cc: New.
* testsuite/23_containers/set/operations/2.cc: New.
diff --git a/libstdc++-v3/include/bits/stl_map.h b/libstdc++-v3/include/bits/stl_map.h
index 3bac4e0..df18973 100644
--- a/libstdc++-v3/include/bits/stl_map.h
+++ b/libstdc++-v3/include/bits/stl_map.h
@@ -824,6 +824,8 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
{ return value_compare(_M_t.key_comp()); }
// [23.3.1.3] map operations
+
+ //@{
/**
* @brief Tries to locate an element in a %map.
* @param __x Key of (key, value) %pair to be located.
@@ -835,10 +837,20 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
* pointing to the sought after %pair. If unsuccessful it returns the
* past-the-end ( @c end() ) iterator.
*/
+
iterator
find(const key_type& __x)
{ return _M_t.find(__x); }
+#if __cplusplus > 201103L
+ template
+ auto
+ find(const _Kt& __x) -> decltype(_M_t._M_find_tr(__x))
+ { return _M_t._M_find_tr(__x); }
+#endif
+ //@}
+
+ //@{
/**
* @brief Tries to locate an element in a %map.
* @param __x Key of (key, value) %pair to be located.
@@ -850,10 +862,20 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
* iterator pointing to the sought after %pair. If unsuccessful it
* returns the past-the-end ( @c end() ) iterator.
*/
+
const_iterator
find(const key_type& __x) const
{ return _M_t.find(__x); }
+#if __cplusplus > 201103L
+ template
+ auto
+ find(const _Kt& __x) const -> decltype(_M_t._M_find_tr(__x))
+ { return _M_t._M_find_tr(__x); }
+#endif
+ //@}
+
+ //@{
/**
* @brief Finds the number of elements with given key.
* @param __x Key of (key, value) pairs to be located.
@@ -866,6 +888,15 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
count(const key_type& __x) const
{ return _M_t.find(__x) == _M_t.end() ? 0 : 1; }
+#if __cplusplus > 201103L
+ template
+ auto
+ count(const _Kt& __x) const -> decltype(_M_t._M_count_tr(__x))
+ { return _M_t._M_find_tr(__x) == _M_t.end() ? 0 : 1; }
+#endif
+ //@}
+
+ //@{
/**
* @brief Finds the beginning of a subsequence matching given key.
* @param __x Key of (key, value) pair to be located.
@@ -881,6 +912,16 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
lower_bound(const key_type& __x)
{ return _M_t.lower_bound(__x); }
+#if __cplusplus > 201103L
+ template
+ auto
+ lower_bound(const _Kt& __x)
+ -> decltype(_M_t._M_lower_bound_tr(__x))
+ { return _M_t._M_lower_bound_tr(__x); }
+#endif
+ //@}
+
+ //@{
/**
* @brief Finds the beginning of a subsequence matching given key.
* @param __x Key of (key, value) pair to be located.
@@ -896,6 +937,16 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
lower_bound(const key_type& __x) const
{ return _M_t.lower_bound(__x); }
+#if __cplusplus > 201103L
+ template
+ auto
+ lower_bound(const _Kt& __x) const
+ -> decltype(_M_t._M_lower_bound_tr(__x))
+ { return _M_t._M_lower_bound_tr(__x); }
+#endif
+ //@}
+
+ //@{
/**
* @brief Finds the end of a subsequence matching given key.
* @param __x Key of (key, value) pair to be located.
@@ -906,6 +957,16 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
upper_bound(const key_type& __x)
{ return _M_t.upper_bound(__x); }
+#if __cplusplus > 201103L
+ template
+ auto
+ upper_bound(const _Kt& __x)
+ -> decltype(_M_t._M_upper_bound_tr(__x))
+ { return _M_t._M_upper_bound
[PATCH, committed] jit: fix crash in memento_of_new_string_literal::make_debug_string
Fix a crash due to missing a format string in a printf-style call,
when printing a string literal that contains formatting characters.
Seen on aarch64, where the patch takes jit.sum to:
# of expected passes7514
and no failures.
Committed to trunk as r219851.
gcc/jit/ChangeLog:
* jit-recording.c
(gcc::jit::recording::memento_of_new_string_literal::make_debug_string):
Add missing format string.
---
gcc/jit/jit-recording.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/gcc/jit/jit-recording.c b/gcc/jit/jit-recording.c
index 76eabbd..2900e18 100644
--- a/gcc/jit/jit-recording.c
+++ b/gcc/jit/jit-recording.c
@@ -4012,6 +4012,7 @@ recording::string *
recording::memento_of_new_string_literal::make_debug_string ()
{
return string::from_printf (m_ctxt,
+ "%s",
m_value->get_debug_string ());
}
--
1.8.5.3
Re: GCC 5 Status Report (2015-01-19), Trunk in Stage 4
On 19 January 2015 at 09:17, Richard Biener wrote: > > Status > == > > The trunk is now in "Stage 4" which means it is open for regression > and documentation fixes only, like if it were a release branch. > > Please concentrate on getting P1 bugs fixed and provide help in > confirming and analyzing UNCONFIRMED bugs. For non-primary, > non-secondary targets important bugs are not flagged with high > priority - instead target maintainers have to ensure themselves > that the GCC 5 release will be in proper shape for them (same > applies to non-C/C++ frontends and runtime). > > Please also make sure to mark bugs as regressions if appropriate, > always filling out the known-to-work and known-to-fail fields. > > > Quality Data > > > Priority # Change from last report > --- --- > P1 32- 7 > P2 97- 1 > P3 32- 16 > --- --- > Total 161- 24 > > > Previous Report > === > > https://gcc.gnu.org/ml/gcc/2015-01/msg00032.html I would like to commit these two patches which complete the C++11 library implementation: https://gcc.gnu.org/ml/gcc-patches/2015-01/msg01694.html https://gcc.gnu.org/ml/gcc-patches/2015-01/msg01648.html And this one to complete C++14 library implementation: https://gcc.gnu.org/ml/gcc-patches/2015-01/msg01704.html This one is tiny, and only affects the header, which is, as the name suggests, experimental: https://gcc.gnu.org/ml/gcc-patches/2015-01/msg01684.html OK? (After that I will stop changing things and fix the regressions!)
Re: [PATCH] Fix PR64664
> Hello.
>
> Following patch correctly handles filtered removed items, where we forgot
> to check that a cgraph node is deleted or not. Apart from that, logic
> in the function was rewritten and is much more understandable what's going on.
>
> Tested on x86_64-linux-pc.
> Ready for installation?
>
> Thanks,
> Martin
> >From 3f1d52424d01e7a76b127bf91bdaa04077371d30 Mon Sep 17 00:00:00 2001
> From: mliska
> Date: Mon, 19 Jan 2015 14:28:50 +0100
> Subject: [PATCH] Fix PR64664.
>
> gcc/ChangeLog:
>
> 2015-01-19 Martin Liska
>
> * ipa-icf.c (sem_item_optimizer::filter_removed_items):
> Handle safe potentially removed nodes during filtering.
OK,
thanks
Honza
> ---
> gcc/ipa-icf.c | 47 +++
> 1 file changed, 19 insertions(+), 28 deletions(-)
>
> diff --git a/gcc/ipa-icf.c b/gcc/ipa-icf.c
> index 0ac01a9..449d552 100644
> --- a/gcc/ipa-icf.c
> +++ b/gcc/ipa-icf.c
> @@ -1652,40 +1652,31 @@ sem_item_optimizer::filter_removed_items (void)
> {
>sem_item *item = m_items[i];
>
> - if (item->type == FUNC
> - && !opt_for_fn (item->decl, flag_ipa_icf_functions))
> - {
> - remove_item (item);
> - continue;
> - }
> -
> - if (!flag_ipa_icf_variables && item->type == VAR)
> - {
> + if (m_removed_items_set.contains (item->node))
> +{
> remove_item (item);
> continue;
> - }
> -
> - bool no_body_function = false;
> +}
>
>if (item->type == FUNC)
> - {
> +{
> cgraph_node *cnode = static_cast (item)->get_node ();
>
> - no_body_function = in_lto_p && (cnode->alias || cnode->body_removed);
> - }
> -
> - if(!m_removed_items_set.contains (m_items[i]->node)
> - && !no_body_function)
> - {
> - if (item->type == VAR || (!DECL_CXX_CONSTRUCTOR_P (item->decl)
> - && !DECL_CXX_DESTRUCTOR_P (item->decl)))
> - {
> - filtered.safe_push (m_items[i]);
> - continue;
> - }
> - }
> -
> - remove_item (item);
> + bool no_body_function = in_lto_p && (cnode->alias ||
> cnode->body_removed);
> + if (no_body_function || !opt_for_fn (item->decl,
> flag_ipa_icf_functions)
> + || DECL_CXX_CONSTRUCTOR_P (item->decl)
> + || DECL_CXX_DESTRUCTOR_P (item->decl))
> + remove_item (item);
> + else
> + filtered.safe_push (item);
> +}
> + else /* VAR. */
> +{
> + if (!flag_ipa_icf_variables)
> + remove_item (item);
> + else
> + filtered.safe_push (item);
> +}
> }
>
>/* Clean-up of released semantic items. */
> --
> 2.1.2
>
[ARM] Wire up the new scheduler description for the ARM Cortex-A57 processor
On Fri, Jan 16, 2015 at 11:14:42AM +, Ramana Radhakrishnan wrote:
>
>
> On 16/01/15 10:20, Marcus Shawcroft wrote:
> > On 15 January 2015 at 09:50, James Greenhalgh
> > wrote:
> >
> >> 2015-01-15 James Greenhalgh
> >>
> >> * config/arm/cortex-a57.md: New.
> >> * config/aarch64/aarch64.md: Include it.
> >> * config/aarch64/aarch64-cores.def (cortex-a57): Tune for it.
> >> * config/aarch64/aarch64-tune.md: Regenerate.
> >
> > This is low risk and only affects aarch64 backend. I think we should
> > take this for gcc 5, so OK.
> >
> > Ramana do you want this wired up for aarch32 in a followup?
>
> Yes please. I think as long as it works, let's just take it for 5.0. I'd
> rather not have divergence between the backends as this just creates
> problems for us elsewhere.
Hi,
OK, that patch looks like this. I know I've missed the stage 3 deadline,
but I agree that the two back ends should not diverge too much - and
this patch is small and gives a nice little boost to performance on
some popular benchmarks.
I've regression tested it over the weekend with no issues.
OK?
Cheers,
James
---
2014-01-19 James Greenhalgh
* config/arm/arm-cores.def (cortex-a57): Use the new Cortex-A57
pipeline model.
config/arm/arm.md: Include the new Cortex-A57 model.
(generic_sched): Don't use generic_sched when tuning for
Cortex-A57.
diff --git a/gcc/config/arm/arm-cores.def b/gcc/config/arm/arm-cores.def
index fa13eb9..f24fefd 100644
--- a/gcc/config/arm/arm-cores.def
+++ b/gcc/config/arm/arm-cores.def
@@ -166,7 +166,7 @@ ARM_CORE("cortex-a17.cortex-a7", cortexa17cortexa7, cortexa7, 7A, FL_LDSCHED |
/* V8 Architecture Processors */
ARM_CORE("cortex-a53", cortexa53, cortexa53, 8A, FL_LDSCHED | FL_CRC32, cortex_a53)
-ARM_CORE("cortex-a57", cortexa57, cortexa15, 8A, FL_LDSCHED | FL_CRC32, cortex_a57)
+ARM_CORE("cortex-a57", cortexa57, cortexa57, 8A, FL_LDSCHED | FL_CRC32, cortex_a57)
ARM_CORE("xgene1", xgene1,xgene1, 8A, FL_LDSCHED,xgene1)
/* V8 big.LITTLE implementations */
diff --git a/gcc/config/arm/arm.md b/gcc/config/arm/arm.md
index 5e6649a5dd39c58fac66bb26e0ffae32d2b4a6b8..149f5bc90d4087c6b1425f8e1fb70503cec18970 100644
--- a/gcc/config/arm/arm.md
+++ b/gcc/config/arm/arm.md
@@ -391,8 +391,8 @@ (define_attr "generic_sched" "yes,no"
arm926ejs,arm1020e,arm1026ejs,arm1136js,\
arm1136jfs,cortexa5,cortexa7,cortexa8,\
cortexa9,cortexa12,cortexa15,cortexa17,\
-cortexa53,cortexm4,cortexm7,marvell_pj4,\
-xgene1")
+cortexa53,cortexa57,cortexm4,cortexm7,\
+marvell_pj4,xgene1")
(eq_attr "tune_cortexr4" "yes"))
(const_string "no")
(const_string "yes"
@@ -425,6 +425,7 @@ (define_attr "generic_vfp" "yes,no"
(include "cortex-a15.md")
(include "cortex-a17.md")
(include "cortex-a53.md")
+(include "cortex-a57.md")
(include "cortex-r4.md")
(include "cortex-r4f.md")
(include "cortex-m7.md")
Re: [AArch64] Add a new scheduling description for the ARM Cortex-A57 processor
On Fri, Jan 16, 2015 at 03:34:30PM +, Ramana Radhakrishnan wrote: > On Fri, Jan 16, 2015 at 3:06 PM, James Greenhalgh > wrote: > > On Fri, Jan 16, 2015 at 10:20:40AM +, Marcus Shawcroft wrote: > >> On 15 January 2015 at 09:50, James Greenhalgh > >> wrote: > >> > >> > 2015-01-15 James Greenhalgh > >> > > >> > * config/arm/cortex-a57.md: New. > >> > * config/aarch64/aarch64.md: Include it. > >> > * config/aarch64/aarch64-cores.def (cortex-a57): Tune for it. > >> > * config/aarch64/aarch64-tune.md: Regenerate. > >> > >> This is low risk and only affects aarch64 backend. I think we should > >> take this for gcc 5, so OK. > > > > Thanks Marcus, > > > > I committed this as revision 219724, but I made a mistake in applying > > the patch and we ended up with two copies of the model in the same > > file. > > > > I've committed the attached as revision 219746 as the obvious > > fixup to my mistake. > > > > This should resolve the build failure that doko was seeing. > > Can you also spin up a changes.html patch for the ARM / AArch64 ports > while you are at it ? Of course, how does the below look to you? OK after the Cortex-A57 scheduling description goes in to the ARM port? Thanks, James --- Index: htdocs/gcc-5/changes.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-5/changes.html,v retrieving revision 1.65 diff -u -r1.65 changes.html --- htdocs/gcc-5/changes.html 14 Jan 2015 11:59:44 - 1.65 +++ htdocs/gcc-5/changes.html 16 Jan 2015 16:10:10 - @@ -439,6 +439,12 @@ AArch64 + Code generation for the ARM Cortex-A57 processor has been improved. + A more accurate instruction scheduling model for the processor is + now used, and a number of compiler tuning parameters have been set + to offer increased performance when compiling with + -mcpu=cortex-a57 or -mtune=cortex-a57. + A workaround for the ARM Cortex-A53 erratum 835769 has been added and can be enabled by giving the -mfix-cortex-a53-835769 option. @@ -471,6 +477,12 @@ configure option with either of --with-tune or --with-arch. + Code generation for the ARM Cortex-A57 processor has been improved. + A more accurate instruction scheduling model for the processor is + now used, and a number of compiler tuning parameters have been set + to offer increased performance when compiling with + -mcpu=cortex-a57 or -mtune=cortex-a57. + Support for the Cortex-A17 processor has been added through the -mcpu=cortex-a17 and -mtune=cortex-a17 options.
[C++ Patch] PR 60218
Hi,
looks like the __bases extensions need some work as regards error
checking / recovery but this specific ICE on invalid seems easy and safe
to fix: check that TYPE_BINFO isn't null and handle the possibility of
vector->length () null during error recovery.
Tested x86_64-linux.
Thanks,
Paolo.
/
/cp
2015-01-19 Paolo Carlini
PR c++/60218
* semantics.c (calculate_bases_helper): Don't call dfs_walk_all
when TYPE_BINFO (type) is null.
(calculate_bases): Handle gracefully a null vector->length ().
/testsuite
2015-01-19 Paolo Carlini
PR c++/60218
* g++.dg/ext/bases2.C: New.
Index: cp/semantics.c
===
--- cp/semantics.c (revision 219849)
+++ cp/semantics.c (working copy)
@@ -3804,8 +3804,9 @@ calculate_bases_helper (tree type)
vec *vector = make_tree_vector();
/* Now add non-virtual base classes in order of construction */
- dfs_walk_all (TYPE_BINFO (type),
-dfs_calculate_bases_pre, dfs_calculate_bases_post, &vector);
+ if (TYPE_BINFO (type))
+dfs_walk_all (TYPE_BINFO (type),
+ dfs_calculate_bases_pre, dfs_calculate_bases_post, &vector);
return vector;
}
@@ -3839,13 +3840,18 @@ calculate_bases (tree type)
vec_safe_splice (vector, nonvbases);
release_tree_vector (nonvbases);
- /* Last element is entire class, so don't copy */
- bases_vec = make_tree_vec (vector->length () - 1);
+ /* NB: vector->length () can even be zero during error recovery. */
+ if (vector->length () > 1)
+{
+ /* Last element is entire class, so don't copy */
+ bases_vec = make_tree_vec (vector->length() - 1);
- for (i = 0; i < vector->length () - 1; ++i)
-{
- TREE_VEC_ELT (bases_vec, i) = (*vector)[i];
+ for (i = 0; i < vector->length () - 1; ++i)
+ TREE_VEC_ELT (bases_vec, i) = (*vector)[i];
}
+ else
+bases_vec = make_tree_vec (0);
+
release_tree_vector (vector);
return bases_vec;
}
Index: testsuite/g++.dg/ext/bases2.C
===
--- testsuite/g++.dg/ext/bases2.C (revision 0)
+++ testsuite/g++.dg/ext/bases2.C (working copy)
@@ -0,0 +1,14 @@
+// PR c++/60218
+// { dg-do compile { target c++11 } }
+
+template struct A {};
+
+template struct B
+{
+ typedef A<__bases(T)...> C;
+};
+
+struct X {};
+struct Y : X* {}; // { dg-error "expected" }
+
+B b;
Re: GCC 5 Status Report (2015-01-19), Trunk in Stage 4
On Mon, Jan 19, 2015 at 12:32 PM, Jonathan Wakely wrote: > I would like to commit these two patches which complete the C++11 > library implementation: I would definitely be in favor. > https://gcc.gnu.org/ml/gcc-patches/2015-01/msg01694.html Just a nit. Why wouldn't you check the value of the variable after the assignment in the test case?
Re: GCC 5 Status Report (2015-01-19), Trunk in Stage 4
On 19 January 2015 at 18:05, Ulrich Drepper wrote: >> https://gcc.gnu.org/ml/gcc-patches/2015-01/msg01694.html > > Just a nit. Why wouldn't you check the value of the variable after > the assignment in the test case? Umm, just because I'm dumb? :-) I'll make that change to my local branch, thanks.
Re: Use static chain and libffi for Go closures
On Sat, Jan 17, 2015 at 7:34 PM, Uros Bizjak wrote:
> On Sat, Jan 17, 2015 at 12:19 AM, Ian Lance Taylor wrote:
>
>>> You should also revert alpha specific change to
>>> libgo/go/testing/quick/quick_test.go, please see [1] and [2].
>>>
>>> [1] https://gcc.gnu.org/ml/gcc-patches/2013-03/msg00038.html
>>> [2] https://gcc.gnu.org/ml/gcc-patches/2013-03/msg00038/foo.patch
>>
>> Done like so. Committed to mainline.
>
> Thanks!
>
> There is another part in runtime/go-ffi.c that looks like it is not
> necessary anymore with FFI_TARGET_HAS_COMPLEX_TYPE.
Attached is a more conservative v2 patch that conditionally enables
fixup code when FFI_TARGET_HAS_COMPLEX_TYPE is not defined.
Tested on x86_64-linux-gnu {-m32} without regressions.
Uros.
Index: runtime/go-ffi.c
===
--- runtime/go-ffi.c(revision 219832)
+++ runtime/go-ffi.c(working copy)
@@ -290,8 +290,8 @@ go_func_return_ffi (const struct __go_func_type *f
if (count == 1)
{
-
-#if defined (__i386__) && !defined (__x86_64__)
+#ifndef FFI_TARGET_HAS_COMPLEX_TYPE
+# if defined (__i386__) && !defined (__x86_64__)
/* FFI does not support complex types. On 32-bit x86, a
complex64 will be returned in %eax/%edx. We normally tell
FFI that a complex64 is a struct of two floats. On 32-bit
@@ -300,6 +300,7 @@ go_func_return_ffi (const struct __go_func_type *f
by pretending that complex64 is int64. */
if ((types[0]->__code & GO_CODE_MASK) == GO_COMPLEX64)
return &ffi_type_sint64;
+# endif
#endif
return go_type_to_ffi (types[0]);
Re: GCC 5 Status Report (2015-01-19), Trunk in Stage 4
On Mon, Jan 19, 2015 at 05:32:39PM +, Jonathan Wakely wrote: > I would like to commit these two patches which complete the C++11 > library implementation: > > https://gcc.gnu.org/ml/gcc-patches/2015-01/msg01694.html > https://gcc.gnu.org/ml/gcc-patches/2015-01/msg01648.html > > And this one to complete C++14 library implementation: > > https://gcc.gnu.org/ml/gcc-patches/2015-01/msg01704.html > > This one is tiny, and only affects the header, > which is, as the name suggests, experimental: > > https://gcc.gnu.org/ml/gcc-patches/2015-01/msg01684.html > > OK? I think this is worth making an exception for it. So ok from me, but please give Richard and/or Joseph a chance to chime in if they disagree. Jakub
Re: Use static chain and libffi for Go closures
On 01/19/2015 10:11 AM, Uros Bizjak wrote:
> Attached is a more conservative v2 patch that conditionally enables
> fixup code when FFI_TARGET_HAS_COMPLEX_TYPE is not defined.
>
> Tested on x86_64-linux-gnu {-m32} without regressions.
I don't think this version should be required.
For x86, FFI_TARGET_HAS_COMPLEX_TYPE is only false for Darwin, which
isn't supported by libgo at all. There are many many other things
which would need to be fixed in order to get libgo working there.
r~
Re: [PATCH 7/8] Model cache auto-prefetcher in scheduler
On Jan 19, 2015, at 6:05 PM, Richard Earnshaw wrote: > On 16/01/15 15:06, Maxim Kuvyrkov wrote: >> @@ -1874,7 +1889,8 @@ const struct tune_params arm_cortex_a15_tune = >> true, true, /* Prefer 32-bit encodings. >> */ >> true, /* Prefer Neon for >> stringops. */ >> 8, /* Maximum insns to inline >> memset. */ >> - ARM_FUSE_NOTHING /* Fuseable pairs of >> instructions. */ >> + ARM_FUSE_NOTHING, /* Fuseable pairs of >> instructions. */ >> + max_insn_queue_index + 1 /* Sched L2 autopref depth. */ >> }; > > > Hmm, two issues here: > 1) This requires a static constructor for the tuning table entry (since > the value of max_insn_queue_index has to be looked up at run time. Are you sure? I didn't check the object files, but, since max_insn_queue_index is a "const int", I would expect a relocation that would be resolved at link time, not a constructor. Is it a problem to have a static constructor for the tables? > > 2) Doesn't this mean that the depth of searching will depend on > properties of the automata rather than some machine specific values (so > that potentially adding or removing unrelated scheduler rules could > change the behaviour of the compiler)? No. The extra queue entries that will appear from extending an unrelated automaton will be empty, so the search will check them, but won't find anything. > > In general, how should someone tuning the compiler for this parameter > select a value that isn't one of (-1, m_i_q_d+1)? >From my experiments it seems there are 4 reasonable values for the parameter: >(-1) autopref turned off, (0) turned on in rank_for_schedule, (m_i_q_d+1) >turned on everywhere. If there is a static constructor generated for tune >tables and it is a problem to have it -- I can shrink acceptable values to >these 3 and call it a day. -- Maxim Kuvyrkov www.linaro.org
Re: [PATCH] Fix scheduling undeterminism from sorting with DEBUG_INSNs
On Jan 19, 2015, at 6:48 PM, Mike Stump wrote: > On Jan 19, 2015, at 5:41 AM, Maxim Kuvyrkov wrote: >> In A < B < C < A case all A, B and C are normal instructions. It is a >> pre-existing condition. When compiling without debug information we have >> ready list "A, B, C". When compiling with debug information, we have ready >> list "A, B, C, D" where "D" is DEBUG_INSN. Because we now have 4 elements >> to sort instead of 3, qsort can choose a different order of comparison >> _among_ A, B and C. > > Not when the uid is mixed in it cannot. :-) I think you are misunderstanding the issue. -- Maxim Kuvyrkov www.linaro.org
[PATCH] Fix PR ipa/64668
Hello.
This is fix for PR64668, where I did a wrong assumption about an arguments
of OBJ_TYPE_REF tree type.
I've been testing the patch on x86_64-linux-pc, ready after it finishes?
Thanks,
Martin
>From 54840c592a866eca0a535cdda3714b4251042153 Mon Sep 17 00:00:00 2001
From: mliska
Date: Mon, 19 Jan 2015 14:37:50 +0100
Subject: [PATCH] Fix PR64668.
gcc/testsuite/ChangeLog:
2015-01-19 Martin Liska
* objc/compile/pr64668.m: New test.
gcc/ChangeLog:
2015-01-19 Martin Liska
PR ipa/64668
* ipa-icf-gimple.c (func_checker::compare_operand): Call proper
function for second argument of OBJ_TYPE_REF.
---
gcc/ipa-icf-gimple.c | 2 +-
gcc/testsuite/objc/compile/pr64668.m | 20
2 files changed, 21 insertions(+), 1 deletion(-)
create mode 100644 gcc/testsuite/objc/compile/pr64668.m
diff --git a/gcc/ipa-icf-gimple.c b/gcc/ipa-icf-gimple.c
index b35d66c..5b176d0 100644
--- a/gcc/ipa-icf-gimple.c
+++ b/gcc/ipa-icf-gimple.c
@@ -456,7 +456,7 @@ func_checker::compare_operand (tree t1, tree t2)
z2 = TREE_OPERAND (t2, 2);
ret = compare_ssa_name (x1, x2)
- && compare_ssa_name (y1, y2)
+ && compare_operand (y1, y2)
&& compare_cst_or_decl (z1, z2);
return return_with_debug (ret);
diff --git a/gcc/testsuite/objc/compile/pr64668.m b/gcc/testsuite/objc/compile/pr64668.m
new file mode 100644
index 000..23a15d2
--- /dev/null
+++ b/gcc/testsuite/objc/compile/pr64668.m
@@ -0,0 +1,20 @@
+typedef struct objc_object {} *id;
+typedef struct _NSZone NSZone;
+@class NSCoder;
+@protocol NSObject - (Class) class;
+@end @protocol NSCopying - (id) copyWithZone: (NSZone*)zone;
+@end @protocol NSMutableCopying - (id) mutableCopyWithZone: (NSZone*)zone;
+@end @protocol NSCoding - (void) encodeWithCoder: (NSCoder*)aCoder;
+@end @interface NSObject {}
+@end typedef double NSTimeInterval;
+@interface NSString :NSObject + (id) string;
+@end @interface NSConstantString : NSString {}
+@end @class NSMutableArray, NSMutableDictionary, NSMutableData, NSData, NSString;
+@interface NSBundle : NSObject {}
+enum { NSMixedState = -1, NSOffState = 0, NSOnState = 1 };
+@end @class NSWindow;
+@interface IBInspector : NSObject { id object; }
+@end @interface GormScrollViewAttributesInspector : IBInspector { id verticalScroll; id horizontalScroll; }
+@end @implementation GormScrollViewAttributesInspector - init {}
+- (void) verticalSelected: (id)sender { [super ok: sender]; [object setHasVerticalScroller: ([verticalScroll state] == NSOnState)]; }
+- (void) horizontalSelected: (id)sender { [super ok: sender]; [object setHasHorizontalScroller: ([horizontalScroll state] == NSOnState)]; }
--
2.1.2
[PATCH] PR ada/64640: Fix Ada bootstrap under cygwin.
Hi, this patch fixes the Ada bootstrap under cygwin-32. See PR ada/64640. Boot-strapped successfully under cygwin-32/XP. OK for trunk? Thanks Bernd. 2015-01-19 Bernd Edlinger PR ada/64640 * adaint.c: Handle __CYGWIN__ like __MINGW32__ here. * mingw32.h: Don't include under cygwin. (_O_U8TEXT, _O_U16TEXT, _O_WTEXT): Set to _O_TEXT if not yet defined. patch-ada-cygwin.diff Description: Binary data
