gfortran currently implements the TRANSPOSE intrinsic by simply rearranging the
array descriptor, which can save considerable time when passed to an
assumed-shape argument. Two more intrinsics can be implemented in this way:
RESHAPE can check for contiguity of its argument and if so, only
--- Comment #1 from highegg at gmail dot com 2007-06-26 06:36 ---
Created an attachment (id=13790)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13790action=view)
speedtester of TRANSPOSE, RESHAPE and SPREAD
this testcase tests speed of constructing an array via TRANSPOSE, RESHAPE
--- Comment #3 from eres at il dot ibm dot com 2007-06-26 07:42 ---
Created an attachment (id=13791)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13791action=view)
fix PR31150
Attached is a patch to initialize the scalar elmenets of the array
which should fix this problem.
char
--- Comment #4 from pault at gcc dot gnu dot org 2007-06-26 09:48 ---
(In reply to comment #3)
I have a fix for this that needs a bit of cleaning up - will submit tonight.
For some reason, gfc_simplify_repeat denies even the possibility of character
literal arguments - it's not even
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-06-26 10:32 ---
The types do not match at gimplification time:
(gdb) call debug_tree (x)
integer_type 0x2b07ce1fb540 int public SI
size integer_cst 0x2b07ce1e8a50 type integer_type 0x2b07ce1fb0c0
bit_size_type constant
--- Comment #10 from rguenth at gcc dot gnu dot org 2007-06-26 10:45
---
Confirmed. This is a VRP or SCEV bug.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-06-26 10:47 ---
Confirmed. I had done tree-level expansion of powi into add/mul sequences at
one time. But this had been rejected for some reason I cannot remember right
now.
--
rguenth at gcc dot gnu dot org changed:
--- Comment #2 from highegg at gmail dot com 2007-06-26 10:56 ---
Just an informal note:
Apparently (using the testcase), EkoPath 3.0 has a fast RESHAPE but not
fast SPREAD, while Intel 9.1 and current g95 have neither.
--
highegg at gmail dot com changed:
What
--- Comment #11 from ed at fxq dot nl 2007-06-26 11:26 ---
It seems to be solved when using -fno-tree-vrp.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32500
--- Comment #14 from jakub at gcc dot gnu dot org 2007-06-26 11:44 ---
Subject: Bug 28709
Author: jakub
Date: Tue Jun 26 11:43:50 2007
New Revision: 126021
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126021
Log:
PR preprocessor/28709
* macro.c (paste_tokens):
--- Comment #12 from jakub at gcc dot gnu dot org 2007-06-26 11:45 ---
Subject: Bug 27567
Author: jakub
Date: Tue Jun 26 11:45:35 2007
New Revision: 126022
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126022
Log:
PR middle-end/27567
* builtins.c
--- Comment #18 from jakub at gcc dot gnu dot org 2007-06-26 11:47 ---
Subject: Bug 29272
Author: jakub
Date: Tue Jun 26 11:47:19 2007
New Revision: 126023
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126023
Log:
PR middle-end/29272
* builtins.c
--- Comment #9 from jakub at gcc dot gnu dot org 2007-06-26 11:49 ---
Subject: Bug 29059
Author: jakub
Date: Tue Jun 26 11:48:55 2007
New Revision: 126024
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126024
Log:
PR tree-opt/29059
* tree-ssa-propagate.c
--- Comment #12 from jakub at gcc dot gnu dot org 2007-06-26 11:52 ---
Subject: Bug 29299
Author: jakub
Date: Tue Jun 26 11:52:20 2007
New Revision: 126026
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126026
Log:
2006-10-18 Jan Hubicka [EMAIL PROTECTED]
PR
--- Comment #3 from burnus at gcc dot gnu dot org 2007-06-26 11:54 ---
Just to show how much time can be saved, I compared the speed with different
compilers (on x86-64/Linux):
gfortran sunstudio12 ifort9.1/10 open64 NAGf95 g95
---
--- Comment #10 from jakub at gcc dot gnu dot org 2007-06-26 11:57 ---
Subject: Bug 31187
Author: jakub
Date: Tue Jun 26 11:57:42 2007
New Revision: 126027
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126027
Log:
2007-03-30 Jason Merrill [EMAIL PROTECTED]
PR
--- Comment #2 from mark at codesourcery dot com 2007-06-26 12:14 ---
Subject: Re: [4.3 Regression] attribute always_inline -
sorry, unimplemented: recursive inlining
rguenth at gcc dot gnu dot org wrote:
TYPE_ARG_TYPES says we want a char, but the call expression has an int. I
--- Comment #4 from eres at il dot ibm dot com 2007-06-26 12:19 ---
There are places which checks that bsi_insert_on_edge_immediate returns
NULL so checking for NULL before calling it would change the semantic.
Here is the fix for this SIGSEGV:
Index: tree-cfg.c
--- Comment #4 from debian-gcc at lists dot debian dot org 2007-06-26
12:28 ---
ok, this is dependent on the build environment; I'm still unsure why I don't
see this on the gcc-4_1-branch. both 4.1 and 4.2 are configured with
--enable-clocale=gnu. On the gcc-4_1-branch, the sanity test
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-26 13:33 ---
*** This bug has been marked as a duplicate of 32374 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from pinskia at gcc dot gnu dot org 2007-06-26 13:33
---
*** Bug 32342 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #33 from manu at gcc dot gnu dot org 2007-06-26 14:38 ---
(In reply to comment #31)
Just mentioning: printf() and std::cout need to be updated if the binary
values
are also to be *output*. Any ideas on how or where that is to be done?
As Joerg pointed out, that is a
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-06-26 14:39 ---
The C front-end has the same wrong type. ./cc1 -funit-at-a-time t.c gives:
t33.c: In function 'f3':
t33.c:2: sorry, unimplemented: inlining failed in call to 'f2': recursive
inlining
t33.c:3: sorry, unimplemented:
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-06-26 14:51 ---
Related to PR 15484, at least that PR is the underlying cause.
For the C front-end the promoting happens in convert_arguments, c-typeck.c.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-06-26 14:53 ---
I am going to change the component as middle-end while someone figures out if
we want to promote in the front-ends or later on. I say we want to promote in
front-ends rather than later on because we get more
--- Comment #3 from jv244 at cam dot ac dot uk 2007-06-26 14:59 ---
I ran the compilation now on a machine with 64Gb of memory, and it still
failed.
According to 'top' the memory used by f951 was about 4Gb. The error message:
f951: out of memory allocating 4064 bytes after a total of
--- Comment #6 from rguenther at suse dot de 2007-06-26 15:03 ---
Subject: Re: [4.3 Regression] attribute always_inline
- sorry, unimplemented: recursive inlining
On Tue, 26 Jun 2007, pinskia at gcc dot gnu dot org wrote:
--- Comment #5 from pinskia at gcc dot gnu dot org
--- Comment #3 from anhvofrcaus at gmail dot com 2007-06-26 15:15 ---
This problem does not occur in gcc-4.3-20070615.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31669
Can we get a better error message than recursive inlining, btw? :-)
--
Daniel Jacobowitz
CodeSourcery
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-26 15:16 ---
This is not a GCC bug. Most likely what is happening is recodif is changing
LD_LIBRARY_PATH and ignoring the old one. There is nothing GCC can do about
this.
--
pinskia at gcc dot gnu dot org changed:
On 26 Jun 2007 14:59:27 -, jv244 at cam dot ac dot uk
[EMAIL PROTECTED] wrote:
f951: out of memory allocating 4064 bytes after a total of 1148219392 bytes
Ignore the second number, it just is total count of memory allocated
via xmalloc and not the amount of memory used at the time of the
--- Comment #4 from pinskia at gmail dot com 2007-06-26 15:20 ---
Subject: Re: hard-coded memory limit ? f951: out of memory with '-O1
-fbounds-check'
On 26 Jun 2007 14:59:27 -, jv244 at cam dot ac dot uk
[EMAIL PROTECTED] wrote:
f951: out of memory allocating 4064 bytes after a
On 26 Jun 2007 03:10:26 -, acahalan at gmail dot com
[EMAIL PROTECTED] wrote:
--- Comment #4 from acahalan at gmail dot com 2007-06-26 03:10 ---
(In reply to comment #3)
Subject: Re: Missed optimizations with -fwhole-program -combine
I would not expect this to be fixed anytime
--- Comment #5 from dberlin at gcc dot gnu dot org 2007-06-26 15:29 ---
Subject: Re: Missed optimizations with -fwhole-program -combine
On 26 Jun 2007 03:10:26 -, acahalan at gmail dot com
[EMAIL PROTECTED] wrote:
--- Comment #4 from acahalan at gmail dot com 2007-06-26
the source made available as
http://www.pci.unizh.ch/vandevondele/tmp/CP2K_gcc_2007_06.tgz
gfortran -O1 -fprofile-generate all.f90
fails with
f951: out of memory allocating 9 bytes after a total of 1076375552 bytes
even though the machine has 64Gb of ram, and according to top f951 uses
! F95: 14.1.2.1:
! A common block name in a scoping unit also may be the name of any local
! entity other than a named constant, intrinsic procedure, or a local variable
! that is also an external function in a function subprogram.
!
! F2003: 16.2.1
! A name that identifies a common block in a
--- Comment #1 from burnus at gcc dot gnu dot org 2007-06-26 15:52 ---
Created an attachment (id=13792)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13792action=view)
Test case
I believe the attached program is valid in Fortran 2003 (modulo typos; as no
compiler accepts it, I
--- Comment #13 from spop at gcc dot gnu dot org 2007-06-26 16:03 ---
Subject: Re: [4.3 Regression] Complete program optimized away (i686,
-ftree-vectorize)
I just reduced the problem to this snippet: the problem seems to be
that the data dependence analysis is wrong by answering that
--- Comment #4 from srm at schokokeks dot org 2007-06-26 16:12 ---
the same here on gentoo-ppc-2.6.21, using gcc-4.1.2
Powerbook G4(5,6)
trying to compile Crystalspace v1.2 --with-python
When ommiting -fPIC OR using --without-python, the build works.
I will see if a revert to 4.1.1
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |burnus at gcc dot gnu dot
|dot org
--- Comment #9 from patchapp at dberlin dot org 2007-06-26 16:25 ---
Subject: Bug number PR 25062
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-06/msg01932.html
--
--- Comment #14 from burnus at gcc dot gnu dot org 2007-06-26 16:25 ---
REAL, DIMENSION(0:100) :: RBOUND
I thought that the array indices start from 1, and not from 0.
Well, dimension(5) means from 1 to 5, but e.g. dimension(-2:4:2) means the
indices {-2, 0, 2, 4}. And in the
--- Comment #7 from drow at gcc dot gnu dot org 2007-06-26 16:29 ---
Can we fix the error message, while we're here? Obviously it wasn't recursive
inlining.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32492
--- Comment #15 from spop at gcc dot gnu dot org 2007-06-26 16:33 ---
Subject: Re: [4.3 Regression] Complete program optimized away (i686,
-ftree-vectorize)
Aha, thanks for the clarifications, and sorry for the noise.
I should read again some fortran tutorial or some more code
written
--- Comment #15 from daney at gcc dot gnu dot org 2007-06-26 17:14 ---
mipsel-linux test results are here:
http://gcc.gnu.org/ml/gcc-testresults/2007-06/msg01158.html
The offending gcc.dg/cleanup-[8|9|10|11].c tests now pass as do almost all C++
and libstdc++ tests.
--
daney at
--- Comment #16 from zadeck at naturalbridge dot com 2007-06-26 17:27
---
Subject: Re: [4.3 Regression] MIPS: FAIL in gcc.dg/cleanup-[8|9|10|11].c
daney at gcc dot gnu dot org wrote:
--- Comment #15 from daney at gcc dot gnu dot org 2007-06-26 17:14
---
mipsel-linux test
--- Comment #17 from dave at hiauly1 dot hia dot nrc dot ca 2007-06-26
17:46 ---
Subject: Re: [4.3 Regression] MIPS: FAIL in gcc.dg/cleanup-[8|9|10|11].c
The offending gcc.dg/cleanup-[8|9|10|11].c tests now pass as do almost all C++
and libstdc++ tests.
Unfortunately, we still
--- Comment #18 from zadeck at naturalbridge dot com 2007-06-26 17:53
---
Subject: Re: [4.3 Regression] MIPS: FAIL in gcc.dg/cleanup-[8|9|10|11].c
dave at hiauly1 dot hia dot nrc dot ca wrote:
--- Comment #17 from dave at hiauly1 dot hia dot nrc dot ca 2007-06-26
17:46
--- Comment #16 from spop at gcc dot gnu dot org 2007-06-26 18:02 ---
Subject: Re: [4.3 Regression] Complete program optimized away (i686,
-ftree-vectorize)
Hi,
The problem comes from the fact that estimated_loop_iterations_int
returns HWI whereas the code in
--- Comment #7 from longb at cray dot com 2007-06-26 18:20 ---
Subject: Re: structure containing allocatable array is
accepted in COPYIN clause
burnus at gcc dot gnu dot org wrote:
--- Comment #4 from burnus at gcc dot gnu dot org 2007-06-22 21:06
---
Thanks for the
--- Comment #3 from jb at gcc dot gnu dot org 2007-06-26 19:00 ---
(In reply to comment #2)
Confirmed. I had done tree-level expansion of powi into add/mul sequences at
one time. But this had been rejected for some reason I cannot remember right
now.
The middle-end is able to
GCC version:
GNU C version 4.2.0 (avr) compiled by GNU C version 4.1.2 20061115 (prerelease)
(Debian 4.1.1-21)
System type:
Linux xx 2.6.18-4-amd64 #1 SMP Fri May 4 00:37:33 UTC 2007 x86_64 GNU/Linux
Options given when GCC was configured/built:
Target: avr
Configured with: ../configure
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|blocker |normal
Component|c |target
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-26 19:32 ---
*** This bug has been marked as a duplicate of 31331 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-06-26 19:32 ---
*** Bug 32517 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from ubizjak at gmail dot com 2007-06-26 19:43 ---
(In reply to comment #0)
gfortran seemingly generates an significatly inferior internal TREE
representation than g95 as for Polyhedron's induct.f90 gfortran is 18% slower
than g95, which is based on GCC 4.0.3.
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-06-26 20:30 ---
They have been improvements in 4.2.0 with respect of having a smaller GOT. Can
you try 4.2.0?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28904
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-26 20:32 ---
Considering inline candidate bar.
Inlining bar into foo.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32511
--- Comment #6 from srm at schokokeks dot org 2007-06-26 20:35 ---
(In reply to comment #5)
They have been improvements in 4.2.0 with respect of having a smaller GOT.
Can
you try 4.2.0?
uh, i'd like to...give me a few days to figure out how i can do a proper
upgrade or setup a
--- Comment #8 from rguenth at gcc dot gnu dot org 2007-06-26 20:45 ---
So, without touching all the frontends we can try to lower constraints checked
at gimplification time to what is actually needed to avoid the ICE during
inlining. Which is to make sure that the actual parameter is
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|major |normal
Component|c++ |debug
--- Comment #9 from rguenth at gcc dot gnu dot org 2007-06-26 21:07 ---
I'm testing a patch.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from rguenth at gcc dot gnu dot org 2007-06-26 21:24
---
And I think we should address PR15484 and not do type promotion until RTL
expansion.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32492
--- Comment #11 from pinskia at gcc dot gnu dot org 2007-06-26 21:33
---
I can find a testcase, if we change where we generate the promotion at the RTL
expansion time, worse code.
Simple testcase:
int f(int b, char a)
{
if (b)
a = 1;
g(a);
}
You can see the difference by
--- Comment #12 from rguenther at suse dot de 2007-06-26 21:55 ---
Subject: Re: [4.3 Regression] attribute always_inline
- sorry, unimplemented: recursive inlining
On Tue, 26 Jun 2007, pinskia at gcc dot gnu dot org wrote:
I can find a testcase, if we change where we generate the
On 26 Jun 2007 21:55:34 -, rguenther at suse dot de
[EMAIL PROTECTED] wrote:
I have a hard time deciding if 3.4 or 4.1 is better:
3.4:
f:
pushl %ebp
movl%esp, %ebp
movl8(%ebp), %edx
movzbl 12(%ebp), %eax
testl %edx, %edx
je
--- Comment #13 from pinskia at gmail dot com 2007-06-26 21:59 ---
Subject: Re: [4.3 Regression] attribute always_inline - sorry, unimplemented:
recursive inlining
On 26 Jun 2007 21:55:34 -, rguenther at suse dot de
[EMAIL PROTECTED] wrote:
I have a hard time deciding if 3.4 or
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-06-26 22:08 ---
Patch testing right now.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32417
--- Comment #9 from zadeck at naturalbridge dot com 2007-06-26 23:01
---
Subject: Re: [Bug target/32437] ICE in df_refs_verify,
at df-scan.c:4058
This patch fixes a problem introduced with the patch to fix pr32437.
In that patch we introduced recursion in dce:deleteable_insn_p in
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-06-26 23:33 ---
Reduced testcase:
namespace a
{
class basic_stringstream {};
typedef basic_stringstream istream;
typedef basic_stringstream stringstream;
}
using namespace a;
void PerformTest02 ()
{
struct Manipulators
--- Comment #5 from pcarlini at suse dot de 2007-06-26 23:44 ---
Yes, today, while offline, I realized that in fact the real issue here was the
fix for 31717 not completely ok for everyone. And we already got a report of
this type before (upon it I decided to clarify the documentation,
--- Comment #18 from sebpop at gmail dot com 2007-06-26 23:54 ---
Subject: Re: [4.3 Regression] Complete program optimized away (i686,
-ftree-vectorize)
Hi,
I'm bootstrapping this patch on both amd64-linux and i686-linux.
The patch passed bootstrap and test on both machines with no
--- Comment #14 from rask at sygehus dot dk 2007-06-27 00:35 ---
Notice in comment 10 that there is no optimization flag. Just -O1 is enough to
make the reload failure go away. I'll see what the libstdc++ people have to say
about that.
--
Derived classes may access protected members of their base class only on
themselves or other instances of the same type or derived type. Here is a link
to the relevant section in the draft of the C++ standard:
http://www.csci.csusb.edu/dick/c++std/cd2/access.html#class.protected
I don't have
Consider a snippet like the following
---Begin Snippet--
#define N 2048
int main(int argc; char *argv[])
{
int mat[N][N];
,,,
---End Snippet--
or the slightly snazified C99 style
---Begin Snippet--
int main(int argc; char *argv[])
76 matches
Mail list logo
