Re: genmatch infinite loop during bootstrap on AIX
On October 26, 2014 12:26:29 AM CEST, David Edelsohn wrote: >Richard, > >I confirmed again with gcc111, which fails with r216632 and succeeds >with r216624. Can you revert r216631 but still keep the r216632 fix? I suppose bootstrap before r216632 still fails on AIX? I'll try to reproduce on ppc-linux tomorrow, otherwise I have to get myself a cfarm account. Thanks, Richard. >On my internal AIX system bootstrapping with GCC 4.7.3, it enters an >infinite loop in stage 1. With gcc111 and bootstrapping with GCC >4.8.1, it enters an infinite loop in stage 2. > >Thanks, David > >On Sat, Oct 25, 2014 at 2:36 PM, David Edelsohn >wrote: >> Richard, >> >> There definitely seems to be something wrong with genmatch and the >> recent match-and-simplify patch (r216632). Using a different, >> internal AIX system to speed up testing the potential causes of the >> problem, a tree at r216661 (just before Marxin's patch) hangs in >> genmatch during stage 1 bootstrap using G++ 4.7.3: >> >> (gdb) where >> #0 0x10068158 in std::allocator::allocator() () >> #1 0x1000b0b0 in _ZN6parser13parse_captureEP7operand >(this=0x2ff20974, op=0x0) >> at /nasfarm/edelsohn/src/src/gcc/genmatch.c:2607 >> #2 0x1000b994 in _ZN6parser8parse_opEv (this=0x2ff20974) >> at /nasfarm/edelsohn/src/src/gcc/genmatch.c:2767 >> #3 0x1000b4f4 in _ZN6parser10parse_exprEv (this=0x2ff20974) >> at /nasfarm/edelsohn/src/src/gcc/genmatch.c:2669 >> #4 0x1000b7c0 in _ZN6parser8parse_opEv (this=0x2ff20974) >> at /nasfarm/edelsohn/src/src/gcc/genmatch.c:2728 >> #5 0x1000ba4c in >> >_ZN6parser14parse_simplifyEjR3vecIP8simplify7va_heap6vl_ptrEP12predicate_idP4expr >> (this=0x2ff20974, match_location=4614, simplifiers=..., >> matcher=0x0, result=0x0) at >/nasfarm/edelsohn/src/src/gcc/genmatch.c:2792 >> #6 0x1000c868 in _ZN6parser13parse_patternEv (this=0x2ff20974) >> at /nasfarm/edelsohn/src/src/gcc/genmatch.c:3052 >> #7 0x1000c544 in _ZN6parser9parse_forEj (this=0x2ff20974) >> at /nasfarm/edelsohn/src/src/gcc/genmatch.c:2991 >> #8 0x1000cb1c in _ZN6parser13parse_patternEv (this=0x2ff20974) >> at /nasfarm/edelsohn/src/src/gcc/genmatch.c:3090 >> #9 0x1000cd78 in _ZN6parserC2EP10cpp_reader (this=0x2ff20974, >r_=0x3000c8e8) >> at /nasfarm/edelsohn/src/src/gcc/genmatch.c:3122 >> #10 0x10011614 in main (argc=3, argv=0x2ff20a3c) >> at /nasfarm/edelsohn/src/src/gcc/genmatch.c:3204 >> >> r216624 (after Maxim's sched patches and before your >> match-and-simplify patch) does not have a problem on gcc111. >> >> - David >> >> >> On Sat, Oct 25, 2014 at 1:18 PM, David Edelsohn >wrote: >>> Bootstrap succeeds with Maxim's patch (r216624). >>> >>> The other, significant changes I see on trunk between r216624 and >r216674 are: >>> >>> match-and-simplify through r216632 >>> ipc-icf in r216662 >>> libstdc++ in r216667 >>> >>> No other patches to trunk *seem* like they should affect PPC >bootstrap. >>> >>> - David >>> >>> >>> On Sat, Oct 25, 2014 at 10:04 AM, David Edelsohn >wrote: It may be fallout from Maxim's scheduler patch. I'm testing that. Backing up before Maxim's patch and your genmatch patch does not >enter an endless loop. - David On Sat, Oct 25, 2014 at 4:06 AM, Richard Biener >wrote: > On October 25, 2014 1:33:39 AM CEST, David Edelsohn > wrote: >>genmatch is hanging when bootstrapping on AIX (gcc111). When I >attach >>to the process: >> >>#0 0x1007efac in std::basic_string, >>std::allocator >::basic_string () >>#1 0x1000e6b0 in _ZN6parser13parse_captureEP7operand >(this=0x300594b8, >>op=0x0) >>at /home/dje/src/src/gcc/genmatch.c:2607 > > Does it really hang in libstdc++ or does it loop somewhere in >genmatch? Is this stage1 or later? > > Does this happen only after the 2nd part of the merge went in? >That is, what revision? > > Thanks, > Richard. > >>#2 0x1000e9f0 in _ZN6parser10parse_exprEv (this=0x2ff20208) >>at /home/dje/src/src/gcc/genmatch.c:2669 >>#3 0x1000ee38 in _ZN6parser8parse_opEv (this=0x2ff20208) >>at /home/dje/src/src/gcc/genmatch.c:2728 >>#4 0x1000efc4 in >>_ZN6parser14parse_simplifyEjR3vecIP8simplify7va_heap6vl_ptrEP12predicate_idP4expr >>(this=0x2ff20208, match_location=4614, simplifiers=..., >>matcher=0x0, result=0x0) at >/home/dje/src/src/gcc/genmatch.c:2792 >>#5 0x100102fc in _ZN6parser13parse_patternEv (this=0x2ff20208) >>at /home/dje/src/src/gcc/genmatch.c:3052 >>#6 0x10010c0c in _ZN6parser9parse_forEj (this=0x2ff20208) >>at /home/dje/src/src/gcc/genmatch.c:2991 >>#7 0x10010350 in _ZN6parser13parse_patternEv (this=0x2ff20208) >>at /home/dje/src/src/gcc/genmatch.c:3090 >>#8 0x1001122c in _ZN6parserC2EP10cpp_reader (this=0x2ff20208, >>r_=0x3003bbec) >>at /home/dje/src/src/gcc/genmatch.c:3122 >>#9 0x10004acc in main (argc=, >>argv=) at _start_ :3204 > >
Re: [PATCH] microblaze: microblaze.md: Use 'SI' instead of 'VOID' for operand 1 of 'call_value_intern'
On 10/22/2014 09:34 AM, Chen Gang wrote: > >>> >>> Yes, if you want to test on a target, you will need a target. You can >>> either have a simulator (see binutils and sim/* for an example of how to >>> write one) or target hardware in some form. >>> After tried 'sim', I found the root cause is microblaze sim does not support '--sysroot', which is the environments for shared libraries and system calls (need load microblaze kernel). - microblaze can successfully execute simple programs which has no glibc and no system call. - In upstream master branch of binutils, for microblaze sim, it has no related testsuite for sim in binutils, neither support '--sysroot', neither support function stack, startup parameters, and environments. - After hard code the default stack in sim, it can start the '-static' program with glibc, but stop at uname() which will use system call. So I want to consult: at present, can we let microblaze sim run 'normal' programs (have glibc, and use system call)? If it does not support, I have to rewind to qemu. If it really happens, it seems I can not finish "gcc testsuite with target" within this month. (although I have several excuses) :-( Thanks. > > I will continue sim, and should try to finish within 2014-10-31. Sorry, > my other things which related open source maybe be delayed (maybe can > not finish within this month, if happens, need finish within next month). > >> >> After trying sim, for me, it is really useful way for test, although I >> also met issues: >> >> For a hello world C program, microblaze gcc succeeded building, gdb can >> load and display the source code, and disassembe code successfully, but >> sim reported failure, the related issue is below: >> >> [root@localhost test]# /upstream/release/bin/microblaze-gchen-linux-run >> ./test >> Loading section .interp, size 0xd vma 0x10f4 >> Loading section .note.ABI-tag, size 0x20 vma 0x1104 >> Loading section .hash, size 0x24 vma 0x1124 >> Loading section .dynsym, size 0x40 vma 0x1148 >> Loading section .dynstr, size 0x3c vma 0x1188 >> Loading section .gnu.version, size 0x8 vma 0x11c4 >> Loading section .gnu.version_r, size 0x20 vma 0x11cc >> Loading section .rela.dyn, size 0x24 vma 0x11ec >> Loading section .rela.plt, size 0x24 vma 0x1210 >> Loading section .init, size 0x58 vma 0x1234 >> Loading section .plt, size 0x44 vma 0x128c >> Loading section .text, size 0x3d0 vma 0x12d0 >> Loading section .fini, size 0x34 vma 0x16a0 >> Loading section .rodata, size 0x12 vma 0x16d4 >> Loading section .eh_frame, size 0x4 vma 0x16e8 >> Loading section .ctors, size 0x8 vma 0x100016ec >> Loading section .dtors, size 0x8 vma 0x100016f4 >> Loading section .jcr, size 0x4 vma 0x100016fc >> Loading section .dynamic, size 0xd0 vma 0x10001700 >> Loading section .got, size 0xc vma 0x100017d0 >> Loading section .got.plt, size 0x18 vma 0x100017dc >> Loading section .data, size 0x10 vma 0x100017f4 >> Start address 0x12d0 >> Transfer rate: 14424 bits in <1 sec. >> ERROR: Unknown opcode >> program stopped with signal 4. >> >> For me, I guess it is sim's issue, and I shall try to fix it in the next >> month, so sorry, I can not finish emulator for microblaze within this >> month. :-( >> >> >> Welcome any ideas, suggestions or completions. >> >> Thanks. >> > -- Chen Gang Open share and attitude like air water and life which God blessed
[committed] Fix signal trampoline detection on hppa-linux
The attached change fixes an unwind problem during pthread
cancellation. For threads,
it turns out the return address is not marked as undefined. As a
result, pa32_fallback_frame_state
is called with an invalid context and the code generates a
segmentation fault looking for
the signal trampoline. This causes 30_threads/thread/native_handle/
cancel.cc and a number
of glibc tests to fail.
This change adds code to test whether the read accesses in
pa32_fallback_frame_state are ok.
This prevents the segmentation fault and the outer most frame is now
detected correctly.
Tested on hppa-unknown-linux-gnu. Committed to trunk, 4.9 and 4.8.
Dave
--
John David Anglin dave.ang...@bell.net
2014-10-26 John David Anglin
* config/pa/linux-unwind.h (pa32_read_access_ok): New function.
(pa32_fallback_frame_state): Use pa32_read_access_ok to check if
memory read accesses are ok.
Index: config/pa/linux-unwind.h
===
--- config/pa/linux-unwind.h(revision 216531)
+++ config/pa/linux-unwind.h(working copy)
@@ -32,6 +32,17 @@
#include
#include
+/* Return TRUE if read access to *P is allowed. */
+
+static inline long
+pa32_read_access_ok (void *p)
+{
+ long ret;
+
+ __asm__ ("proberi (%1),3,%0" : "=r" (ret) : "r" (p) :);
+ return ret;
+}
+
/* Unfortunately, because of various bugs and changes to the kernel,
we have several cases to deal with.
@@ -48,8 +59,13 @@
tell us how to locate the sigcontext structure.
Note that with a 2.4 64-bit kernel, the signal context is not properly
- passed back to userspace so the unwind will not work correctly. */
+ passed back to userspace so the unwind will not work correctly.
+ There is also a bug in various glibc versions. The (CONTEXT)->ra
+ for the outermost frame is not marked as undefined, so we need to
+ check whether read access is allowed for all the accesses used in
+ searching for the signal trampoline. */
+
#define MD_FALLBACK_FRAME_STATE_FOR pa32_fallback_frame_state
static _Unwind_Reason_Code
@@ -73,14 +89,17 @@
e4008200 be,l 0x100(%sr2, %r0), %sr0, %r31
08000240 nop */
- if (pc[0] == 0x3419 || pc[0] == 0x34190002)
+ if (pa32_read_access_ok (pc)
+ && (pc[0] == 0x3419 || pc[0] == 0x34190002))
off = 4*4;
- else if (pc[4] == 0x3419 || pc[4] == 0x34190002)
+ else if (pa32_read_access_ok (&pc[4])
+ && (pc[4] == 0x3419 || pc[4] == 0x34190002))
{
pc += 4;
off = 10 * 4;
}
- else if (pc[5] == 0x3419 || pc[5] == 0x34190002)
+ else if (pa32_read_access_ok (&pc[5])
+ && (pc[5] == 0x3419 || pc[5] == 0x34190002))
{
pc += 5;
off = 10 * 4;
@@ -96,13 +115,16 @@
word boundary and we can then determine the frame offset. */
sp = (unsigned long)context->ra;
pc = (unsigned int *)sp;
- if ((pc[0] == 0x3419 || pc[0] == 0x34190002) && (sp & 4))
+ if ((sp & 4)
+ && pa32_read_access_ok (pc)
+ && (pc[0] == 0x3419 || pc[0] == 0x34190002))
off = 5 * 4;
else
return _URC_END_OF_STACK;
}
- if (pc[1] != 0x3414015a
+ if (!pa32_read_access_ok (&pc[3])
+ || pc[1] != 0x3414015a
|| pc[2] != 0xe4008200
|| pc[3] != 0x08000240)
return _URC_END_OF_STACK;
Re: [microblaze] RFA: Use new rtl iterators in microblaze_tls_referenced_p
On 10/25/14 03:05, Richard Sandiford wrote:
This is part of a series to remove uses of for_each_rtx from the ports.
Tested by making sure there were no code changes for gcc.dg, gcc.c-torture
and g++.dg for microblaze-elf. OK to install?
Yes, this is OK. Please check for trailing whitespace.
Thanks,
Richard
gcc/
* config/microblaze/microblaze.c: Include rtl-iter.h.
(microblaze_tls_referenced_p_1): Delete.
(microblaze_tls_referenced_p): Use FOR_EACH_SUBRTX.
Index: gcc/config/microblaze/microblaze.c
===
--- gcc/config/microblaze/microblaze.c 2014-10-25 09:40:37.967516501 +0100
+++ gcc/config/microblaze/microblaze.c 2014-10-25 09:51:27.863905096 +0100
@@ -56,6 +56,7 @@
#include "diagnostic-core.h"
#include "cgraph.h"
#include "builtins.h"
+#include "rtl-iter.h"
#define MICROBLAZE_VERSION_COMPARE(VA,VB) strcasecmp (VA, VB)
@@ -444,20 +445,6 @@ microblaze_tls_symbol_p (rtx x)
return SYMBOL_REF_TLS_MODEL (x) != 0;
}
-static int
-microblaze_tls_operand_p_1 (rtx *x, void *data ATTRIBUTE_UNUSED)
-{
- if (GET_CODE (*x) == SYMBOL_REF)
-return SYMBOL_REF_TLS_MODEL (*x) != 0;
-
- /* Don't recurse into UNSPEC_TLS looking for TLS symbols; these are
- TLS offsets, not real symbol references. */
- if (GET_CODE (*x) == UNSPEC && XINT (*x, 1) == UNSPEC_TLS)
-return -1;
-
- return 0;
-}
-
/* Return TRUE if X contains any TLS symbol references. */
bool
@@ -465,8 +452,18 @@ microblaze_tls_referenced_p (rtx x)
{
if (!TARGET_HAVE_TLS)
return false;
-
- return for_each_rtx (&x, microblaze_tls_operand_p_1, NULL);
+ subrtx_iterator::array_type array;
+ FOR_EACH_SUBRTX (iter, array, x, ALL)
+{
+ const_rtx x = *iter;
+ if (GET_CODE (x) == SYMBOL_REF && SYMBOL_REF_TLS_MODEL (x) != 0)
+ return true;
+ /* Don't recurse into UNSPEC_TLS looking for TLS symbols; these are
+TLS offsets, not real symbol references. */
+ if (GET_CODE (x) == UNSPEC && XINT (x, 1) == UNSPEC_TLS)
+ iter.skip_subrtxes ();
+}
+ return false;
}
bool
--
Michael Eagerea...@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: [PATCH] Fix PR63266: Keep track of impact of sign extension in bswap
On 22 October 2014 10:56, Thomas Preud'homme wrote:
>> From: Christophe Lyon [mailto:christophe.l...@linaro.org]
>> Sent: Tuesday, October 21, 2014 10:03 PM
>> > +typedef int SItype __attribute__ ((mode (SI)));
>> What's the purpose of this? It seems unused.
>
> Sigh. Bad copy/paste from optimize-bswapsi-1.c
>
> I'll add it to my patch for pr63259.
>
>
>> I believe this should be:
>> "checks that unknown byte markers are set correctly in case of cast"
>
> Indeed, there is a 's' missing for markers.
>
>>
>> > +
>> > +HItype
>> > +swap16 (HItype in)
>> > +{
>> > + return (HItype) (((in >> 0) & 0xFF) << 8)
>> > + | (((in >> 8) & 0xFF) << 0);
>> > +}
>> > +
>> > /* { dg-final { scan-tree-dump-times "16 bit load in target endianness
>> found at" 3 "bswap" } } */
>> > -/* { dg-final { scan-tree-dump-times "16 bit bswap implementation
>> found at" 3 "bswap" { xfail alpha*-*-* arm*-*-* } } } */
>> > +/* { dg-final { scan-tree-dump-times "16 bit bswap implementation
>> found at" 1 "bswap" { target alpha*-*-* arm*-*-* } } } */
>>
>> This line fails when forcing the compiler to target -march=armv5t for
>> instance. I suspect this is because the check_effective_target_bswap
>> test is too permissive.
>
> Yep, it's likely to be the case. Feel to add a version check in it.
>
I tried to modify check_effective_target_bswap
and added:
+ } else {
+ if { [istarget arm*-*-*]
+&& [check_no_compiler_messages_nocache arm_v6_or_later object {
+#if __ARM_ARCH < 6
+#error not armv6 or later
+#endif
+int i;
+} ""] } {
+ set et_bswap_saved 1
+ }
since the rev* instructions appeared in v6.
Regarding the testsuite, it moves the tests to UNSUPPORTED vs a mix of
PASS/FAIL/XFAIL
< UNSUPPORTED: gcc.dg/optimize-bswaphi-1.c
< UNSUPPORTED: gcc.dg/optimize-bswapsi-1.c
< UNSUPPORTED: gcc.dg/optimize-bswapsi-2.c
---
> PASS: gcc.dg/optimize-bswaphi-1.c (test for excess errors)
> FAIL: gcc.dg/optimize-bswaphi-1.c scan-tree-dump-times bswap "16 bit bswap
> implementation found at" 1
> XFAIL: gcc.dg/optimize-bswaphi-1.c scan-tree-dump-times bswap "16 bit bswap
> implementation found at" 4
> PASS: gcc.dg/optimize-bswaphi-1.c scan-tree-dump-times bswap "16 bit load in
> target endianness found at" 3
> PASS: gcc.dg/optimize-bswapsi-1.c (test for excess errors)
> PASS: gcc.dg/optimize-bswapsi-1.c scan-tree-dump-times bswap "32 bit bswap
> implementation found at" 4
> PASS: gcc.dg/optimize-bswapsi-2.c (test for excess errors)
> XFAIL: gcc.dg/optimize-bswapsi-2.c scan-tree-dump-times bswap "32 bit bswap
> implementation found at" 3
> PASS: gcc.dg/optimize-bswapsi-2.c scan-tree-dump-times bswap "32 bit load in
> target endianness found at" 3
The PASS seems not very informative, so it may not be a problem to
loose these few PASS/XFAIL.
We can also explicitly skip optimize-bswaphi-1 when ARM_ARCH < 6.
Not sure what's preferred?
Christophe.
> Thanks for the review.
>
> Best regards,
>
> Thomas
>
>
>
>
Re: [Patch ARM-AArch64/testsuite v3 00/21] Neon intrinsics executable tests
On 24 October 2014 10:07, Marcus Shawcroft wrote:
> On 21 October 2014 14:02, Christophe Lyon wrote:
>> This patch series is an updated version of the series I sent here:
>> https://gcc.gnu.org/ml/gcc-patches/2014-07/msg00022.html
>>
>> I addressed comments from Marcus and Richard, and decided to skip
>> support for half-precision variants for the time being. I'll post
>> dedicated patches later.
>>
>> Compared to v2:
>> - the directory containing the new tests is named
>> gcc.target/aarch64/adv-simd instead of
>> gcc.target/aarch64/neon-intrinsics.
>> - the driver is named adv-simd.exp instead of neon-intrinsics.exp
>> - the driver is guarded against the new test parallelization framework
>> - the README file uses 'Advanced SIMD (Neon)' instead of 'Neon'
>>
>
> Thank you Christophe. Please commit all 21 patches in the series.
>
Thanks, I have committed the whole series.
I've just realized afterwards that the tests aren't guarded against
targets not supporting Neon.
How about adding the attached small patch?
(ChangeLog incorrectly formatted :-()
2014-10-26 Christophe Lyon
gcc.target/aarch64/advsimd-intrinsics/advsimd-intrinsics.exp: Skip
tests if target does not support Neon.
Christophe
> /Marcus
diff --git a/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/advsimd-intrinsics.exp b/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/advsimd-intrinsics.exp
index 3aa0e1c..938086b 100644
--- a/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/advsimd-intrinsics.exp
+++ b/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/advsimd-intrinsics.exp
@@ -32,6 +32,11 @@ load_lib torture-options.exp
dg-init
+if {[istarget arm*-*-*]
+&& ![check_effective_target_arm_neon_ok]} then {
+ return
+}
+
torture-init
set-torture-options $C_TORTURE_OPTIONS {{}} $LTO_TORTURE_OPTIONS
Re: [PATCH] microblaze: microblaze.md: Use 'SI' instead of 'VOID' for operand 1 of 'call_value_intern'
On 10/26/14 03:36, Chen Gang wrote: On 10/22/2014 09:34 AM, Chen Gang wrote: Yes, if you want to test on a target, you will need a target. You can either have a simulator (see binutils and sim/* for an example of how to write one) or target hardware in some form. After tried 'sim', I found the root cause is microblaze sim does not support '--sysroot', which is the environments for shared libraries and system calls (need load microblaze kernel). - microblaze can successfully execute simple programs which has no glibc and no system call. - In upstream master branch of binutils, for microblaze sim, it has no related testsuite for sim in binutils, neither support '--sysroot', neither support function stack, startup parameters, and environments. - After hard code the default stack in sim, it can start the '-static' program with glibc, but stop at uname() which will use system call. So I want to consult: at present, can we let microblaze sim run 'normal' programs (have glibc, and use system call)? Microblaze-sim provides basic instruction set architecture and memory simulation. There is no operating system support. (It's also quite old. I'm not sure which version of the MB architecture it models, but it is not recent.) Microblaze-sim is not a full system simulator, like QEMU. To be able to run a program which requires glibc, you need to be able to boot a full Linux image on the simulator, which microblaze-sim cannot do. QEMU models an entire processor and can boot a Linux image. -- Michael Eagerea...@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: [PATCH diagnostics] PR 53061 cleanup initialization
I committed this as https://gcc.gnu.org/r216720 following all your comments except for: On 23 October 2014 12:31, Dodji Seketeli wrote: >> + >> +/* Construct a C++-aware pretty-printer for CONTEXT. It is assumed >> + that CONTEXT->printer is an already constructed basic pretty_printer. */ > > I'd be even more specific in the comment by saying that CONTEXT->printer > is a basic pretty printer that was constructed presumably by > diagnostic_initialize(), called early in the compiler's initialization > process (in general_init) Before the FE is initialized. This (C++) > FE-specific diagnostic initializer is thus replacing the basic pretty > printer with one that has C++-aware capacities. > > Or maybe write this generic big-picture awareness comment before the > diagnostic_context::printer data member. If you don't have time for > this, I'll do it myself in a subsequent patch. I am writing this, also > for myself, as a reminder :-) I did the former and not the latter because the basic pp does not need to be overridden, the FEs can do it but they don't need to. Thus, I was not sure what you really wanted me to write in diagnostic.h The current comment is: /* Where most of the diagnostic formatting work is done. */ pretty_printer *printer; which admittedly is not that informative. Cheers, Manuel.
[Patch] Improving jump-thread pass for PR 54742
Sebastian Pop wrote: > Jeff Law wrote: > > On 08/21/14 04:30, Richard Biener wrote: > > >>It turns Jeff's jump-threading code in to a strange franken-pass of bits > > >>and > > >>pieces of detection and optimisation, and would need some substantial > > >>reworking to fit in with Jeff's changes last Autumn, but if it is more > > >>likely to be acceptable for trunk then perhaps we could look to revive it. > > >>It would be nice to reuse the path copy code Jeff added last year, but I > > >>don't have much intuition as to how feasible that is. > > >> > > >>Was this the sort of thing that you were imagining? > > > > > >Yeah, didn't look too closely though. > > It'd be pretty ugly I suspect. But it's probably worth pondering > > since that approach would eliminate the concerns about the cost of > > detection (which is problematical for the jump threader) by using > > Steve's code for that. > > > > On the update side, I suspect most, if not all of the framework is > > in place to handle this kind of update if the right threading paths > > were passed to the updater. I can probably cobble together that > > by-hand and see what the tree-ssa-threadupdate does with it. But > > it'll be a week or so before I could look at it. > > I adapted the patch James has sent last year to use the new update paths Attached an updated version of the patch. > mechanism. I verified that the attached patch does register all the paths > that > need to be threaded. Thread updater seems to have some problems handling the > attached testcase (a simplified version of the testcase attached to the bug.) > > Jeff, could you please have a look at why the jump-thread updater is crashing? I have tried to understand why the code generation part ICEs on coremark: the first problem that I have seen is that tree-ssa-threadupdate.c does not handle more than a joiner block per path to be threaded, so we would not be able to jump thread accross the joiners of the if condition and the joiner of the switch condition: i.e., these paths patch: Registering jump thread: (7, 10) incoming edge; (10, 25) joiner; (25, 26) joiner; (26, 4) nocopy; (4, 37) nocopy; (37, 36) nocopy; (36, 14) nocopy; patch: Registering jump thread: (28, 10) incoming edge; (10, 25) joiner; (25, 26) joiner; (26, 4) nocopy; (4, 37) nocopy; (37, 36) nocopy; (36, 11) nocopy; patch: Registering jump thread: (8, 10) incoming edge; (10, 25) joiner; (25, 26) joiner; (26, 4) nocopy; (4, 37) nocopy; (37, 36) nocopy; (36, 17) nocopy; patch: Registering jump thread: (9, 10) incoming edge; (10, 25) joiner; (25, 26) joiner; (26, 4) nocopy; (4, 37) nocopy; (37, 36) nocopy; (36, 25) nocopy; Another problem is that we attach the path to be threaded to the ->aux field of the first edge in the path, such that we would have to cancel some of the paths because we cannot keep track of all the paths to be threaded. For coremark, we would discover some jump-thread paths from one of the switch cases over the loop exit condition, either to bb_27 outside the loop, or to bb_4 staying inside the loop. Then with the "patch:" we would discover jump threads that would thread switch cases to switch cases, and because these paths start with the same edges for which we have already assigned a path to e->aux, we would have to cancel the interesting threads added by the patch: Registering jump thread: (12, 25) incoming edge; (25, 26) joiner; (26, 4) nocopy; Registering jump thread: (13, 25) incoming edge; (25, 26) joiner; (26, 27) nocopy; Registering jump thread: (29, 25) incoming edge; (25, 26) joiner; (26, 4) nocopy; Registering jump thread: (31, 25) incoming edge; (25, 26) joiner; (26, 27) nocopy; Registering jump thread: (16, 25) incoming edge; (25, 26) joiner; (26, 4) nocopy; Registering jump thread: (15, 25) incoming edge; (25, 26) joiner; (26, 4) nocopy; Registering jump thread: (32, 25) incoming edge; (25, 26) joiner; (26, 27) nocopy; Registering jump thread: (19, 25) incoming edge; (25, 26) joiner; (26, 4) nocopy; Registering jump thread: (18, 25) incoming edge; (25, 26) joiner; (26, 4) nocopy; Registering jump thread: (22, 25) incoming edge; (25, 26) joiner; (26, 27) nocopy; Registering jump thread: (21, 25) incoming edge; (25, 26) joiner; (26, 4) nocopy; Registering jump thread: (34, 25) incoming edge; (25, 26) joiner; (26, 27) nocopy; Registering jump thread: (33, 25) incoming edge; (25, 26) joiner; (26, 4) nocopy; Registering jump thread: (35, 25) incoming edge; (25, 26) joiner; (26, 27) nocopy; Registering jump thread: (24, 25) incoming edge; (25, 26) joiner; (26, 4) nocopy; patch: Registering jump thread: (12, 25) incoming edge; (25, 26) joiner; (26, 4) nocopy; (4, 37) nocopy; (37, 36) nocopy; (36, 17) nocopy; patch: Registering jump thread: (16, 25) incoming edge; (25, 26) joiner; (26, 4) nocopy; (4, 37) nocopy; (37, 36) nocopy; (36, 14) nocopy; patch: Registering jump thread
Fwd: g++ off-by-one bug in utf16 conversion
I believe I sent this yesterday to the incorrect list...
-- Forwarded message --
From: John Schmerge
Date: Sun, Oct 26, 2014 at 1:58 AM
Subject: g++ off-by-one bug in utf16 conversion
To: gcc-b...@gcc.gnu.org
Hey guys,
I came across this bug earlier today in implementing some
unit tests for utf8/16 conversions... The following c++
fragment gives the wrong result:
int main() {
char16_t s[] = u"\u";
std::cout << std::hex << s[0] << " " << s[1] << std::endl;
}
it prints:
d7ff dfff
where as it should print:
0
For those unfamiliar with utf16, all unicode values less than
or equal to 0x remain 16 bit values and no conversion is
done on them, code points greater than 0x get converted
to a pair of 16-bit shorts, where the 1st is in the range
0xd800-dbff and the 2nd is in the range 0xdc00-d.
Clearly this is an off-by-one issue. I traced it down to a
use of a less-than operator vs less-than-equal operator in
libcpp/charset.c
I have verified this is a bug with versions 4.4.7 (rhel 6.5),
4.8.2 (linaro/ubuntu/mint) and g++ (GCC) 5.0.0 20141025...
I am a bit surprised that this has gone so many years unnoticed
or at least unresolved.
Attached is a patch against gcc 4.8.2 from the gcc website for
the issue to $gcc-root/libcpp/charset.c that fixes the issue by my tests.
Thanks,
John
--- libcpp/charset.c 2014-10-26 01:24:10.583796875 -0400
+++ libcpp/charset.c.old 2014-10-26 01:23:50.103796842 -0400
@@ -353,7 +353,7 @@
return EILSEQ;
}
- if (s <= 0x)
+ if (s < 0x)
{
if (*outbytesleftp < 2)
{
Re: [patch] only emit one DIE for external declarations in the local scope
OK. Jason
Re: genmatch infinite loop during bootstrap on AIX
Richi, Does genmatch rely on static constructors or implicitly rely on the order of static constructors? Sometimes those cause problems on AIX. Bootstrap on AIX succeeds prior to r216631, e.g., r216624. It works after your commit r216619 to correct Makefile.in, or prior to that by manually editing Makefile.in to add LIBICONV and LIBINTL. Thanks, David On Sun, Oct 26, 2014 at 5:36 AM, Richard Biener wrote: > On October 26, 2014 12:26:29 AM CEST, David Edelsohn > wrote: >>Richard, >> >>I confirmed again with gcc111, which fails with r216632 and succeeds >>with r216624. > > Can you revert r216631 but still keep the r216632 fix? I suppose bootstrap > before r216632 still fails on AIX? > > I'll try to reproduce on ppc-linux tomorrow, otherwise I have to get myself a > cfarm account. > > Thanks, > Richard. > >>On my internal AIX system bootstrapping with GCC 4.7.3, it enters an >>infinite loop in stage 1. With gcc111 and bootstrapping with GCC >>4.8.1, it enters an infinite loop in stage 2. >> >>Thanks, David >> >>On Sat, Oct 25, 2014 at 2:36 PM, David Edelsohn >>wrote: >>> Richard, >>> >>> There definitely seems to be something wrong with genmatch and the >>> recent match-and-simplify patch (r216632). Using a different, >>> internal AIX system to speed up testing the potential causes of the >>> problem, a tree at r216661 (just before Marxin's patch) hangs in >>> genmatch during stage 1 bootstrap using G++ 4.7.3: >>> >>> (gdb) where >>> #0 0x10068158 in std::allocator::allocator() () >>> #1 0x1000b0b0 in _ZN6parser13parse_captureEP7operand >>(this=0x2ff20974, op=0x0) >>> at /nasfarm/edelsohn/src/src/gcc/genmatch.c:2607 >>> #2 0x1000b994 in _ZN6parser8parse_opEv (this=0x2ff20974) >>> at /nasfarm/edelsohn/src/src/gcc/genmatch.c:2767 >>> #3 0x1000b4f4 in _ZN6parser10parse_exprEv (this=0x2ff20974) >>> at /nasfarm/edelsohn/src/src/gcc/genmatch.c:2669 >>> #4 0x1000b7c0 in _ZN6parser8parse_opEv (this=0x2ff20974) >>> at /nasfarm/edelsohn/src/src/gcc/genmatch.c:2728 >>> #5 0x1000ba4c in >>> >>_ZN6parser14parse_simplifyEjR3vecIP8simplify7va_heap6vl_ptrEP12predicate_idP4expr >>> (this=0x2ff20974, match_location=4614, simplifiers=..., >>> matcher=0x0, result=0x0) at >>/nasfarm/edelsohn/src/src/gcc/genmatch.c:2792 >>> #6 0x1000c868 in _ZN6parser13parse_patternEv (this=0x2ff20974) >>> at /nasfarm/edelsohn/src/src/gcc/genmatch.c:3052 >>> #7 0x1000c544 in _ZN6parser9parse_forEj (this=0x2ff20974) >>> at /nasfarm/edelsohn/src/src/gcc/genmatch.c:2991 >>> #8 0x1000cb1c in _ZN6parser13parse_patternEv (this=0x2ff20974) >>> at /nasfarm/edelsohn/src/src/gcc/genmatch.c:3090 >>> #9 0x1000cd78 in _ZN6parserC2EP10cpp_reader (this=0x2ff20974, >>r_=0x3000c8e8) >>> at /nasfarm/edelsohn/src/src/gcc/genmatch.c:3122 >>> #10 0x10011614 in main (argc=3, argv=0x2ff20a3c) >>> at /nasfarm/edelsohn/src/src/gcc/genmatch.c:3204 >>> >>> r216624 (after Maxim's sched patches and before your >>> match-and-simplify patch) does not have a problem on gcc111. >>> >>> - David >>> >>> >>> On Sat, Oct 25, 2014 at 1:18 PM, David Edelsohn >>wrote: Bootstrap succeeds with Maxim's patch (r216624). The other, significant changes I see on trunk between r216624 and >>r216674 are: match-and-simplify through r216632 ipc-icf in r216662 libstdc++ in r216667 No other patches to trunk *seem* like they should affect PPC >>bootstrap. - David On Sat, Oct 25, 2014 at 10:04 AM, David Edelsohn >>wrote: > It may be fallout from Maxim's scheduler patch. I'm testing that. > Backing up before Maxim's patch and your genmatch patch does not >>enter > an endless loop. > > - David > > On Sat, Oct 25, 2014 at 4:06 AM, Richard Biener >>wrote: >> On October 25, 2014 1:33:39 AM CEST, David Edelsohn >> wrote: >>>genmatch is hanging when bootstrapping on AIX (gcc111). When I >>attach >>>to the process: >>> >>>#0 0x1007efac in std::basic_string, >>>std::allocator >::basic_string () >>>#1 0x1000e6b0 in _ZN6parser13parse_captureEP7operand >>(this=0x300594b8, >>>op=0x0) >>>at /home/dje/src/src/gcc/genmatch.c:2607 >> >> Does it really hang in libstdc++ or does it loop somewhere in >>genmatch? Is this stage1 or later? >> >> Does this happen only after the 2nd part of the merge went in? >>That is, what revision? >> >> Thanks, >> Richard. >> >>>#2 0x1000e9f0 in _ZN6parser10parse_exprEv (this=0x2ff20208) >>>at /home/dje/src/src/gcc/genmatch.c:2669 >>>#3 0x1000ee38 in _ZN6parser8parse_opEv (this=0x2ff20208) >>>at /home/dje/src/src/gcc/genmatch.c:2728 >>>#4 0x1000efc4 in >>>_ZN6parser14parse_simplifyEjR3vecIP8simplify7va_heap6vl_ptrEP12predicate_idP4expr >>>(this=0x2ff20208, match_location=4614, simplifiers=..., >>>matcher=0x0, result=0x0) at >>/home/dje/src/src/gcc/genmatch.c:2792 >>>#5 0x100102fc in _ZN6parser13parse_p
Re: [PATCH] microblaze: microblaze.md: Use 'SI' instead of 'VOID' for operand 1 of 'call_value_intern'
On 10/27/14 2:22, Michael Eager wrote: > On 10/26/14 03:36, Chen Gang wrote: >> On 10/22/2014 09:34 AM, Chen Gang wrote: >>> > > Yes, if you want to test on a target, you will need a target. You can > either have a simulator (see binutils and sim/* for an example of how to > write one) or target hardware in some form. > >> >> After tried 'sim', I found the root cause is microblaze sim does not >> support '--sysroot', which is the environments for shared libraries and >> system calls (need load microblaze kernel). >> >> - microblaze can successfully execute simple programs which has no >> glibc and no system call. >> >> - In upstream master branch of binutils, for microblaze sim, it has no >> related testsuite for sim in binutils, neither support '--sysroot', >> neither support function stack, startup parameters, and environments. >> >> - After hard code the default stack in sim, it can start the '-static' >> program with glibc, but stop at uname() which will use system call. >> >> So I want to consult: at present, can we let microblaze sim run 'normal' >> programs (have glibc, and use system call)? > > Microblaze-sim provides basic instruction set architecture and memory > simulation. > There is no operating system support. (It's also quite old. I'm not sure > which version of the MB architecture it models, but it is not recent.) > > Microblaze-sim is not a full system simulator, like QEMU. To be able to > run a program which requires glibc, you need to be able to boot a full Linux > image on the simulator, which microblaze-sim cannot do. QEMU models an > entire processor and can boot a Linux image. > OK, thank you very much, I shall rewind to qemu, and should try my best to finish within within this month. Thanks. -- Chen Gang Open, share, and attitude like air, water, and life which God blessed
[PATCH, ifcvt] Check size cost in noce_try_store_flag_mask
Hi,
Function noce_try_store_flag_mask converts "if (test) x = 0;" to "x &=
-(test == 0);"
But from code size view, "x &= -(test == 0);" might have more instructions
than "if (test) x = 0;". The patch checks the cost to determine the
conversion is valuable or not.
Bootstrap and no make check regression on X86-64.
No make check regression with Cortex-M0 qemu.
For CSiBE, ARM Cortex-m0 result is a little better. A little regression for
MIPS. Roughly no change for PowerPC.
OK for trunk?
Thanks!
-Zhenqiang
ChangeLog:
2014-10-27 Zhenqiang Chen
* ifcvt.c (noce_try_store_flag_mask): Check rtx cost.
testsuite/ChangeLog:
2014-10-27 Zhenqiang Chen
* gcc.target/arm/ifcvt-size-check.c: New test.
diff --git a/gcc/ifcvt.c b/gcc/ifcvt.c
index 949d2b4..3abd518 100644
--- a/gcc/ifcvt.c
+++ b/gcc/ifcvt.c
@@ -1393,6 +1393,14 @@ noce_try_store_flag_mask (struct noce_if_info
*if_info)
if (!seq)
return FALSE;
+ if (optimize_function_for_size_p (cfun))
+ {
+ int old_cost = COSTS_N_INSNS (if_info->branch_cost + 1);
+ int new_cost = seq_cost (seq, 0);
+ if (new_cost > old_cost)
+ return FALSE;
+ }
+
emit_insn_before_setloc (seq, if_info->jump,
INSN_LOCATION (if_info->insn_a));
return TRUE;
diff --git a/gcc/testsuite/gcc.target/arm/ifcvt-size-check.c
b/gcc/testsuite/gcc.target/arm/ifcvt-size-check.c
new file mode 100644
index 000..43fa16b
--- /dev/null
+++ b/gcc/testsuite/gcc.target/arm/ifcvt-size-check.c
@@ -0,0 +1,13 @@
+/* { dg-do assemble } */
+/* { dg-options "-mthumb -Os " } */
+/* { dg-require-effective-target arm_thumb1_ok } */
+
+int
+test (unsigned char iov_len, int count, int i)
+{
+ unsigned char bytes = 0;
+ if ((unsigned char) ((char) 127 - bytes) < iov_len)
+return 22;
+ return 0;
+}
+/* { dg-final { object-size text <= 12 } } */
Re: [PATCH, ifcvt] Check size cost in noce_try_store_flag_mask
On Sun, Oct 26, 2014 at 6:53 PM, Zhenqiang Chen wrote:
> Hi,
>
> Function noce_try_store_flag_mask converts "if (test) x = 0;" to "x &=
> -(test == 0);"
>
> But from code size view, "x &= -(test == 0);" might have more instructions
> than "if (test) x = 0;". The patch checks the cost to determine the
> conversion is valuable or not.
>
> Bootstrap and no make check regression on X86-64.
> No make check regression with Cortex-M0 qemu.
> For CSiBE, ARM Cortex-m0 result is a little better. A little regression for
> MIPS. Roughly no change for PowerPC.
>
> OK for trunk?
>
> Thanks!
> -Zhenqiang
>
> ChangeLog:
> 2014-10-27 Zhenqiang Chen
>
> * ifcvt.c (noce_try_store_flag_mask): Check rtx cost.
>
> testsuite/ChangeLog:
> 2014-10-27 Zhenqiang Chen
>
> * gcc.target/arm/ifcvt-size-check.c: New test.
>
> diff --git a/gcc/ifcvt.c b/gcc/ifcvt.c
> index 949d2b4..3abd518 100644
> --- a/gcc/ifcvt.c
> +++ b/gcc/ifcvt.c
> @@ -1393,6 +1393,14 @@ noce_try_store_flag_mask (struct noce_if_info
> *if_info)
> if (!seq)
> return FALSE;
>
> + if (optimize_function_for_size_p (cfun))
> + {
> + int old_cost = COSTS_N_INSNS (if_info->branch_cost + 1);
> + int new_cost = seq_cost (seq, 0);
> + if (new_cost > old_cost)
> + return FALSE;
> + }
Why not do it unconditionally rather than base this on optimize for size?
If the costs are incorrect for non optimize for size, we need to fix those.
Thanks,
Andrew Pinski
> +
> emit_insn_before_setloc (seq, if_info->jump,
>INSN_LOCATION (if_info->insn_a));
> return TRUE;
> diff --git a/gcc/testsuite/gcc.target/arm/ifcvt-size-check.c
> b/gcc/testsuite/gcc.target/arm/ifcvt-size-check.c
> new file mode 100644
> index 000..43fa16b
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/arm/ifcvt-size-check.c
> @@ -0,0 +1,13 @@
> +/* { dg-do assemble } */
> +/* { dg-options "-mthumb -Os " } */
> +/* { dg-require-effective-target arm_thumb1_ok } */
> +
> +int
> +test (unsigned char iov_len, int count, int i)
> +{
> + unsigned char bytes = 0;
> + if ((unsigned char) ((char) 127 - bytes) < iov_len)
> +return 22;
> + return 0;
> +}
> +/* { dg-final { object-size text <= 12 } } */
>
>
>
[RFC PATCH, AARCH64] Add support for -mlong-calls option
Hi,
This patch adds support for -mlong-calls option for aarch64 port. Major
code borrowed from ARM.
I'm doing regression test for it right now. Any comments?
Index: gcc/config/aarch64/aarch64.opt
===
--- gcc/config/aarch64/aarch64.opt (revision 216558)
+++ gcc/config/aarch64/aarch64.opt (working copy)
@@ -75,6 +75,10 @@ mlittle-endian
Target Report RejectNegative InverseMask(BIG_END)
Assume target CPU is configured as little endian
+mlong-calls
+Target Report Mask(LONG_CALLS)
+Generate call insns as indirect calls, if necessary
+
mcmodel=
Target RejectNegative Joined Enum(cmodel) Var(aarch64_cmodel_var)
Init(AARCH64_CMODEL_SMALL)
Specify the code model
Index: gcc/config/aarch64/aarch64-protos.h
===
--- gcc/config/aarch64/aarch64-protos.h (revision 216558)
+++ gcc/config/aarch64/aarch64-protos.h (working copy)
@@ -217,6 +217,10 @@ bool aarch64_use_return_insn_p (void);
const char *aarch64_output_casesi (rtx *);
const char *aarch64_rewrite_selected_cpu (const char *name);
+extern void aarch64_pr_long_calls (struct cpp_reader *);
+extern void aarch64_pr_no_long_calls (struct cpp_reader *);
+extern void aarch64_pr_long_calls_off (struct cpp_reader *);
+
enum aarch64_symbol_type aarch64_classify_symbol (rtx,
enum aarch64_symbol_context);
enum aarch64_symbol_type aarch64_classify_tls_symbol (rtx);
Index: gcc/config/aarch64/aarch64.c
===
--- gcc/config/aarch64/aarch64.c(revision 216558)
+++ gcc/config/aarch64/aarch64.c(working copy)
@@ -69,6 +69,9 @@
#include "dumpfile.h"
#include "builtins.h"
+static void aarch64_set_default_type_attributes (tree);
+static int aarch64_comp_type_attributes (const_tree, const_tree);
+
/* Defined for convenience. */
#define POINTER_BYTES (POINTER_SIZE / BITS_PER_UNIT)
@@ -530,12 +533,158 @@ aarch64_hard_regno_caller_save_mode (unsigned regn
return choose_hard_reg_mode (regno, nregs, false);
}
+/* Table of machine attributes. */
+static const struct attribute_spec aarch64_attribute_table[] =
+{
+ /* { name, min_len, max_len, decl_req, type_req, fn_type_req, handler,
+ affects_type_identity } */
+ /* Function calls made to this symbol must be done indirectly, because
+ it may lie outside of the 26 bit addressing range of a normal function
+ call. */
+ { "long_call",0, 0, false, true, true, NULL, false },
+ /* Whereas these functions are always known to reside within the 26 bit
+ addressing range. */
+ { "short_call", 0, 0, false, true, true, NULL, false },
+ { NULL, 0, 0, false, false, false, NULL, false }
+};
+
+/* Encode the current state of the #pragma [no_]long_calls. */
+typedef enum
+{
+ OFF, /* No #pragma [no_]long_calls is in effect. */
+ LONG,/* #pragma long_calls is in effect. */
+ SHORT/* #pragma no_long_calls is in effect. */
+} aarch64_pragma_enum;
+
+static aarch64_pragma_enum aarch64_pragma_long_calls = OFF;
+
+void
+aarch64_pr_long_calls (struct cpp_reader * pfile ATTRIBUTE_UNUSED)
+{
+ aarch64_pragma_long_calls = LONG;
+}
+
+void
+aarch64_pr_no_long_calls (struct cpp_reader * pfile ATTRIBUTE_UNUSED)
+{
+ aarch64_pragma_long_calls = SHORT;
+}
+
+void
+aarch64_pr_long_calls_off (struct cpp_reader * pfile ATTRIBUTE_UNUSED)
+{
+ aarch64_pragma_long_calls = OFF;
+}
+
+/* Return 0 if the attributes for two types are incompatible, 1 if they
+ are compatible, and 2 if they are nearly compatible (which causes a
+ warning to be generated). */
+static int
+aarch64_comp_type_attributes (const_tree type1, const_tree type2)
+{
+ int l1, l2, s1, s2;
+
+ /* Check for mismatch of non-default calling convention. */
+ if (TREE_CODE (type1) != FUNCTION_TYPE)
+return 1;
+
+ /* Check for mismatched call attributes. */
+ l1 = lookup_attribute ("long_call", TYPE_ATTRIBUTES (type1)) != NULL;
+ l2 = lookup_attribute ("long_call", TYPE_ATTRIBUTES (type2)) != NULL;
+ s1 = lookup_attribute ("short_call", TYPE_ATTRIBUTES (type1)) != NULL;
+ s2 = lookup_attribute ("short_call", TYPE_ATTRIBUTES (type2)) != NULL;
+
+ /* Only bother to check if an attribute is defined. */
+ if (l1 | l2 | s1 | s2)
+{
+ /* If one type has an attribute, the other must have the same attribute.
*/
+ if ((l1 != l2) || (s1 != s2))
+ return 0;
+
+ /* Disallow mixed attributes. */
+ if ((l1 & s2) || (l2 & s1))
+ return 0;
+}
+
+ return 1;
+}
+
+/* Assigns default attributes to newly defined type. This is used to
+set short_call/long_call attributes for function types of
+functions defined inside corresponding #pragma scopes. */
+static void
+aarch64_set_default_type_attributes (tree type)
+{
+ /* Add __attribute__ ((long_call)) to all functions, w
[C++ PING] Re: [PATCH 5/5] Add illegal cilk checks to C++ front.
Andi Kleen writes:
Ping!
Can someone from the C++ side please approve this patch?
That's the only patch not approved in this patch kit, but blocking
the commit.
-Andi
> From: Andi Kleen
>
> Add calls for several illegal Cilk cases to the C++ frontend.
> C++ usually doesn't ICE unlike C on illegal cilk, but it's
> better to match C in what is allowed and what is not.
>
> if (_Cilk_spawn ...) is still not errored, but at least it doesn't ICE.
>
> gcc/cp/:
>
> 2014-09-30 Andi Kleen
>
> * semantics.c (finish_goto_stmt): Call check_no_cilk.
> (finish_while_stmt_cond): Dito.
> (finish_do_stmt): Dito.
> (finish_for_cond): Dito.
> (finish_switch_cond): Dito.
> ---
> gcc/cp/semantics.c | 12
> 1 file changed, 12 insertions(+)
>
> diff --git a/gcc/cp/semantics.c b/gcc/cp/semantics.c
> index 7569826..9ca03be 100644
> --- a/gcc/cp/semantics.c
> +++ b/gcc/cp/semantics.c
> @@ -621,6 +621,8 @@ finish_goto_stmt (tree destination)
> TREE_USED (destination) = 1;
>else
> {
> + if (check_no_cilk (destination, "as a computed goto expression"))
> + destination = error_mark_node;
>destination = mark_rvalue_use (destination);
>if (!processing_template_decl)
> {
> @@ -792,6 +794,8 @@ begin_while_stmt (void)
> void
> finish_while_stmt_cond (tree cond, tree while_stmt, bool ivdep)
> {
> + if (check_no_cilk (cond, "as a condition for while statement"))
> +cond = error_mark_node;
>cond = maybe_convert_cond (cond);
>finish_cond (&WHILE_COND (while_stmt), cond);
>begin_maybe_infinite_loop (cond);
> @@ -847,6 +851,8 @@ finish_do_body (tree do_stmt)
> void
> finish_do_stmt (tree cond, tree do_stmt, bool ivdep)
> {
> + if (check_no_cilk (cond, "as a condition for a do-while statement"))
> +cond = error_mark_node;
>cond = maybe_convert_cond (cond);
>end_maybe_infinite_loop (cond);
>if (ivdep && cond != error_mark_node)
> @@ -956,6 +962,8 @@ finish_for_init_stmt (tree for_stmt)
> void
> finish_for_cond (tree cond, tree for_stmt, bool ivdep)
> {
> + if (check_no_cilk (cond, "in a condition for a for-loop"))
> +cond = error_mark_node;
>cond = maybe_convert_cond (cond);
>finish_cond (&FOR_COND (for_stmt), cond);
>begin_maybe_infinite_loop (cond);
> @@ -1118,6 +1126,10 @@ void
> finish_switch_cond (tree cond, tree switch_stmt)
> {
>tree orig_type = NULL;
> +
> + if (check_no_cilk (cond, "as a condition for switch statement"))
> +cond = error_mark_node;
> +
>if (!processing_template_decl)
> {
>/* Convert the condition to an integer or enumeration type. */
--
a...@linux.intel.com -- Speaking for myself only
Re: genmatch infinite loop during bootstrap on AIX
On October 27, 2014 1:49:54 AM CET, David Edelsohn wrote: >Richi, > >Does genmatch rely on static constructors or implicitly rely on the >order of static constructors? Sometimes those cause problems on AIX. No, it doesn't. >Bootstrap on AIX succeeds prior to r216631, e.g., r216624. It works >after your commit r216619 to correct Makefile.in, or prior to that by >manually editing Makefile.in to add LIBICONV and LIBINTL. OK, so this would mean that r216631 causes a miscompile for you. Though that does not match up with you seeing this happening during stage1... Bah. The place where it is looping is using std::map . Does -static-libstdc++ work for you host compilers? Can you try emptying gcc/match.pd for a non-working rev.? Thanks, Richard. >Thanks, David > >On Sun, Oct 26, 2014 at 5:36 AM, Richard Biener >wrote: >> On October 26, 2014 12:26:29 AM CEST, David Edelsohn > wrote: >>>Richard, >>> >>>I confirmed again with gcc111, which fails with r216632 and succeeds >>>with r216624. >> >> Can you revert r216631 but still keep the r216632 fix? I suppose >bootstrap before r216632 still fails on AIX? >> >> I'll try to reproduce on ppc-linux tomorrow, otherwise I have to get >myself a cfarm account. >> >> Thanks, >> Richard. >> >>>On my internal AIX system bootstrapping with GCC 4.7.3, it enters an >>>infinite loop in stage 1. With gcc111 and bootstrapping with GCC >>>4.8.1, it enters an infinite loop in stage 2. >>> >>>Thanks, David >>> >>>On Sat, Oct 25, 2014 at 2:36 PM, David Edelsohn >>>wrote: Richard, There definitely seems to be something wrong with genmatch and the recent match-and-simplify patch (r216632). Using a different, internal AIX system to speed up testing the potential causes of the problem, a tree at r216661 (just before Marxin's patch) hangs in genmatch during stage 1 bootstrap using G++ 4.7.3: (gdb) where #0 0x10068158 in std::allocator::allocator() () #1 0x1000b0b0 in _ZN6parser13parse_captureEP7operand >>>(this=0x2ff20974, op=0x0) at /nasfarm/edelsohn/src/src/gcc/genmatch.c:2607 #2 0x1000b994 in _ZN6parser8parse_opEv (this=0x2ff20974) at /nasfarm/edelsohn/src/src/gcc/genmatch.c:2767 #3 0x1000b4f4 in _ZN6parser10parse_exprEv (this=0x2ff20974) at /nasfarm/edelsohn/src/src/gcc/genmatch.c:2669 #4 0x1000b7c0 in _ZN6parser8parse_opEv (this=0x2ff20974) at /nasfarm/edelsohn/src/src/gcc/genmatch.c:2728 #5 0x1000ba4c in >>>_ZN6parser14parse_simplifyEjR3vecIP8simplify7va_heap6vl_ptrEP12predicate_idP4expr (this=0x2ff20974, match_location=4614, simplifiers=..., matcher=0x0, result=0x0) at >>>/nasfarm/edelsohn/src/src/gcc/genmatch.c:2792 #6 0x1000c868 in _ZN6parser13parse_patternEv (this=0x2ff20974) at /nasfarm/edelsohn/src/src/gcc/genmatch.c:3052 #7 0x1000c544 in _ZN6parser9parse_forEj (this=0x2ff20974) at /nasfarm/edelsohn/src/src/gcc/genmatch.c:2991 #8 0x1000cb1c in _ZN6parser13parse_patternEv (this=0x2ff20974) at /nasfarm/edelsohn/src/src/gcc/genmatch.c:3090 #9 0x1000cd78 in _ZN6parserC2EP10cpp_reader (this=0x2ff20974, >>>r_=0x3000c8e8) at /nasfarm/edelsohn/src/src/gcc/genmatch.c:3122 #10 0x10011614 in main (argc=3, argv=0x2ff20a3c) at /nasfarm/edelsohn/src/src/gcc/genmatch.c:3204 r216624 (after Maxim's sched patches and before your match-and-simplify patch) does not have a problem on gcc111. - David On Sat, Oct 25, 2014 at 1:18 PM, David Edelsohn >>>wrote: > Bootstrap succeeds with Maxim's patch (r216624). > > The other, significant changes I see on trunk between r216624 and >>>r216674 are: > > match-and-simplify through r216632 > ipc-icf in r216662 > libstdc++ in r216667 > > No other patches to trunk *seem* like they should affect PPC >>>bootstrap. > > - David > > > On Sat, Oct 25, 2014 at 10:04 AM, David Edelsohn > >>>wrote: >> It may be fallout from Maxim's scheduler patch. I'm testing >that. >> Backing up before Maxim's patch and your genmatch patch does not >>>enter >> an endless loop. >> >> - David >> >> On Sat, Oct 25, 2014 at 4:06 AM, Richard Biener > >>>wrote: >>> On October 25, 2014 1:33:39 AM CEST, David Edelsohn >>> wrote: genmatch is hanging when bootstrapping on AIX (gcc111). When I >>>attach to the process: #0 0x1007efac in std::basic_stringstd::char_traits, std::allocator >::basic_string () #1 0x1000e6b0 in _ZN6parser13parse_captureEP7operand >>>(this=0x300594b8, op=0x0) at /home/dje/src/src/gcc/genmatch.c:2607 >>> >>> Does it really hang in libstdc++ or does it loop somewhere in >>>genmatch? Is this stage1 or later? >>> >>> Does this happen only after the 2nd part of the merge went in? >>>That is, what revision? >>> >>> Thanks, >>> Richard.
