--no-create --no-recursion
Thread model: posix
gcc version 4.3.0 20080206 (experimental) (GCC)
--
Summary: [OpenMP] ICE in remove_unreachable_regions with -O -
fopenmp
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity
--- Comment #1 from t-gcc-bugzilla at snowelm dot com 2008-02-06 08:03
---
Created an attachment (id=15103)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15103action=view)
Testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35099
--- Comment #9 from pault at gcc dot gnu dot org 2008-02-06 08:16 ---
Thanks to one and all for the quick report and the equally quick fix. As I
said in mail to the list, for the umpteenth time, I have been caught by
Cygwin's ability to disappear some segfaults. I do apologise and, as
--- Comment #10 from pault at gcc dot gnu dot org 2008-02-06 08:33 ---
This bug is caused by gfc_conv_intrinsic_conversion calling
gfc_conv_intrinsic_function_args, which builds a temporary without checking if
the allocatable array 'yy' has been allocated or not.
This can be cured by
--- Comment #23 from steven at gcc dot gnu dot org 2008-02-06 09:00 ---
The IS_STACK_MODE trick is mine, and if this affects SSE code generation, the
bug is that IS_STACK_MODE returns true for registers that will not go on the
stack.
I acknowledge the IS_STACK_MODE is a big hammer, but
--- Comment #11 from burnus at gcc dot gnu dot org 2008-02-06 09:09 ---
Is the correct thing to throw an error or to quietly do the conversion?
I tried the example (with integer(4) and integer(8)) with several compilers and
none of them gave an error. (With -Wall g95 gives a conversion
--- Comment #14 from rguenth at gcc dot gnu dot org 2008-02-06 09:28
---
Err well. Adjusted the summary to something more descriptive, marked as
a regression (4.2 did profiledbootstrap ok).
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #5 from steven at gcc dot gnu dot org 2008-02-06 09:05 ---
There was -Wnull-dereference once. I don't know if it still exists.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35092
--- Comment #9 from ismail at pardus dot org dot tr 2008-02-06 09:34
---
CC'ing Dorit to get his idea on the vectorizer dump.
--
ismail at pardus dot org dot tr changed:
What|Removed |Added
--- Comment #1 from debian-gcc at lists dot debian dot org 2008-02-06
09:38 ---
Created an attachment (id=15104)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15104action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35100
seen with trunk 20080202, works with g77. Compiling without -mlongcall
succeeds.
Matthias
$ /usr/bin/gcc-4.3 -save-temps -DL2SIZE=2097152
-I/home/doko/tmp/atlas-3.6.0/include
-I/home/doko/tmp/atlas-3.6.0/include/Linux_altivec_shared
-I/home/doko/tmp/atlas-3.6.0/include/contrib -DAdd_
--- Comment #8 from uros at gcc dot gnu dot org 2008-02-06 10:46 ---
Subject: Bug 35083
Author: uros
Date: Wed Feb 6 10:45:29 2008
New Revision: 132144
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=132144
Log:
PR target/35083
* optabs.c (expand_float): Do not
--- Comment #15 from rguenth at gcc dot gnu dot org 2008-02-06 09:59
---
profiledbootstrap on x86_64 fails for me with
checking for x86_64-unknown-linux-gnu-gcc... /space/rguenther/obj/./gcc/xgcc
-B/space/rguenther/obj/./gcc/ -B/usr/local/x86_64-unknown-linux-gnu/bin/
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #16 from rguenth at gcc dot gnu dot org 2008-02-06 11:19
---
Just re-building real.o with removing the real.gc* files before fixes the bug,
so to trigger this bug you indeed need the profile-feedback.
-O2 -fbranch-probabilities -finline-functions is enough to trigger the
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-02-06 11:23 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #24 from hubicka at gcc dot gnu dot org 2008-02-06 11:26
---
IS_STACK_MODE returns true for MODEs that *might* go to the stack registers.
When we do SSE math, SFmode/DFmode will most likely go into SSE register, but
still they are valid for stack register and might go
--- Comment #9 from ubizjak at gmail dot com 2008-02-06 11:11 ---
Fixed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|NEW
--- Comment #14 from ubizjak at gmail dot com 2008-02-06 11:05 ---
We still generate:
.L8:
movl(%ebx), %eax
addl$1, %edx
addl$4, %ebx
fldl(%edi,%eax,8)
fmull (%ecx)
addl$8, %ecx
cmpl%edx, %esi
--- Comment #2 from debian-gcc at lists dot debian dot org 2008-02-06
11:08 ---
reconfirmed with trunk 20080205
=== libjava tests ===
Running target unix
FAIL:
/scratch/packages/gcc/4.3/java/gcj-4.3-4.3-20080205/src/libjava/testsuite/libjava.jar/TestClosureGC.jar
--- Comment #25 from hubicka at gcc dot gnu dot org 2008-02-06 11:30
---
Hmm, sorry. IS_STACK_MODE obviously return false for SSE math, per Paolo's
commit. Since it is not used except for the hacks to avoid constant hoisting,
I guess it is OK. I will commit only the patch for pertial
--- Comment #5 from hubicka at gcc dot gnu dot org 2008-02-06 11:34 ---
Subject: Bug 5587
Author: hubicka
Date: Wed Feb 6 11:34:00 2008
New Revision: 132145
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=132145
Log:
PR target/5587
* i386.md (moddf_integer): Do
--- Comment #27 from hubicka at gcc dot gnu dot org 2008-02-06 11:55
---
I noticed those posts. Part of the problem might be that hoisting triggers the
partial memory stall bug I fixed. Partial memory stalls are quite expensive, so
this might improve scores without the hack in some
The following code causes compile error, but this is an example of the
standard.
struct S{
mutable int i;
};
const S cs;
--
Summary: Const object creation with mutable field
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity:
--- Comment #26 from steven at gcc dot gnu dot org 2008-02-06 11:43 ---
You could read up on the following mailing list threads if you want to know
where the IS_STACK_REG check comes from:
http://gcc.gnu.org/ml/gcc-patches/2005-12/msg01859.html
--- Comment #9 from jpr at csc dot fi 2008-02-06 11:31 ---
Subject: Re: I/O leaks handles/memory on Windows XP
just an observation: if i build gcc with thread model=single, all seems
well.
Juha
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2008-02-06 01:27
---
Today's (2008-02-06) gcc-trunk (rev 132144) fails to build rtems.
Seemingly it generates invalid assembly code:
# i386-rtems4.9-gcc --pipe -mtune=pentiumpro --pipe -DHAVE_CONFIG_H -I..
-I../../../lib/include -I../../../../../../rtems.orig/cpukit/libnetworking
-D_COMPILING_BSD_KERNEL_ -DKERNEL
--- Comment #1 from corsepiu at gcc dot gnu dot org 2008-02-06 12:01
---
Created an attachment (id=15105)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15105action=view)
preprocessed source of file producing breakdown
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35102
--- Comment #10 from corsepiu at gcc dot gnu dot org 2008-02-06 12:03
---
Thanks Uros, i386-rtems*-gcc now bootstraps again.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35083
--- Comment #2 from ubizjak at gmail dot com 2008-02-06 12:09 ---
Please find movb insn (or similar that operates on 8bit reg) in your source
and change its constraint from r to q.
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-02-06 12:23 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-02-06 12:25 ---
GCC 3.3 rejected this code with
t.C:3: error: syntax error before `__attribute'
so there's no 'working' version.
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Component|c++ |middle-end
Keywords|
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-02-06 12:29 ---
Also ICEs on x86_64 with -m32 (but not without).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35099
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35100
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-02-06 12:38 ---
Please quote the relevant parts of the standard. IMHO cs needs an initializer
or an explicitly declared default constructor. And no, examples in the std
are not always without errors.
--
rguenth at gcc dot gnu
--- Comment #17 from hubicka at gcc dot gnu dot org 2008-02-06 13:28
---
One problem is the following:
do {
;
match = window + cur_match;
if (match[best_len] != scan_end ||
match[best_len-1] != scan_end1 ||
*match != *scan ||
i use gnumake 3.81 and gcc 3.4.6 to compile gcc 4.2.2 on solaris8 (117350-23)
and i get this error:
make[2]: Warning: File `stage_current' has modification time 7.2 s in the
future
../.././gcc/gcov-io.c: In function 'gcov_write_block':
../.././gcc/gcov-io.c:208: internal compiler error: in ?, at
--- Comment #10 from ubizjak at gmail dot com 2008-02-06 13:32 ---
I have noticed, that following text is missing from your vect dump:
Dependence tester statistics:
Number of dependence tests: 0
Number of dependence tests classified dependent: 0
Number of dependence tests classified
--- Comment #11 from ismail at pardus dot org dot tr 2008-02-06 13:33
---
(In reply to comment #10)
I have noticed, that following text is missing from your vect dump:
Dependence tester statistics:
Number of dependence tests: 0
Number of dependence tests classified dependent: 0
--- Comment #5 from ludovic at ludovic-brenta dot org 2008-02-06 13:42
---
Since the test case uses only Ada 95 features, what does the compiler say with
-gnat95?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33420
--- Comment #2 from tatraian at inf dot elte dot hu 2008-02-06 13:43
---
The example is in the section: [expr.mptr.oper]
But, if the stadnadr code examples can contain errors maybe this is one of
them.
The whole example is the next:
struct S {
mutable int i;
};
const S cs;
--- Comment #12 from ubizjak at gmail dot com 2008-02-06 14:02 ---
(In reply to comment #11)
(In reply to comment #10)
I have noticed, that following text is missing from your vect dump:
I don't why but I didn't modify the vector dump :/
Eh, my dump was produced with
--- Comment #13 from ubizjak at gmail dot com 2008-02-06 14:11 ---
I think that following difference is the key:
In case vectorizer is able to vecotrize, we enter vectorizer pass with:
bb 3:
# ivtmp.17_1 = PHI ivtmp.17_2(4), 26(2)
# i_18 = PHI i_10(4), 0(2)
# s_17 = PHI s_9(4),
I found this bug in cygwin's gcc, but it is probably
general problem.
#include cmath fails to undefine math.h's macro log2.
I personally thinks, that like other math functions,
log2 shoud be function in namespace std, not macro.
(Bug found, when I was defining own int log2(int) function
in class)
gnatmake -Pxxx/taskman.gpr taskman.adb -d
gcc-4.1 -c -g -g -gnat05 -gnatwc -gnatwd -gnatwi -gnatwj -gnatwp -gnatwr
-gnatVc -gnatVi -gnatVm -gnatVr -I- -gnatA xxx/tasks.adb
+===GNAT BUG DETECTED==+
| 4.1.3 20070929 (prerelease) (Ubuntu
--- Comment #1 from nowak2000 at poczta dot onet dot pl 2008-02-06 15:00
---
Created an attachment (id=15106)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15106action=view)
gnatchop concatenated sources
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35105
--- Comment #28 from hubicka at gcc dot gnu dot org 2008-02-06 15:10
---
*** Bug 23305 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23322
--- Comment #12 from hubicka at gcc dot gnu dot org 2008-02-06 15:10
---
Looks like last remaining problem is the missed loop invariant motion due to
STACK_REGS hack as in the case of pr23322
[EMAIL PROTECTED]:/aux/hubicka/trunk-write/buidl2/gcc$ time
./a.out-nostackregs-hack
real
--- Comment #2 from dgregor at gcc dot gnu dot org 2008-02-06 15:18 ---
This is the comptypes issue dealt with in PR 35049. I've verified that the fix
for that issue handles this test case, too.
*** This bug has been marked as a duplicate of 35049 ***
--
dgregor at gcc dot gnu dot
--- Comment #9 from dgregor at gcc dot gnu dot org 2008-02-06 15:18 ---
*** Bug 35096 has been marked as a duplicate of this bug. ***
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from hjl at gcc dot gnu dot org 2008-02-06 15:23 ---
Subject: Bug 34921
Author: hjl
Date: Wed Feb 6 15:22:35 2008
New Revision: 132148
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=132148
Log:
gcc/
2008-02-06 Joey Ye [EMAIL PROTECTED]
PR
You can define functions as overloaded or with default arguments. For the user
of the defined function, if it is defined by overloading or by default
arguments should be completely indifferent.
--
Summary: Unconsistent handling of overloaded vs default arguments
--- Comment #10 from ilmarw at simula dot no 2008-02-06 15:37 ---
Can confirm this on 32-bit platform as well:
Linux multiboot 2.6.22-14-generic #1 SMP Fri Feb 1 04:59:50 UTC 2008 i686
GNU/Linux
gcc version 4.2.1 (Ubuntu 4.2.1-5ubuntu4)
I recompiled after patching as suggested above,
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-02-06 16:11 ---
What are you trying to say?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-02-06 16:15 ---
log2 is part of C99 which C++ does not know about. C++ only knows about C89
routines in math.h.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from vonbrand at inf dot utfsm dot cl 2008-02-06 16:22
---
(In reply to comment #1)
What are you trying to say?
If I declare:
void f();
void f(int);
or
void f(int i = 100);
should behave exactly the same way. If not, what is the point of offering
default
--- Comment #3 from zadeck at naturalbridge dot com 2008-02-06 16:26
---
The dataflow changes caused, at least, the latest level of messing this up by
splitting, combining and removing a large number of passes without regard to
this antiquated system of naming the passes.
if the
--- Comment #18 from hubicka at gcc dot gnu dot org 2008-02-06 16:44
---
Created an attachment (id=15107)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15107action=view)
Path to predict_paths_leading_to
Hi,
I've revived the continue heuristic patch. By itself it does not help
--- Comment #19 from hubicka at gcc dot gnu dot org 2008-02-06 16:56
---
Created an attachment (id=15108)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15108action=view)
Complete continue heuristic patch
Hi,
this is the complete patch. With this patch we produce profile sane
--- Comment #14 from ismail at pardus dot org dot tr 2008-02-06 17:01
---
I tried building without BOOT_CFLAGS and such but no luck.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35085
--- Comment #1 from dannysmith at users dot sourceforge dot net 2008-02-06
17:29 ---
Patch at:
http://gcc.gnu.org/ml/gcc-patches/2008-02/msg00120.html
--
dannysmith at users dot sourceforge dot net changed:
What|Removed |Added
--- Comment #21 from rth at gcc dot gnu dot org 2008-02-06 17:38 ---
Created an attachment (id=15109)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15109action=view)
fix, try 2
I see, said the blind man.
It turns out that the emission of the libcall had been responsible for
--- Comment #10 from pinskia at gcc dot gnu dot org 2008-02-06 18:04
---
This also ICEs on valid code.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from Ralf dot Wildenhues at gmx dot de 2008-02-06 18:05
---
Created an attachment (id=15110)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15110action=view)
fairly reduced testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35099
--- Comment #2 from danglin at gcc dot gnu dot org 2008-02-06 18:10 ---
It turns out these failures are a result of using the 2.0n ABI
with gmp-4.2.2. This is the default for hppa2.0w-hp-hpux11.11.
In all my previous testing, I had built GMP using the standard
1.x ABI. Using the 2.0n
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-02-06 18:10 ---
I still don't understand what you are asking? Do you have an example of where
the differences comes into play? The only one I Know of is taking the address
of the function, The default argument case cannot be
During bootstrap, GCC links all host programs with -lgmp -lmpfr. Only the
compiler itself (cc1, cc1plus, jc1, etc) need to do this. The other programs
(xgcc, gcj, cpp, gcov, jcf-dump, etc) don't need it. With static libs it
doesn't matter, but for shared libs it hooks in the .so file at runtime
--- Comment #1 from janis at gcc dot gnu dot org 2008-02-06 18:16 ---
I agree that the behavior should be the same for any non-hardware vector that
is passed or returned. That includes vectors that are different sizes from
hardware vectors, and vectors that are the same size as
--- Comment #4 from vonbrand at inf dot utfsm dot cl 2008-02-06 18:23
---
(In reply to comment #3)
I still don't understand what you are asking? Do you have an example of where
the differences comes into play? The only one I Know of is taking the address
of the function, The
--- Comment #5 from vonbrand at inf dot utfsm dot cl 2008-02-06 18:25
---
Created an attachment (id=15111)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15111action=view)
A testcase showing the inconsistency
realf and realg should behave the same, but compiling gives an error
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-02-06 18:18 ---
How did you configure GCC? How did you invoke make?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
With gcc version 4.3.0 20071218, with this file:
$ cat test.f90
PROGRAM Outer
IMPLICIT NONE
REAL, DIMENSION(100) :: A
INTEGER :: k
!$OMP PARALLEL DO PRIVATE(k)
DO k=1,SIZE(A)
END DO
!$OMP END PARALLEL DO
CONTAINS
SUBROUTINE Inner
IMPLICIT NONE
A(k)=0.0D0
END SUBROUTINE
Fall-out from PR 35099:
g++ -c test2.ii
test2.ii: In member function typename vector_Tp, _Alloc::iterator
vector_Tp, _Alloc::insert(__normal_iterator, const _Tp):
test2.ii:13: internal compiler error: in lookup_name_real, at
cp/name-lookup.c:4056
Please submit a full bug report,
That is with
--- Comment #1 from Ralf dot Wildenhues at gmx dot de 2008-02-06 18:34
---
Created an attachment (id=15112)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15112action=view)
failing test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35109
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Summary|ICE in lookup_name_real, at |[4.3 Regression] ICE in
|cp/name-lookup.c:4056
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-02-06 18:38 ---
This is invalid code.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #20 from ubizjak at gmail dot com 2008-02-06 18:42 ---
Whoa, adding -fomit-frame-pointer brings us from
(gcc -O3 -m32)
user0m41.031s
to
(gcc -O3 -m32 -fomit-frame-pointer)
user0m30.006s
Since -fo-f-p adds another free reg, it looks that since inlining increases
the below code snippet compiles using gcc 3.3.1 but fails to compile with gcc
4.1.1 giving the error
error: void* my_alloc::operator new(size_t, char*, int) may not be declared
within a namespace
- namespace_operator_new.cpp
#include new
using std::bad_alloc;
using
--- Comment #3 from dgregor at gcc dot gnu dot org 2008-02-06 18:49 ---
Subject: Bug 35096
Author: dgregor
Date: Wed Feb 6 18:49:03 2008
New Revision: 132152
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=132152
Log:
2008-02-06 Douglas Gregor [EMAIL PROTECTED]
PR
--- Comment #11 from dgregor at gcc dot gnu dot org 2008-02-06 18:49
---
Subject: Bug 35049
Author: dgregor
Date: Wed Feb 6 18:49:03 2008
New Revision: 132152
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=132152
Log:
2008-02-06 Douglas Gregor [EMAIL PROTECTED]
PR
--- Comment #12 from dgregor at gcc dot gnu dot org 2008-02-06 18:50
---
Fixed in mainline
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from brossob at yahoo dot com 2008-02-06 18:53 ---
i installed gcc3.4.6 from the sun freeware site.
and i just invoked make without any arguments.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35103
--- Comment #3 from brossob at yahoo dot com 2008-02-06 18:54 ---
just did
./configure
and then
make.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35103
--- Comment #6 from pinskia at gcc dot gnu dot org 2008-02-06 18:30 ---
Yes and I just mentioned why this case is incorrect. :)
Anyways we had an undocumented extension (which means it was a bug) in GCC
before 4.2 with this respect.
--
pinskia at gcc dot gnu dot org changed:
--- Comment #1 from schwab at suse dot de 2008-02-06 19:05 ---
*** This bug has been marked as a duplicate of 13903 ***
--
schwab at suse dot de changed:
What|Removed |Added
--- Comment #4 from schwab at suse dot de 2008-02-06 19:05 ---
*** Bug 35110 has been marked as a duplicate of this bug. ***
--
schwab at suse dot de changed:
What|Removed |Added
--- Comment #21 from ubizjak at gmail dot com 2008-02-06 19:10 ---
(In reply to comment #20)
Since -fo-f-p adds another free reg, it looks that since inlining increases
register pressure some unlucky heavy-used variable gets allocated to the stack
slot.
It is best_len (and
--- Comment #7 from vonbrand at inf dot utfsm dot cl 2008-02-06 19:12
---
(In reply to comment #6)
Yes and I just mentioned why this case is incorrect. :)
Anyways we had an undocumented extension (which means it was a bug) in GCC
before 4.2 with this respect.
What is the point of
--- Comment #22 from hubicka at gcc dot gnu dot org 2008-02-06 19:22
---
Yes, there are number of unlucky variables. However the real source is here
seems to be always wrong profile guiding regalloc to optimize for cold portions
of the function rather than real increase of register
The following invalid testcase triggers a broken error message
('tree_list' not supported by dump_decl) and an ICE since GCC 4.1.0:
namespace X { struct A; }
namespace Y { struct A; }
namespace Z { struct A; }
using namespace X;
using namespace Y;
using namespace Z;
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||diagnostic
Target Milestone|--- |4.1.3
--- Comment #1 from ghazi at gcc dot gnu dot org 2008-02-06 20:24 ---
Patch posted here:
http://gcc.gnu.org/ml/gcc-patches/2008-02/msg00187.html
--
ghazi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from yalbasilva at gmail dot com 2008-02-06 20:25 ---
Hi,
Yes, I had a typo when I included $JAVA_HOME/include/linux. Once I fixed it I
was able to compile OK.
Thanks for looking into this so quick! This can be closed.
--
yalbasilva at gmail dot com changed:
--- Comment #10 from Jerry_V_DeLisle at rl dot gov 2008-02-06 20:25 ---
Reply to comment #9:
This is a very important observation. I have checked the code and we have code
that free's the internal unit (free_internal_unit) and I have confirmed that it
is called correctly after every
--- Comment #19 from aoliva at gcc dot gnu dot org 2008-02-06 20:32 ---
Subject: Bug 35056
Author: aoliva
Date: Wed Feb 6 20:31:43 2008
New Revision: 132158
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=132158
Log:
gcc/cp/ChangeLog:
PR c++/35056
* tree.c: Include tree-flow.h.
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-02-06 20:33 ---
Technically this is a regression. Not linking against unneeded libraries will
speed up dynamic loading as well.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35107
--- Comment #20 from aoliva at gcc dot gnu dot org 2008-02-06 20:33 ---
Err, mine ;-)
--
aoliva at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #21 from aoliva at gcc dot gnu dot org 2008-02-06 20:34 ---
Fixed
--
aoliva at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #7 from rguenth at gcc dot gnu dot org 2008-02-06 20:36 ---
*** Bug 35108 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
1 - 100 of 143 matches
Mail list logo
