--- Comment #5 from nightstrike at gmail dot com 2008-05-25 06:54 ---
I am regtesting it now. Note that it will take a very long time to complete
(several days).
This does apply to 4.3 and 4.4
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36321
--- Comment #1 from oliver dot kellogg at eads dot com 2008-05-25 09:39
---
Must have been some leftovers in my build dir.
Works after complete rebuild from scratch. Sorry for the noise
--
oliver dot kellogg at eads dot com changed:
What|Removed
--- Comment #3 from oliver dot kellogg at eads dot com 2008-05-25 10:38
---
Does not happen with -gnatc (syntax and semantics check only.)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34898
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-05-25 12:03 ---
Does enabling optimization (-O) fix the problem? My guess is that the
gimplification of the aggregate assignments creates lots of overhead, but that
needs to be investigated by Ada people - stats with a compiler
--- Comment #9 from jv244 at cam dot ac dot uk 2008-05-25 12:13 ---
It's not complete yet, and some details need to be fixed, but the basic
functionality is there. I hope it can be committed to trunk quite soon.
that would be great... I really hope this will be enough to enable the
mora celeste
kristina
meltin calvin
kongjoo cimarron dong hplab jill
arun hashim
--- Comment #7 from rguenth at gcc dot gnu dot org 2008-05-25 13:48 ---
Well, this assignment seems to be _very_ expensive both in terms of parsing
time
and size of the IL to expand. It certainly looks unreasonable.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34898
I think the following code is invalid:
interface
subroutine foo
end subroutine
end interface
external foo
Because the INTERFACE statement already specifies the EXTERNAL attribute, which
is thus specified twice.
This code *is* actually rejected (as of rev. 135859), but the error message is
--- Comment #5 from oliver dot kellogg at eads dot com 2008-05-25 13:31
---
Created an attachment (id=15679)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15679action=view)
statistics output from gnat1 on pkg001u.adb without aggregate assignments
--
--- Comment #6 from oliver dot kellogg at eads dot com 2008-05-25 13:38
---
Created an attachment (id=15680)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15680action=view)
statistics output from gnat1 on pkg001u.adb with one assignment
Here, I enabled the assignment in line 377,
--- Comment #1 from jaydub66 at gmail dot com 2008-05-25 14:02 ---
Here is a first patch:
Index: gcc/fortran/symbol.c
===
--- gcc/fortran/symbol.c(revision 135859)
+++ gcc/fortran/symbol.c(working copy)
@@
--- Comment #2 from jaydub66 at gmail dot com 2008-05-25 14:45 ---
Ok, this produces an impressive list of regressions.
Many of those (e.g. actual_procedure_1.f90) seem to be related to
conf (external, dimension); /* See Fortran 95's R504. */
I'm not sure if the constraint from
--- Comment #3 from burnus at gcc dot gnu dot org 2008-05-25 15:36 ---
Ok, this produces an impressive list of regressions.
Many of those (e.g. actual_procedure_1.f90) seem to be related to
conf (external, dimension); /* See Fortran 95's R504. */
I'm not sure if the constraint
--- Comment #8 from oliver dot kellogg at eads dot com 2008-05-25 15:42
---
(in reply to comment #4)
Does enabling optimization (-O) fix the problem?
No, does not change the behavior (other than taking even longer)
[...] stats with a compiler configured with
union X { int i; double x; };
int foo (union X *p)
{
union X x = *p;
return x.x;
}
produces
union X x.0;
x.0 = *p;
x = x.0;
this is not optimized at any point. Using a struct instead usually SRA
is able to remove the extra copy.
--
Summary: gimplification of aggregate
--- Comment #4 from janus at gcc dot gnu dot org 2008-05-25 16:37 ---
(In reply to comment #2)
Others testcases (like argument_checking_3.f90) fail because they define lots
of specific interfaces, but no external implementation for those.
Obviously I got this wrong. The actual reason
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-05-25 16:47 ---
Caused by the fix for PR17526.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
OK, this bug was brought on by a mistake I made while writing a
removenode function for a linked list class that I'm making in C++.
It's easy to trigger and, while a program written correctly won't ever
experience a defect from it, it does cause problems while debugging.
I'm using gcc 4.3.0.
--- Comment #5 from burnus at gcc dot gnu dot org 2008-05-25 17:11 ---
Which leads me to think we should probably implement this (for the case that
the interface is explicit). Or is there any good reason that this is not done?
Well, regarding the reason: Before interfaces had no
--- Comment #35 from rguenth at gcc dot gnu dot org 2008-05-25 17:17
---
Subject: Bug 17526
Author: rguenth
Date: Sun May 25 17:16:38 2008
New Revision: 135876
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=135876
Log:
2008-05-25 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-05-25 17:18 ---
Which was just a workaround. It needs proper fixing so that
Index: tree-gimple.c
===
--- tree-gimple.c (revision 135859)
+++ tree-gimple.c
struct X { int i; int j; };
void bar (struct X *);
int foo (struct X *p)
{
struct X x;
p-i = 1;
x = *p;
x.j = 2;
return p-i - x.i;
}
this should be optimized to return zero. -fno-tree-sra required to show
the missed optimization.
--
Summary: SCCVN should look through
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot
|dot org
--- Comment #26 from ghazi at gcc dot gnu dot org 2008-05-25 17:29 ---
I also get this failure on x86 when using ilp32 pic. See:
x86_64: http://gcc.gnu.org/ml/gcc-testresults/2008-05/msg02221.html
i686: http://gcc.gnu.org/ml/gcc-testresults/2008-05/msg01800.html
--
ghazi at gcc
--- Comment #1 from ghazi at gcc dot gnu dot org 2008-05-25 17:31 ---
I also get this failure on x86 when using ilp32 pic. See:
x86_64: http://gcc.gnu.org/ml/gcc-testresults/2008-05/msg02221.html
i686: http://gcc.gnu.org/ml/gcc-testresults/2008-05/msg01800.html
--
ghazi at gcc dot
--- Comment #14 from burnus at gcc dot gnu dot org 2008-05-25 17:52 ---
Subject: Bug 32600
Author: burnus
Date: Sun May 25 17:52:03 2008
New Revision: 135877
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=135877
Log:
2008-05-25 Tobias Burnus [EMAIL PROTECTED]
PR
--- Comment #15 from burnus at gcc dot gnu dot org 2008-05-25 17:55 ---
FIXED on the trunk (4.4).
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from ghazi at gcc dot gnu dot org 2008-05-25 18:03 ---
The testcase also fails for me on x86_64-unknown-linux-gnu or
i686-unknown-linux-gnu but requires -fpic/-fPIC to trigger. (That may explain
the darwin x86 error.) See:
x86_64:
--- Comment #10 from ghazi at gcc dot gnu dot org 2008-05-25 18:08 ---
I see the failure with x86_64 -m32 or native i686 on the trunk:
x86_64: http://gcc.gnu.org/ml/gcc-testresults/2008-05/msg02221.html
i686: http://gcc.gnu.org/ml/gcc-testresults/2008-05/msg01800.html
--
ghazi at
--- Comment #9 from oliver dot kellogg at eads dot com 2008-05-25 18:12
---
Created an attachment (id=15681)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15681action=view)
gnat1 (trunk r135848) output from -fmem-report, no aggregate assignments
--
--- Comment #10 from ghazi at gcc dot gnu dot org 2008-05-25 18:13 ---
Failure also occurs on x86_64-unknown-linux-gnu and i686-unknown-linux-gnu,
see:
x86_64: http://gcc.gnu.org/ml/gcc-testresults/2008-05/msg02221.html
i686: http://gcc.gnu.org/ml/gcc-testresults/2008-05/msg01800.html
--- Comment #10 from oliver dot kellogg at eads dot com 2008-05-25 18:17
---
Created an attachment (id=15682)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15682action=view)
same as above but with assignments in pkg001u.adb lines 296 and 377 enabled
--
--- Comment #11 from oliver dot kellogg at eads dot com 2008-05-25 18:43
---
Created an attachment (id=15683)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15683action=view)
att15682 was incorrect, two assignments already exhaust the memory. memreport
for _one_ assignmt.
--
--- Comment #12 from rguenth at gcc dot gnu dot org 2008-05-25 18:56
---
ada/utils2.c:1774 (build_simple_component_ref)111547200:71.1%
clearly a frontend issue.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from janus at gcc dot gnu dot org 2008-05-25 19:08 ---
Created an attachment (id=15684)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15684action=view)
patch
Ok, I extended the patch, and got the regression count down from a few million
to exactly two:
FAIL:
--- Comment #5 from pluto at agmk dot net 2008-05-25 19:20 ---
(In reply to comment #4)
This would fix it.
4.3.1-20080525 with this patch seems to work fine.
Index: tree-eh.c
===
--- tree-eh.c (revision 135433
gcc 4.3.0 was configured with an explicit exec-prefix (different from prefix):
$ ../configure --target=powerpc-rtems --prefix=/opt/rtems-head//host
--exec-prefix=/opt/rtems-head//host/i386_linux26/gcc-4.3.0
--mandir=/opt/rtems-head//doc/man --infodir=/opt/rtems-head//doc/info
Something doesn't work as expected with tree inlining. This is visible by
adding the missing check to the CALL_CANNOT_INLINE_P flag:
#define CALL_CANNOT_INLINE_P(NODE) (CALL_EXPR_CHECK (NODE)-base.static_flag)
You get gazillions of failures in the C testsuite coming from cgraphbuild.c
and
--- Comment #7 from burnus at gcc dot gnu dot org 2008-05-25 19:58 ---
Patch is attached.
You need also to reject the following, which violates R504.
interface
real function bar()
end function bar
end interface
dimension :: bar(4)
end
--
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-05-25 19:59 ---
The call edge's statement will either be an assignment (whos rhs is a call
expression) or a call expression (if the call's return value is ignored).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36329
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-05-25 20:00 ---
The checks in ipa-inline.c should all look like CALL_CANNOT_INLINE_P
(get_call_expr_in (...)).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36329
--- Comment #1 from tkoenig at gcc dot gnu dot org 2008-05-25 20:03 ---
This should be fun :-)
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from tkoenig at gcc dot gnu dot org 2008-05-25 20:08 ---
This works for me down to 4.1.3:
$ gfortran-4.1 -static foo.f
$ ./a.out
$ head -4 fort.10
0.99950656E+00 0.31410759E-01 0.99950656E+00 0.31410759E-01
0.99802673E+00 0.62790520E-01 0.99802673E+00
--- Comment #7 from jakub at gcc dot gnu dot org 2008-05-25 20:24 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #2 from burnus at gcc dot gnu dot org 2008-05-25 21:28 ---
Close as invalid. If you think this is an error, please reopen. If you have
further questions, send those to the gfortran mailing list.
Thanks for sending a bugreport after finding a bug. (Even though it turned out
--- Comment #5 from burnus at gcc dot gnu dot org 2008-05-25 22:00 ---
Somewhere a
fold_convert (TREE_TYPE (to_tree), from_tree)
is missing, but I fail to see where. I think one could add a couple of those in
trans-array.c; I think there is more than one missing.
--
--- Comment #8 from janus at gcc dot gnu dot org 2008-05-25 22:33 ---
The failure of proc_decl_9.f90 was actually due to a bug that slipped in with
my procedure declaration update patch from May 1st, which I have fixed now.
So we're left with gomp/reduction3.f90, which contains this
--- Comment #9 from dfranke at gcc dot gnu dot org 2008-05-25 22:38 ---
Subject: Bug 18428
Author: dfranke
Date: Sun May 25 22:37:41 2008
New Revision: 135882
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=135882
Log:
gcc:
2008-05-26 Daniel Franke [EMAIL PROTECTED]
PR
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dfranke at gcc dot gnu dot
|dot org
i386-pc-solaris2.10 configure: error: C compiler cannot create executables.
gcc-4.3.1-RC-20080523.tar.bz2
binutils 2.18
Solaris 10 x86_64 U4
I can build gcc 4.2.3.
But I can't build gcc 4.2.4 and 4.3.1.
pwd: /export/home/test/gcc-4.3.1-build/build/i386-pc-solaris2.10
configure: creating cache
--- Comment #1 from cnstar9988 at gmail dot com 2008-05-26 00:43 ---
gmp 4.2.2, mpfr 2.3.1
Both gmp and mpfr build with --disable-shared ABI=32
gcc 4.3.1 configure:
../src/configure --prefix=/opt/gcc-4.3.1 --with-gmp=/opt/gcc-4.3.1/gmp
--with-mpfr=/opt/gcc-4.3.1/mpfr
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-05-26 00:50 ---
-m64
Use --disable-multilib.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from cnstar9988 at gmail dot com 2008-05-26 00:54 ---
I want both build my programs -m32 -m64
My OS is solaris 10 x86_64.
I can run well with gcc 4.2.3.
If I build gcc 4.3.1 with --disable-multilib, I can only compile with apps with
-m32?
--
cnstar9988 at gmail dot
On Linux/ia32, Linux/Intel64 and Linux/ia64, when configured with
--enable-clocale=gnu --with-system-zlib --enable-decimal-float=bid
--with-demangler-in-ld --enable-shared --enable-threads=posix --enable-haifa
--enable-checking=assert --prefix=/usr/gcc-4.4 --with-local-prefix=/usr/local
revision
--- Comment #4 from cnstar9988 at gmail dot com 2008-05-26 02:14 ---
gcc 4.3.1 can build with --disable-multilib on i386-pc-solaris2.10.
It can only compiles 32bit apps.
gcc 4.3.1 can build on sparc-sun-solaris2.10.
It can compiles 32bit and 64bit apps.
55 matches
Mail list logo
