Re: New test is invalid for AVR
Hello Ian,
> In that case, just comment out the bulk of the test based on
> STACK_SIZE.
Ok. How about that patch? It should be ok until someone digs out a
target with a stack size below 64 bytes ;) (plus the bytes for the
other auto variables).
I've decided not to disable the testcase completely for small stack
sizes. Although it is unlikely that it triggers the reload problem in
some way the testcase is weird enough to trigger something else.
Ok for mainline?
Bye,
-Andreas-
Index: gcc/testsuite/gcc.c-torture/compile/20080806-1.c
===
*** /dev/null 1970-01-01 00:00:00.0 +
--- gcc/testsuite/gcc.c-torture/compile/20080806-1.c2008-08-08
09:16:01.0 +0200
***
*** 0
--- 1,41
+ /* This used to ICE on s390x due to a reload bug. */
+
+ #if defined(STACK_SIZE) && (STACK_SIZE < 65536)
+ #define BYTES 64
+ #else
+ #define BYTES 65400
+ #endif
+
+ int gl2;
+ typedef __SIZE_TYPE__ size_t;
+
+ extern void *memcpy (void *dest, const void *src, size_t n);
+
+ void
+ f1 ()
+ {
+ int i2;
+ unsigned char bf[BYTES];
+
+ for (i2 = 0; i2 < 3; i2++)
+ {
+ unsigned char *p2 = bf;
+ unsigned char *p3 = ((void *) 0);
+ unsigned short ctf2;
+
+ p2 += sizeof (short);
+
+ for (ctf2 = 0; ctf2 < 3; ctf2++)
+ {
+ if (ctf2 == 1)
+ {
+ unsigned short of = p2 - bf - 6;
+ unsigned short *ofp = (unsigned short *) &of;
+ memcpy (p3, ofp, sizeof (short));
+ }
+
+ if (gl2 == 1)
+ p2 += 3;
+ }
+ }
+ }
Index: gcc/testsuite/gcc.target/s390/20080806-1.c
===
*** gcc/testsuite/gcc.target/s390/20080806-1.c 2008-08-08 09:06:30.0
+0200
--- /dev/null 1970-01-01 00:00:00.0 +
***
*** 1,38
- /* This used to ICE on s390x due to a reload bug. */
-
- /* { dg-do compile } */
- /* { dg-options "-O2" } */
-
- int gl2;
- typedef __SIZE_TYPE__ size_t;
-
- extern void *memcpy (void *dest, const void *src, size_t n);
-
- void
- f1 ()
- {
- int i2;
- unsigned char bf[64 * 1024 + 4];
-
- for (i2 = 0; i2 < 3; i2++)
- {
- unsigned char *p2 = bf;
- unsigned char *p3 = ((void *) 0);
- unsigned short ctf2;
-
- p2 += sizeof (short);
-
- for (ctf2 = 0; ctf2 < 3; ctf2++)
- {
- if (ctf2 == 1)
- {
- unsigned short of = p2 - bf - 6;
- unsigned short *ofp = (unsigned short *) &of;
- memcpy (p3, ofp, sizeof (short));
- }
-
- if (gl2 == 1)
- p2 += 3;
- }
- }
- }
--- 0
RE: New test is invalid for AVR
Ian Lance Taylor wrote on 08 August 2008 01:17: > "Dave Korn" <[EMAIL PROTECTED]> writes: > >> Ian Lance Taylor wrote on 07 August 2008 19:20: >> >>> If the test will run on most normal targets, then a better approach is >>> to add something like >>> >>> #if defined(STACK_SIZE) && STACK_SIZE < 1000 >>> exit (0); /* or "return 0" from main, as appropriate" >>> #endif >> >> :) Actually, it's a compile test! > > A compile test breaks because it uses a large stack? Yep! Reload generates an offset that isn't allowable in the machine insns. Frame-pointer elimination was causing it to be larger than expected. http://gcc.gnu.org/ml/gcc-patches/2008-08/msg00439.html cheers, DaveK -- Can't think of a witty .sigline today
Re: s-oscons technique does not work for RTEMS
> "Thomas" == Thomas Quinot <[EMAIL PROTECTED]> writes: Thomas> As an alternative to Arno's suggestion, maybe you could use Thomas> the --with-sysroot configure parameter to make the required Thomas> headers available to the build process. I know others have Thomas> used this method on some cross targets. Do you mean --with-build-sysroot? Sam -- Samuel Tardieu -- [EMAIL PROTECTED] -- http://www.rfc1149.net/
Re: s-oscons technique does not work for RTEMS
Samuel Tardieu wrote: "Thomas" == Thomas Quinot <[EMAIL PROTECTED]> writes: Thomas> As an alternative to Arno's suggestion, maybe you could use Thomas> the --with-sysroot configure parameter to make the required Thomas> headers available to the build process. I know others have Thomas> used this method on some cross targets. Do you mean --with-build-sysroot? I tried that and got a variation on the theme to work. I used CFLAGS_FOR_TARGETS to pass in where the OS include files where. I posted a patch to gcc-patches and ACATS results to gcc-testresults. Thanks for the hint. Hopefully the patch is OK. It isn't big. FWIW cd2a24e now has a gnat bug box on sparc and powerpc. I filed it as PR 35298. For those who care, --sysroot does not work RTEMS because: (1) Apparently the RTEMS standard binutils RPMs do not support sysroots. /home/joel/work-gnat/svn//install/powerpc-rtems4.9/bin/ld: this linker was not configured to use sysroots collect2: ld returned 1 exit status (2) RTEMS doesn't install into a /usr/include structure. According to the gcc documentation--sysroot DIR looks in DIR/usr/[include|lib]. --joel
Re: New test is invalid for AVR
"Andreas Krebbel" <[EMAIL PROTECTED]> writes: > I've decided not to disable the testcase completely for small stack > sizes. Although it is unlikely that it triggers the reload problem in > some way the testcase is weird enough to trigger something else. > > Ok for mainline? OK. Thanks. Ian
gcc-4.4-20080808 is now available
Snapshot gcc-4.4-20080808 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20080808/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.4 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 138887 You'll find: gcc-4.4-20080808.tar.bz2 Complete GCC (includes all of below) gcc-core-4.4-20080808.tar.bz2 C front end and core compiler gcc-ada-4.4-20080808.tar.bz2 Ada front end and runtime gcc-fortran-4.4-20080808.tar.bz2 Fortran front end and runtime gcc-g++-4.4-20080808.tar.bz2 C++ front end and runtime gcc-java-4.4-20080808.tar.bz2 Java front end and runtime gcc-objc-4.4-20080808.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.4-20080808.tar.bz2The GCC testsuite Diffs from 4.4-20080801 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.4 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Is the following "dg" syntax correct?
Is the following syntax correct?
/* { dg-require-effective-target ilp32 && dfp } */
It appears in gcc/testsuite/gcc.target/i386/pr32000-2.c and
gcc/testsuite/gcc.target/i386/stackalign/return-3.c.
TIA
Dominique
GCC 4.4.0 Status Report (2008-08-08)
Status == It's time to start moving GCC 4.4.0 towards a release, with a release target date in Q4 2008 or Q1 2009. We have had an extraordinarily long Stage 1 in order to allow development of a variety of important functionality, including the IRA register allocator, tuples, the Graphite loop optimization functionality, and many other important projects. Most of these are either done, or appear to be nearing conclusion. So, we've got plenty of new functionality, and it's time to start driving towards a release. Therefore, Jakub, Joseph, Richard, and I have decided to close Stage 1 as of August 31st, 2008. We will at that point go directly to Stage 3, during which time only bug fixes will be accepted. That means that all new features must be submitted prior to August 31st. Any exceptions to this policy will be made on a case-by-case basis by consensus of the RMs. If you're a maintainer, please help to review outstanding new-feature patches before this time, so that we are as feature-complete as possible by September 1st. Traditionally, Stage 3 has been scheduled for two months, but, as for past releases, we will probably stay until Stage 3 until we feel that we have reached a sufficiently low bug count to merit going to the final regression-only stage. Quality Data Priority # Change from Last Report --- --- P1 13 P2 119 P32 --- --- Total 134 So long ago it doesn't matter This is a reasonably good situation to be in at this point. Of course, as further testing is performed we are likely to see a variety of issues. As much of the functionality in 4.4 is aimed at optimization, we need to be particularly sensitive to performance issues. If our benchmark numbers aren't improved relative to the previous release, or if we've increased code size when compiling with -Os, then we've got a problem. Some of those issues will probably be difficult to fix. Previous Report === http://gcc.gnu.org/ml/gcc/2008-04/msg00539.html Next Report === The next report for 4.4.0 will be sent by Richard. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
GCC 4.3.2 Status Report (2008-08-08)
Status == The GCC 4.3 branch is open for commits under normal release branch rules. We are trying to drive towards a 4.3.2 release, but there are still two P1s: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36998 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37014 These look like issues that can and should be resolved, so hopefully that will happen quickly. Quality Data Priority # Change from Last Report --- --- P130 P2 113 - 2 P30 - 2 --- --- Total 116 - 4 The best way to highlight PRs that you believe to be incorrectly categorized is to put a note in the PR audit trail CC'ing one of the RMs. Previous Report === http://gcc.gnu.org/ml/gcc/2008-07/msg00660.html Next Report === While normally the next report would be given by Richard, I'd like to skip ahead to Joseph, so that the same RM isn't responsible for two reports in the same week. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
