Re: writing patterns
On Thu, Jul 31, 2014 at 9:10 PM, Richard Sandiford wrote: > Richard Biener writes: >> On Wed, Jul 30, 2014 at 12:49 PM, Prathamesh Kulkarni >> wrote: >>> Hi, >>>Sorry to ask a stupid question, but I am having issues writing patterns >>> involving casts. I am trying to write patterns from simplify_rotate. >>> >>> Could you show me how to write a patterns that involve >>> casts ? >>> for eg: >>> ((T) ((T2) X << CNT1)) + ((T) ((T2) X >> CNT2)) iff CNT1 + CNT2 == B >>> T -> some unsigned type with bitsize B, and some type T2 wider than T. >>> How to express this in the pattern ? >> >> [copying gcc@ because of the syntax stuff] >> >> for example with (leaving captures as the appear in the pattern above) >> >> (match_and_simplify >>(plus (convert@2 (lshift (convert@0 X) CNT1)) >>(convert (rshift (convert@1 X) CNT2))) >> /* Types T2 have to match */ >>(if (types_compatible_p (TREE_TYPE (@0), TREE_TYPE (@1)) >> /* Type T should be unsigned. */ >>&& TYPE_UNSIGNED (TREE_TYPE (@2)) >>/* T2 should be wider than T. */ >>&& TYPE_PRECISION (TREE_TYPE (@0)) > TYPE_PRECISION (TREE_TYPE (@2)) >>/* CNT1 + CNT2 == B */ >>&& wi::eq_p (TYPE_PRECISION (TREE_TYPE (@2)), >>wi::add (CNT1, CNT2 >>(lrotate CNT1)) >> >> which suggests that we may want to add some type capturing / matching >> so we can maybe write >> >> (plus (convert@T (lshift (convert@T2 X) CNT1)) >> (convert (rshift (convert@T2 X) CNT2))) >> (if (/* T2s will be matched automagically */ >>&& TYPE_UNSIGNED (@T) >>&& TYPE_PRECISION (@T2) > TYPE_PRECISION (@T) >>&& wi::eq_p (TYPE_PRECISION (@T), wi::add (CNT1, CNT2 >> >> which is less to type and supports requiring matching types. Maybe >> require @T[0-9]+ here thus use @T0 and disallow plain @T. We could >> then also use @T for the implicitely "captured" outermost type we >> refer to as plain 'type' right now. > > Would it also be worth trying to push more of the type properties into > the pattern, a bit like md predicates? (Not the same syntax though, > obviously.) Was just thinking that postponing things like > "TYPE_UNSIGNED (@T)" until the whole tree has been matched could > be inefficient in some cases. Maybe, but as we are using a decision tree for the matching it's not so easy to handle this kind of checks efficiently (compared to a simple switch cascade on TREE_CODE). Richard. > Might be going over old ground though, sorry. > > Richard
devirt-34.C failing
Hi, is it known that the test is failing on many x86_64-linux targets? FAIL: g++.dg/ipa/devirt-34.C -std=gnu++98 scan-ipa-dump devirt "Targets that are not likely" FAIL: g++.dg/ipa/devirt-34.C -std=gnu++11 scan-ipa-dump devirt "Targets that are not likely" FAIL: g++.dg/ipa/devirt-34.C -std=gnu++1y scan-ipa-dump devirt "Targets that are not likely" Thanks! Paolo.
Re: ARM Linux EABI: unwinding through a segfault handler
Hi, We are also observing same issue and this was fixed in ulibc in below link and we are looking for any solution if exists in glibc similar to this. Please let us know. http://lists.uclibc.org/pipermail/uclibc/2013-September/047932.html Thanks, Prafulla -- View this message in context: http://gcc.1065356.n5.nabble.com/ARM-Linux-EABI-unwinding-through-a-segfault-handler-tp692287p1056478.html Sent from the gcc - Dev mailing list archive at Nabble.com.
Re: Build failure for sparc-sun-solaris2.10
Hi Art,
> I've had no luck building GCC on a Sparc-based Solaris machine here
> since early March - right around the time some LTO related patches
> landed. I've started trying again and the build fails when linking
> libgcc_so at the end of stage1. Here's the end of the build log:
>
> { ... snip ... }
> /bin/bash /export/home/arth/src/gcc.git/libgcc/../mkinstalldirs sparcv9
> mkdir -p -- sparcv9
> /export/home/arth/src/gcc-0731/./gcc/xgcc
> -B/export/home/arth/src/gcc-0731/./gcc/
> -B/export/home/arth/local/sparc-sun-solaris2.10/bin
> / -B/export/home/arth/local/sparc-sun-solaris2.10/lib/ -isystem
> /export/home/arth/local/sparc-sun-solaris2.10/include -isystem /expor
> t/home/arth/local/sparc-sun-solaris2.10/sys-include -O2 -g -O2 -DIN_GCC -W
> -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -W
> no-format -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition
> -isystem ./include -fPIC -g -DIN_LIBGCC2 -fbuilding-libg
> cc -fno-stack-protector -shared -nodefaultlibs -Wl,--soname=libgcc_s.so.1
> -Wl,--version-script=libgcc.map -o sparcv9/libgcc_s.so.1.t
> mp -g -O2 -m64 -B./ _muldi3_s.o _negdi2_s.o _lshrdi3_s.o _ashldi3_s.o
> _ashrdi3_s.o _cmpdi2_s.o _ucmpdi2_s.o _clear_cache_s.o _trampol
> ine_s.o __main_s.o _absvsi2_s.o _absvdi2_s.o _addvsi3_s.o _addvdi3_s.o
> _subvsi3_s.o _subvdi3_s.o _mulvsi3_s.o _mulvdi3_s.o _negvsi2_s
> .o _negvdi2_s.o _ctors_s.o _ffssi2_s.o _ffsdi2_s.o _clz_s.o _clzsi2_s.o
> _clzdi2_s.o _ctzsi2_s.o _ctzdi2_s.o _popcount_tab_s.o _popcou
> ntsi2_s.o _popcountdi2_s.o _paritysi2_s.o _paritydi2_s.o _powisf2_s.o
> _powidf2_s.o _powixf2_s.o _powitf2_s.o _mulsc3_s.o _muldc3_s.o
> _mulxc3_s.o _multc3_s.o _divsc3_s.o _divdc3_s.o _divxc3_s.o _divtc3_s.o
> _bswapsi2_s.o _bswapdi2_s.o _clrsbsi2_s.o _clrsbdi2_s.o _fixu
> nssfsi_s.o _fixunsdfsi_s.o _fixunsxfsi_s.o _fixsfdi_s.o _fixdfdi_s.o
> _fixxfdi_s.o _fixtfdi_s.o _fixunssfdi_s.o _fixunsdfdi_s.o _fixun
> sxfdi_s.o _fixunstfdi_s.o _floatdisf_s.o _floatdidf_s.o _floatdixf_s.o
> _floatditf_s.o _floatundisf_s.o _floatundidf_s.o _floatundixf_
> s.o _floatunditf_s.o _divdi3_s.o _moddi3_s.o _udivdi3_s.o _umoddi3_s.o
> _udiv_w_sdiv_s.o _udivmoddi4_s.o enable-execute-stack_s.o unwi
> nd-dw2_s.o unwind-dw2-fde-dip_s.o unwind-sjlj_s.o unwind-c_s.o emutls_s.o
> libgcc.a -lc && rm -f sparcv9/libgcc_s.so && if [ -f sparcv
> 9/libgcc_s.so.1 ]; then mv -f sparcv9/libgcc_s.so.1
> sparcv9/libgcc_s.so.1.backup; else true; fi && mv sparcv9/libgcc_s.so.1.tmp
> sparc
> v9/libgcc_s.so.1 && ln -s libgcc_s.so.1 sparcv9/libgcc_s.so
> collect2: fatal error: ld terminated with signal 10 [Bus Error], core dumped
> compilation terminated.
> gmake[5]: *** [libgcc_s.so] Error 1
> gmake[5]: Leaving directory
> `/export/home/arth/src/gcc-0731/sparc-sun-solaris2.1
> 0/sparcv9/libgcc'
> gmake[4]: *** [multi-do] Error 1
> gmake[4]: Leaving directory
> `/export/home/arth/src/gcc-0731/sparc-sun-solaris2.1
> 0/libgcc'
> gmake[3]: *** [all-multi] Error 2
> gmake[3]: *** Waiting for unfinished jobs
> gmake[3]: Leaving directory
> `/export/home/arth/src/gcc-0731/sparc-sun-solaris2.1
> 0/libgcc'
> gmake[2]: *** [all-stage1-target-libgcc] Error 2
> gmake[2]: Leaving directory `/export/home/arth/src/gcc-0731'
> gmake[1]: *** [stage1-bubble] Error 2
> gmake[1]: Leaving directory `/export/home/arth/src/gcc-0731'
> gmake: *** [bootstrap] Error 2
>
> The machine has the 2.24 release of GNU binutils installed. The crash
> leaves a core file which contains this backtrace:
>
> $ cd ~/src/gcc-0731/sparc-sun-solaris2.10/sparcv9/libgcc
> $ pstack core
> core 'core' of 20626: /export/home/arth/local/bin/ld -plugin
> /export/home/arth/src/gcc-0731/
> fbb54bc0 claim_file_handler (ffbfb664, ffbfb5fc, 0, 0, 0, 0) + 38
> 0003198c plugin_maybe_claim (ffbfb664, 186840, 2, 181000, 181000, 189220) +
> 6c
> 0002ecf0 ldfile_try_open_bfd (1, 186840, fbb43800, 0, 6, ffbfbf59) + 1b0
> 0002f3ec ldfile_open_file (186840, 1, e8070, fba563a0, fbb3e3c0, fbb485b8) +
> ac
> 00022560 load_symbols (186840, ffbfb7a0, , fff8, 0, 186840) + 20
> 000233a0 open_input_bfds (186840, 0, 1b174, 1, 1859ac, 1811ac) + 1a0
> 000259a4 lang_process (185800, 185800, 181000, 0, 181000, 1859d8) + a4
> 000129e4 main (185a64, 181000, 185800, 185ab8, 1859d8, 0) + 604
> 00012f9c _start (0, 0, 0, 0, 0, 0) + 5c
> $
>
> I hope the backtrace is helpful to some degree even though the crash is
> in the GNU 'ld' linker.
Not necessarily: claim_file_handler is most likely in lto-plugin.so,
which is from the gcc tree. I'd initially have said that any ld crash
is ld's fault, but this is probably different due to the plugin
involved. To investigate more closely, you'd have to run ld under gdb
and check what exactly is breaking here.
That said, I'm bootstrapping with gas/gld 2.24 on Solaris/SPARC all the
time, and it works fine for me. One important issue is that I configure
binutils with --enable-largefile to avoid the issues mentioned in PR
lto/50935.
> When looking over the mailing list archives I foun
GCC Developer Collaboration Patterns
Dear GCC Developers, The University of Passau is currently studying the mechanisms that contribute to effective collaboration in open-source projects so that appropriate tools and techniques are created to support the needs of open-source developers. To achieve this goal, we are evaluating the usefulness of software archives (e.g., mailing lists, version-control system, and bug tracker) to quantitatively model social relationships and collaborative patterns in open-source projects. The culmination of this effort is an open-source project called Codeface, which is a framework and web front-end for analyzing social and technical aspects of software development. To learn more about Codeface, please visit http://siemens.github.io/codeface. We are now recruiting open-source developers to participate in a short survey. The survey is composed of 4 questions and takes about *5 minutes* to complete. We ensure that all of your information will be kept confidential and will only be used for scientific research purposes. There is no commercial interest in the results. We are merely interested in learning about your collaborative experiences as an open-source developer. To access the survey, please click on the link below. http://rfhinf067.hs-regensburg.de:8080/login.html We highly appreciate your efforts, and we sincerely hope that you will take the time to participate. Upon completion of the survey, you may include your e-mail address so that we can send you the anonymized survey results. We would also like to express our gratitude for support from Siemens Corporate Research and University of Applied Sciences Regensburg. Sincerely, Mitchell Joblin PhD Student Department of Informatics and Mathematics University of Passau
Re: Prototype of a --report-bug option
On Tue, Jul 29, 2014 at 11:35 AM, David Malcolm wrote: > > At Cauldron on the Sunday morning there was a Release Management BoF > session, replacing the specRTL talk (does anyone know what happened to > the latter?) The specRTL presenter had to leave early for personal reasons. Ian
New GCC mirror
Hi, we set up a new GCC mirror for the community. URL: http://mirrors.concertpass.com/gcc/ Organization/Contact: ConcertPass (ad...@mirrors.concertpass.com) Location: United States, Michigan Please, add it to your mirror list page. Thanks
RE: Build failure for sparc-sun-solaris2.10
> Hi Art,
Hi. Thanks for helping me try to fix the build problem I'm seeing.
{ ... snip ... }
> Could be, see above. Apart from that, I wonder why you insist on using
> GNU ld on Solaris. install.texi strongly suggests to use the Solaris
> linker instead, and I stand by that advise.
> A couple of comments on those configure options: avoid everything not
> strictly necessary and stay with the defaults.
{ ... snip ... }
I had a small script which runs 'configure' and using GNU as/ld had worked. I've
adjusted the script so that GCC is configured to use Sun /usr/ccs/bin/ld instead
of the GNU ld binary, and I also got rid of '--enable-threads' and the
'--enable-libstdcxx-pch=no' options
With the adjustments to the configuration my build got past the 'libgcc_s.so'
error
I'd been seeing, and proceeded into the 'stage2' build before it failed:
libtool: link: /export/home/arth/src/gcc-0801/./prev-gcc/xgcc -B/export/home/ar
th/src/gcc-0801/./prev-gcc/ -B/export/home/arth/local/sparc-sun-solaris2.10/bin/
-B/export/home/arth/local/sparc-sun-solaris2.10/bin/ -B/export/home/arth/local/
sparc-sun-solaris2.10/lib/ -isystem /export/home/arth/local/sparc-sun-solaris2.1
0/include -isystem /export/home/arth/local/sparc-sun-solaris2.10/sys-include
-shared .libs/lto-plugin.o-static-libgcc -static-libstdc++ -static-libgcc .
./libiberty/pic/libiberty.a -Wl,-soname -Wl,liblto_plugin.so.0 -o .libs/liblto
_plugin.so.0.0.0
ld: warning: option -o appears more than once, first setting taken
ld: fatal: file liblto_plugin.so.0: open failed: No such file or directory
ld: fatal: File processing errors. No output written to .libs/liblto_plugin.so.0
.0.0
collect2: error: ld returned 1 exit status
gmake[4]: *** [liblto_plugin.la] Error 1
gmake[4]: Leaving directory `/export/home/arth/src/gcc-0801/lto-plugin'
I copied the failing link into a script, added a '-v' option to see what was
going
on, and the link command was this:
/export/home/arth/src/gcc-0801/./prev-gcc/collect2 -V -G -dy -z text -M
/export/home/arth/src/gcc-0801/./prev-gcc/libgcc-unwind.map -Y P,/lib:/usr/lib
-Qy -o .libs/liblto_plugin.so.0.0.0 /usr/lib/crti.o /usr/lib/values-Xa.o
/export/home/arth/src/gcc-0801/./prev-gcc/crtbegin.o
-L/export/home/arth/src/gcc-0801/./prev-gcc
-L/export/home/arth/local/sparc-sun-solaris2.10/bin
-L/export/home/arth/local/sparc-sun-solaris2.10/bin
-L/export/home/arth/local/sparc-sun-solaris2.10/lib .libs/lto-plugin.o
../libiberty/pic/libiberty.a -soname liblto_plugin.so.0 -lgcc -lgcc_eh -lc
-lgcc -lgcc_eh -lc /export/home/arth/src/gcc-0801/./prev-gcc/crtend.o
/usr/lib/crtn.o
ld: Software Generation Utilities - Solaris Link Editors: 5.10-1.490
ld: warning: option -o appears more than once, first setting taken
ld: fatal: file liblto_plugin.so.0: open failed: No such file or directory
ld: fatal: File processing errors. No output written to
.libs/liblto_plugin.so.0.0.0
collect2: error: ld returned 1 exit status
The warning about the '-o' option appearing twice was really strange until I
found out through some trial and error that the '-soname' option was the cause.
If I run that command above but use the '-h' option instead the shared object
links successfully:
$ /export/home/arth/src/gcc-0801/./prev-gcc/collect2 -V -G -dy -z text -M
/export/home/arth/src/gcc-0801/./prev-gcc/libgcc-unwind.map -Y P,/lib:/usr/lib
-Qy -o ./.libs/liblto_plugin.so.0.0.0 /usr/lib/crti.o /usr/lib/values-Xa.o
/export/home/arth/src/gcc-0801/./prev-gcc/crtbegin.o
-L/export/home/arth/src/gcc-0801/prev-gcc
-L/export/home/arth/local/sparc-sun-solaris-2.10/bin
-L/export/home/arth/local/sparc-sun-solaris-2.10/bin
-L/export/home/arth/local/sparc-sun-solaris-2.10/lib ./.libs/lto-plugin.o
../libiberty/pic/libiberty.a -h liblto_plugin.so.0 -lgcc -lgcc_eh -lc -lgcc
-lgcc_eh -lc /export/home/arth/src/gcc-0801/prev-gcc/crtend.o /usr/lib/crtn.o
ld: Software Generation Utilities - Solaris Link Editors: 5.10-1.490
$
I guess now the trick is figuring out how to have the collect2 program use '-h'
instead of '-soname' when it invokes the Sun linker. Suggestions?
Thanks in advance.
Art Haas
Re: devirt-34.C failing
Hi again,
On 08/01/2014 11:40 AM, Paolo Carlini wrote:
Hi,
is it known that the test is failing on many x86_64-linux targets?
FAIL: g++.dg/ipa/devirt-34.C -std=gnu++98 scan-ipa-dump devirt
"Targets that are not likely"
FAIL: g++.dg/ipa/devirt-34.C -std=gnu++11 scan-ipa-dump devirt
"Targets that are not likely"
FAIL: g++.dg/ipa/devirt-34.C -std=gnu++1y scan-ipa-dump devirt
"Targets that are not likely"
Just noticed that the very:
/* { dg-final { scan-ipa-dump "Targets that are not likely" "devirt" } } */
seems suspect: we don't have anything similar anywhere else...
Thanks,
Paolo.
