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[])
{
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 acce
--- 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.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=
--- 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 #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, w
--- 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 #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 ord
--- 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 #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 o
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 #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 th
--- 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 looki
--- 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 #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
Assign
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|major |normal
Component|c++ |debug
--- 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 c
--- 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
--- 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 #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 #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. (Compa
--- 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 #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
--
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|blocker |normal
Component|c |target
http:
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 --pref
--- 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 ex
--- 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 re
--- 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 analyze_subscript_affine_
--- 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 #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 ha
--- 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 te
--- 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 gcc
--- 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 #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 #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 #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
--
http://gcc.gnu.org/bugzilla/s
--
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 #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 bring
--- 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 #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=13792&action=view)
Test case
I believe the attached program is valid in Fortran 2003 (modulo typos; as no
compiler accepts it, I ca
! 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
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 o
--- 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-2
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 any
--- 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
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 #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:
Can we get a better error message than "recursive inlining", btw? :-)
--
Daniel Jacobowitz
CodeSourcery
--- 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
--- 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 2
--- 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 #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 informa
--- 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 #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 #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
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- 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
-
--- 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 #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" tes
--- 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 #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 #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=gcc&view=rev&rev=126027
Log:
2007-03-30 Jason Merrill <[EMAIL PROTECTED]>
PR c++/3
--- 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 #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=gcc&view=rev&rev=126026
Log:
2006-10-18 Jan Hubicka <[EMAIL PROTECTED]>
PR middle-
--- 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=gcc&view=rev&rev=126024
Log:
PR tree-opt/29059
* tree-ssa-propagate.c (set_rhs
--- 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=gcc&view=rev&rev=126023
Log:
PR middle-end/29272
* builtins.c (fold_builtin_m
--- 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=gcc&view=rev&rev=126022
Log:
PR middle-end/27567
* builtins.c (fold_builtin_m
--- 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=gcc&view=rev&rev=126021
Log:
PR preprocessor/28709
* macro.c (paste_tokens):
--- 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 #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|Remov
--- 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 #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 #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)
constant invariant 32>
unit size constant invariant 4>
align 32 symtab 0 alias set -1 canonical type 0x2b07ce1fb540 precision 32
mi
--- 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 eve
--- 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=13791&action=view)
fix PR31150
Attached is a patch to initialize the scalar elmenets of the array
which should fix this problem.
cha
74 matches
Mail list logo
