--- Comment #5 from jakub at gcc dot gnu dot org 2010-03-17 21:44 ---
Argh, seems ARM is very badly abusing PRE_DEC:
(insn/f 72 41 73 2 /opt/trunk/libgcc/../gcc/libgcc2.c:553 (parallel [
(set (mem/c:BLK (pre_dec:BLK (reg/f:SI 13 sp)) [6 A8])
(unspec:BLK [
--- Comment #1 from tromey at gcc dot gnu dot org 2010-03-17 21:46 ---
I tried it and it works fine with svn head.
Make sure to rm a.h before trying with different flags.
Or, use -force.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
C++ inlining of virtual calls does not occur in many instances when it should
be easy to determine that it is safe.
The problem occurs when there is an object that is referred to via a pointer or
reference. Normally a virtual call through a pointer cannot be inlined because
it is not known what it
--- Comment #8 from sje at cup dot hp dot com 2010-03-17 22:09 ---
I tried the patch and didn't have any problem bootstrapping and I didn't see
any regressions. It also fixed my small test case, but when I went back and
tried some of the other tests from PR 28490 I still saw some of the
symbol.c's gfc_build_class_symbol has:
(*as) = NULL; /* XXX */
Thus the following invalid program is accepted as the check for
"Assumed size array at %L must be a dummy argument" fails as sym->as == NULL.
module m
type t
end type t
end module m
subroutine foo()
use m
class(t), pointer
--- Comment #12 from kargl at gcc dot gnu dot org 2010-03-17 22:20 ---
(In reply to comment #10)
> (In reply to comment #9)
> > (In reply to comment #8)
> > > Maybe we just need to document that -pedantic changes the range of
> > > integers to
> > > be what the Fortran standard requires
--- Comment #13 from kargl at gcc dot gnu dot org 2010-03-17 22:26 ---
(In reply to comment #11)
> > Well, the number model is symmetric. See Fortran 2003 ...
>
> I agree, but it is a very pedantic view that should at least be mentioned in
> the manual.
You forgot to attach your patch.
The powerpc64-unknown-linux-gnu compiler generates much worse code on the
inl1130 function in the gromacs benchmark from spec 2006 when compiling for the
VSX instruction set with -mcpu=power7 (or -mvsx). The code in question in not
vectorizable, and in fact only uses integer and single precision f
--- Comment #1 from meissner at gcc dot gnu dot org 2010-03-17 22:35
---
Created an attachment (id=20134)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20134&action=view)
Test case from the gromacs benchmark
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43413
--- Comment #2 from meissner at gcc dot gnu dot org 2010-03-17 22:37
---
Created an attachment (id=20135)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20135&action=view)
Bzip2 tar file of the assembly output for altivec, vsx, scalar, and no-spill
--
http://gcc.gnu.org/bugzil
--- Comment #3 from meissner at gcc dot gnu dot org 2010-03-17 22:38
---
Created an attachment (id=20136)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20136&action=view)
Bzip2 tar file of the ira dump output for altivec, vsx, scalar, and no-spill
--
http://gcc.gnu.org/bugzil
--- Comment #6 from ramana at gcc dot gnu dot org 2010-03-17 22:43 ---
As per Comment #4 and based on conversations on IRC, this is certainly a target
bug . I have verified that this very testcase attached also has the same effect
on the arm-eabi target ( a simple -g -O2 is enough to tri
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43399
DWARF4 draft: http://dwarfstd.org/doc/DWARF4-public-review.pdf
gfortran uses
main()
to initialize the program and
MAIN__
as actual Fortran program.
DWARF4 offers:
DW_AT_main_subprogram Main or starting subprogram
Unit containing main or starting subprogram
File:
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-03-17 23:14 ---
I had filed PR 23280 for that really but it turned out I used the incorrect
dwarf and it pushed to alternative entry points.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #9 from wilson at codesourcery dot com 2010-03-17 23:25 ---
Subject: Re: [ia64] Inappropriate address spills
On Wed, 2010-03-17 at 22:09 +, sje at cup dot hp dot com wrote:
> I tried the patch and didn't have any problem bootstrapping and I didn't see
> any regressions.
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
CC||rearnsha at gcc dot gnu dot
|
--- Comment #10 from sje at cup dot hp dot com 2010-03-17 23:47 ---
Reading Richard's initial comment I thought the problem was that the code was
(or could be) illegal because the relocation may be out of range and we
shouldn't
use the gprel relocation for any of these constant pool refe
I came across some source code that failed to compile in gcc 4.4.3 with -O3
because the kernel shot gcc for using too much memory. After I minimized the
code (and converted it from C++ to C for simplicity) into the below example,
gcc 4.4.3 still took over a minute of CPU and a gigabyte of RAM for
--- Comment #11 from wilson at codesourcery dot com 2010-03-18 00:12
---
Subject: Re: [ia64] Inappropriate address spills
On Wed, 2010-03-17 at 23:47 +, sje at cup dot hp dot com wrote:
> Reading Richard's initial comment I thought the problem was that the code was
> (or could be)
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
Component|bootstrap |target
Priority|P3 |P1
http://g
--- Comment #8 from doko at ubuntu dot com 2010-03-18 00:52 ---
checked that this patch fixes the testcase, and doesn't show any regressions on
ia64-linux-gnu for the testsuite (4.4 branch 20100311).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43348
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2010-03-18 02:14
---
I have a few other bugs ahead of this, but I will fix it if no one else does so
before I get to it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43409
--- Comment #19 from jvdelisle at gcc dot gnu dot org 2010-03-18 02:38
---
Subject: Bug 43265
Author: jvdelisle
Date: Thu Mar 18 02:38:17 2010
New Revision: 157527
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157527
Log:
2010-03-17 Jerry DeLisle
PR libfortran/4326
--- Comment #20 from jvdelisle at gcc dot gnu dot org 2010-03-18 02:43
---
Subject: Bug 43265
Author: jvdelisle
Date: Thu Mar 18 02:43:10 2010
New Revision: 157528
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157528
Log:
2010-03-17 Jerry DeLisle
PR libfortran/4326
--- Comment #21 from jvdelisle at gcc dot gnu dot org 2010-03-18 02:52
---
The above patches take care of several other corner cases with end file
conditions. Thanks Terry for report and Tobias for helping with test cases.
I am not proceeding to back port to 4.4.
--
http://gcc.gnu
--- Comment #22 from jvdelisle at gcc dot gnu dot org 2010-03-18 02:54
---
Correction s/not/now
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43265
--- Comment #9 from bergner at gcc dot gnu dot org 2010-03-18 03:10 ---
Subject: Bug 42427
Author: bergner
Date: Thu Mar 18 03:10:04 2010
New Revision: 157530
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157530
Log:
gcc/
PR target/42427
* config/rs6000/rs6000.c
I came across some code that previously compiled at -O3 without complaint on
gcc version 4.3.0 20080428 (Red Hat 4.3.0-8) and gcc version 4.4.1 (Ubuntu
4.4.1-4ubuntu9), but triggered a segmentation fault on gcc 4.4.3. After
minimization, here is the segmentation fault:
$ /net/test-hsa014/wlam/loc
--- Comment #1 from wlam at kosmix dot com 2010-03-18 03:11 ---
Created an attachment (id=20137)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20137&action=view)
Minimized C++ source causing segmentation fault in gcc 4.4.3 at -O3
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=
--- Comment #10 from bergner at gcc dot gnu dot org 2010-03-18 03:14
---
Fixed.
--
bergner at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNE
--- Comment #2 from wlam at kosmix dot com 2010-03-18 03:14 ---
Oops, the description is truncated:
(built from the GNU source distribution, though the Fedora version of 4.4.3
shows similar behavior--
$ g++ -Wfatal-errors -c -O3 -Wall foo.ccfoo.cc: In member function void
TypeRegistry
--- Comment #23 from jvdelisle at gcc dot gnu dot org 2010-03-18 03:52
---
Subject: Bug 43265
Author: jvdelisle
Date: Thu Mar 18 03:51:43 2010
New Revision: 157532
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157532
Log:
2010-03-17 Jerry DeLisle
PR libfortran/4326
--- Comment #5 from carrot at google dot com 2010-03-18 03:52 ---
In this case arm_arm_address_cost does the right thing. The problem is in
function should_replace_address.
When two addresses have same address cost, we choose the one with higher rtx
cost. The reason is "That has the pot
--- Comment #24 from jvdelisle at gcc dot gnu dot org 2010-03-18 03:56
---
Subject: Bug 43265
Author: jvdelisle
Date: Thu Mar 18 03:55:52 2010
New Revision: 157533
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157533
Log:
2010-03-17 Jerry DeLisle
PR libfortran/4326
--- Comment #25 from jvdelisle at gcc dot gnu dot org 2010-03-18 03:58
---
IO library is significantly changed from 4.3 to 4.4/4.5 No Backport to 4.3
Closing.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--
101 - 136 of 136 matches
Mail list logo
