Re: Effects of newly introduced -mpcX 80387 precision flag
> > m68k does too, just nobody uses it any more or the ones they use don't > > have the co-processor or have a different FP instructions now. In > > fact this where the problem started, i387 just continued in the same > > fashion. > > Huh? m68k still uses extended precisions and will continue to do so, it's > ColdFire that doesn't have it anymore. IIUC excess precision is only a problem on earler m68k implementations. The 68040 adds instructions that perform correct rounding (fdadd.x etc.), so does not suffer from the excess precision problems. Paul
Re: Expression with 2 operations
Quoting Tom Tromey <[EMAIL PROTECTED]>:
"Antoine" == Antoine Eiche <[EMAIL PROTECTED]> writes:
Without more information I don't know how to answer your question.
But I do have a question for you...
Antoine> I must calculate the address of an element's array.
Antoine> If the size of an element is one integer it's good.
Antoine> I do like that:
Antoine> new_rhs=fold_build2(PLUS_EXPR,TREE_TYPE(TREE_OPERAND(rhs,1)),
Antoine>build1(ADDR_EXPR, build_pointer_type
(TREE_TYPE
Antoine> (array)),array),
Antoine>index);
Why not use ARRAY_REF here? Then you don't have to worry about the
size of an element of the array.
Tom
I tested whit ARRAY_REF but I did not succeed to build the address
(error when I test my pass).
Then, I try to calculate the address whit the index and the size of an
element.
I specify that I just have the problem whit a static array.
This code is the code which is in the source file of a test program:
int main()
{
int a[10];
int i;
for(i=0;i<10;i++){
a[i]=1;
}
}
I have succeed to transform the code like that:
int main(){
int a[10];
int i;
for(i=0;i<10;i++){
foo(a + i);
a[i]=1;
}
}
But I want to transform like that:
int main(){
int a[10];
int i;
for(i=0;i<10;i++){
foo(a + i * sizeof(*a));
a[i]=1;
}
}
I specify that I have not succeed to transform like that!:
int main(){
int a[10];
int i;
for(i=0;i<10;i++){
foo(& a[i]);
a[i]=1;
}
}
Why can I not do "foo(a + i * x)" then I can do "foo(i * x)" ou "foo(a
+ i)" ?*
How can I do that ?
Thanks in advance.
Regression in gfortran.fortran-torture/execute/st_function.f90
This has appeared in recent days, with any level of optimization other than none at all. [EMAIL PROTECTED] prs]# /svn-4.3/bin/gfortran -static -O1 $test/../gfortran.fortran-torture/execute/st_function.f90 /svn/trunk/gcc/testsuite/gfortran.dg/../gfortran.fortran-torture/execute/st_function.f90: In function 'MAIN__': /svn/trunk/gcc/testsuite/gfortran.dg/../gfortran.fortran-torture/execute/st_function.f90:63: internal compiler error: in expand_expr_real_1, at expr.c:8833 Paul Thomas -- "Success is the ability to go from one failure to another with no loss of enthusiasm." - Winston Churchill
Re: Regression in gfortran.fortran-torture/execute/st_function.f90
On Saturday 05 May 2007 17:57:30 Paul Richard Thomas wrote: > This has appeared in recent days, with any level of optimization other > than none at all. > > [EMAIL PROTECTED] prs]# /svn-4.3/bin/gfortran -static -O1 > $test/../gfortran.fortran-torture/execute/st_function.f90 > /svn/trunk/gcc/testsuite/gfortran.dg/../gfortran.fortran-torture/execute/st >_function.f90: In function 'MAIN__': > /svn/trunk/gcc/testsuite/gfortran.dg/../gfortran.fortran-torture/execute/st >_function.f90:63: internal compiler error: in expand_expr_real_1, at > expr.c:8833 See PR31095.
Re: Regression in gfortran.fortran-torture/execute/st_function.f90
See PR31095. Thanks, Daniel. Paul
Re: GCC 4.2.0 RC3 Available
GCC 4.2.0 RC3 is now available from: ftp://gcc.gnu.org/pub/gcc/prerelease-4.2.0-20070501 It does not build LLVM there seems to be a stdlib++ problem. I cannot really file a BugZilla report as I have not distilled the code down to make an accurate report. Luckily it was just a local library file selection problem. LLVM and LLVM-GCC4 build on GCC 4.2.0 RC3. Aaron
Re: GCC 4.2.0 RC3 Available
Richard Earnshaw wrote: >> Mark Mitchell wrote: >>> GCC 4.2.0 RC3 is now available from: >>> >>> ftp://gcc.gnu.org/pub/gcc/prerelease-4.2.0-20070501 >>> >>> This build now contains the fixes for the Ada build problem present in RC2. >>> >>> At this point, I have no plans for an RC4. However, I am reviewing the >>> various open issues, and available patches, so I might change my mind >>> about that. > > Another problem is that --enable-checking hasn't been set to 'release', > so the stage1 binary is too big to run on my ARM systems (and the > compiler will be unnecessarily slower than it needs to be). That's a serious issue. But, I'm confused: gcc/DEV-PHASE on the branch is set to "prerelease", and, in the auto-host.h file from the build that gets done as part of the prerelease tarball-building script, I see: /* Define if you want the garbage collector to do object poisoning and other memory allocation checks. This is quite expensive. */ #ifndef USED_FOR_TARGET /* #undef ENABLE_GC_CHECKING */ #endif which looks like GC-checking has indeed been turned off, which is consistent with gcc/configure.ac detecting that we're in release mode. Are you sure that we're not building with release-checking only? Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: GCC 4.2.0 RC3 Available
On 5/5/07, Mark Mitchell <[EMAIL PROTECTED]> wrote: Richard Earnshaw wrote: >> Mark Mitchell wrote: >>> GCC 4.2.0 RC3 is now available from: >>> >>> ftp://gcc.gnu.org/pub/gcc/prerelease-4.2.0-20070501 >>> >>> This build now contains the fixes for the Ada build problem present in RC2. >>> >>> At this point, I have no plans for an RC4. However, I am reviewing the >>> various open issues, and available patches, so I might change my mind >>> about that. > > Another problem is that --enable-checking hasn't been set to 'release', > so the stage1 binary is too big to run on my ARM systems (and the > compiler will be unnecessarily slower than it needs to be). That's a serious issue. But, I'm confused: gcc/DEV-PHASE on the branch is set to "prerelease", and, in the auto-host.h file from the build that gets done as part of the prerelease tarball-building script, I see: /* Define if you want the garbage collector to do object poisoning and other memory allocation checks. This is quite expensive. */ #ifndef USED_FOR_TARGET /* #undef ENABLE_GC_CHECKING */ #endif which looks like GC-checking has indeed been turned off, which is consistent with gcc/configure.ac detecting that we're in release mode. Are you sure that we're not building with release-checking only? stage1 is always built with checking enabled. Richard.
Re: GCC 4.2.0 RC3 Available
Richard Guenther wrote: >> > Another problem is that --enable-checking hasn't been set to 'release', >> > so the stage1 binary is too big to run on my ARM systems (and the >> > compiler will be unnecessarily slower than it needs to be). >> Are you sure that we're not building with release-checking only? > > stage1 is always built with checking enabled. OK. There's a good chance that both Richard E. and I didn't realize that (it didn't use to be true). So, from what you're saying, there doesn't seem to be an evidence that this is a real problem. Do we build stage1 with checking enabled even if --disable-checking is in effect? Otherwise, how to do folks like Richard E. that are running natively on small systems work around this issue? Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: GCC 4.2.0 RC3 Available
On 5/5/07, Mark Mitchell <[EMAIL PROTECTED]> wrote: Richard Guenther wrote: >> > Another problem is that --enable-checking hasn't been set to 'release', >> > so the stage1 binary is too big to run on my ARM systems (and the >> > compiler will be unnecessarily slower than it needs to be). >> Are you sure that we're not building with release-checking only? > > stage1 is always built with checking enabled. OK. There's a good chance that both Richard E. and I didn't realize that (it didn't use to be true). So, from what you're saying, there doesn't seem to be an evidence that this is a real problem. Do we build stage1 with checking enabled even if --disable-checking is in effect? Otherwise, how to do folks like Richard E. that are running natively on small systems work around this issue? Specifying --disable-stage1-checking should work. (it's in the toplevel configure) Richard.
Re: GCC 4.2.0 RC3 Available
On 5/5/07, Richard Guenther <[EMAIL PROTECTED]> wrote: On 5/5/07, Mark Mitchell <[EMAIL PROTECTED]> wrote: > Richard Guenther wrote: > > >> > Another problem is that --enable-checking hasn't been set to 'release', > >> > so the stage1 binary is too big to run on my ARM systems (and the > >> > compiler will be unnecessarily slower than it needs to be). > > >> Are you sure that we're not building with release-checking only? > > > > stage1 is always built with checking enabled. > > OK. There's a good chance that both Richard E. and I didn't realize > that (it didn't use to be true). So, from what you're saying, there > doesn't seem to be an evidence that this is a real problem. > > Do we build stage1 with checking enabled even if --disable-checking is > in effect? Otherwise, how to do folks like Richard E. that are running > natively on small systems work around this issue? Specifying --disable-stage1-checking should work. (it's in the toplevel configure) I see this is not documented, though :/ Richard, can you check if it actually works? Thanks, Richard.
Re: GCC 4.2.0 RC3 Available
On 5/5/07, Richard Guenther <[EMAIL PROTECTED]> wrote: On 5/5/07, Richard Guenther <[EMAIL PROTECTED]> wrote: > On 5/5/07, Mark Mitchell <[EMAIL PROTECTED]> wrote: > > Richard Guenther wrote: > > > > >> > Another problem is that --enable-checking hasn't been set to 'release', > > >> > so the stage1 binary is too big to run on my ARM systems (and the > > >> > compiler will be unnecessarily slower than it needs to be). > > > > >> Are you sure that we're not building with release-checking only? > > > > > > stage1 is always built with checking enabled. > > > > OK. There's a good chance that both Richard E. and I didn't realize > > that (it didn't use to be true). So, from what you're saying, there > > doesn't seem to be an evidence that this is a real problem. > > > > Do we build stage1 with checking enabled even if --disable-checking is > > in effect? Otherwise, how to do folks like Richard E. that are running > > natively on small systems work around this issue? > > Specifying --disable-stage1-checking should work. (it's in the toplevel > configure) I see this is not documented, though :/ Richard, can you check if it actually works? And if it does, the following patch documents it. Ok for the branch? Richard. 2007-05-05 Richard Guenther <[EMAIL PROTECTED]> * doc/install.texi (--disable-stage1-checking): Document. disables1c Description: Binary data
Re: GCC 4.2.0 RC3 Available
Richard Guenther wrote:
> 2007-05-05 Richard Guenther <[EMAIL PROTECTED]>
>
>* doc/install.texi (--disable-stage1-checking): Document.
> [EMAIL PROTECTED] --disable-stage1-checking
> [EMAIL PROTECTED] [EMAIL PROTECTED]
> +Regardless of what is specified with @samp{--enable-checking} the
> +stage1 compiler is built with checking enabled. For small or slow
> +systems you can disable checking for stage1 using
> [EMAIL PROTECTED]
Minor editing:
"By default, the Stage 1 compiler is built with checking enabled, even
if @option{--disable-checking} is used. If your system is too slow or
too small to bootstrap the compiler with checking enabled, you can use
@option{--disable-stage1-checking} to disable checking for the Stage 1
compiler."
Note, in particular, that you should use @option rather than @samp.
This patch is OK for 4.2 and mainline, assuming that someone verifies
that the switch actually performs as advertised.
Thanks!
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Re: Reload bug with register elimination + reload inheritance
On Tue, May 01, 2007 at 11:45:57PM +0200, Rask Ingemann Lambertsen wrote:
>
> $ ./xgcc -B./ ~/cvssrc/gcc/gcc/testsuite/gcc.dg/20020210-1.c \
> -O2 -sim=linuxvm86 -o /tmp/20020210-1-fp -fno-omit-frame-pointer
> $ /tmp/20020210-1-fp; echo $?
> 0
>
> $ ./xgcc -B./ ~/cvssrc/gcc/gcc/testsuite/gcc.dg/20020210-1.c \
> -O2 -sim=linuxvm86 -o /tmp/20020210-1-nofp -fomit-frame-pointer
> $ /tmp/20020210-1-nofp; echo $?
> 1
It looks like I have a fix:
$ ./xgcc -B./ ~/cvssrc/gcc/gcc/testsuite/gcc.dg/20020210-1.c \
-O2 -sim=linuxvm86 -o /tmp/20020210-1-nofp-ny -fomit-frame-pointer
$ /tmp/20020210-1-nofp-ny; echo $?
0
--- 20020210-1-nofp.s 2007-05-01 19:16:23.0 +0200
+++ 20020210-1-nofp-ny.s2007-05-06 02:10:04.0 +0200
@@ -24,9 +24,13 @@
subw$10,%sp
movw%sp,%bp
pushw 22(%bp)
+ movw%sp,%bp
pushw 22(%bp)
+ movw%sp,%bp
pushw 22(%bp)
+ movw%sp,%bp
pushw 22(%bp)
+ movw%sp,%bp
pushw 22(%bp)
callbar
addw$20,%sp
Index: reload1.c
===
--- reload1.c (revision 124334)
+++ reload1.c (working copy)
@@ -2709,6 +2722,20 @@ eliminate_regs (rtx x, enum machine_mode
return eliminate_regs_1 (x, mem_mode, insn, false);
}
+/* Disable inheritance of past reloads from hard reg REG. Helper function
+ for elimination_effects(). */
+static void
+break_reload_inheritance (unsigned int reg)
+{
+ unsigned int r;
+
+ for (r = 0; r < FIRST_PSEUDO_REGISTER; r++)
+{
+ if (reg_reloaded_contents[r] == reg)
+ CLEAR_HARD_REG_BIT (reg_reloaded_valid, r);
+}
+}
+
/* Scan rtx X for modifications of elimination target registers. Update
the table of eliminables to reflect the changed state. MEM_MODE is
the mode of an enclosing MEM rtx, or VOIDmode if not within a MEM. */
@@ -2798,6 +2825,8 @@ elimination_effects (rtx x, enum machine
else
ep->can_eliminate = 0;
}
+ /* The offset changed, past reloads can't be inherited. */
+ break_reload_inheritance (ep->to);
}
/* These two aren't unary operators. */
@@ -2882,7 +2911,11 @@ elimination_effects (rtx x, enum machine
if (GET_CODE (src) == PLUS
&& XEXP (src, 0) == SET_DEST (x)
&& GET_CODE (XEXP (src, 1)) == CONST_INT)
- ep->offset -= INTVAL (XEXP (src, 1));
+ {
+ ep->offset -= INTVAL (XEXP (src, 1));
+ /* The offset changed, past reloads can't be inherited. */
+ break_reload_inheritance (ep->to);
+ }
else
ep->can_eliminate = 0;
}
(Heading for bed.)
--
Rask Ingemann Lambertsen
libjava Divide_1 and pr6388 fail on 4.2.0 RC3 for several targets
Hi, I've noticed that some libjava tests fail for SH on trunk and 4.2.0 RC3. New tests that FAIL: Divide_1 -O3 -findirect-dispatch output - bytecode->native test Divide_1 -O3 output - bytecode->native test Divide_1 -O3 output - source compiled test Divide_1 -findirect-dispatch output - bytecode->native test Divide_1 output - bytecode->native test Divide_1 output - source compiled test pr6388 -O3 -findirect-dispatch output - bytecode->native test pr6388 -O3 output - bytecode->native test pr6388 -O3 output - source compiled test pr6388 -findirect-dispatch output - bytecode->native test pr6388 output - bytecode->native test pr6388 output - source compiled test I see same FAILs in the RC3 testresults for x86_64, hppa, ia64, ppc, sparc and s390 at gcc-testresults, though not for i686. Is this a known issue? Regards, kaz
Re: libjava Divide_1 and pr6388 fail on 4.2.0 RC3 for several targets
Kaz Kojima wrote: Hi, I've noticed that some libjava tests fail for SH on trunk and 4.2.0 RC3. New tests that FAIL: Divide_1 -O3 -findirect-dispatch output - bytecode->native test Divide_1 -O3 output - bytecode->native test Divide_1 -O3 output - source compiled test Divide_1 -findirect-dispatch output - bytecode->native test Divide_1 output - bytecode->native test Divide_1 output - source compiled test pr6388 -O3 -findirect-dispatch output - bytecode->native test pr6388 -O3 output - bytecode->native test pr6388 -O3 output - source compiled test pr6388 -findirect-dispatch output - bytecode->native test pr6388 output - bytecode->native test pr6388 output - source compiled test I see same FAILs in the RC3 testresults for x86_64, hppa, ia64, ppc, sparc and s390 at gcc-testresults, though not for i686. Is this a known issue? It is now. Same thing on mipsel-unknown-linux-gnu: http://gcc.gnu.org/ml/gcc-testresults/2007-05/msg00265.html This is a regression from: http://gcc.gnu.org/ml/gcc-testresults/2007-04/msg00666.html I was hoping that 4.2.0 would be good, but very recently someone broke it. Don't people test for regressions before committing? David Daney
Re: libjava Divide_1 and pr6388 fail on 4.2.0 RC3 for several targets
David Daney wrote:
Kaz Kojima wrote:
Hi,
I've noticed that some libjava tests fail for SH on trunk and
4.2.0 RC3.
New tests that FAIL:
Divide_1 -O3 -findirect-dispatch output - bytecode->native test
Divide_1 -O3 output - bytecode->native test
Divide_1 -O3 output - source compiled test
Divide_1 -findirect-dispatch output - bytecode->native test
Divide_1 output - bytecode->native test
Divide_1 output - source compiled test
pr6388 -O3 -findirect-dispatch output - bytecode->native test
pr6388 -O3 output - bytecode->native test
pr6388 -O3 output - source compiled test
pr6388 -findirect-dispatch output - bytecode->native test
pr6388 output - bytecode->native test
pr6388 output - source compiled test
I see same FAILs in the RC3 testresults for x86_64, hppa, ia64,
ppc, sparc and s390 at gcc-testresults, though not for i686.
Is this a known issue?
It is now.
Same thing on mipsel-unknown-linux-gnu:
http://gcc.gnu.org/ml/gcc-testresults/2007-05/msg00265.html
This is a regression from:
http://gcc.gnu.org/ml/gcc-testresults/2007-04/msg00666.html
I was hoping that 4.2.0 would be good, but very recently someone broke
it. Don't people test for regressions before committing?
According to the testresults list, this broke between r124328 and
r124356. There were two commits to the branch in that interval. I
leave it as an exercise to the reader to determine which could have
precipitated this problem.
$ svn log -r 124328:124356
r124331 | jsm28 | 2007-05-01 10:39:16 -0700 (Tue, 01 May 2007) | 2 lines
* config/rs6000/libgcc-ppc-glibc.ver (__gcc_qgt): Fix typo.
r124338 | ian | 2007-05-01 12:23:47 -0700 (Tue, 01 May 2007) | 13 lines
PR tree-optimization/31739
* tree-vrp.c (vrp_val_is_max): New static function.
(vrp_val_is_min): New static function.
(set_value_range_to_value): Use TYPE_{MAX,MIN}_VALUE rather than
copying the node.
(set_value_range): Use vrp_val_is_{max,min}.
(extract_range_from_assert): Likewise.
(extract_range_from_binary_expr): Likewise.
(extract_range_from_unary_expr): Likewise.
(dump_value_range, vrp_meet): Likewise.
(vrp_visit_phi_node): Likewise.
* tree.c (build_distinct_type_copy): Revert change of 2007-04-27.
I will build x86_64-pc-linux-gnu before and after r124338
including PR summary in gcc-cvs commit mails
Hello. I have a question regarding the svn logs that get sent to the gcc-cvs mailing list on every commit. I was wondering if it would be possible for those mails that contain a PR number to also include the title of that PR (ie. the contents of in bugzilla). This would allow people to find the checkins that interest them without having to open each and every one in bugzilla. -- where to now? if i had to guess dirtyepic gentoo orgi'm afraid to say antarctica's next 9B81 6C9F E791 83BB 3AB3 5B2D E625 A073 8379 37E8 (0x837937E8)
Re: libjava Divide_1 and pr6388 fail on 4.2.0 RC3 for several targets
David Daney wrote:
David Daney wrote:
Kaz Kojima wrote:
Hi,
I've noticed that some libjava tests fail for SH on trunk and
4.2.0 RC3.
New tests that FAIL:
Divide_1 -O3 -findirect-dispatch output - bytecode->native test
Divide_1 -O3 output - bytecode->native test
Divide_1 -O3 output - source compiled test
Divide_1 -findirect-dispatch output - bytecode->native test
Divide_1 output - bytecode->native test
Divide_1 output - source compiled test
pr6388 -O3 -findirect-dispatch output - bytecode->native test
pr6388 -O3 output - bytecode->native test
pr6388 -O3 output - source compiled test
pr6388 -findirect-dispatch output - bytecode->native test
pr6388 output - bytecode->native test
pr6388 output - source compiled test
I see same FAILs in the RC3 testresults for x86_64, hppa, ia64,
ppc, sparc and s390 at gcc-testresults, though not for i686.
Is this a known issue?
It is now.
Same thing on mipsel-unknown-linux-gnu:
http://gcc.gnu.org/ml/gcc-testresults/2007-05/msg00265.html
This is a regression from:
http://gcc.gnu.org/ml/gcc-testresults/2007-04/msg00666.html
I was hoping that 4.2.0 would be good, but very recently someone
broke it. Don't people test for regressions before committing?
According to the testresults list, this broke between r124328 and
r124356. There were two commits to the branch in that interval. I
leave it as an exercise to the reader to determine which could have
precipitated this problem.
$ svn log -r 124328:124356
r124331 | jsm28 | 2007-05-01 10:39:16 -0700 (Tue, 01 May 2007) | 2 lines
* config/rs6000/libgcc-ppc-glibc.ver (__gcc_qgt): Fix typo.
r124338 | ian | 2007-05-01 12:23:47 -0700 (Tue, 01 May 2007) | 13 lines
PR tree-optimization/31739
* tree-vrp.c (vrp_val_is_max): New static function.
(vrp_val_is_min): New static function.
(set_value_range_to_value): Use TYPE_{MAX,MIN}_VALUE rather than
copying the node.
(set_value_range): Use vrp_val_is_{max,min}.
(extract_range_from_assert): Likewise.
(extract_range_from_binary_expr): Likewise.
(extract_range_from_unary_expr): Likewise.
(dump_value_range, vrp_meet): Likewise.
(vrp_visit_phi_node): Likewise.
* tree.c (build_distinct_type_copy): Revert change of 2007-04-27.
I will build x86_64-pc-linux-gnu before and after r124338
This is now: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31842
Successful build of GCC 4.2.0 RC3 on latest Cygwin snapshot 20070427
I have successfully built GCC-4.2.0-20070501 on latest Cygwin snapshot 20070427. GCC 4.2.0 RC3 is available from: ftp://gcc.gnu.org/pub/gcc/prerelease-4.2.0-20070501 I have not done run the testsuite ( make check) but have built LLVM and LLVM-GCC4. So indications are very good. Aaron
