Re: [PATCH] RE: libcilkrts/runtime/config/generic/cilk-abi-vla.c failure (was: [PATCH, committed] libcilkrts - Add check for availability of alloca.h (Bug Bootstrap/58918))
On Thu, Oct 31, 2013 at 03:21:14AM +, Iyer, Balaji V wrote: > It is because of this line: > > i[456]86-*-*) > config_dir="x86" > ;; > > It should include a 3 too. My bad sorry. I have fixed it. Attached, please > find a patch. It is committed as obvious. It is not just about not including 3, but also the []s in configure.ac were eaten by m4. In any case, shouldn't you fix also config/generic? Jakub
Re: [RFC] Detect most integer overflows.
On 30/10/13 16:56, Andrew Haley wrote: > On 10/30/2013 03:23 PM, David Brown wrote: >> I believe that's only a minor reason for making signed overflows >> undefined behaviour. If it were a matter of implementation, I think it >> would have been made "implementation defined" rather than "undefined", >> so that two's complement machines could use wrapping while other systems >> (which are very rare now) could have other defined overflow behaviour. >> >> The main reason (again, this is my guess - I don't know what the C >> standards folk /actually/ thought) is that there is no obvious "correct" >> behaviour for signed overflow > > A more important reason that having signed overflow undefined allows > a lot of powerful loop optimization algorithms. > Didn't I mention that? I certainly meant to! There was a recent discussion on comp.lang.c about this. I don't know how one could (or should) grade the relative importance of reasons, but certainly by having signed overflow as undefined you can enable many nice optimisations. These don't really turn up in "normal" code - how many people would explicitly write "if (i + 10 > i) ..."? But with inlining, templates, constant propagation, etc., this sort of code gets generated - and it is very nice that the compiler can optimise it. mvh., David
RE: [PATCH] RE: libcilkrts/runtime/config/generic/cilk-abi-vla.c failure (was: [PATCH, committed] libcilkrts - Add check for availability of alloca.h (Bug Bootstrap/58918))
> -Original Message- > From: Jakub Jelinek [mailto:ja...@redhat.com] > Sent: Thursday, October 31, 2013 3:46 AM > To: Iyer, Balaji V > Cc: Gerald Pfeifer; Jeff Law; gcc@gcc.gnu.org > Subject: Re: [PATCH] RE: libcilkrts/runtime/config/generic/cilk-abi-vla.c > failure > (was: [PATCH, committed] libcilkrts - Add check for availability of alloca.h > (Bug > Bootstrap/58918)) > > On Thu, Oct 31, 2013 at 03:21:14AM +, Iyer, Balaji V wrote: > > It is because of this line: > > > > i[456]86-*-*) > > config_dir="x86" > > ;; > > > > It should include a 3 too. My bad sorry. I have fixed it. Attached, please > > find a > patch. It is committed as obvious. > > It is not just about not including 3, but also the []s in configure.ac were > eaten by > m4. In any case, shouldn't you fix also config/generic? > I am in the process of fixing config/generic. I also replaced [456] with i?86. That should work fine right? > Jakub
Re: [PATCH] RE: libcilkrts/runtime/config/generic/cilk-abi-vla.c failure (was: [PATCH, committed] libcilkrts - Add check for availability of alloca.h (Bug Bootstrap/58918))
On Thu, Oct 31, 2013 at 01:32:19PM +, Iyer, Balaji V wrote: > > It is not just about not including 3, but also the []s in configure.ac were > > eaten by > > m4. In any case, shouldn't you fix also config/generic? > > > > I am in the process of fixing config/generic. I also replaced [456] with > i?86. That should work fine right? Yes. Jakub
Re: [PATCH] RE: libcilkrts/runtime/config/generic/cilk-abi-vla.c failure
Jakub Jelinek writes:
> On Thu, Oct 31, 2013 at 01:32:19PM +, Iyer, Balaji V wrote:
>> > It is not just about not including 3, but also the []s in configure.ac
>> > were eaten by
>> > m4. In any case, shouldn't you fix also config/generic?
>> >
>>
>> I am in the process of fixing config/generic. I also replaced [456] with
>> i?86. That should work fine right?
>
> Yes.
Even with that change, i386-pc-solaris2.11 bootstrap is broken in
libcilkrts in two different ways:
* Configuring the library fails for the 64-bit multilib: config.log
shows
configure:3105: checking whether the C++ compiler works
configure:3114: ./a.out
ld.so.1: a.out: fatal:
/var/gcc/regression/trunk/11-gcc/build/./gcc/libgcc_s.so.1: wrong ELF class:
ELFCLASS32
/vol/gcc/src/hg/trunk/local/libcilkrts/configure[3116]: eval: line 1: 4955:
Killed
configure:3118: $? = 265
configure:3125: error: in
`/var/gcc/regression/trunk/11-gcc/build/i386-pc-solaris2.11/amd64/libcilkrts':
configure:3127: error: cannot run C++ compiled programs.
There's no 64-bit libgcc_s.so.1 installed in the runtime linker's
default search path, and toplevel Makefile (via RPATH_ENVVAR) only
takes care of the default multilib. This is also reported for the
libgcj case in PR other/43445.
* Even after setting LD_LIBRARY_PATH_64 to work around this,
compilation fails for os-unix.c:
/vol/gcc/src/hg/trunk/local/libcilkrts/runtime/os-unix.c:66:5: error: #error
"Unsupported OS"
# error "Unsupported OS"
^
/vol/gcc/src/hg/trunk/local/libcilkrts/runtime/os-unix.c: In function
'__cilkrts_hardware_cpu_count':
/vol/gcc/src/hg/trunk/local/libcilkrts/runtime/os-unix.c:378:2: error: #error
"Unknown architecture"
#error "Unknown architecture"
^
/vol/gcc/src/hg/trunk/local/libcilkrts/runtime/os-unix.c: In function
'__cilkrts_yield':
/vol/gcc/src/hg/trunk/local/libcilkrts/runtime/os-unix.c:411:5: warning:
implicit declaration of function 'pthread_yield'
[-Wimplicit-function-declaration]
pthread_yield();
^
make[2]: *** [os-unix.lo] Error 1
The following patch fixes this:
2013-10-31 Rainer Orth
* runtime/os-unix.c [__sun__ && __svr4__]: Include .
(__cilkrts_hardware_cpu_count) [__sun__ && __svr4__]: Use sysconf.
(__cilkrts_yield) [__sun__ && __svr4__]: Use sched_yield.
diff --git a/libcilkrts/runtime/os-unix.c b/libcilkrts/runtime/os-unix.c
--- a/libcilkrts/runtime/os-unix.c
+++ b/libcilkrts/runtime/os-unix.c
@@ -62,6 +62,9 @@
# include
# include
# include
+// Solaris
+#elif defined __sun__ && defined __svr4__
+# include
#else
# error "Unsupported OS"
#endif
@@ -346,7 +349,7 @@ static int linux_get_affinity_count (int
COMMON_SYSDEP int __cilkrts_hardware_cpu_count(void)
{
-#if defined ANDROID
+#if defined ANDROID || (defined(__sun__) && defined(__svr4__))
return sysconf (_SC_NPROCESSORS_ONLN);
#elif defined __MIC__
/// HACK: Usually, the 3rd and 4th hyperthreads are not beneficial
@@ -401,9 +404,9 @@ COMMON_SYSDEP void __cilkrts_yield(void)
// giving up the processor and latency starting up when work becomes
// available
_mm_delay_32(1024);
-#elif defined(ANDROID)
-// On Android, call sched_yield to yield quantum. I'm not sure why we
-// don't do this on Linux also.
+#elif defined(ANDROID) || (defined(__sun__) && defined(__svr4__))
+// On Android and Solaris, call sched_yield to yield quantum. I'm not
+// sure why we don't do this on Linux also.
sched_yield();
#else
// On Linux, call pthread_yield (which in turn will call sched_yield)
Rainer
--
-
Rainer Orth, Center for Biotechnology, Bielefeld University
Question about a fix for PR 58925
Hello Everyone, I am currently looking to fix the bug reported in PR 58925. Here is the issue, When the user configures using the following command: ../gcc/configure --enable-version-specific-runtime-libs --disable-bootstrap --disable-werror --disable-multilib --enable-languages=c,c++ Make is OK, but when they do make install: here is the output we get /include" "AR=/usr/x86_64-pc-linux-gnu/bin/ar" "AS=/var/tmp/gcc_build_dir/./gcc/as" "LD=/var/tmp/gcc_build_dir/./gcc/collect-ld" "LIBCFLAGS=-g -O2" "NM=/var/tmp/gcc_build_dir/./gcc/nm" "PICFLAG=" "RANLIB=/usr/x86_64-pc-linux-gnu/bin/ranlib" "DESTDIR=" DO=install multi-do # make test -z "/usr/lib/gcc/x86_64-pc-linux-gnu/" || /bin/mkdir -p "/usr/lib/gcc/x86_64-pc-linux-gnu/" /bin/sh ./libtool --mode=install /usr/bin/install -c libcilkrts.la '/usr/lib/gcc/x86_64-pc-linux-gnu/' libtool: install: error: cannot install `libcilkrts.la' to a directory not ending in /usr/lib/gcc/x86_64-pc-linux-gnu/ I googled the error, but most of them seem to say the issue is in libtool and doing a make clean before make would fix it. I tried that and it is not fixing it. Can someone please give me a suggestion as to where/what I should look for? Thanks, Balaji V. Iyer.
Re: [RFC] Target compilation for offloading
Let's check my understanding: 1) We can configure gcc with, say, --offload-target=mic,ptx. It means that after build and install we have 3 compilers: for host, for mic and for ptx. In general case, the number may be less, because one compiler may suit more than one target/host (e.g.when host and one of the targets both x86). All compilers are located together in 'prefix' directory, so host compiler will find target gcc there just by name. 2) Also, we can set option -foffload-target=hsail -B. It tells gcc to create offload binary for hsail too, besides mic and ptx we've selected in configure. Hsail compiler should be installed separately and can be found by name in directory we set in '-B' option. If there is no right compiler there and in 'prefix' directory, gcc throws error. The thing which is not quite clear for me is your way of compiler options ammending. For example, I want to use knc compiler for offload on mic, so target name is something like x86_64-k1om-linux. However, I don't want to select offload target during configuration, I just use compiler option: -foffload-target=x86_64-k1om-linux. How will gcc recognize option like -foffload-target-x86_64-k1om-linux= if offload target hasn't been set during configuration? On Tue, Oct 29, 2013 at 1:49 PM, Jakub Jelinek wrote: > On Tue, Oct 29, 2013 at 01:33:17PM +0400, Andrey Turetskiy wrote: >> I wonder how compiler is going to choose which target binaries should >> be created for offload? Will compiler make choice on its own or it is >> the user who should add specific options like --offload-target=... >> How does compiler know paths to target compilers? Will it use >> environment variables or paths will be set during compiler >> configuration? > > That needs to be designed. I'd say best would be to allow the default > set of target compilers (if any at all) to be specified during configure, > allow the user to override on the command line and look for the target > compilers using similar mechanism as we use for looking for libraries, > compiler binaries, ld, as etc. in the gcc driver, with possibility to > override it say through GCC specs or -B. Note that also there needs to be > a way to ammend compiler options for the individual targets (already talked > about this earlier in some offloading thread on the mailing list). So, > say if the corresponding host CU is compiled with -O3 -fopenmp -mavx > -mtune=core-avx2, likely you want by default to use -O3 -fopenmp for the > target compilation of the target portion of the CU, but not with the -m* > options, but instead you should be able to specify -mwhatever-else that > is appended after the options copied from the host compilation. > So, I'd like to see that at configure time you specify say that you don't > want any offloading support at all by default, or say mic + ptx (but leave > hsail out), etc., and be able to then say > -foffload-target=mic,hsail -foffload-target-mic=-mbar,-mbaz > -foffload-target-hsail=-mfroboz > (what exact strings to use instead of mic and hsail and ptx I guess depends > on what will be the configuration triplets for those). > > Jakub -- Best regards, Andrey Turetskiy
Re: Question about a fix for PR 58925
on a related note, is there something I have to do to make the compiler bootstrap on x86_64? on x86_64 I checked out a fresh branch this morning, and my bootstrap fails trying to configure cilk runtime. It was doing it yesterday to me when I updated, so I tried a fresh checkout this morning.. same thing. its actually just configured pretty blandly on x86_64-unknown-linux-gnu... /gcc/2013-10-31/gcc/configure --verbose --prefix=/gcc/2013-10-31/install Checking multilib configuration for libcilkrts...(1) make[2]: Entering directory `/gcc/2013-10-31/build/x86_64-unknown-linux-gnu/libcilkrts' /bin/sh ./libtool --tag=CC --mode=compile /gcc/2013-10-31/build/./gcc/xgcc -B/gcc/2013-10-31/build/./gcc/ -B/gcc/2013-10-31/install/x86_64-unknown-linux-gnu/bin/ -B/gcc/2013-10-31/install/x86_64-unknown-linux-gnu/lib/ -isystem /gcc/2013-10-31/install/x86_64-unknown-linux-gnu/include -isystem /gcc/2013-10-31/install/x86_64-unknown-linux-gnu/sys-include -DPACKAGE_NAME=\"Cilk\ Runtime\ Library\" -DPACKAGE_TARNAME=\"cilk-runtime-library\" -DPACKAGE_VERSION=\"2.0\" -DPACKAGE_STRING=\"Cilk\ Runtime\ Library\ 2.0\" -DPACKAGE_BUGREPORT=\"c...@intel.com\" -DPACKAGE_URL=\"\" -DPACKAGE=\"cilk-runtime-library\" -DVERSION=\"2.0\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_ALLOCA_H=1 -DHAVE_ALLOCA=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -I. -I/gcc/2013-10-31/gcc/libcilkrts -I/gcc/2013-10-31/gcc/libcilkrts/include -I/gcc/2013-10-31/gcc/libcilkrts/runtime -I/gcc/2013-10-31/gcc/libcilkrts/runtime/config/x86 -DIN_CILK_RUNTIME=1 -D_Cilk_spawn="" -D_Cilk_sync="" -D_Cilk_for=for -fcilkplus -I/gcc/2013-10-31/gcc/libcilkrts/include -I/gcc/2013-10-31/gcc/libcilkrts/runtime -I/gcc/2013-10-31/gcc/libcilkrts/runtime/config/x86 -DIN_CILK_RUNTIME=1 -D_Cilk_spawn="" -D_Cilk_sync="" -D_Cilk_for=for -fcilkplus -std=c99 -g -O2 -MT cilk-abi-vla.lo -MD -MP -MF .deps/cilk-abi-vla.Tpo -c -o cilk-abi-vla.lo `test -f 'runtime/config/x86/cilk-abi-vla.c' || echo '/gcc/2013-10-31/gcc/libcilkrts/'`runtime/config/x86/cilk-abi-vla.c /bin/sh: ./libtool: No such file or directory make[2]: *** [cilk-abi-vla.lo] Error 127 make[2]: Leaving directory `/gcc/2013-10-31/build/x86_64-unknown-linux-gnu/libcilkrts' make[1]: *** [all-target-libcilkrts] Error 2 make[1]: Leaving directory `/gcc/2013-10-31/build' make: *** [all] Error 2 Andrew
RE: Question about a fix for PR 58925
> -Original Message- > From: Andrew MacLeod [mailto:amacl...@redhat.com] > Sent: Thursday, October 31, 2013 11:44 AM > To: Iyer, Balaji V > Cc: 'gcc@gcc.gnu.org'; Jeff Law > Subject: Re: Question about a fix for PR 58925 > > on a related note, is there something I have to do to make the compiler > bootstrap on x86_64? > > on x86_64 I checked out a fresh branch this morning, and my bootstrap fails > trying to configure cilk runtime. It was doing it yesterday to me when I > updated, > so I tried a fresh checkout this morning.. same thing. > > its actually just configured pretty blandly on x86_64-unknown-linux-gnu... > /gcc/2013-10-31/gcc/configure --verbose --prefix=/gcc/2013-10-31/install > That should just work. Let me look into this and get back to you. It bootstrapped for me correctly yesterday. Thanks, Balaji V. Iyer. > > Checking multilib configuration for libcilkrts...(1) > make[2]: Entering directory > `/gcc/2013-10-31/build/x86_64-unknown-linux-gnu/libcilkrts' > /bin/sh ./libtool --tag=CC --mode=compile > /gcc/2013-10-31/build/./gcc/xgcc -B/gcc/2013-10-31/build/./gcc/ -B/gcc/2013- > 10-31/install/x86_64-unknown-linux-gnu/bin/ > -B/gcc/2013-10-31/install/x86_64-unknown-linux-gnu/lib/ -isystem /gcc/2013- > 10-31/install/x86_64-unknown-linux-gnu/include -isystem /gcc/2013-10- > 31/install/x86_64-unknown-linux-gnu/sys-include > -DPACKAGE_NAME=\"Cilk\ Runtime\ Library\" > -DPACKAGE_TARNAME=\"cilk-runtime-library\" -DPACKAGE_VERSION=\"2.0\" > -DPACKAGE_STRING=\"Cilk\ Runtime\ Library\ 2.0\" > -DPACKAGE_BUGREPORT=\"c...@intel.com\" -DPACKAGE_URL=\"\" > -DPACKAGE=\"cilk-runtime-library\" -DVERSION=\"2.0\" -DSTDC_HEADERS=1 > -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 > -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 > -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 > -DHAVE_ALLOCA_H=1 -DHAVE_ALLOCA=1 -DHAVE_DLFCN_H=1 - > DLT_OBJDIR=\".libs/\" -I. -I/gcc/2013-10-31/gcc/libcilkrts -I/gcc/2013-10- > 31/gcc/libcilkrts/include > -I/gcc/2013-10-31/gcc/libcilkrts/runtime > -I/gcc/2013-10-31/gcc/libcilkrts/runtime/config/x86 -DIN_CILK_RUNTIME=1 - > D_Cilk_spawn="" -D_Cilk_sync="" -D_Cilk_for=for -fcilkplus -I/gcc/2013-10- > 31/gcc/libcilkrts/include > -I/gcc/2013-10-31/gcc/libcilkrts/runtime > -I/gcc/2013-10-31/gcc/libcilkrts/runtime/config/x86 -DIN_CILK_RUNTIME=1 - > D_Cilk_spawn="" -D_Cilk_sync="" -D_Cilk_for=for -fcilkplus -std=c99 -g > -O2 -MT cilk-abi-vla.lo -MD -MP -MF .deps/cilk-abi-vla.Tpo -c -o > cilk-abi-vla.lo > `test -f 'runtime/config/x86/cilk-abi-vla.c' || echo '/gcc/2013-10- > 31/gcc/libcilkrts/'`runtime/config/x86/cilk-abi-vla.c > /bin/sh: ./libtool: No such file or directory > make[2]: *** [cilk-abi-vla.lo] Error 127 > make[2]: Leaving directory > `/gcc/2013-10-31/build/x86_64-unknown-linux-gnu/libcilkrts' > make[1]: *** [all-target-libcilkrts] Error 2 > make[1]: Leaving directory `/gcc/2013-10-31/build' > make: *** [all] Error 2 > > > Andrew
Re: Question about a fix for PR 58925
On 10/31/2013 12:05 PM, Iyer, Balaji V wrote: -Original Message- From: Andrew MacLeod [mailto:amacl...@redhat.com] Sent: Thursday, October 31, 2013 11:44 AM To: Iyer, Balaji V Cc: 'gcc@gcc.gnu.org'; Jeff Law Subject: Re: Question about a fix for PR 58925 on a related note, is there something I have to do to make the compiler bootstrap on x86_64? on x86_64 I checked out a fresh branch this morning, and my bootstrap fails trying to configure cilk runtime. It was doing it yesterday to me when I updated, so I tried a fresh checkout this morning.. same thing. its actually just configured pretty blandly on x86_64-unknown-linux-gnu... /gcc/2013-10-31/gcc/configure --verbose --prefix=/gcc/2013-10-31/install That should just work. Let me look into this and get back to you. It bootstrapped for me correctly yesterday. Jakub says it does for him too... So Im not sure what he scoop is. And it turns out it does work on a different x86 box I have. This is a pretty vanilla fedora 18.. huh. I'll keep poking, especially now that i have aworking version I can compare the config.log files
weird logic about redeclaring builtins...
Given the logic in c/c-decl.c's diagnose_mismatched_decls, if a built-in function is *also* declared in a system header (which is common with newlib), gcc fails to mention either the builtin or the declaration if you redeclare the function as something else. I.e. this code: int foo(); int foo; gives the expected "previous declaration was at ..." error, and this code: int index; gives the expected "built-in function 'index' declared ..." error. However, this code: char *index(const char *,int); int index; gives neither the built-in error nor the previous-decl error. It *only* gives the "'index' was redeclared" error. Is this intentional? Is there an easy fix for this that works for all cases?
Re: [RFC] Detect most integer overflows.
On 10/31/2013 08:02 AM, David Brown wrote: > On 30/10/13 16:56, Andrew Haley wrote: >> On 10/30/2013 03:23 PM, David Brown wrote: >>> I believe that's only a minor reason for making signed overflows >>> undefined behaviour. If it were a matter of implementation, I think it >>> would have been made "implementation defined" rather than "undefined", >>> so that two's complement machines could use wrapping while other systems >>> (which are very rare now) could have other defined overflow behaviour. >>> >>> The main reason (again, this is my guess - I don't know what the C >>> standards folk /actually/ thought) is that there is no obvious "correct" >>> behaviour for signed overflow >> >> A more important reason that having signed overflow undefined allows >> a lot of powerful loop optimization algorithms. > > Didn't I mention that? I certainly meant to! > > There was a recent discussion on comp.lang.c about this. I don't know > how one could (or should) grade the relative importance of reasons, but > certainly by having signed overflow as undefined you can enable many > nice optimisations. These don't really turn up in "normal" code They do: for (int i = 0; i < 5; i ++) a(p + i * 10); -> for (int p1 = p; p1 < p + 50; p1 += 10) a(p1); Andrew.
Re: Question about a fix for PR 58925
On 10/31/2013 12:13 PM, Andrew MacLeod wrote: On 10/31/2013 12:05 PM, Iyer, Balaji V wrote: -Original Message- From: Andrew MacLeod [mailto:amacl...@redhat.com] Sent: Thursday, October 31, 2013 11:44 AM To: Iyer, Balaji V Cc: 'gcc@gcc.gnu.org'; Jeff Law Subject: Re: Question about a fix for PR 58925 on a related note, is there something I have to do to make the compiler bootstrap on x86_64? on x86_64 I checked out a fresh branch this morning, and my bootstrap fails trying to configure cilk runtime. It was doing it yesterday to me when I updated, so I tried a fresh checkout this morning.. same thing. its actually just configured pretty blandly on x86_64-unknown-linux-gnu... /gcc/2013-10-31/gcc/configure --verbose --prefix=/gcc/2013-10-31/install That should just work. Let me look into this and get back to you. It bootstrapped for me correctly yesterday. Jakub says it does for him too... So Im not sure what he scoop is. And it turns out it does work on a different x86 box I have. This is a pretty vanilla fedora 18.. huh. I'll keep poking, especially now that i have aworking version I can compare the config.log files Very strange... the only real difference is that libtool commands are not executed on my fedora 18 box, resulting in no ./libtool to execute.. from the log: ## -- ## ## Running config.status. ## ## -- ## This file was extended by Cilk Runtime Library config.status 2.0, which was generated by GNU Autoconf 2.64. Invocation command line was CONFIG_FILES= CONFIG_HEADERS = CONFIG_LINKS= CONFIG_COMMANDS = $ ./config.status on x220 config.status:1093: creating Makefile config.status:1249: executing depfiles commands config.status:1249: executing default-1 commands ## ## ## Cache variables. ## ## ## Whereas the is one additional line on my box that does work: config.status:1093: creating Makefile config.status:1249: executing depfiles commands config.status:1249: executing default-1 command config.status:1249: executing libtool commands There isnt much difference in the log or status files... nothing real obvious. ie, no fails or anything... still looking... I *hate* configuration crud. sigh. Andrew
Re: [RFC] Detect most integer overflows.
On 31/10/13 17:51, Andrew Haley wrote: On 10/31/2013 08:02 AM, David Brown wrote: On 30/10/13 16:56, Andrew Haley wrote: On 10/30/2013 03:23 PM, David Brown wrote: I believe that's only a minor reason for making signed overflows undefined behaviour. If it were a matter of implementation, I think it would have been made "implementation defined" rather than "undefined", so that two's complement machines could use wrapping while other systems (which are very rare now) could have other defined overflow behaviour. The main reason (again, this is my guess - I don't know what the C standards folk /actually/ thought) is that there is no obvious "correct" behaviour for signed overflow A more important reason that having signed overflow undefined allows a lot of powerful loop optimization algorithms. Didn't I mention that? I certainly meant to! There was a recent discussion on comp.lang.c about this. I don't know how one could (or should) grade the relative importance of reasons, but certainly by having signed overflow as undefined you can enable many nice optimisations. These don't really turn up in "normal" code They do: for (int i = 0; i < 5; i ++) a(p + i * 10); -> for (int p1 = p; p1 < p + 50; p1 += 10) a(p1); Andrew. I hadn't thought of that sort of thing - thanks. Maybe I'll annoy the comp.lang.c folks by resurrecting that thread with more cases! David
RE: Question about a fix for PR 58925
> -Original Message- > From: Andrew MacLeod [mailto:amacl...@redhat.com] > Sent: Thursday, October 31, 2013 12:14 PM > To: Iyer, Balaji V > Cc: 'gcc@gcc.gnu.org'; Jeff Law > Subject: Re: Question about a fix for PR 58925 > > On 10/31/2013 12:05 PM, Iyer, Balaji V wrote: > > > >> -Original Message- > >> From: Andrew MacLeod [mailto:amacl...@redhat.com] > >> Sent: Thursday, October 31, 2013 11:44 AM > >> To: Iyer, Balaji V > >> Cc: 'gcc@gcc.gnu.org'; Jeff Law > >> Subject: Re: Question about a fix for PR 58925 > >> > >> on a related note, is there something I have to do to make the > >> compiler bootstrap on x86_64? > >> > >> on x86_64 I checked out a fresh branch this morning, and my bootstrap > >> fails trying to configure cilk runtime. It was doing it yesterday to > >> me when I updated, so I tried a fresh checkout this morning.. same thing. > >> > >> its actually just configured pretty blandly on x86_64-unknown-linux-gnu... > >> /gcc/2013-10-31/gcc/configure --verbose > >> --prefix=/gcc/2013-10-31/install > >> > > That should just work. Let me look into this and get back to you. It > bootstrapped for me correctly yesterday. > > > > Jakub says it does for him too... So Im not sure what he scoop is. > And it turns out it does work on a different x86 box I have. > This is a pretty vanilla fedora 18.. huh. I'll keep poking, especially now > that i > have aworking version I can compare the config.log files > I have tried it on my Ubuntu and Suse machine. Both seem to work fine. Let me see if I can track down a Fedora machine...
Re: Question about a fix for PR 58925
On 10/31/2013 01:02 PM, Andrew MacLeod wrote: On 10/31/2013 12:13 PM, Andrew MacLeod wrote: There isnt much difference in the log or status files... nothing real obvious. ie, no fails or anything... still looking... I *hate* configuration crud. sigh. Andrew OK, hacking around with configure, I find that in the libcilk.rts configure, it tests for the c++ compiler to find the default extenstion, and builds a.out. Then around line 3106 where it checks "checking whether the C++ compiler works...", it executes the binary via: ac_try='./$ac_file' If I do all this by hand and build the c++ conftest.c file, the command line looks like: /gcc/2013-10-31/build/./gcc/xg++ -B/gcc/2013-10-31/build/./gcc/ -nostdinc++ -nostdinc++ -I/gcc/2013-10-31/build/x86_64-unknown-linux-gnu/32/libstdc++-v3/include/x86_64-unknown-linux-gnu -I/gcc/2013-10-31/build/x86_64-unknown-linux-gnu/32/libstdc++-v3/include -I/gcc/2013-10-31/gcc/libstdc++-v3/libsupc++ -I/gcc/2013-10-31/gcc/libstdc++-v3/include/backward -I/gcc/2013-10-31/gcc/libstdc++-v3/testsuite/util -L/gcc/2013-10-31/build/x86_64-unknown-linux-gnu/32/libstdc++-v3/src -L/gcc/2013-10-31/build/x86_64-unknown-linux-gnu/32/libstdc++-v3/src/.libs -L/gcc/2013-10-31/build/x86_64-unknown-linux-gnu/32/libstdc++-v3/libsupc++/.libs -B/gcc/2013-10-31/install/x86_64-unknown-linux-gnu/bin/ -B/gcc/2013-10-31/install/x86_64-unknown-linux-gnu/lib/ -isystem /gcc/2013-10-31/install/x86_64-unknown-linux-gnu/include -isystem /gcc/2013-10-31/install/x86_64-unknown-linux-gnu/sys-include -m32 -g -O2 -D_GNU_SOURCE conftest.c if I try to run a.out generated by hand, I get: ./a.out: error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory So it thinks my c++ compiler doesn't work If I change that compile command to NOT use -m32 and the 32bit subdirectories, then it works fine. so the problem seems to be related to the 32 bit side of things. ldd indicates that the a.out executable does not have libstdc++.so.6 => not found but the file is in the correct directory: /gcc/2013-10-31/build/x86_64-unknown-linux-gnu/32/libstdc++-v3/src/.libs/libstdc++.so -> libstdc++.so.6.0.19 /gcc/2013-10-31/build/x86_64-unknown-linux-gnu/32/libstdc++-v3/src/.libs/libstdc++.so.6 -> libstdc++.so.6.0.19 /gcc/2013-10-31/build/x86_64-unknown-linux-gnu/32/libstdc++-v3/src/.libs/libstdc++.so.6.0.19 Im still poking around at it. very odd. Andrew...
Re: Question about a fix for PR 58925
On 10/31/2013 03:31 PM, Andrew MacLeod wrote: On 10/31/2013 01:02 PM, Andrew MacLeod wrote: On 10/31/2013 12:13 PM, Andrew MacLeod wrote: but the file is in the correct directory: /gcc/2013-10-31/build/x86_64-unknown-linux-gnu/32/libstdc++-v3/src/.libs/libstdc++.so -> libstdc++.so.6.0.19 /gcc/2013-10-31/build/x86_64-unknown-linux-gnu/32/libstdc++-v3/src/.libs/libstdc++.so.6 -> libstdc++.so.6.0.19 /gcc/2013-10-31/build/x86_64-unknown-linux-gnu/32/libstdc++-v3/src/.libs/libstdc++.so.6.0.19 Im still poking around at it. very odd. Andrew... OK, so libcilkrts will not configure properly without libstdc++.i686 in the system .. so somewhere in the configury magic its falling back on the system libstdc++ library, and won't work without it. My little test program worked fine when I added export LD_LIBRARY_PATH=/gcc/2013-10-31/build/x86_64-unknown-linux-gnu/32/libstdc++-v3/src/.libs:/gcc/2013-10-31/build/./gcc/32/ to pick up the 2 shared libraries... so I presume LD_LIBRARY_PATH needs to be set by your configure stuff in order to work. You should be able to test this by uninstalling libstdc++.i686 ona 64 bit machine and configuring. I didn;'t have it, and when I did add it, everything works fine. Andrew
Re: Question about a fix for PR 58925
On Thu, Oct 31, 2013 at 04:10:51PM -0400, Andrew MacLeod wrote:
> On 10/31/2013 03:31 PM, Andrew MacLeod wrote:
> >On 10/31/2013 01:02 PM, Andrew MacLeod wrote:
> >>On 10/31/2013 12:13 PM, Andrew MacLeod wrote:
> >
> >but the file is in the correct directory:
> >/gcc/2013-10-31/build/x86_64-unknown-linux-gnu/32/libstdc++-v3/src/.libs/libstdc++.so
> >-> libstdc++.so.6.0.19
> >/gcc/2013-10-31/build/x86_64-unknown-linux-gnu/32/libstdc++-v3/src/.libs/libstdc++.so.6
> >-> libstdc++.so.6.0.19
> >/gcc/2013-10-31/build/x86_64-unknown-linux-gnu/32/libstdc++-v3/src/.libs/libstdc++.so.6.0.19
> >
> >
> >
> >Im still poking around at it. very odd.
> >
> >Andrew...
> >
> OK, so libcilkrts will not configure properly without libstdc++.i686
> in the system .. so somewhere in the configury magic its falling
> back on the system libstdc++ library, and won't work without it.
>
> My little test program worked fine when I added
> export
> LD_LIBRARY_PATH=/gcc/2013-10-31/build/x86_64-unknown-linux-gnu/32/libstdc++-v3/src/.libs:/gcc/2013-10-31/build/./gcc/32/
>
> to pick up the 2 shared libraries... so I presume LD_LIBRARY_PATH
> needs to be set by your configure stuff in order to work.
>
>
> You should be able to test this by uninstalling libstdc++.i686 ona
> 64 bit machine and configuring. I didn;'t have it, and when I did
> add it, everything works fine.
I guess have a look at libsanitizer/configure.ac, it contains e.g.
# Do not delete or change the following two lines. For why, see
# http://gcc.gnu.org/ml/libstdc++/2003-07/msg00451.html
AC_CANONICAL_SYSTEM
target_alias=${target_alias-$host_alias}
AC_SUBST(target_alias)
GCC_LIBSTDCXX_RAW_CXX_FLAGS
and also --enable-version-specific-runtime-libs, I guess you want both.
Perhaps there is also some other magic why libsanitizer AC_PROG_CXX
works and libcilkrts doesn't.
Jakub
RE: [PATCH] RE: libcilkrts/runtime/config/generic/cilk-abi-vla.c failure
Hi Rainer, This patch looks OK. Thanks, Balaji V. Iyer. -Original Message- From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of Rainer Orth Sent: Thursday, October 31, 2013 10:02 AM To: Jakub Jelinek Cc: Iyer, Balaji V; Gerald Pfeifer; Jeff Law; gcc@gcc.gnu.org Subject: Re: [PATCH] RE: libcilkrts/runtime/config/generic/cilk-abi-vla.c failure Jakub Jelinek writes: > On Thu, Oct 31, 2013 at 01:32:19PM +, Iyer, Balaji V wrote: >> > It is not just about not including 3, but also the []s in >> > configure.ac were eaten by m4. In any case, shouldn't you fix also >> > config/generic? >> > >> >> I am in the process of fixing config/generic. I also replaced [456] >> with i?86. That should work fine right? > > Yes. Even with that change, i386-pc-solaris2.11 bootstrap is broken in libcilkrts in two different ways: * Configuring the library fails for the 64-bit multilib: config.log shows configure:3105: checking whether the C++ compiler works configure:3114: ./a.out ld.so.1: a.out: fatal: /var/gcc/regression/trunk/11-gcc/build/./gcc/libgcc_s.so.1: wrong ELF class: ELFCLASS32 /vol/gcc/src/hg/trunk/local/libcilkrts/configure[3116]: eval: line 1: 4955: Killed configure:3118: $? = 265 configure:3125: error: in `/var/gcc/regression/trunk/11-gcc/build/i386-pc-solaris2.11/amd64/libcilkrts': configure:3127: error: cannot run C++ compiled programs. There's no 64-bit libgcc_s.so.1 installed in the runtime linker's default search path, and toplevel Makefile (via RPATH_ENVVAR) only takes care of the default multilib. This is also reported for the libgcj case in PR other/43445. * Even after setting LD_LIBRARY_PATH_64 to work around this, compilation fails for os-unix.c: /vol/gcc/src/hg/trunk/local/libcilkrts/runtime/os-unix.c:66:5: error: #error "Unsupported OS" # error "Unsupported OS" ^ /vol/gcc/src/hg/trunk/local/libcilkrts/runtime/os-unix.c: In function '__cilkrts_hardware_cpu_count': /vol/gcc/src/hg/trunk/local/libcilkrts/runtime/os-unix.c:378:2: error: #error "Unknown architecture" #error "Unknown architecture" ^ /vol/gcc/src/hg/trunk/local/libcilkrts/runtime/os-unix.c: In function '__cilkrts_yield': /vol/gcc/src/hg/trunk/local/libcilkrts/runtime/os-unix.c:411:5: warning: implicit declaration of function 'pthread_yield' [-Wimplicit-function-declaration] pthread_yield(); ^ make[2]: *** [os-unix.lo] Error 1 The following patch fixes this: 2013-10-31 Rainer Orth * runtime/os-unix.c [__sun__ && __svr4__]: Include . (__cilkrts_hardware_cpu_count) [__sun__ && __svr4__]: Use sysconf. (__cilkrts_yield) [__sun__ && __svr4__]: Use sched_yield.
Canadian cross / caddr_t / mingw problem
I have run into a canadian cross build problem that seems to have existed for some time involving the caddr_t type and the mingw compilers. For example, here is an email from 2011: https://sourceware.org/ml/crossgcc/2011-03/msg00161.html There are several comments about how to work around this problem but I haven't found any actual proposed fix for it. Addtionally, I notice that this problematic test for caddr_t is using an old to-be-obsoleted form of the AC_TYPE_CHECK macro and we should probably change that. There is also an obsolete AC_TYPE_CHECK use for ssize_t in the same gcc configure.ac file and in the libjava configure.ac. Before I dig into this too far I thought I would ask if anyone already has a fix (not a workaround, a fix) for this problem. If you are not familiar with the issue, it looks like when building a normal cross compiler on linux AC_TYPE_CHECK(caddr_t, char *) finds the caddr_t type and all is fine. When building a canadian cross on linux using the mingw compilers then the check for caddr_t fails and auto-host.h winds up with "#define caddr_t char *" in it and that causes a build failure later on. Steve Ellcey sell...@mips.com
Fwd: [RTL, ARM] subreg of partially invalid register, is it valid RTL?
[Retrying in plain text] Hi Background info: This question is prompted from debugging a segfault reported at https://bugs.launchpad.net/gcc-linaro/+bug/1215925?comments=all. The segfault only occurs on gcc linaro-4.7 on an arm target[1]. However, similar RTL appears in fsf 4.7, so it's not a Linaro-specific problem. The test case is compiled with: $ gcc -c upsampling_neon.c -march=armv7-a -mfloat-abi=softfp -mfpu=neon -O3 -frename-registers -mtune=cortex-a9 -marm -g The question: The insn which causes the segfault is: (debug_insn 1548 1547 1886 11 (var_location:V4HI __b (subreg:V4HI (reg:V8HI 125 d31 [orig:657 vr ] [657]) 0)) upsampling_neon.c:850 -1 (nil)) The variable vr is declared as a NEON vector of 8 16bit integers, and -frename-registers has caused it to be separated into 2 64bit parts. So the register allocation is ok, but if considered in isolation the part which reads (reg:V8HI 125 d31 [orig:657 vr ] [657]) represents a non-existent register, as the last physical register is d31 (regnos 125,126). When this is processed by sched_analyze_2 in sched-deps.c, the subreg is handled by treating it as the included (reg), and it therefore adds dependencies on invalid physical registers, which leads to a segfault. If the variable was not assigned to d31 (as in fsf 4.7), then it would not crash, but would add false dependencies. So, my question is: Is the above RTL valid? In other words, should sched-deps.c handle this, or should all reg RTL expressions represent fully valid registers? Thanks for any insight, Charles [1] gcc -v reports: Configured with: /home/cbaylis/srcarea/gcc/gcc-linaro-4.7/configure --prefix=/home/cbaylis/tools//tools-arm-unknown-linux-gnueabihf-linaro-4.7 --target=arm-unknown-linux-gnueabihf --enable-languages=c,c++ --with-sysroot=/home/cbaylis/tools//sysroot-arm-unknown-linux-gnueabihf-linaro-4.7 --with-arch=armv7-a --with-fpu=vfpv3-d16 --with-float=softfp --with-thumb
Re: [PATCH] RE: libcilkrts/runtime/config/generic/cilk-abi-vla.c failure
cOn Thu, 31 Oct 2013, Iyer, Balaji V wrote: > It should include a 3 too. My bad sorry. I have fixed it. Attached, > please find a patch. It is committed as obvious. Thanks. Now the next failure mode, I'm afraid. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58951 libtool: link: /scratch2/tmp/gerald/OBJ-1031-1937/./gcc/xg++ -B/scratch2/tmp/gerald/OBJ-1031-1937/./gcc/ -nostdinc++ -nostdinc++ -I/scratch2/tmp/gerald/OBJ-103a1-1937/i386-unknown-freebsd10.0/libstdc++-v3/include/i386-unknown-freebsd10.0 -I/scratch2/tmp/gerald/OBJ-1031-1937/i386-unknown-freebsd10.0/libstdc++-v3/include -I/scratch2/tmp/gerald/gcc-HEAD/libstdc++-v3/libsupc++ -I/scratch2/tmp/gerald/gcc-HEAD/libstdc++-v3/include/backward -I/scratch2/tmp/gerald/gcc-HEAD/libstdc++-v3/testsuite/util -L/scratch2/tmp/gerald/OBJ-1031-1937/i386-unknown-freebsd10.0/libstdc++-v3/src -L/scratch2/tmp/gerald/OBJ-1031-1937/i386-unknown-freebsd10.0/libstdc++-v3/src/.libs -L/scratch2/tmp/gerald/OBJ-1031-1937/i386-unknown-freebsd10.0/libstdc++-v3/libsupc++/.libs -B/home/gerald/gcc-ref10-i386/i386-unknown-freebsd10.0/bin/ -B/home/gerald/gcc-ref10-i386/i386-unknown-freebsd10.0/lib/ -isystem /home/gerald/gcc-ref10-i386/i386-unknown-freebsd10.0/include -isystem /home/gerald/gcc-ref10-i386/i386-unknown-freebsd10.0/sys-include -shared -nostdlib /usr/lib/crti.o /scratch2/tmp/gerald/OBJ-1031-1937/./gcc/crtbeginS.o .libs/cilk-abi-vla.o .libs/os-unix-sysdep.o .libs/bug.o .libs/cilk-abi.o .libs/cilk-abi-cilk-for.o .libs/cilk-abi-vla-internal.o .libs/cilk_api.o .libs/cilk_fiber.o .libs/cilk_fiber-unix.o .libs/cilk_malloc.o .libs/c_reducers.o .libs/except-gcc.o .libs/frame_malloc.o .libs/full_frame.o .libs/global_state.o .libs/jmpbuf.o .libs/local_state.o .libs/metacall_impl.o .libs/os_mutex-unix.o .libs/os-unix.o .libs/pedigrees.o .libs/record-replay.o .libs/reducer_impl.o .libs/scheduler.o .libs/signal_node.o .libs/spin_mutex.o .libs/stats.o .libs/symbol_test.o .libs/sysdep-unix.o .libs/worker_mutex.o -Wl,-rpath -Wl,/scratch2/tmp/gerald/OBJ-1031-1937/i386-unknown-freebsd10.0/libstdc++-v3/src/.libs -Wl,-rpath -Wl,/home/gerald/gcc-ref10-i386/lib -L/scratch2/tmp/gerald/OBJ-1031-1937/i386-unknown-freebsd10.0/libstdc++-v3/src/.libs -L/scratch2/tmp/gerald/OBJ-1031-1937/i386-unknown-freebsd10.0/libstdc++-v3/src -L/scratch2/tmp/gerald/OBJ-1031-1937/i386-unknown-freebsd10.0/libstdc++-v3/libsupc++/.libs -lpthread -ldl -L/scratch2/tmp/gerald/OBJ-1031-1937/./gcc /scratch2/tmp/gerald/OBJ-1031-1937/i386-unknown-freebsd10.0/libstdc++-v3/src/.libs/libstdc++.so -lm -lc -lgcc_s /scratch2/tmp/gerald/OBJ-1031-1937/./gcc/crtendS.o /usr/lib/crtn.o -Wl,-soname -Wl,libcilkrts.so.5 -o .libs/libcilkrts.so.5 /home/gerald/10-i386/bin/ld: cannot find -ldl collect2: error: ld returned 1 exit status gmake[2]: *** [libcilkrts.la] Error 1 gmake[2]: Leaving directory `/scratch2/tmp/gerald/OBJ-1031-1937/i386-unknown-fre ebsd10.0/libcilkrts' gmake[1]: *** [all-target-libcilkrts] Error 2 gmake[1]: Leaving directory `/scratch2/tmp/gerald/OBJ-1031-1937' gmake: *** [bootstrap] Error 2 By the way, in the ChangeLog entry of 2013-10-30 Balaji V. Iyer * configure: Reconfigured. * configure.ac: Add AC_FUNC_ALLOCA. * runtime/sysdep-unix.c: Added check for alloca.h before including it. * config/x86/cilk-abi-vla.c: Likewise. * runtime/cilk_fiber-unix.cpp: Likewise. you did not add the PR and the respective bug is still open. I think you can close that now (and add the note to the ChangeLog entry). Gerald
