Re: Division by INT64_MIN

On 06/10/15 01:09, Joseph Myers wrote: On Mon, 5 Oct 2015, Matthew Fernandez wrote: on x86 is emitted as a call to __divdi3. If the numerator or denominator are negative, __divdi3 negates them. If either of these values is INT64_MIN, I believe this negation is undefined. Is this correct? If thi

Re: Understand GCC test process

On 10/07/2015 09:43 PM, Sabrina Souto wrote: > I'm understanding that the major of code that I instrumented (in the > first level of ..gcc-version-x.x/gcc/ and the dirs related to C/C++) > is part of the 'gcc' driver. If so, this explains the great amount of > common function calls across the tests

gcc-4.9-20151007 is now available

Snapshot gcc-4.9-20151007 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.9-20151007/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.9 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches

Re: Understand GCC test process

On 7 October 2015 at 19:43, Sabrina Souto wrote: > I ran > make RUNTESTFLAGS='dg.exp=c90-float-1.c -v -v' check-gcc > And I saw in the log: > ... > doing compile > Invoking the compiler as > ../gcc-r227092/objdir/gcc/testsuite/g++/../../xg++ -B/... > ... > > The test ../testsuite/gcc.dg/c90-float-1

Re: Understand GCC test process

> OK, all that does is process some options and then call another > executable, which does the actual compilation. > > To compile C code it calls cc1, to compile C++ code it calls cc1plus etc. > > So if you're only tracing the 'gcc' driver then you are basically only > tracing the code for parsing

Re: [RFC, VECTOR ABI] Allow __attribute__((vector)) in GCC by default.

On 10/07/2015 11:34 AM, Ramana Radhakrishnan wrote: On Wed, Oct 7, 2015 at 6:22 PM, Joseph Myers wrote: On Wed, 7 Oct 2015, Jeff Law wrote: I'm not sure why this attribute isn't documented, but clearly that should be fixed. I assume the reasoning was: we document support for Cilk+ (and what

Re: [RFC, VECTOR ABI] Allow __attribute__((vector)) in GCC by default.

On 10/07/2015 11:22 AM, Joseph Myers wrote: On Wed, 7 Oct 2015, Jeff Law wrote: I'm not sure why this attribute isn't documented, but clearly that should be fixed. I assume the reasoning was: we document support for Cilk+ (and what's included in Cilk+ is externally documented). When it becom

Re: Missing dependency in Ada build?

> So it looks like there are two problems here: > (1) xsinfo not terminating; > (2) a missing dependency, that the g++ steps should depend upon the step > producing sinfo.h (i.e. the mv that comes after problem (1)) > > I'm going to look at (1), but I'm hoping someone more familiar with the Ada >

Re: [RFC, VECTOR ABI] Allow __attribute__((vector)) in GCC by default.

On Wed, Oct 7, 2015 at 6:22 PM, Joseph Myers wrote: > On Wed, 7 Oct 2015, Jeff Law wrote: > >> I'm not sure why this attribute isn't documented, but clearly that should be >> fixed. > > I assume the reasoning was: we document support for Cilk+ (and what's > included in Cilk+ is externally document

Re: [RFC, VECTOR ABI] Allow __attribute__((vector)) in GCC by default.

On Wed, 7 Oct 2015, Jeff Law wrote: > I'm not sure why this attribute isn't documented, but clearly that should be > fixed. I assume the reasoning was: we document support for Cilk+ (and what's included in Cilk+ is externally documented). When it becomes a generic GNU C attribute, that reasoni

Re: [RFC, VECTOR ABI] Allow __attribute__((vector)) in GCC by default.

On 10/05/2015 07:24 AM, Joseph Myers wrote: On Mon, 5 Oct 2015, Kirill Yukhin wrote: To enable vectorization of loops w/ calls to math functions it is reasonable to enable parsing of attribute vector for functions unconditionally and change GlibC's header file not to use `omp declare simd', but

Re: Understand GCC test process

On 7 October 2015 at 16:45, Sabrina Souto wrote: >> What exactly are you tracing, and how? > I'm proposing an approach for testing configurable system in my > research, and I'm trying to apply it to GCC. So, I instrumented the > GCC function calls (in the first level of ..gcc-version-x.x/gcc/ and

Re: Understand GCC test process

On October 7, 2015 5:45:31 PM GMT+02:00, Sabrina Souto wrote: >> What exactly are you tracing, and how? >I'm proposing an approach for testing configurable system in my >research, and I'm trying to apply it to GCC. So, I instrumented the >GCC function calls (in the first level of ..gcc-version-x.

Re: Understand GCC test process

> What exactly are you tracing, and how? I'm proposing an approach for testing configurable system in my research, and I'm trying to apply it to GCC. So, I instrumented the GCC function calls (in the first level of ..gcc-version-x.x/gcc/ and the dirs related to C/C++) and some options, in a semi-au

Re: Understand GCC test process

On 7 October 2015 at 14:57, Sabrina Souto wrote: > I was seeing these files but I could not put the puzzle pieces > together in my mind, and after you explained, all pieces make sense > now. Thanks for the explanation, Jonathan. You're doing better than I am then, noting about DejaGnu makes comple

Re: Understand GCC test process

On 10/07/2015 07:57 AM, Sabrina Souto wrote: I was seeing these files but I could not put the puzzle pieces together in my mind, and after you explained, all pieces make sense now. Thanks for the explanation, Jonathan. The testing process is clear now, but I still not understanding what can expla

Re: reload question about unmet constraints

DJ Delorie wrote: > For such constraints that are memory operands but not > define_memory_constraint, you need to use '*' to keep reload from > trying to guess a register class from them (it guesses wrong for > rl78). > > I.e. use "*Wfr" instead of "Wfr". Huh? That seems weird. It should make

Re: Understand GCC test process

I was seeing these files but I could not put the puzzle pieces together in my mind, and after you explained, all pieces make sense now. Thanks for the explanation, Jonathan. The testing process is clear now, but I still not understanding what can explain that amount of common functions (over 60%) a

Missing dependency in Ada build?

I've been erratically seeing my Ada builds (bootstrap or even with --disable-bootstrap) on an arm-none-linux-gnueabihf system, with errors like this: g++ -fno-PIE -c -DIN_GCC_FRONTEND -g -O2 -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-str

Re: Understand GCC test process

On 7 October 2015 at 14:03, Sabrina Souto wrote: >>> Hi, >>> I'm needing to analyze the execution flow of a test, but don't >>> understand how the test drivers, e.g., gcc-dg.exp or dg.exp, access >>> the source code of GCC. When a test starts, what is the first function >>> that is called? How can

Re: Understand GCC test process

>> Hi, >> I'm needing to analyze the execution flow of a test, but don't >> understand how the test drivers, e.g., gcc-dg.exp or dg.exp, access >> the source code of GCC. When a test starts, what is the first function >> that is called? How can I know that? > > The first function is main(), because

Re: Understand GCC test process

On 7 October 2015 at 12:38, Sabrina Souto wrote: > Hi, > I'm needing to analyze the execution flow of a test, but don't > understand how the test drivers, e.g., gcc-dg.exp or dg.exp, access > the source code of GCC. When a test starts, what is the first function > that is called? How can I know tha

Understand GCC test process

Hi, I'm needing to analyze the execution flow of a test, but don't understand how the test drivers, e.g., gcc-dg.exp or dg.exp, access the source code of GCC. When a test starts, what is the first function that is called? How can I know that? On another note, I observed the execution traces of some

Re: abort might not flush all open streams before process termination

Thomas Schwinge writes: > On Tue, 06 Oct 2015 13:55:00 +0200, Andreas Schwab > wrote: >> Thomas Schwinge writes: >> >> > | The two regressed test cases use __builtin_printf instead of fprintf to >> > | stderr, but as far as I know, abort is to flush all open streams before >> > | process term

abort might not flush all open streams before process termination (was: aarch64-suse-linux-gnu: libgomp.oacc-c-c++-common/abort-1.c, libgomp.oacc-c-c++-common/abort-3.c FAILs)

Hi! Copying glibc for your information/in case anyone has any further comments, and the man-pages maintainer, Michael Kerrisk. The issue is that abort might not flush all open streams before process termination; original thread starting at