--- Comment #1 from pinskia at gcc dot gnu dot org 2009-02-23 08:02 ---
Why don't you think all would work? So you are asking for only 8Gig of memory.
On a 64bit machine it should work because of virtual memory. Anyways the
nothrow version of operator new, just call directly malloc,
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-02-23 09:56 ---
Confirmed. Fails at least since GCC 3.3.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-02-23 09:58 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #14 from hubicka at gcc dot gnu dot org 2009-02-23 13:11
---
Subject: Bug 37709
Author: hubicka
Date: Mon Feb 23 13:10:53 2009
New Revision: 144381
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144381
Log:
PR tree-optimization/37709
--- Comment #15 from hubicka at gcc dot gnu dot org 2009-02-23 13:12
---
Fixed.
--
hubicka at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #19 from rguenth at gcc dot gnu dot org 2009-02-23 13:35
---
To be fixed with the alias-improvements branch merge. Not going to be fixed
on the 4.3 or the 4.4 branch.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #44 from hubicka at gcc dot gnu dot org 2009-02-23 13:41
---
Hi,
I believe that using fold_convert instead of fold_build1 means that we would
bypass folding done in fold_unary that handles stuff like two conversions in a
row while fold_convert is primarily about returning
--- Comment #23 from rguenth at gcc dot gnu dot org 2009-02-23 13:43
---
-O2 compile-time improved from ~300s to ~180s over the last 1.5 years.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12392
--- Comment #5 from jamborm at gcc dot gnu dot org 2009-02-23 14:09 ---
I don't understand the comment above the assert at all (Honza probably
does) and so this might not be the correct approach but the following
patch should just obviously work. At least it does for this testcase
--- Comment #24 from rguenth at gcc dot gnu dot org 2009-02-23 14:16
---
I just timed a-i branch and we get most of the time spent in PRE...
PRE : 18.69 (13%) usr 0.25 ( 7%) sys 19.30 (12%) wall
39484 kB ( 5%) ggc
301320 10.8102 compute_transp
104175
t.h:
#pragma GCC system_header
extern __inline __attribute__ ((__always_inline__)) char *
__attribute__ ((__nothrow__)) blabla (char *__restrict __dest, __const char
*__restrict __src)
{
return __builtin___strcpy_chk (__dest, __src, __builtin_object_size (__dest,
2 1));
}
t.c:
#include t.h
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2009-02-23 14:43
---
Visible on s390x as well:
http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg02251.html
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2009-02-23 14:43
---
Investigating.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rob1weld at aol dot com 2009-02-23 14:52 ---
Dismal Testsuite results are here:
http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg02284.html
Rob
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39019
--- Comment #6 from jh at suse dot cz 2009-02-23 15:05 ---
Subject: Re: [4.4 Regression] internal
compiler error: in initialize_cfun, at tree-inline.c:1749
Hi,
the assert seems confused. We can clone setjmp/alloca, just can't inline it.
(well, in fact we even can inline alloca
The configure options:
/t3-0/shared/gnu/gcc-4.3.3/configure --prefix=/t3-0/shared/gnu/gcc-trunk
--srcdir=/t3-0/shared/gnu/gcc-4.3.3 --enable-languages=c,fortran
--with-mpfr=/usr/local --with-gmp=/usr/local --with-pkgversion=432
--disable-bootstrap CC=gcc
Using this compiler:
gcc -v
Reading
--- Comment #1 from rvatne at gmail dot com 2009-02-23 15:08 ---
Created an attachment (id=17347)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17347action=view)
the failing config.log
the config.log from sparc-sun-solaris2.8/libgcc
--
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-02-23 15:09 ---
No the .libs/libmpfr.so.1.2.0 is embeded into libmpfr.so.1.2.0 . So something
is incorrect in your building of MPRF.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39273
--- Comment #3 from rvatne at gmail dot com 2009-02-23 15:18 ---
(In reply to comment #2)
No the .libs/libmpfr.so.1.2.0 is embeded into libmpfr.so.1.2.0 . So something
is incorrect in your building of MPRF.
NO, I don't think so. The MPRF is pkgadded from sunfreeware.com -
and
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-02-23 15:23 ---
That only shows that .libs/libmpfr.so.1.2.0 is inside cc1's path. I think you
should try a simple programed linked with MPFR using the old GCC and you most
likely get the same behavior.
--
This simple code:
typedef void (*TestFunction)(int *);
void Add(int *testCase);
void test(void);
int* TestNew( TestFunction function);
static void foo(int* tc){
test();
}
int* GetProfileSuite(){
Add(TestNew(foo));
return 0;
}
...triggers internal assert on my port of 4.3.2 when
--- Comment #52 from hubicka at gcc dot gnu dot org 2009-02-23 16:06
---
With patches proposed for c/12245 we now need 377MB (from original over 1GB)
garbage and produce 920MB of IL.
Pretty much all the garbage is coming from temporary list constructed here:
/* Add it to the
{~/tmp}$gcc --version
gcc (GCC) 4.4.0 20090223 (experimental)
Copyright (C) 2009 Free Software Foundation, Inc.
{~/tmp}$g++ -O2 -funroll-loops -c looppass.cpp
/mnt/svn/svn/llvm/lib/Analysis/LoopPass.cpp: In member function 'void
llvm::LPPassManager::deleteLoopFromQueue(llvm::Loop*)':
/mnt/svn
--- Comment #53 from mark at codesourcery dot com 2009-02-23 16:11 ---
Subject: Re: [4.2/4.3/4.4 Regression] out of memory while
parsing array with many initializers
hubicka at gcc dot gnu dot org wrote:
Perhaps explicitly freeing would be good idea?
I certainly have no objection
# gcc/xgcc -v
Using built-in specs.
COLLECT_GCC=gcc/xgcc
Target: i386-pc-solaris2.11
Configured with: ../lto_trunk/configure --prefix=/usr/local/lto
--enable-languages=lto,c++ --enable-shared --disable-static --enable-multilib
--with-gnu-as --with-as=/usr/local/bin/as --with-gnu-ld
--- Comment #1 from linuxl4 at sohu dot com 2009-02-23 16:15 ---
Created an attachment (id=17348)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17348action=view)
source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39275
--- Comment #46 from hubicka at gcc dot gnu dot org 2009-02-23 16:29
---
So with brand new tuplified world, we need new statistics ;)
After parsing we are still the same:
cfg.c:216 (connect_src) 608608: 0.2%520:
0.0%3028808: 1.6% 519680:
--- Comment #3 from hubicka at gcc dot gnu dot org 2009-02-23 16:39 ---
Testcase no longer compile:
/home/jh/bitmachine.cc:5049: error: declaration of 'typedef typename
Context::inner_context_type::state_base_type
boost::fsm::simple_stateMostDerived, Context, Reactions, InnerInitial,
--- Comment #45 from hubicka at gcc dot gnu dot org 2009-02-23 16:46
---
Subject: Bug 12245
Author: hubicka
Date: Mon Feb 23 16:46:32 2009
New Revision: 144384
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144384
Log:
PR c/12245
* ggc.h (htab_create_ggc): Use
--- Comment #1 from rob1weld at aol dot com 2009-02-23 16:48 ---
Created an attachment (id=17349)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17349action=view)
Proposed Patch to fix ltrans-driver on Platform OpenSolaris
This patch should fix this Bug (and another, use gawk
--- Comment #54 from hubicka at ucw dot cz 2009-02-23 16:51 ---
Subject: Re: [4.2/4.3/4.4 Regression] out of memory while parsing array with
many initializers
Perhaps explicitly freeing would be good idea?
I certainly have no objection to explicitly freeing storage if we know
I am compiling version 2.3.3 (or 2.3.4) of the Pari/GP math library. The
compiler crashes with a segmentation fault, when the source file arith1.c is
compiled with -O3.
The compiler is gcc 4.3.3, freshly compiled on Solaris 2.8.
Here's the log output of the compile:
Using built-in specs.
--- Comment #1 from Michael dot Finken at me dot com 2009-02-23 16:57
---
Created an attachment (id=17350)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17350action=view)
This is the log of the compile command
This is the complete output of the compile command, when run with gcc
--- Comment #2 from Michael dot Finken at me dot com 2009-02-23 16:58
---
Created an attachment (id=17351)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17351action=view)
The intermediate file after pre-processing
The magic source file...
--
--- Comment #3 from Michael dot Finken at me dot com 2009-02-23 16:58
---
Created an attachment (id=17352)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17352action=view)
The assembler source, created upto the crash.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39277
--- Comment #4 from Michael dot Finken at me dot com 2009-02-23 17:01
---
This happens with gcc 4.3.2 as well.
I compiled gcc 4.3.3 today, hoping that the problem would no longer appear.
--
Michael dot Finken at me dot com changed:
What|Removed
--- Comment #2 from rob1weld at aol dot com 2009-02-23 17:04 ---
Created an attachment (id=17353)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17353action=view)
Proposed Patch to fix ltrans-driver on Platform OpenSolaris
Revised Patch.
--
rob1weld at aol dot com changed:
--- Comment #12 from sje at cup dot hp dot com 2009-02-23 17:16 ---
I am adding Nick Clifton to the CC list since he is listed as the maintainer
for fr30 and mcore. fr30 and it's two options (-mno-lsim and -msmall-model)
are not documented at all in invoke.texi. mcore is missing
--- Comment #2 from sje at cup dot hp dot com 2009-02-23 17:27 ---
Adding Dorit Nuzman and Devang Patel to the CC list since they are listed as
the authors of the patch that created this macro.
--
sje at cup dot hp dot com changed:
What|Removed
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-02-23 17:29 ---
I don't think ltrans-driver should be a shell script anyways because on windows
you will most likely not have /bin/sh installed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #4 from dnovillo at google dot com 2009-02-23 17:33 ---
Subject: Re: [lto] - Testsuite gcc.log shows many getconf:
Invalid argument (_NPROCESSORS_ONLN)
On Mon, Feb 23, 2009 at 12:29, pinskia at gcc dot gnu dot org
gcc-bugzi...@gcc.gnu.org wrote:
--- Comment
--- Comment #5 from hjl dot tools at gmail dot com 2009-02-23 17:39 ---
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2009-02/msg01073.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #3 from hjl dot tools at gmail dot com 2009-02-23 17:43 ---
Oops. A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2008-08/msg00575.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #25 from stevenb dot gcc at gmail dot com 2009-02-23 17:47
---
Subject: Re: very long optimized compile
Re Comment #24:
I can look into it...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12392
If gcc is invoked without an absolute path, and there is a *directory* named
'gcc' which can be found by searching $PATH before the actual gcc executable,
then that location is taken as a starting point for searching for includes. As
a result, standard include files such as stddef.h cannot be
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-02-23 18:01 ---
*** This bug has been marked as a duplicate of 38966 ***
*** This bug has been marked as a duplicate of 38966 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #5 from pinskia at gcc dot gnu dot org 2009-02-23 18:01 ---
*** Bug 39278 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from sje at cup dot hp dot com 2009-02-23 18:55 ---
It looks to me like this has been fixed. In the -O documentation in
invoke.texi it says:
@option{-O} also turns on @option{-fomit-frame-pointer} on machines
where doing so does not interfere with debugging.
Closing it
--- Comment #6 from janis at gcc dot gnu dot org 2009-02-23 19:00 ---
Subject: Bug 33466
Author: janis
Date: Mon Feb 23 19:00:32 2009
New Revision: 144391
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144391
Log:
PR c/33466
* expr.c (interpret_float_suffix):
--- Comment #7 from janis at gcc dot gnu dot org 2009-02-23 19:05 ---
The checkin is for Joseph's c-4.5 branch. I'll move this to trunk after 4.4
branches.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33466
# cat stage_current
stage2
# gcc/xgcc -v
Using built-in specs.
COLLECT_GCC=gcc/xgcc
Target: i386-pc-solaris2.11
Configured with: ../lto_trunk/configure --prefix=/usr/local/lto
--enable-languages=lto,c++ --enable-shared --disable-static --enable-multilib
--with-gnu-as --with-as=/usr/local/bin/as
--- Comment #1 from aesok at gcc dot gnu dot org 2009-02-23 19:10 ---
Hi.
The GCC always use a shift for optimizing multiply by power of 2 constant.
expr.c:expand_expr_real_1:8680
/* Check for a multiplication with matching signedness. */
else if (TREE_CODE
--- Comment #3 from dfranke at gcc dot gnu dot org 2009-02-23 19:38 ---
parse.c (next_statement):
816 if (gfc_at_eol ())
817 {
818 if ((gfc_option.warn_line_truncation || gfc_current_form ==
FORM_FREE)
819gfc_current_locus.lb
820
$ cat foo.f90
subroutine foo
implicit none
integer :: i,n
do i=1,10
n = (-1)**(i+1)
call bar(n)
end do
end subroutine foo
$ gfortran -S -O2 -fdump-tree-optimized foo.f90
...
i = i + 1;
n.0 = _gfortran_pow_i4_i4 (-1, i);
n = n.0;
bar (n);
We could eliminate the call to
Usually this error message is issued when semicolon is missing after the
struct/class declaration.
Message itself is pretty obscure.
It's better to change it:
error: multiple types in one declaration, missing semicolon after type
declaration?
This will give users a clue and will likely
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39281
template typename T
struct ManagerBase
{
virtual void insert( T* );
};
template typename T
class ManagerInterface : public ManagerBase T
{
using ManagerBase T ::insert;
public:
virtual bool insert( T* d, char const* ) = 0;
};
template typename T
class ManagerImpl :
--- Comment #11 from jason at gcc dot gnu dot org 2009-02-23 21:24 ---
Subject: Bug 38880
Author: jason
Date: Mon Feb 23 21:23:58 2009
New Revision: 144395
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144395
Log:
PR c++/38880
* varasm.c
--- Comment #8 from joseph at codesourcery dot com 2009-02-23 21:43 ---
Subject: Re: mixed-case suffix for decimal float constants
On Mon, 23 Feb 2009, janis at gcc dot gnu dot org wrote:
Modified:
branches/c-4_5-branch/gcc/testsuite/ChangeLog
--- Comment #4 from sje at cup dot hp dot com 2009-02-23 22:21 ---
I think this has been fixed by the updates of libtool. At least I don't see it
in my ToT build. HJ, are you still seeing this? Can we close this defect?
--
sje at cup dot hp dot com changed:
What
--- Comment #4 from hjl at gcc dot gnu dot org 2009-02-23 22:35 ---
Subject: Bug 36411
Author: hjl
Date: Mon Feb 23 22:34:50 2009
New Revision: 144396
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144396
Log:
gcc/cp
2009-02-23 H.J. Lu hongjiu...@intel.com
PR
--- Comment #5 from hjl dot tools at gmail dot com 2009-02-23 22:35 ---
Fixed.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #5 from hjl dot tools at gmail dot com 2009-02-23 22:38 ---
Fixed as of revision 144386.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Maybe there are two bugs here.
#include stdio.h
typedef int ix __attribute__ ((__aligned__ (16)));
typedef volatile int vx __attribute__ ((__aligned__ (16)));
ix ix1 = __alignof__ (ix);
ix ix2 = __alignof__ (ix1);
vx vx1 = __alignof__ (vx);
vx vx2 = __alignof__ (vx1);
int main(void)
{
printf
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-02-23 22:43 ---
This works correctly with the C++ front-end:
[dhcp-10-98-10-23:~] apinski% ~/local-gcc/bin/gcc t.c
[dhcp-10-98-10-23:~] apinski% ./a.out
ix1: 16, ix2: 16, vx1: 4, vx2: 4
[dhcp-10-98-10-23:~] apinski%
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-02-23 22:45 ---
So the cris problem with 1 vs 4 might be a different issue but the C front-end
does something incorrectly anyways.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39283
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-02-23 22:46 ---
This is by design; GCSE is the one which pulls back the computed gotos IIRC.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from hp at gcc dot gnu dot org 2009-02-23 22:48 ---
(In reply to comment #2)
So the cris problem with 1 vs 4 might be a different issue but the C front-end
does something incorrectly anyways.
I was assuming it's the same basic problem, if nothing else that assumption
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-02-23 22:48 ---
It says may but not will get better performance.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39284
--- Comment #4 from hp at gcc dot gnu dot org 2009-02-23 22:56 ---
(In reply to comment #3)
But sure, middle-end instead of target is then
more consistent.
...or c. Whatever!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39283
--- Comment #4 from jyasskin at gmail dot com 2009-02-23 22:58 ---
Taking out -fno-gcse doesn't change the result.
$ gcc-4.4 -m32 -pthread -fno-strict-aliasing -g -fwrapv -O3 --param
max-goto-duplication-insns=10 -S -dA ceval.i -o ceval.s
$ egrep -c 'jmp[[:space:]]*\*' ceval.s
4
--- Comment #5 from steven at gcc dot gnu dot org 2009-02-23 23:19 ---
Should unfactor. We have pass_duplicate_computed_gotos for this. We should
look into this, see why it doesn't work.
Someone added a optimize_for_size_p() check in duplicate_computed_gotos().
That is just
--- Comment #7 from john dot carter at tait dot co dot nz 2009-02-23 23:53
---
R Guenther said...
(int)u1 == (int)(u8_t)(~(int)u2)
that we do not warn for the first case is because it is optimized to
u1 == ~u2 before.
Why do you think the warning is incorrect?
--- Comment #3 from sje at cup dot hp dot com 2009-02-24 00:01 ---
More work is needed then just setting flag_branch_target_optimize{,2}, we need
to define TARGET_BRANCH_TARGET_REGISTER_CLASS (return BR_REGS) and
TARGET_BRANCH_TARGET_REGISTER_CALLEE_SAVED (return 1) but even then it
--- Comment #8 from michael dot malone at tait dot co dot nz 2009-02-24
00:40 ---
#ifdef UINT
#include stdint.h
#define TYPE uint16_t
#else
#define TYPE unsigned short int
#endif
#define VALUE 0xFF
int main(void);
int main() {
TYPE variable_a = ~VALUE;
TYPE variable_b =
--- Comment #9 from michael dot malone at tait dot co dot nz 2009-02-24
00:43 ---
I forgot to mention, if you assign to an intermediate variable, the warning
also disappears which is the behaviour I would expect from an explicit cast.
--
michael dot malone at tait dot co dot nz
--- Comment #6 from howarth at nitro dot med dot uc dot edu 2009-02-24
01:17 ---
The currently proposed patch doesn't solve the problem where 'make -k
check-libiberty' executed at the top level of the build directory results in
gcc being used instead of xgcc. If you execute 'make -k
--- Comment #2 from bkoz at gcc dot gnu dot org 2009-02-24 01:23 ---
Mine. This is still broken in 4.4.0.
Actually, in 4.2.4 --enable-symvers=gnu-versioned-namespace runs into a build
error in libgomp, where the argument given (gnu-versioned-namespace) does not
match with yes, no,
--- Comment #3 from bkoz at gcc dot gnu dot org 2009-02-24 01:24 ---
Created an attachment (id=17355)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17355action=view)
enable-symvers=gnu-versioned-namespace vs. libgomp
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36104
--- Comment #12 from jason at gcc dot gnu dot org 2009-02-24 05:14 ---
Fixed.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #1 from jason at gcc dot gnu dot org 2009-02-24 05:21 ---
The error is correct: the ManagerInterfaceT::insert using declaration is
private.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from spop at gcc dot gnu dot org 2009-02-24 06:48 ---
Subject: Bug 39260
Author: spop
Date: Tue Feb 24 06:47:56 2009
New Revision: 144403
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144403
Log:
2009-02-23 Sebastian Pop sebastian@amd.com
PR
--- Comment #2 from spop at gcc dot gnu dot org 2009-02-24 07:04 ---
The bug is fixed on trunk revision 144404.
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from bkoz at gcc dot gnu dot org 2009-02-24 07:05 ---
Any chance you could narrow this down? The revision stated as problematic has
nothing to do with libstdc++. The file implicated, cfenv, has not had a change
in 3 months.
What was a revision that worked?
This seems
84 matches
Mail list logo
