Bootstrap broken in libobjc/sendmsg.c
Hi today the bootstrap is broken, some sort of infinite recursion. A quick make gives the below. Thanks, Paolo. / libtool: compile: /home/paolo/Gcc/svn-dirs/trunk-build/./gcc/xgcc -B/home/paolo/Gcc/svn-dirs/trunk-build/./gcc/ -B/home/paolo/Gcc/svn-dirs/trunk-install/x86_64-unknown-linux-gnu/bin/ -B/home/paolo/Gcc/svn-dirs/trunk-install/x86_64-unknown-linux-gnu/lib/ -isystem /home/paolo/Gcc/svn-dirs/trunk-install/x86_64-unknown-linux-gnu/include -isystem /home/paolo/Gcc/svn-dirs/trunk-install/x86_64-unknown-linux-gnu/sys-include /scratch/Gcc/svn-dirs/trunk/libobjc/sendmsg.c -c -I. -I/scratch/Gcc/svn-dirs/trunk/libobjc -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -DIN_GCC -DIN_TARGET_LIBS -fno-strict-aliasing -fexceptions -I/scratch/Gcc/svn-dirs/trunk/libobjc/../gcc -I/scratch/Gcc/svn-dirs/trunk/libobjc/../gcc/config -I../.././gcc -I/scratch/Gcc/svn-dirs/trunk/libobjc/../libgcc -I../libgcc -I/scratch/Gcc/svn-dirs/trunk/libobjc/../include -fPIC -DPIC -o .libs/sendmsg.o xgcc: internal compiler error: Segmentation fault (program cc1) 0x40d04e execute /scratch/Gcc/svn-dirs/trunk/gcc/gcc.c:2864 0x40d18e do_spec_1 /scratch/Gcc/svn-dirs/trunk/gcc/gcc.c:4656 0x40f83b process_brace_body /scratch/Gcc/svn-dirs/trunk/gcc/gcc.c:5929 0x40f83b handle_braces /scratch/Gcc/svn-dirs/trunk/gcc/gcc.c:5843 0x40da61 do_spec_1 /scratch/Gcc/svn-dirs/trunk/gcc/gcc.c:5310 0x40f83b process_brace_body /scratch/Gcc/svn-dirs/trunk/gcc/gcc.c:5929 0x40f83b handle_braces /scratch/Gcc/svn-dirs/trunk/gcc/gcc.c:5843 0x40da61 do_spec_1 /scratch/Gcc/svn-dirs/trunk/gcc/gcc.c:5310 0x40d8be do_spec_1 /scratch/Gcc/svn-dirs/trunk/gcc/gcc.c:5415 0x40f83b process_brace_body /scratch/Gcc/svn-dirs/trunk/gcc/gcc.c:5929 0x40f83b handle_braces /scratch/Gcc/svn-dirs/trunk/gcc/gcc.c:5843 0x40da61 do_spec_1 /scratch/Gcc/svn-dirs/trunk/gcc/gcc.c:5310 0x40f83b process_brace_body /scratch/Gcc/svn-dirs/trunk/gcc/gcc.c:5929 0x40f83b handle_braces /scratch/Gcc/svn-dirs/trunk/gcc/gcc.c:5843 0x40da61 do_spec_1 /scratch/Gcc/svn-dirs/trunk/gcc/gcc.c:5310 0x40f83b process_brace_body /scratch/Gcc/svn-dirs/trunk/gcc/gcc.c:5929 0x40f83b handle_braces /scratch/Gcc/svn-dirs/trunk/gcc/gcc.c:5843 0x40da61 do_spec_1 /scratch/Gcc/svn-dirs/trunk/gcc/gcc.c:5310 0x40f83b process_brace_body /scratch/Gcc/svn-dirs/trunk/gcc/gcc.c:5929 0x40f83b handle_braces /scratch/Gcc/svn-dirs/trunk/gcc/gcc.c:5843
Re: Bootstrap broken in libobjc/sendmsg.c
.. looks like this is target/58269, which therefore affects x86_64-linux too. Paolo.
Re: Bootstrap broken in libobjc/sendmsg.c
. on x86_64-linux, this commit broke the build of that file: http://gcc.gnu.org/ml/gcc-cvs/2013-09/msg00149.html CC-ing Peter. Thanks, Paolo.
Re: Bootstrap broken in libobjc/sendmsg.c
On Fri, 2013-09-06 at 13:36 +0200, Paolo Carlini wrote: > . on x86_64-linux, this commit broke the build of that file: > > http://gcc.gnu.org/ml/gcc-cvs/2013-09/msg00149.html > > CC-ing Peter. Can you try the patch that HJ suggested? http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58139#c9 Peter
Re: Bootstrap broken in libobjc/sendmsg.c
Hi, On 09/06/2013 01:46 PM, Peter Bergner wrote: On Fri, 2013-09-06 at 13:36 +0200, Paolo Carlini wrote: . on x86_64-linux, this commit broke the build of that file: http://gcc.gnu.org/ml/gcc-cvs/2013-09/msg00149.html CC-ing Peter. Can you try the patch that HJ suggested? http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58139#c9 Thanks. It works, in the sense that the file compiles again for me and a quick build completes. Whether it's the right thing to do, I can't say of course. Paolo.
Re: Bootstrap broken in libobjc/sendmsg.c
> .. looks like this is target/58269, which therefore affects > x86_64-linux too. Now this reproduces to me, too. apppy_args expansion is trying to preserve AVX register in V8SF mode when AVX is disabled. This leads to move expander to not allow moving it and we end up infinitely recursing trying to expand the move. I am not sure what change triggered it. I am looking into fix. Honza
RE: Reusing OpenMP front end infrastructure for OpenACC -- how?
Hi, all!
My colleagues and I are going to share our initial support of OpenACC soon
(in a week, I hope). We're on stage of internal approval before making first
public commit, FE+BE patches are prepared already.
So, I think we need to discuss our future collaboration in case we all want
to implement ACC.
Our current status is the following:
- Fortran finished and applies OpenACC 1.0 specs - we're testing it
right now.
- C is mostly finished - in development
- C++ is on initial stage - in development
- Run-time library is finished
- Also we have prototype of OpenCL code generator as back-end
solution
- Tests for FE generated by script, and reduced to acceptable count.
For front-ends it was decided not to touch exciting OpenMP implementation
for now for the reason:
- perform refactoring with achieved understanding of what should be
done will be much easier, than merge it after global redesign and some bunch
of further development
I agree that there are some front-end specific things that can be reused by
OpenACC, but most of them are related to clauses processing.
For back-end, as was discussed earlier, we developed prototype of code
generator that emits OpenCL code for kernel/parallel directives and for
copy* clauses.
For today we can compile and execute simple test like these ones on GPU
using Intel's and Nvidia's CL drivers:
1 #include
2
3 #define SIZE 64
4
5 int main() {
6 int i;
7 float a[SIZE], b[SIZE], c[SIZE];
8
9 for (i = 0; i < SIZE; i++) {
10 a[i] = (i + 1) / 10.0;
11 b[i] = (SIZE - i) / 10.0;
12 }
13
14 for (i = 0; i < SIZE; i++) {
15 printf ("%f ", a[i]);
16 }
17 printf ("\n");
18
19 for (i = 0; i < SIZE; i++) {
20 printf ("%f ", b[i]);
21 }
22 printf ("\n");
23
24
25 #pragma acc kernels
26 for (i = 0; i < SIZE; i++) {
27 c[i] = a[i] / b[i];
28 }
29
30 for (i = 0; i < SIZE; i++) {
31 printf ("%f ", c[i]);
32 }
33 printf ("\n");
34
35 printf ("test finished\n");
36 return 0;
37 }
1 PROGRAM test
2 IMPLICIT NONE
3 INTEGER :: i
4 REAL :: a(64), b(64), c(64)
5
6 DO i = 1, 64
7 a(i) = (i)/10.0
8 b(i) = (64 - i + 1)/10.0
9 ENDDO
10
11 PRINT *, a
12 PRINT *, b
13
14 !$ACC KERNELS
15 DO i = 1, 64
16 c(i) = a(i)/b(i)
17 ENDDO
18 !$ACC END KERNELS
19
20 PRINT *, c
21 END PROGRAM test
-
Thanks, Evgeny.
-Original Message-
From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of
Jakub Jelinek
Sent: Thursday, September 05, 2013 7:02 PM
To: Thomas Schwinge
Cc: gcc@gcc.gnu.org
Subject: Re: Reusing OpenMP front end infrastructure for OpenACC -- how?
On Thu, Sep 05, 2013 at 04:51:14PM +0200, Thomas Schwinge wrote:
> Implementing OpenACC support in GCC's frontends, there are things that
> I trivially have to reimplement, that are already present for OpenMP.
> For example, the infrastructure for parsing clauses (as attached to
> OpenACC and OpenMP directives), and their representation in the GCC
> internal data structures. Given the syntactical similarity of OpenACC
> and OpenMP, this infrastructure is similar, too, if not even
> identical. Thus, my inner engineer tells me we ought to share this
> infrastructure instead of having a copy of it only different for
s%omp%oacc.
>
> For a specific example, I'd like to reuse everything known by
> omp_clause* and similar, and extend it with the things OpenACC does
> additionally/differently (adding safe-guards, if not already present,
> to the OpenMP code so that no clauses specific to OpenACC end up there).
Most of the omp-low.c code has asserts to verify no unknown clauses are
passed to it, and during parsing it has bitmasks of allowable clauses.
> Is this generally an accepted approach? If yes, should I rename omp*
> to, say, oacc_omp* (putting the OpenACC tag first for the simple
> reason that it sorts first alphabetically), or can we think of a
> better tag than oacc_omp, or should I leave the names as omp* and add
> comments that these things are used for OpenACC, too?
I think there is no point in renaming the existing stuff, we use it for some
Cilk+ stuff too these days, renaming could only complicate maintainance,
making it harder to backport OpenMP bugfixes to older release branches etc.
IMHO just use from the OpenMP parsing, trees and gimple stuff whatever is
usable for OpenACC too, and just for stuff that doesn't have counterparts
add oacc/OACC stuff.
Say, for clauses IMHO it is just fine if you use OMP_CLAUSE tree code, and
just add additional OACC_CLAUSE_SOMETHING, OACC_CLAUSE_SOMETHINGELSE etc.
to the list of omp clauses and descriptors, just put it likely at the end of
the list with a comment that it is OpenACC specific stuff. If some clause
is used with the same meaning in both standards, y
Re: Bootstrap broken in libobjc/sendmsg.c
> > .. looks like this is target/58269, which therefore affects > > x86_64-linux too. > > Now this reproduces to me, too. apppy_args expansion is trying to preserve > AVX > register in V8SF mode when AVX is disabled. This leads to move expander to > not > allow moving it and we end up infinitely recursing trying to expand the move. > I am not sure what change triggered it. I am looking into fix. I am testing the following. Obviously AVX mode is not OK for SSE reg when AVX is disabled. Other code paths allowing AVX modes seems to be propertly guarded. Index: config/i386/i386.c === --- config/i386/i386.c (revision 202322) +++ config/i386/i386.c (working copy) @@ -34466,7 +34471,7 @@ ix86_hard_regno_mode_ok (int regno, enum /* OImode move is available only when AVX is enabled. */ return ((TARGET_AVX && mode == OImode) - || VALID_AVX256_REG_MODE (mode) + || (TARGET_AVX && VALID_AVX256_REG_MODE (mode)) || VALID_SSE_REG_MODE (mode) || VALID_SSE2_REG_MODE (mode) || VALID_MMX_REG_MODE (mode)
Re: Bootstrap broken in libobjc/sendmsg.c
On Fri, Sep 06, 2013 at 02:38:01PM +0200, Jan Hubicka wrote: > > > .. looks like this is target/58269, which therefore affects > > > x86_64-linux too. > > > > Now this reproduces to me, too. apppy_args expansion is trying to preserve > > AVX > > register in V8SF mode when AVX is disabled. This leads to move expander to > > not > > allow moving it and we end up infinitely recursing trying to expand the > > move. > > I am not sure what change triggered it. I am looking into fix. > > I am testing the following. Obviously AVX mode is not OK for SSE reg > when AVX is disabled. Other code paths allowing AVX modes seems to be > propertly > guarded. Sounds like http://gcc.gnu.org/ml/gcc-bugs/2013-09/msg00308.html Please look at PR58139 and PR58269, various patches have been posted or attached for that. BTW, I wonder why this spot doesn't contain also (TARGET_AVX512F && VALID_AVX512F_REG_MODE (mode)) > --- config/i386/i386.c(revision 202322) > +++ config/i386/i386.c(working copy) > @@ -34466,7 +34471,7 @@ ix86_hard_regno_mode_ok (int regno, enum > >/* OImode move is available only when AVX is enabled. */ >return ((TARGET_AVX && mode == OImode) > - || VALID_AVX256_REG_MODE (mode) > + || (TARGET_AVX && VALID_AVX256_REG_MODE (mode)) > || VALID_SSE_REG_MODE (mode) > || VALID_SSE2_REG_MODE (mode) > || VALID_MMX_REG_MODE (mode) Jakub
Re: [ping] [buildrobot] gcc/config/linux-android.c:40:7: error: ‘OPTION_BIONIC’ was not declared in this scope
On Mon, 2013-08-26 12:51:53 +0200, Jan-Benedict Glaw wrote: > On Tue, 2013-08-20 11:24:31 +0400, Alexander Ivchenko > wrote: > > Hi, thanks for cathing this. > > > > I certainly missed that OPTION_BIONIC is not defined for linux targets > > that do not include config/linux.h in their tm.h. > > > > This patch fixed build for powerpc64le-linux and mn10300-linux. > > linux_libc, LIBC_GLIBC, LIBC_BIONIC should be defined for all targets. > [...] Seems the commit at Thu Sep 5 13:01:35 2013 (CEST) fixed most of the fallout. Thanks! > mn10300-linux: > http://toolchain.lug-owl.de/buildbot/showlog.php?id=9657&mode=view This however still seems to have issues in a current build: http://toolchain.lug-owl.de/buildbot/showlog.php?id=10520&mode=view g++ -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -I. -I. -I../../../../gcc/gcc -I../../../../gcc/gcc/. -I../../../../gcc/gcc/../include -I../../../../gcc/gcc/../libcpp/include -I../../../../gcc/gcc/../libdecnumber -I../../../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber -I../../../../gcc/gcc/../libbacktrace-I. -I. -I../../../../gcc/gcc -I../../../../gcc/gcc/. -I../../../../gcc/gcc/../include -I../../../../gcc/gcc/../libcpp/include -I../../../../gcc/gcc/../libdecnumber -I../../../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber -I../../../../gcc/gcc/../libbacktrace \ ../../../../gcc/gcc/config/linux-android.c ../../../../gcc/gcc/config/linux-android.c: In function ‘bool linux_android_libc_has_function(function_class)’: ../../../../gcc/gcc/config/linux-android.c:38:7: error: ‘OPTION_GLIBC’ was not declared in this scope if (OPTION_GLIBC) ^ ../../../../gcc/gcc/config/linux-android.c:40:7: error: ‘OPTION_BIONIC’ was not declared in this scope if (OPTION_BIONIC) ^ make[2]: *** [linux-android.o] Error 1 MfG, JBG -- Jan-Benedict Glaw jbg...@lug-owl.de +49-172-7608481 Signature of: Träume nicht von Deinem Leben: Lebe Deinen Traum! the second : signature.asc Description: Digital signature
Re: Bootstrap broken in libobjc/sendmsg.c
> On Fri, Sep 06, 2013 at 02:38:01PM +0200, Jan Hubicka wrote: > > > > .. looks like this is target/58269, which therefore affects > > > > x86_64-linux too. > > > > > > Now this reproduces to me, too. apppy_args expansion is trying to > > > preserve AVX > > > register in V8SF mode when AVX is disabled. This leads to move expander > > > to not > > > allow moving it and we end up infinitely recursing trying to expand the > > > move. > > > I am not sure what change triggered it. I am looking into fix. > > > > I am testing the following. Obviously AVX mode is not OK for SSE reg > > when AVX is disabled. Other code paths allowing AVX modes seems to be > > propertly > > guarded. > > Sounds like http://gcc.gnu.org/ml/gcc-bugs/2013-09/msg00308.html > Please look at PR58139 and PR58269, various patches have been posted or > attached for that. > > BTW, I wonder why this spot doesn't contain also > (TARGET_AVX512F && VALID_AVX512F_REG_MODE (mode)) I have tested and comitted the patch now. Hj, can you please look into the (TARGET_AVX512F && VALID_AVX512F_REG_MODE (mode)) issue? It seems like obvious omission but I can not test the patch. Honza > > > --- config/i386/i386.c (revision 202322) > > +++ config/i386/i386.c (working copy) > > @@ -34466,7 +34471,7 @@ ix86_hard_regno_mode_ok (int regno, enum > > > >/* OImode move is available only when AVX is enabled. */ > >return ((TARGET_AVX && mode == OImode) > > - || VALID_AVX256_REG_MODE (mode) > > + || (TARGET_AVX && VALID_AVX256_REG_MODE (mode)) > > || VALID_SSE_REG_MODE (mode) > > || VALID_SSE2_REG_MODE (mode) > > || VALID_MMX_REG_MODE (mode) > > Jakub
Re: Bootstrap broken in libobjc/sendmsg.c
On Fri, Sep 6, 2013 at 7:40 AM, Jan Hubicka wrote: >> On Fri, Sep 06, 2013 at 02:38:01PM +0200, Jan Hubicka wrote: >> > > > .. looks like this is target/58269, which therefore affects >> > > > x86_64-linux too. >> > > >> > > Now this reproduces to me, too. apppy_args expansion is trying to >> > > preserve AVX >> > > register in V8SF mode when AVX is disabled. This leads to move expander >> > > to not >> > > allow moving it and we end up infinitely recursing trying to expand the >> > > move. >> > > I am not sure what change triggered it. I am looking into fix. >> > >> > I am testing the following. Obviously AVX mode is not OK for SSE reg >> > when AVX is disabled. Other code paths allowing AVX modes seems to be >> > propertly >> > guarded. >> >> Sounds like http://gcc.gnu.org/ml/gcc-bugs/2013-09/msg00308.html >> Please look at PR58139 and PR58269, various patches have been posted or >> attached for that. >> >> BTW, I wonder why this spot doesn't contain also >> (TARGET_AVX512F && VALID_AVX512F_REG_MODE (mode)) > > I have tested and comitted the patch now. Hj, can you please look into the > (TARGET_AVX512F && VALID_AVX512F_REG_MODE (mode)) issue? It seems like > obvious > omission but I can not test the patch. There are if (TARGET_AVX512F && (mode == XImode || VALID_AVX512F_REG_MODE (mode) || VALID_AVX512F_SCALAR_MODE (mode))) return true; > Honza >> >> > --- config/i386/i386.c (revision 202322) >> > +++ config/i386/i386.c (working copy) >> > @@ -34466,7 +34471,7 @@ ix86_hard_regno_mode_ok (int regno, enum >> > >> >/* OImode move is available only when AVX is enabled. */ >> >return ((TARGET_AVX && mode == OImode) >> > - || VALID_AVX256_REG_MODE (mode) >> > + || (TARGET_AVX && VALID_AVX256_REG_MODE (mode)) >> > || VALID_SSE_REG_MODE (mode) >> > || VALID_SSE2_REG_MODE (mode) >> > || VALID_MMX_REG_MODE (mode) >> Or we can do return ((TARGET_AVX && VALID_AVX256_REG_OR_OI_MODE (mode)) || VALID_SSE_REG_MODE (mode) || VALID_SSE2_REG_MODE (mode) || VALID_MMX_REG_MODE (mode) || VALID_MMX_REG_MODE_3DNOW (mode)); -- H.J.
