[MIPS] Test case dspr2-MULT is failed
Hi, There are two test cases failed when run 'make check-gcc RUNTESTFLAGS="mips.exp"'. The log is, Executing on host: /home/xmj/tools/build-test-trunk-mips/gcc/xgcc -B/home/xmj/tools/build-test-trunk-mips/gcc/ /home/xmj/tools/test-trunk/gcc/testsuite/gcc.target/mips/dspr2-MULT.c -DNOMIPS16=__attribute__((nomips16)) -mabi=32 -mips32r2 -mgp32 -O2 -mdspr2 -mtune=74kc -ffixed-hi -ffixed-lo -S -o dspr2-MULT.s (timeout = 300) PASS: gcc.target/mips/dspr2-MULT.c (test for excess errors) PASS: gcc.target/mips/dspr2-MULT.c scan-assembler \tmult\t PASS: gcc.target/mips/dspr2-MULT.c scan-assembler ac1 FAIL: gcc.target/mips/dspr2-MULT.c scan-assembler ac2 Executing on host: /home/xmj/tools/build-test-trunk-mips/gcc/xgcc -B/home/xmj/tools/build-test-trunk-mips/gcc/ /home/xmj/tools/test-trunk/gcc/testsuite/gcc.target/mips/dspr2-MULTU.c -DNOMIPS16=__attribute__((nomips16)) -mabi=32 -mips32r2 -mgp32 -O2 -mdspr2 -mtune=74kc -ffixed-hi -ffixed-lo -S -o dspr2-MULTU.s (timeout = 300) PASS: gcc.target/mips/dspr2-MULTU.c (test for excess errors) PASS: gcc.target/mips/dspr2-MULTU.c scan-assembler \tmultu\t PASS: gcc.target/mips/dspr2-MULTU.c scan-assembler ac1 FAIL: gcc.target/mips/dspr2-MULTU.c scan-assembler ac2 Is it a bug? Thanks, Mingjie
GNU Fortran 4.6.0
Dear GNU Fortran Expert: (1) On December 16, 2010, I downloaded: gfortran-snwleo-intel-bin.tar.gz onto my MacBook Pro running Snow Leopard 10.6. Hence, this would be GNU Fortran (GCC) 4.6.0 20101106 (experimental). This followed downloading XCode, which I believe is necessary for the Fortran. The installation appeared to go smoothly. (2) I currently have a suite of 227 main Fortran programs. Despite the fact that these have been developed and debugged over a 40-year period using various IBM mainframes, three Cyber computers, VMS (VAX 32 bit), VMS (Alpha 64-bit), VMS (Itanium 64-bit), and MacBook Pro (64-bit, earlier GCC Fortran version, namely 4.5), the compiler was able to detect more ”errors”. A good example, is the need to use the parentheses in the declaration: character*(1) a, b, c Which had not been previously necessary. I did not mind this because your error messages are extremely clear in meaning and it was a simple matter to make these modifications. (3) I compile using the command: gfortran -c -std=f2008 -fdefault-real-8 -fdefault-integer-8 \ -fdollar-ok -fbounds-check -Wcharacter-truncation \ -Wuninitialized -Wunderflow -Werror -fbacktrace program.for (4) Using the "-v" option when compiling gives the following information: Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-apple-darwin10.4.0/4.6.0/lto-$ Target: x86_64-apple-darwin10.4.0 Configured with: ../gcc-4.6-20101106/configure --enable-languages=c++,fortran Thread model: posix gcc version 4.6.0 20101106 (experimental) (GCC) COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.6.4' '-c' '-std=f2008' '-fdefault-$ /usr/local/libexec/gcc/x86_64-apple-darwin10.4.0/4.6.0/f951 xacvopt.for -ffixe$ GNU Fortran (GCC) version 4.6.0 20101106 (experimental) (x86_64-apple-darwin10.$ compiled by GNU C version 4.6.0 20101106 (experimental), GMP version 4.$ GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 GNU Fortran (GCC) version 4.6.0 20101106 (experimental) (x86_64-apple-darwin10.$ compiled by GNU C version 4.6.0 20101106 (experimental), GMP version 4.$ GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.6.4' '-c' '-std=f2008' '-fdefault-$ as -arch x86_64 -force_cpusubtype_ALL -o xacvopt.o /var/folders/3D/3Dikh2dMHY4$ COMPILER_PATH=/usr/local/libexec/gcc/x86_64-apple-darwin10.4.0/4.6.0/:/usr/loca$ LIBRARY_PATH=/usr/local/lib/gcc/x86_64-apple-darwin10.4.0/4.6.0/:/usr/local/lib$ COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.6.4' '-c' '-std=f2008' '-fdefault-$ COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.6.4' '-c' '-std=f2008' '-fdefault-$ (5) The reason that I write is that the parameter “end= label” appears to be ignored in a READ statement. (a) This causes the program to crash with a Fortran run error if the very last character of the data set is a carriage return. (I believe that this is the custom with Unix – to complete a plain text file with a carriage return.) I am still becoming familiar with Unix. As you will note from the above, my expertise is with VMS which is very unfussy about such details. (b) Almost all my data for my Fortran programs is read using NAMELIST. If I remove the offending carriage return, the program runs smoothly with no Fortran errors, but the last NAMELIST data set is apparently ignored. I can fix this in a crude manner by adding another, dummy, NAMELIST with no variables in it (again, being careful not to include that offending final carriage return). Then all the data is processed. (6) For the moment, I can also fix the problem more professionally by adding the parameter “ios= iostat” in the READ statement and adding a line to the program with the Fortran statement: if (ios .eq. 5010) goto label I trust that I have described the problem fully. I really doubt that there could be such a basic error in GNU Fortran and I therefore suspect that there is a problem elsewhere. I hope that I do not cause you too much trouble over this but would be pleased to hear from you if you have the time to comment. I can, of course, send you a very short sample file demonstrating the problem. With best wishes for the Season, Larry Lawrence J. Doctors Emeritus Professor Naval Architecture Program School of Mechanical and Manufacturing Engineering The University of New South Wales Sydney, NSW 2052, Australia Telephone: +61-2-9385 4098 Messages: +61-2-9385 4093 Facsimile: +61-2-9663 1222
Re: call for libstdc++ profile mode diagnostic ideas
On 29 December 2010 01:15, Hargett, Matt wrote:
>
> 1) allocation of std::string in local variable
> 2) calls to said local string's c_str() method within loops
> 3) and said loops do not modify the contents of the value returned from
> c_str()
You can't modify the contents, c_str() returns a const char*
> Example:
>
> #include
> #include
>
> void notify(const char* printable) { printf("%s\n", printable); }
>
> int main(void)
> {
> std::string name("bob");
> for (int i = 0; i < name.length(); i++)
> {
> notify(name.c_str());
What would you do to improve performance here?
I don't see any significant opportunity for optimisation here.
The second idea is obviously useful, as it could avoid unnecessary
heap allocations (although not in C++0x where strings are not going to
be reference-counted.)
Re: ICE in dwarf2out_frame_debug_expr() while supporting call-stack debug info
Hi,
> +rtx
> +avr_incoming_return_addr_rtx (void)
> +{
> + /* Compute return address which is stored on the stack.
> + Current stack pointer at the begining of frame, before the prologue
> + execution holds the return address. So our job is done if we get
> + the stack pointer register value which inturn points to return address
> + */
> + return gen_rtx_MEM (HImode, stack_pointer_rtx); }
> +
>
> This change gives me an ICE in dwarf2out_frame_debug_expr() while
> compiling libgcc2.c as the switch in MEM case is not matched (and
> therefore reaches gcc_unreachable()). Error pasted below.
(The above piece of conversation was sent by me)
I just found the reason for the ICE in dwarf2out_frame_debug_expr ().
The POST_DEC mode is not handled when a register is saved onto the
stack. For AVR, STACK_PUSH_CODE is defined as POST_DEC. A quick
search in all other architectures shows that only AVR uses post
decrement mode for stack push.
A possible fix can be along the lines of POST_INC with a modification
for 'offset' assignment :
static void
dwarf2out_frame_debug_expr ( rtx expr, const char * label )
{
...
+ case POST_DEC:
+ //gcc_assert ( cfa_temp.reg == (unsigned) REGNO ( XEXP ( XEXP(
dest, 0), 0)));
+ offset =cfa_temp.offset;
+ cfa_temp.offset -=GET_MODE_SIZE (GET_MODE( dest ) );
+ break;
case POST_INC:
...
}
To avoid assertion error, I commented gcc_assert(). I can see that
POST_INC logic is based on Rule 14. Going by the comments given in the
code, my understanding of cfa_store and cfa_temp is partial and I
would appreciate if someone can explain the requirement for assertion
as well as comment on the fix.
With the above change, I am now able to build the compiler. A quick
check of .debug_frame shows that call-stack debug info is now
generated. Ofcourse I am to yet validate the correctness of output.
Thanks
Anitha
FW:RE
Recently I often bought some products from a business company. Very cost-effective and convenient, if you are free, you can go to browse: okayele.com , enrich a shopping choice for yourself wonderful life
Re: Problem updating 2yr old port
Hello Ian, On 28.12.10 06:37, Ian Lance Taylor wrote: Seems like you don't have a cbranchMODE4 insn in the required mode. Double check that. You should only get to that assert if there is no cbranch pattern. To assert is indicating that if there is no cbranch pattern there has to be a cmp pattern. gcc doesn't have any other options for a compare-and-branch. cbranchpsi4 was missing. Now I'm a step further. Thanks. regards, chris
