[Bug middle-end/26379] [4.0/4.1/4.2 Regression] ICE on vector shift RTL simplification
--- Comment #3 from jakub at gcc dot gnu dot org 2006-02-21 08:09 --- Subject: Bug 26379 Author: jakub Date: Tue Feb 21 08:09:08 2006 New Revision: 111328 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=111328 Log: PR middle-end/26379 * combine.c (simplify_shift_const_1): Disable nested shifts optimization for vector shifts. * gcc.target/i386/mmx-7.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/mmx-7.c Modified: trunk/gcc/ChangeLog trunk/gcc/combine.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26379
[Bug java/26390] New: Problem dispatching method call when method does not exist in superclass
Classpath 0.21-pre contains the following code in
gnu/java/awt/peer/swing/SwingFramePeer.java:
public void setBounds(int x, int y, int w, int h)
{
super.setBounds(x, y, w, h);
if (menuBar != null)
menuBar.setWidth(w);
where the method setBounds(int, int, int, int) does not exist in the immediate
superclass (SwingWindowPeer). The class appears to compile, but during the
linking phase we get undefined reference to
java::awt::peer::swing::SwingWindowPeer::setBounds(int, int, int, int).
--
Summary: Problem dispatching method call when method does not
exist in superclass
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: david at jpackage dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26390
[Bug fortran/25619] tempary array of constant size character type goes wrong
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2006-02-21 09:08
---
(In reply to comment #2)
the variable does not have to be a dummy variable either to reproduce this.
subroutine option_stopwatch_s()
character(len=1) :: default_clock
call option_stopwatch_a((/default_clock/))
end subroutine option_stopwatch_s
Another example of the (probably) same bug (reported by Vivek Rao, reduced by
myself):
$ cat vivek.f90
character(len=1) :: s(1) =
integer :: i(1)
print *, s(i)
end
$ gfortran -c vivek.f90
vivek.f90: In function MAIN__:
vivek.f90:3: internal compiler error: in gimplify_expr, at gimplify.c:5788
The top of the gdb backtrace is:
Breakpoint 1, fancy_abort (file=0x859ff15 ../../../trunk/gcc/gimplify.c,
line=5788, function=0x85a052e gimplify_expr)
at ../../../trunk/gcc/diagnostic.c:641
641 {
(gdb) where
#0 fancy_abort (file=0x859ff15 ../../../trunk/gcc/gimplify.c, line=5788,
function=0x85a052e gimplify_expr) at ../../../trunk/gcc/diagnostic.c:641
#1 0x080e49d0 in gimplify_expr (expr_p=0xb7bcc09c, pre_p=0xbfafd324,
post_p=Variable post_p is not available.
)
at ../../../trunk/gcc/gimplify.c:5788
#2 0x080e2b5b in gimplify_expr (expr_p=0xb7b6e434, pre_p=0xbfafd324,
post_p=0xbfafd320, gimple_test_f=0x80dae80 is_gimple_mem_rhs,
fallback=fb_rvalue) at ../../../trunk/gcc/gimplify.c:5341
#3 0x080e1a1a in gimplify_modify_expr (expr_p=0xb7bba554, pre_p=0xbfafd324,
post_p=0xbfafd320, want_value=0 '\0') at ../../../trunk/gcc/gimplify.c:3433
#4 0x080e3b1a in gimplify_expr (expr_p=0xb7bba554, pre_p=0xbfafd324,
post_p=Variable post_p is not available.
)
at ../../../trunk/gcc/gimplify.c:5270
#5 0x080e5dcf in gimplify_stmt (stmt_p=0xb7bba554)
at ../../../trunk/gcc/gimplify.c:4129
#6 0x080e27f7 in gimplify_expr (expr_p=0xb7bb0570, pre_p=0xbfafd3c4,
post_p=0xbfafd3c0, gimple_test_f=0x80daf90 is_gimple_stmt,
fallback=fb_none) at ../../../trunk/gcc/gimplify.c:3591
#7 0x080e5dcf in gimplify_stmt (stmt_p=0xb7bb0570)
at ../../../trunk/gcc/gimplify.c:4129
#8 0x080e6c17 in gimplify_to_stmt_list (stmt_p=0xb7bb0570)
at ../../../trunk/gcc/gimplify.c:4137
#9 0x080e7753 in gimplify_bind_expr (expr_p=0xb7bba56c, temp=0x0,
pre_p=0xbfafd4c4) at ../../../trunk/gcc/gimplify.c:1036
#10 0x080e30e5 in gimplify_expr (expr_p=0xb7bba56c, pre_p=0xbfafd4c4,
post_p=0xbfafd4c0, gimple_test_f=0x80daf90 is_gimple_stmt,
fallback=fb_none) at ../../../trunk/gcc/gimplify.c:5376
#11 0x080e5dcf in gimplify_stmt (stmt_p=0xb7bba56c)
at ../../../trunk/gcc/gimplify.c:4129
#12 0x080e27f7 in gimplify_expr (expr_p=0xbfafd5b0, pre_p=0xbfafd564,
post_p=0xbfafd560, gimple_test_f=0x80daf90 is_gimple_stmt,
fallback=fb_none) at ../../../trunk/gcc/gimplify.c:3591
#13 0x080e5dcf in gimplify_stmt (stmt_p=0xbfafd5b0)
at ../../../trunk/gcc/gimplify.c:4129
#14 0x080e7c6f in gimplify_and_add (t=0xb7bc88e8, list_p=0xbfafd614)
at ../../../trunk/gcc/gimplify.c:336
#15 0x080e2c8c in gimplify_expr (expr_p=0xb7bba590, pre_p=0xbfafd614,
post_p=0xbfafd610, gimple_test_f=0x80daf90 is_gimple_stmt,
fallback=fb_none) at ../../../trunk/gcc/gimplify.c:1241
#16 0x080e5dcf in gimplify_stmt (stmt_p=0xb7bba590)
at ../../../trunk/gcc/gimplify.c:4129
#17 0x080e27f7 in gimplify_expr (expr_p=0xb7bb05c0, pre_p=0xbfafd6b4,
post_p=0xbfafd6b0, gimple_test_f=0x80daf90 is_gimple_stmt,
fallback=fb_none) at ../../../trunk/gcc/gimplify.c:3591
#18 0x080e5dcf in gimplify_stmt (stmt_p=0xb7bb05c0)
at ../../../trunk/gcc/gimplify.c:4129
#19 0x080e6c17 in gimplify_to_stmt_list (stmt_p=0xb7bb05c0)
at ../../../trunk/gcc/gimplify.c:4137
#20 0x080e7753 in gimplify_bind_expr (expr_p=0xb7bba5a8, temp=0x0,
pre_p=0xbfafd7b4) at ../../../trunk/gcc/gimplify.c:1036
#21 0x080e30e5 in gimplify_expr (expr_p=0xb7bba5a8, pre_p=0xbfafd7b4,
post_p=0xbfafd7b0, gimple_test_f=0x80daf90 is_gimple_stmt,
fallback=fb_none) at ../../../trunk/gcc/gimplify.c:5376
#22 0x080e5dcf in gimplify_stmt (stmt_p=0xb7bba5a8)
at ../../../trunk/gcc/gimplify.c:4129
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
CC||fxcoudert at gcc dot gnu dot
||org
Last reconfirmed|2006-01-27 20:42:14 |2006-02-21 09:08:01
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25619
[Bug c/26366] __builtin_expect needs better documentation
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-02-21 09:57 --- Another way instead of if(__builtin_expect((__builtin_expect(x,1) __builtin_expect(y,1)), 0)) would be if(__builtin_expect(!(x y), 1)) I'm sure this does _not_ result in same behavior as __builtin_expect is evaluated quite late during compilation. Some clarification in the docs would be really nice. As to standalone __builtin_expect() calls, they should have no effect. There was talking about a __builtin_assert() or __builtin_assume() that would force a known value. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-02-21 09:57:21 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26366
[Bug c/26367] multiple levels of __builtin_expect
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-02-21 10:03 --- With exception to 'certain' this doesn't really make sense. And the 'certain' one should be called __builtin_assert(). But then, VRP or DOM might already extract information from if (x == 0) abort(); return x; (no, neither 4.1 nor mainline can do this ATM). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26367
[Bug c/26369] value expectation attribute
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-02-21 10:06 --- This doesn't really make any sense. Trying to over-educate a compiler usually leads to worse code. Please rather try to isolate testcases where gcc does not extract value range information it could extract. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26369
[Bug c/26370] anon union/struct at top level
--- Comment #6 from rguenth at gcc dot gnu dot org 2006-02-21 10:09 --- You want to avoid spelling the useless name? Use the preprocessor. Also using a union will prevent a lot of compiler optimization from happening as you are making alias analysis harder. As this is never going to happen. WONTFIX. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26370
[Bug c/26371] dead variable attributes
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-02-21 10:14 ---
So you want
typedef struct {
int bar;
void *foobar
#if !NEEDED_BY_ARCH
__attribute__((readas(0)))
#endif
;
} Foo;
so Foo.foobar is NULL for !NEEDED_BY_ARCH? Why not do the proper thing
and provide accessors like f.i. int the LK:
#define foo_foo(x) (x).bar
#if !NEEDED_BY_ARCH
#define foo_foobar(x) NULL
#else
#define foo_foobar(x) (x).foobar
#endif
no need to invent funny attributes for this. And #defines are properly
localized in some header. OO makes you happy.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26371
[Bug c/26372] opposite of may_alias attribute
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-02-21 10:17 --- This needs more explanation. char pointers are special with and without strict-aliasing. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26372
[Bug libgcj/17021] libgcj verifier resolves classes too eagerly
--- Comment #16 from thebohemian at gmx dot net 2006-02-21 10:37 --- Fixed by the following patches: Main patch: http://gcc.gnu.org/ml/java-patches/2006-q1/msg00124.html Build fix for ARM: http://gcc.gnu.org/ml/java-patches/2006-q1/msg00143.html Stylistic: remove casts http://gcc.gnu.org/ml/java-patches/2006-q1/msg00144.html Stylistic: Indentation http://gcc.gnu.org/ml/java-patches/2006-q1/msg00228.html -- thebohemian at gmx dot net changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17021
[Bug c++/25878] Excessive memory and compile-time with std::map init sequence
--- Comment #9 from rguenth at gcc dot gnu dot org 2006-02-21 11:11 --- Worst offenders are (--disable-checking mainline) cfg cleanup : 2.30 ( 3%) usr 0.00 ( 0%) sys 2.36 ( 3%) wall 1474 kB ( 0%) ggc integration : 5.99 ( 7%) usr 0.29 (11%) sys 6.28 ( 7%) wall 197009 kB (39%) ggc tree CFG cleanup : 3.04 ( 4%) usr 0.03 ( 1%) sys 3.15 ( 4%) wall 10852 kB ( 2%) ggc tree PTA : 3.07 ( 4%) usr 0.06 ( 2%) sys 3.14 ( 4%) wall 10492 kB ( 2%) ggc tree alias analysis : 7.58 ( 9%) usr 0.19 ( 7%) sys 7.81 ( 9%) wall 13190 kB ( 3%) ggc tree SSA incremental : 3.41 ( 4%) usr 0.01 ( 0%) sys 3.37 ( 4%) wall 2068 kB ( 0%) ggc tree operand scan : 1.97 ( 2%) usr 0.18 ( 7%) sys 2.09 ( 2%) wall 14274 kB ( 3%) ggc dominator optimization: 1.26 ( 2%) usr 0.04 ( 2%) sys 1.26 ( 2%) wall 16471 kB ( 3%) ggc tree PRE : 2.34 ( 3%) usr 0.08 ( 3%) sys 2.44 ( 3%) wall 5784 kB ( 1%) ggc tree FRE : 1.85 ( 2%) usr 0.24 ( 9%) sys 2.13 ( 3%) wall 17853 kB ( 3%) ggc dominance frontiers : 2.78 ( 3%) usr 0.00 ( 0%) sys 2.79 ( 3%) wall 0 kB ( 0%) ggc expand: 3.94 ( 5%) usr 0.06 ( 2%) sys 4.05 ( 5%) wall 41170 kB ( 8%) ggc CPROP 1 : 2.31 ( 3%) usr 0.01 ( 0%) sys 2.30 ( 3%) wall 2020 kB ( 0%) ggc PRE : 7.39 ( 9%) usr 0.70 (26%) sys 8.09 (10%) wall 516 kB ( 0%) ggc CPROP 2 : 2.13 ( 3%) usr 0.01 ( 0%) sys 2.14 ( 3%) wall 1402 kB ( 0%) ggc global alloc : 1.84 ( 2%) usr 0.01 ( 0%) sys 1.86 ( 2%) wall 8196 kB ( 2%) ggc TOTAL : 81.14 2.6583.81 510593 kB -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Keywords||compile-time-hog Last reconfirmed|2006-01-20 17:19:33 |2006-02-21 11:11:36 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25878
[Bug other/26208] Serious problem with unwinding through signal frames
--- Comment #6 from jakub at gcc dot gnu dot org 2006-02-21 12:02 --- Created an attachment (id=10884) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10884action=view) gcc-trunk-pr26208.patch -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26208
[Bug other/26208] Serious problem with unwinding through signal frames
--- Comment #7 from jakub at gcc dot gnu dot org 2006-02-21 12:02 --- Created an attachment (id=10885) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10885action=view) binutils-trunk-pr26208.patch -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26208
[Bug fortran/26393] New: CONTAIN-ed + assumed character length + WRITE - ICE at trans-decl.c:849?
Hi! I have some severly twisted code (..): a CONTAIN-ed routine with assumed character length arguments writing out a string (...) which causes an ICE. The bad news, is that a barebones similar thing compiles (and runs) fine, so I had to reduce it by trial and error, 8-( ... Whatever, don't look for much sense here, but I believe that to be still valid (and lf95 would seem to agree!). Philippe PS: what I get (and how I do it): gfortran -c -g -pedantic-errors -Wall Sources.f90 Sources.f90: In function 'outdiffkoeff': Sources.f90:85: internal compiler error: in gfc_get_symbol_decl, at fortran/trans-decl.c:849 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. PPS: the sources: ! MODULE MODULE_DIMENSION ! INTEGER, PARAMETER :: Sng = 4 INTEGER, PARAMETER :: Dbl = 8 INTEGER, PARAMETER :: Dft = Sng ! INTEGER, PARAMETER :: Length_File_Name = 1000 ! END MODULE MODULE_DIMENSION ! ! MODULE MODULE_CONC ! USE MODULE_DIMENSION, ONLY: Length_File_Name, Dft, Sng, Dbl ! INTEGER, PARAMETER :: Weight = 1, Atom = 2 INTEGER, PARAMETER :: Atom_to_Weight = 1, Weight_to_Atom = 2 ! INTEGER, SAVE :: anzKomponenten = 0 INTEGER, SAVE :: concTyp INTEGER, SAVE, ALLOCATABLE, DIMENSION(:,:,:):: diffZeiger ! REAL ( KIND = Dft ), SAVE, ALLOCATABLE :: diffKoefKonst(:) REAL ( KIND = Dft ), SAVE, ALLOCATABLE :: diffKoefAkt(:) ! END MODULE MODULE_CONC ! ! MODULE MODULE_THERMOCALC ! USE MODULE_DIMENSION, ONLY: Dft, Sng, Dbl ! CHARACTER ( LEN = 2 ), SAVE, ALLOCATABLE :: kompNameTQ(:) CHARACTER ( LEN = 12 ), SAVE, ALLOCATABLE :: phaseNameTQ(:) ! LOGICAL, SAVE, ALLOCATABLE :: usePhaseTQ(:) LOGICAL, SAVE, ALLOCATABLE :: diff_Coeff_Inter(:,:) ! INTEGER, SAVE, ALLOCATABLE :: cNr(:) INTEGER, SAVE, ALLOCATABLE :: pNr(:) ! REAL ( KIND = Dft ), SAVE, ALLOCATABLE :: diff_Coeff_Cond_Conc(:,:) REAL ( KIND = Dft ), SAVE, ALLOCATABLE :: diff_Coeff_Cond_Temp(:) ! INTERFACE FUNCTION solveCConvert ( Flag_Conversion, Composition ) USE MODULE_CONC, ONLY: anzKomponenten USE MODULE_DIMENSION, ONLY: Dft IMPLICIT NONE INTEGER, INTENT ( IN ) :: Flag_Conversion REAL ( KIND = Dft ), INTENT ( IN ) :: Composition ( 1 : anzKomponenten ) REAL ( KIND = Dft ):: solveCConvert ( 1 : anzKomponenten ) END FUNCTION solveCConvert END INTERFACE ! END MODULE MODULE_THERMOCALC ! ! SUBROUTINE outDiffKoeff ( phase ) ! USE MODULE_CONC USE MODULE_DIMENSION USE MODULE_THERMOCALC ! IMPLICIT NONE ! LOGICAL, PARAMETER :: thermocalc = .TRUE. ! INTEGER :: IO_Stat INTEGER :: phase, k ! REAL ( KIND = Dft ), PARAMETER:: R = 8.31441 REAL ( KIND = Dft ) :: buffer_conc ( 1 : anzKomponenten ) ! CHARACTER ( LEN = 250 ) :: String ! WRITE ( String, FMT = * ) diff_Coeff_Cond_Temp(phase) CALL CTN_Write_String ( TRIM(String), (A) ) IF ( ( ( thermocalc ) .AND. ( concTyp .EQ. Weight ) ) ) THEN buffer_conc = solveCConvert ( Atom_to_Weight, diff_Coeff_Cond_Conc(phase,:) ) * 1E2 ELSE buffer_conc = diff_Coeff_Cond_Conc(phase,:) * 1E2 ENDIF DO k = 1, anzKomponenten WRITE ( UNIT = String, FMT = (ES12.4) ) buffer_conc(k) CALL CTN_Write_String ( TRIM(String), (A) ) ENDDO ! CONTAINS ! SUBROUTINE CTN_Write_String ( String, Fmt ) ! CHARACTER ( LEN = * ), INTENT ( IN ):: String, Fmt ! WRITE ( UNIT = 12, FMT = TRIM(Fmt), IOSTAT = IO_Stat ) TRIM(String) IF ( IO_Stat .NE. 0 ) THEN CALL toolStop ENDIF ! END SUBROUTINE CTN_Write_String ! END SUBROUTINE outDiffKoeff ! PPPS: I'm using 4.2.0 20060221 (experimental) -- Summary: CONTAIN-ed + assumed character length + WRITE - ICE at trans-decl.c:849? Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org
[Bug fortran/26393] CONTAIN-ed + assumed character length + WRITE - ICE at trans-decl.c:849?
--- Comment #1 from P dot Schaffnit at access dot rwth-aachen dot de 2006-02-21 12:24 --- Oops! I forgot to mention that the whole thing occurs under Linux (see hereafter). Philippe PS: uname -a: Linux pinguin7 2.6.5-7.104-bigsmp #1 SMP Wed Jul 28 16:42:13 UTC 2004 i686 i686 i386 GNU/Linux -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26393
[Bug target/15617] building groff-1.19.1 with -Os -march=pentium4 causes sig 11
--- Comment #12 from belyshev at depni dot sinp dot msu dot ru 2006-02-21 12:38 --- (In reply to comment #11) duplicate of #13685 ? yes. *** This bug has been marked as a duplicate of 13685 *** -- belyshev at depni dot sinp dot msu dot ru changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15617
[Bug target/13685] Building simple test application with -march=pentium3 -Os gives SIGSEGV (unaligned sse instruction)
--- Comment #14 from belyshev at depni dot sinp dot msu dot ru 2006-02-21 12:38 --- *** Bug 15617 has been marked as a duplicate of this bug. *** -- belyshev at depni dot sinp dot msu dot ru changed: What|Removed |Added CC||kpfleming at ||backtobasicsmgmt dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13685
[Bug target/13685] Building simple test application with -march=pentium3 -Os gives SIGSEGV (unaligned sse instruction)
--- Comment #15 from belyshev at depni dot sinp dot msu dot ru 2006-02-21
12:45 ---
Another testcase, use -Os -msse, fails with all versions since 3.2:
typedef float __m128 __attribute__ ((vector_size (16)));
typedef int __m64 __attribute__ ((vector_size (8)));
int puts (const char *s);
void foo (__m128 *, __m64 *, int);
int main (void)
{
foo (0, 0, 0);
return 0;
}
void foo (__m128 *dst, __m64 *src, int n)
{
__m128 xmm0 = { 0 };
while (n 64)
{
puts ();
xmm0 = __builtin_ia32_cvtpi2ps (xmm0, *src);
*dst = xmm0;
n --;
}
}
--
belyshev at depni dot sinp dot msu dot ru changed:
What|Removed |Added
Known to fail||3.2.3 3.3.6 3.4.6 4.0.3
||4.1.0 4.2.0
Last reconfirmed|-00-00 00:00:00 |2006-02-21 12:45:28
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13685
[Bug target/13685] Building simple test application with -march=pentium3 -Os gives SIGSEGV (unaligned sse instruction)
--- Comment #16 from belyshev at depni dot sinp dot msu dot ru 2006-02-21 12:51 --- raising severity because this bug makes -Os almost useless on modern x86. -- belyshev at depni dot sinp dot msu dot ru changed: What|Removed |Added CC||belyshev at depni dot sinp ||dot msu dot ru Severity|normal |major http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13685
[Bug fortran/26393] ICE with function returning variable lenght array
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-02-21 12:58 --- Reduced testcase: MODULE MODULE_CONC INTEGER, SAVE :: anzKomponenten = 0 END MODULE MODULE_CONC MODULE MODULE_THERMOCALC INTERFACE FUNCTION solveCConvert ( ) USE MODULE_CONC, ONLY: anzKomponenten REAL :: solveCConvert ( 1 : anzKomponenten ) END FUNCTION solveCConvert END INTERFACE END MODULE MODULE_THERMOCALC SUBROUTINE outDiffKoeff ( ) USE MODULE_CONC USE MODULE_THERMOCALC REAL:: buffer_conc ( 1 : anzKomponenten ) buffer_conc = solveCConvert ( ) * 1E2 END SUBROUTINE outDiffKoeff This has nothing to do with assumed write or characters. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-valid-code Last reconfirmed|-00-00 00:00:00 |2006-02-21 12:58:56 date|| Summary|CONTAIN-ed + assumed |ICE with function returning |character length + WRITE -|variable lenght array | ICE at trans-decl.c:849? | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26393
[Bug other/26208] Serious problem with unwinding through signal frames
--- Comment #8 from jakub at gcc dot gnu dot org 2006-02-21 13:12 ---
Created an attachment (id=10886)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10886action=view)
linux-2.6.15-pr26208.patch
This is what I have so far (libjava not done yet), but I'm not sure a simple
CIE flag isn't sufficient on all arches. Consider:
#define _GNU_SOURCE
#include signal.h
#include string.h
#include fenv.h
int *p;
double d = 1.0, e = 0.0;
void sigfpe (int signo) { }
void sigsegv (int signo) { }
void fpe (void) { d /= e; }
void segv (void) { *p = 0; }
int
main (int argc, char **argv)
{
struct sigaction sa;
sa.sa_handler = sigfpe;
sigemptyset (sa.sa_mask);
sa.sa_flags = 0;
sigaction (SIGFPE, sa, 0);
feenableexcept (FE_ALL_EXCEPT);
sa.sa_handler = sigsegv;
sigemptyset (sa.sa_mask);
sa.sa_flags = 0;
sigaction (SIGSEGV, sa, 0);
if (argc 2)
return 1;
if (strcmp (argv[1], fpe) == 0)
fpe ();
else if (strcmp (argv[1], segv) == 0)
segv ();
else
return 1;
return 0;
}
For segv the PC saved in sigcontext is always before the faulting instruction,
at least on i386, x86_64, ppc, ppc64, s390x I tried.
For asynchronously sent signals (that's the reason why I opened this PR), saved
PC will be also before the next instruction to be executed, so for SIGSEGV as
well asynchronously sent signals we want the fs-pc = context-ra in
execute_cfa_program and _Unwind_Find_FDE (context-ra, ) behavior.
But, for SIGFPE things are more difficult.
On s390x, PC is in this case after the ddbr instruction rather than before it,
on i386 when using i387 FPU stack PC is after the fdivrp instruction, but at
the following fstpl instruction; adding nops in between shows that it actually
is always before fstpl), on x86_64 or i386 -mfpmath=sse it is before the
failing divsd, on ppc similarly.
We should avoid doing hacks, because then say if you inside a SIGFPE handler
call a cancellation point function and a thread is cancelled, we can't rely
on hacks like libjava/include/*-signal.h is doing. And the instruction that
divides by zero can be e.g. at the very beginning of a function, or the last
instruction in it.
So, my preference would be for the S flag to mean there is a CFA expression
present in the FDE augmentation area. unwind-dw2.c (uw_frame_state_for) would
evaluate that expression (first pushing say context-cfa to the stack) and
set fs-signal_frame to 1 iff it evaluates to non-zero.
MD_FALLBACK_FRAME_STATE_FOR would conditionally define fs-signal_frame
depending on signal number, or si_code and other stuff.
On i386/x86_64 I guess we want to always set fs-signal_frame (so e.g.
the S CFA expression would be DW_OP_lit1), I'd appreciate feedback for other
arches.
Another issue is that this needs coordination between
libgcc/binutils/glibc/kernel/libjava.
I did a quick check:
alpha libc cfi
i386 vDSO or libc libjava private sigaction
x86_64 libc (bogus cfi, in the end MD_FALLBACK_FRAME_STATE_FOR)
ppc vDSO
ppc64 vDSO
sparc32 libc, MD_FALLBACK_FRAME_STATE_FOR
sparc64 libc, MD_FALLBACK_FRAME_STATE_FOR
s390 stack, MD_FALLBACK_FRAME_STATE_FOR libjava private sigaction
s390x stack, MD_FALLBACK_FRAME_STATE_FORlibjava private sigaction
ia64 irrelevant, doesn't use Dwarf2 unwind info
This is most important for libjava, as libjava is doing ugly hacks around this
problem and thus should know if S flag will be used or not. In i386 case we
are fine, libjava calls sigaction syscall directly and sets SA_RESTORER, so
sigreturn pad in libjava is used. Alpha could use the same trick,
MD_FALLBACK_FRAME_STATE_FOR is under GCC's control, but on ppc/ppc64 we are
in trouble when using approx. November 2005 till now kernels (before that
there was no vDSO on ppc{,64}).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26208
[Bug c++/21583] FAIL: g++.old-deja/g++.eh/badalloc1.C execution test
--- Comment #7 from ghazi at gcc dot gnu dot org 2006-02-21 13:34 --- Subject: Bug 21583 Author: ghazi Date: Tue Feb 21 13:34:23 2006 New Revision: 111333 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=111333 Log: PR c++/21583 Backport: 2004-11-30 Loren James Rittle [EMAIL PROTECTED] * g++.old-deja/g++.eh/badalloc1.C (arena_size): Bump up to 262144 to support new requirements on FreeBSD 5. 2004-11-26 Mark Mitchell [EMAIL PROTECTED] * g++.old-deja/g++.eh/badalloc1.C: Robustify. Modified: branches/gcc-3_4-branch/gcc/testsuite/ChangeLog branches/gcc-3_4-branch/gcc/testsuite/g++.old-deja/g++.eh/badalloc1.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21583
[Bug c++/21583] FAIL: g++.old-deja/g++.eh/badalloc1.C execution test
--- Comment #8 from ghazi at gcc dot gnu dot org 2006-02-21 13:40 --- This issue was fixed by backporting the 4.0 version of the testcase. The update to the testcase necessary for ia64-hpux is on mainline/4.1 and is not included in this fix. However it is tracked in PR 19888 in case someone wants to backport that additional bit to 4.0 3.4. -- ghazi at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||19888 nThis|| Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |3.4.6 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21583
[Bug libgomp/26234] [4.2 Regression] --disable-libgomp is not documented
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-02-21 13:50:33 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26234
[Bug middle-end/20623] ICE: fold check: original tree changed by fold with --enable-checking=fold
--- Comment #10 from ghazi at gcc dot gnu dot org 2006-02-21 13:59 --- 4.0 results are now on par with 4.1, meaning AFAICS we only have the address of labels problem to worry about on all 4.* branches. http://gcc.gnu.org/ml/gcc-testresults/2006-02/msg00986.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20623
[Bug tree-optimization/26376] K+R style function compiled with -qipa-pta ICEs
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-21 14:05 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||dberlin at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-valid-code Last reconfirmed|-00-00 00:00:00 |2006-02-21 14:05:16 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26376
[Bug c++/26395] New: Wrong attempts to create a copy of an anonymous object
The bug is triggered by a very simple code below (it doesn't need anything to
include, etc)
-
class A { };
class C : public A {
public:
C() {}
private:
C(const C ) : A() {} // copying prohibited
};
void f(const A ref) {}
void g() {
f(C());
}
-
The compiler prints the following error messasge:
test_bug.cpp: In function 'void g()':
test_bug.cpp:6: error: 'C::C(const C)' is private
test_bug.cpp:10: error: within this context
As easy to see, there is no need for a copy constructor here, because C is the
immediate descender of the class A, so it can be (and must be) cast to A
without creating any temporaries.
BTW, if we replace the body of g() with smth. like this:
void g() {
C c;
f(c);
}
no errors are reported, and the compilation succeeds.
I tried this with 3.4 and 4.1, they do the same wrong thing. Funny to say, 2.96
compiles the code with no complains.
The most recent compiler I've got gives the following version info:
g++41 (GCC) 4.1.0 20050924 (experimental)
Copyright (C) 2005 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
As my 3.4 does the same, I guess that the bug remains uncaught for 1 year at
least so I don't think it's already known.
As far as I understand, the bug is serious because in fact compiler sil;ently
creates copies which it must not create; the only thing which let me know the
bug is that I've made the copy conastructor private to prohibit copying of some
complicated objects.
--
Summary: Wrong attempts to create a copy of an anonymous object
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: z81 at backpath dot croco dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26395
[Bug tree-optimization/26376] K+R style function compiled with -fipa-pta ICEs
--- Comment #2 from dberlin at gcc dot gnu dot org 2006-02-21 14:48 --- fipa-pta currently doesn't do anything interesting, it just builds points-to sets and then deletes them. I will fix things when i get a chance.. -- dberlin at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dberlin at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-02-21 14:05:16 |2006-02-21 14:48:34 date|| Summary|K+R style function compiled |K+R style function compiled |with -qipa-pta ICEs |with -fipa-pta ICEs http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26376
[Bug libgcj/26351] Native Momory Leak in ResourceBundle
--- Comment #3 from fexx at fexx dot org 2006-02-21 14:52 --- I belive this is another bug than 12475. (I'm using libgcj come with gcc 3.4.5 distribution.) PR 12475 stated that, when an Exception was initialized, a constructor gnu.gcj.runtime.StackTrace(int) was indirectly invoked, and the native memory allocated and set to StackTrace.addrs in StackTrace.fillInStackTrace(int,int) leaked. Hence, the fix to 12475 freed the (leaked) native memory in gnu.gcj.finalize(). This one, PR 26351, is a problem regarding some use of gnu.gcj.runtime.StackTrace.classAt(int). It causes two (or more) invokation of StackTrace.fillInStackTrace(int,int) against a same StackTrace object, once from its constructor, and once more from classAt(int). Every invokation of fillInStackTrace(int,int) allocates a new native memory through _Jv_Malloc() and store it in addrs. The second invokation silently discards the native memory allocated during the first, causing a leak. _Jv_Free in finalize() doesn't help. (Please note that the macro GET_FRAME used in the native method StackTrace.classAt(int) *may* invoke fillInStackTrace *when* N is larger than expected.) There may be another execution paths, but calling java.util.ResourceBundle.getBundle(String) was the easiest case that I could find. -- fexx at fexx dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26351
[Bug c/26396] New: Incorrect opcode in __do_clear_bss if bss has more than 15 bytes
Sixteen or more bytes of uninitialized global variables in a program will
cause gcc to generate an incorrect opcode in __do_clear_bss in the startup
for the avr target as shown in this example.
Source file, t.c:
char x[16];
int main(void) { }
Compile script:
avr-gcc -c -mmcu=atmega88 -o t.o t.c
avr-gcc -mmcu=atmega88 -Wl,-mavr4 -Wl,--oformat=ihex,-s t.o -o t.hex
avr-gcc -g -mmcu=atmega88 -Wl,-mavr4 t.o -o t.elf
avr-objdump -dSCg t.elf t.lst
Output t.lst, lines 68,69:
0060 .do_clear_bss_start:
60: a0 31 cpi r26, 0x10 ; 16
Output t.hex, line 8:
:100056001160A0E1B16001C01D92B031B107E1F7B6
The listing is correct, a0 31, but the hex file is wrong, B031.
And, indeed, test programs fail to execute on real hardware with 16
or more bytes of BSS, but _do_ execute with less.
The relevant source file is gcc-4.0.2/gcc/config/avr/libgcc.S, line 727.
But I'm having difficulty finding the actual bug.
I'm using Mandriva Linux 2006 (2.6.12-12mdk) and compiled from source
binutils-2.16.1, gcc-4.0.2, and avr-libc-1.4.3.
$ avr-gcc -v
Using built-in specs.
Target: avr
Configured with: ../configure --target=avr --host=i686-pc-linux-gnu
--disable-shared --disable-nls --enable-languages=c,c++
Thread model: single
gcc version 4.0.2
Note: This is a tiny wrinkle in an excellent piece of software.
I thank everyone that works on gcc and related projects.
--
Summary: Incorrect opcode in __do_clear_bss if bss has more than
15 bytes
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: KenJackson at ieee dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: avr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26396
[Bug c++/26397] New: Program crashes when rethrowing exception
The program below crashes with illegal instruction when rethrowing the
previously caught exception.
GCC version:
$ powerpc-ibm-aix5.2.0.0-gcc-4.0.2 -v
Using built-in specs.
Target: powerpc-ibm-aix5.2.0.0
Configured with: ../gcc-4.0.2/configure --disable-nls --enable-threads=posix
--enable-languages=c,c++ --disable-shared
--enable-version-specific-runtime-libs
Thread model: aix
gcc version 4.0.2
$ powerpc-ibm-aix5.2.0.0-gcc-4.0.2 exctest.cpp -lstdc++ -o exctest
#include string
struct FzException
{
const char *what()
{
mWhat = std::string(a) + std::string(b);
return mWhat.c_str();
}
std::string mWhat;
};
int main(int, char **argv)
{
try
{
try
{
throw FzException();
}
catch(FzException e)
{
e.what();
throw;
}
}
catch(...)
{
exit(1);
}
}
--
Summary: Program crashes when rethrowing exception
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: michael dot klein at fazi dot de
GCC build triplet: powerpc-ibm-aix5.2.0.0
GCC host triplet: powerpc-ibm-aix5.2.0.0
GCC target triplet: powerpc-ibm-aix5.2.0.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26397
[Bug target/26397] Program crashes when rethrowing exception
--- Comment #1 from michael dot klein at fazi dot de 2006-02-21 15:57 --- Created an attachment (id=10887) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10887action=view) Preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26397
[Bug c++/26395] Wrong attempts to create a copy of an anonymous object
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-21 15:59 --- Please read: http://gcc.gnu.org/gcc-3.4/changes.html GCC before 3.4 was accepting invalid code. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26395
[Bug target/26396] Incorrect opcode in __do_clear_bss if bss has more than 15 bytes
--- Comment #1 from KenJackson at ieee dot org 2006-02-21 16:00 ---
I have confirmed that I can work around the error by adding these two lines:
void skip_clear_bss(void) __attribute__((naked,section(.init3)));
void skip_clear_bss(void) { asm volatile (rjmp main : :); }
But unfortunately this also skips __do_copy_data, which initializes all
initialized global data. Both it and __do_clear_bss are in segment .init4.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26396
[Bug target/26396] Incorrect opcode in __do_clear_bss if bss has more than 15 bytes
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-02-21 16:02 --- Which is just: .section .init4,ax,@progbits .global __do_clear_bss __do_clear_bss: ldi r17, hi8(__bss_end) ldi r26, lo8(__bss_start) ldi r27, hi8(__bss_start) rjmp.do_clear_bss_start .do_clear_bss_loop: st X+, __zero_reg__ .do_clear_bss_start: cpi r26, lo8(__bss_end) cpc r27, r17 brne.do_clear_bss_loop -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|major |normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26396
[Bug target/26396] Incorrect opcode in __do_clear_bss if bss has more than 15 bytes
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-02-21 16:02 --- __do_clear_bss comes from libgcc.S in gcc/config/avr. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26396
[Bug target/26396] Incorrect opcode in __do_clear_bss if bss has more than 15 bytes
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-02-21 16:04 --- From looking at this bug, I want to say this is actually a binutils bug and not a GCC one. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26396
[Bug target/26397] Program crashes when rethrowing exception
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-02-21 16:05 --- $ powerpc-ibm-aix5.2.0.0-gcc-4.0.2 exctest.cpp -lstdc++ -o exctest Can you try linking with: $ powerpc-ibm-aix5.2.0.0-g++-4.0.2 exctest.cpp -o exctest instead and see if that helps? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26397
[Bug target/26396] Incorrect opcode in __do_clear_bss if bss has more than 15 bytes
--- Comment #5 from KenJackson at ieee dot org 2006-02-21 16:17 --- I found libgcc.S and even referenced it in the original post, but I can't reproduce the error with avr-as from binutils. For example: Source file, u.s: .section .init5,ax,@progbits .global xfunc .func xfunc xfunc: cpi r26,16 .endfunc Assemble script: avr-as u.s -o u.o avr-ld --oformat=ihex -s u.o -o u.hex Output u.hex, line 1: :0200A0312D The opcode is correct, A031. -- KenJackson at ieee dot org changed: What|Removed |Added Severity|normal |major http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26396
[Bug target/26397] Program crashes when rethrowing exception
--- Comment #3 from michael dot klein at fazi dot de 2006-02-21 16:21 --- Didn't help, same result with powerpc-ibm-aix5.2.0.0-g++ (there is no powerpc-ibm-aix5.2.0.0-g++-4.0.2 here). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26397
[Bug tree-optimization/26376] K+R style function compiled with -fipa-pta ICEs
--- Comment #3 from dberlin at gcc dot gnu dot org 2006-02-21 16:20 --- Subject: Re: K+R style function compiled with -qipa-pta ICEs On Tue, 2006-02-21 at 14:05 +, pinskia at gcc dot gnu dot org wrote: --- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-21 14:05 --- Confirmed. So this occurs because the argument doesn't appear in the DECL_ARGUMENTS list when we have K+R functions (probably because they have no real parameter lists, or some such) This is not something I can really fix, it is only something i should be able to avoid. If we can't get the real argument list for a function, we will never be able to properly process function calls anyway. Basically, i will make fipa-pta do nothing at all if it sees K + R functions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26376
[Bug target/26396] Incorrect opcode in __do_clear_bss if bss has more than 15 bytes
--- Comment #6 from KenJackson at ieee dot org 2006-02-21 16:23 --- To further narrow this, I should replace the linking line from my original post: avr-gcc -mmcu=atmega88 -Wl,-mavr4 -Wl,--oformat=ihex,-s t.o -o t.hex with the equivalent call to avr-ld. But it's not clear what that would be. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26396
[Bug c/26398] New: Wrong code generated with SPE-Extensions on PowerPC
Hello, I got some problems with the SPE-extensions. Quite a severe as I think. For float t; char u; t = 1.0; u = ( ( t0.0)?-1:((t0.0)?1:0)); with the following compiler flags -mcpu=8540 -meabi -mspe=yes -mabi=spe -mfloat-gprs=yes -fsingle-precision-constant -fshort-double -mno-sdata -c -g -D__EMB_RPE__ the result for u is either -1 if t 0.0 or 0 else. The case if t 0.0 is never taken. My diab shows correct results. Generated assembler: t = 1.0; lis r0,0x3F80 stw r0,0x1EC(r31) u = ( ( t0.0)?-1:((t0.0)?1:0)); lwz r9,0x1EC(r31) lir0,0x0 efscmplt cr7,r9,r0 bgt cr7,0x39F04 b 0x39F10 lir0,-0x1 stb r0,0x1F1(r31) b 0x39F28 lwz r9,0x1EC(r31) lir0,0x0 efscmpgt cr7,r9,r0 mfcr r0 extrwir0,r0,0x1,0x1E ; r0,r0,1,30 stb r0,0x1F1(r31) lbz r0,0x1F1(r31) stb r0,0x1F0(r31) Looking in the e500-core-manual it shows that the GT-compare-result is stored in bit 61 of CR. I suppose in this case the extrwi (or rlwinm-Instruction in case of objdump) should check for bit 29 (=61-32), which is not the case. Sincery yours, Christian Metzler. -- Summary: Wrong code generated with SPE-Extensions on PowerPC Product: gcc Version: 3.4.4 Status: UNCONFIRMED Severity: critical Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: christian dot metzler at bmw-carit dot de GCC host triplet: i686-pc-cygwin GCC target triplet: powerpc-unknown-eabi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26398
[Bug target/26398] Wrong code generated with SPE-Extensions on PowerPC
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|normal GCC target triplet|powerpc-unknown-eabi|powerpc-unknown-eabispe http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26398
[Bug c++/26399] New: -fprofile-use fails with unnamed namespaces in 4.1.0 prerelease
Hello,
the problem seems to have returned, similar problems have been reported several
times at least in the 4.0.0 prerelease time, as far as Google tells.
See
gcc.gnu.org/ml/gcc/2005-03/msg00844.html
http://kegel.com/crosstool/crosstool-0.38/patches/gcc-4.0.1/pr20815-fix.patch
I have a larger code base, where the compiler bails out at every first
occurence of unnamed
namespaces with -fprofile-use. The working files get a remarkable speedup due
to profile-use,
so I would prefer to be able to use it for all files without having to assign
the namespaces
names. I can get away for the moment by compiling the failing files without
-fprofile-use.
Thanks,
Bernd Strieder
proft1.cc:
--
namespace {
int calc(int j)
{
if (j==0) return 0;
return calc(j-1)*j % 17;
}
}
int main(void)
{
return calc(25);
}
--
Steps to reproduce:
g++ -fprofile-generate -c proft1.cc
g++ -fprofile-generate -o proft1 proft1.o
./proft1
g++ -fprofile-use -c proft1.cc
proft1.cc: In function 'intunnamed::calc(int)':
proft1.cc:13: error: coverage mismatch for function
'_ZN38_GLOBAL__N_proft1.cc__DA7CA6ED4calcEi' while reading counter
'arcs'
proft1.cc:13: error: checksum is 2c81fd4d instead of dd8ba62c
--
Summary: -fprofile-use fails with unnamed namespaces in 4.1.0
prerelease
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: strieder at informatik dot uni-kl dot de
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26399
[Bug gcov/profile/26399] -fprofile-use fails with unnamed namespaces in 4.1.0 prerelease
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-21 16:59 --- 2005-10-31 Jan Hubicka [EMAIL PROTECTED] PR profile/20815 * coverage.c (coverage_checksum_string): Fix code to stip random seeds from symbol names while computing checkup. The patch which you referenced was applied. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26399
[Bug libstdc++/26297] boostrap fails with invalid cast compiling libstdc++ with --disable-nls on AIX
--- Comment #10 from multix at gmail dot com 2006-02-21 17:00 ---
thanks. I fixed the header as you suggest and typed the same boostrap make
command again and left it running overninght. I found that gcc had completed
build and I installed.
Trying to compile a hello world program like
#include iostream
int main ()
{
std::cout hello;
return 0;
}
yields me
g++ hello.c
ld: 0711-317 ERROR: Undefined symbol: __gxx_personality_v0
ld: 0711-317 ERROR: Undefined symbol: .std::basic_ostreamchar,
std::char_traitschar std::operator std::char_traitschar
(std::basic_ostreamchar, std::char_traitschar , char const*)
ld: 0711-317 ERROR: Undefined symbol: .std::ios_base::Init::Init()
ld: 0711-317 ERROR: Undefined symbol: .std::ios_base::Init::~Init()
ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information.
collect2: ld returned 8 exit status
I don't think this is now related to the bugs we are discussing here ? Since
the gcc 3.04 has known problems too (ld: 0711-317 ERROR: Undefined symbol:
std::string::_Rep::_S_max_size) I tried the program with 2.95 and it works.
I wonder know if your fix is safe and if it could be integrated in future
stable versions of 3.4x and 4.x and that there are other problems to solve
instead.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26297
[Bug gcov/profile/26399] -fprofile-use fails with unnamed namespaces in 4.1.0 prerelease
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-02-21 17:00 --- But still fails. Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||hubicka at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-02-21 17:00:58 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26399
[Bug rtl-optimization/26375] [4.2 Regression] Swing modulo scheduling results in ICE
--- Comment #6 from janis at gcc dot gnu dot org 2006-02-21 17:08 --- I kept losing contact with the regression hunt system, and the first, bogus result was based on a typo I didn't notice before getting kicked off the system again. The fixed regression hunt on powerpc-linux identified the following patch from dberlin and zadeck: http://gcc.gnu.org/viewcvs?view=revrev=110312 r110312 | zadeck | 2006-01-27 22:23:32 + (Fri, 27 Jan 2006) -- janis at gcc dot gnu dot org changed: What|Removed |Added CC||zadeck at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26375
[Bug target/26396] Incorrect opcode in __do_clear_bss if bss has more than 15 bytes
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-02-21 17:11 --- Try doing: avr-gcc -mmcu=atmega88 -Wl,-mavr4 -Wl,--oformat=ihex,-s t.o -o t.hex -v (note the -v) So this is not a GCC after all. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26396
Re: [Bug c++/26395] Wrong attempts to create a copy of an anonymous object
pinskia at gcc dot gnu dot org [EMAIL PROTECTED] writes: | --- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-21 15:59 --- | Please read: | http://gcc.gnu.org/gcc-3.4/changes.html | | | GCC before 3.4 was accepting invalid code. | | | -- | | pinskia at gcc dot gnu dot org changed: | |What|Removed |Added | | Status|UNCONFIRMED |RESOLVED | Resolution||INVALID In fact, there should be an open PR for this -- which is a request for enhancement. The code is ill-formed under C++98 and C++03; it is well formed in C++0x (the changes are in the Working Paper.) -- Gaby
[Bug c++/26395] Wrong attempts to create a copy of an anonymous object
--- Comment #2 from gdr at integrable-solutions dot net 2006-02-21 17:19 --- Subject: Re: Wrong attempts to create a copy of an anonymous object pinskia at gcc dot gnu dot org [EMAIL PROTECTED] writes: | --- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-21 15:59 --- | Please read: | http://gcc.gnu.org/gcc-3.4/changes.html | | | GCC before 3.4 was accepting invalid code. | | | -- | | pinskia at gcc dot gnu dot org changed: | |What|Removed |Added | | Status|UNCONFIRMED |RESOLVED | Resolution||INVALID In fact, there should be an open PR for this -- which is a request for enhancement. The code is ill-formed under C++98 and C++03; it is well formed in C++0x (the changes are in the Working Paper.) -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26395
[Bug other/26208] Serious problem with unwinding through signal frames
--- Comment #9 from jakub at gcc dot gnu dot org 2006-02-21 17:52 --- This is related to the almost forgotten http://sources.redhat.com/bugzilla/show_bug.cgi?id=300 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26208
[Bug tree-optimization/26400] New: Missed jump threading on the tree level
Missed jump threading on the tree level with the following C code:
struct a
{
int t;
};
int f(struct a *b, struct a *c)
{
if (b != c)
{
int *d = b-t;
int *d1 = c-t;
if (d == d1)
return 1;
}
return 0;
}
This shows up in tramp3d:
if (__last != __last.8832) goto L16; else goto L17;
L16:;
if (__last-engine_m != __last.8832-engine_m) goto L18; else goto L17;
--
Summary: Missed jump threading on the tree level
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: missed-optimization, TREE
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
OtherBugsDependingO 22501
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26400
[Bug tree-optimization/26400] Missed jump threading on the tree level
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-21 18:06 --- This comes from std::vector_Tp, _Alloc::_M_insert_aux. Another example from the same function: L15:; if (__position$_M_current != __x_copy) goto L20; else goto L9; L20:; if (__position$_M_current-engine_m != __x_copy.engine_m) goto L22; else goto L9; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26400
[Bug target/26396] Incorrect opcode in __do_clear_bss if bss has more than 15 bytes
--- Comment #8 from KenJackson at ieee dot org 2006-02-21 18:23 --- Thanks for the -v. I ran this: avr-ld -m avr4 -Tdata 0x800100 -o t.hex /usr/local/avr/lib/avr4/crtm88.o \ -L/usr/local/lib/gcc/avr/4.0.2/avr4 \ -L/usr/local/lib/gcc/avr/4.0.2 \ -L/usr/local/avr/lib/avr4 \ -L/usr/local/avr/lib\ -mavr4 --oformat=ihex -s t.o -lgcc -lc And the resulting t.hex has the incorrect opcode, B031. I wasn't aware that ld generated any opcodes. I thought it just scooped up the outputs from compilers and assemblers and linked them together. But apparently it does, and apparently avr-ld generated this bad opcode. I searched the binutils bugzilla at sourceware.org for bss and avr and each search returned Zarro Boogs found. Makes me wonder. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26396
[Bug target/26146] [4.2 Regression] Bootstrapping mainline on Solaris 10/x86 fails
--- Comment #3 from brett dot albertson at stratech dot com 2006-02-21 18:42 --- (In reply to comment #0) /vol/gcc/src/gcc-dist/gcc/config/i386/gmon-sol2.c:1: error: CPU you selected does not support x86-64 instruction set make[5]: *** [amd64/gmon.o] Error 1 I confirm that I get this same error. I'm also building on Solaris 10 x86. My triple is i386-pc-solaris2.10 as detected by the configuration machinery. This is a regression from 4.1 and 4.0 since those bootstrap successfully. -- brett dot albertson at stratech dot com changed: What|Removed |Added CC||brett dot albertson at ||stratech dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26146
[Bug other/26208] Serious problem with unwinding through signal frames
--- Comment #10 from rth at gcc dot gnu dot org 2006-02-21 18:47 ---
(In reply to comment #8)
This is what I have so far (libjava not done yet)
The patches so far look fine.
but I'm not sure a simple CIE flag isn't sufficient on all arches.
You're confounding two different problems: (1) How to unwind from a signal,
at whatever point the signal is delivered, and (2) How to recognize a given
signal within an exception handling region.
Problem 1 is we arrive at the signal handler with the PC set somewhere. We
assume that the insn at the PC is the next insn to be executed, and that all
previous insns have already been executed. This is as true of SIGFPE as any
other signal.
Problem 2 is that the SIGFPE may be deliviered much later than the insn that
caused the signal. This is particularly obvious with 80387, in that it may
not be delivered until the next FP insn. The only reason we might want to
care about this problem is if we wish to turn the signal into an exception,
and send that to a surrounding catch handler. This is not the problem we're
trying to solve in this PR. Frankly, I'm not too concerned about solving it
ever; it requires changes to code generation to solve properly, and I've seen
no one actually request it. If anyone would have wanted it, I would have
expected Java, but Java runs with all FP excptions masked.
This is most important for libjava, as libjava is doing ugly hacks around this
problem and thus should know if S flag will be used or not. In i386 case we
are fine, libjava calls sigaction syscall directly and sets SA_RESTORER, so
sigreturn pad in libjava is used. Alpha could use the same trick
Yep.
MD_FALLBACK_FRAME_STATE_FOR is under GCC's control, but on ppc/ppc64 we are
in trouble when using approx. November 2005 till now kernels (before that
there was no vDSO on ppc{,64}).
Will these kernels refuse the sa_restorer field? I see that ppc does
have such a field...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26208
[Bug libobjc/26309] [4.1/4.2 Regression] libobjc bootstrap failure on Tru64 UNIX V4.0F
--- Comment #8 from ro at gcc dot gnu dot org 2006-02-21 19:13 --- Subject: Bug 26309 Author: ro Date: Tue Feb 21 19:13:21 2006 New Revision: 111339 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=111339 Log: PR libobjc/26309 * thr-objc.c (_XOPEN_SOURCE): Don't define on Tru64 UNIX. Modified: trunk/libobjc/ChangeLog trunk/libobjc/thr-objc.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26309
[Bug libobjc/26309] [4.1/4.2 Regression] libobjc bootstrap failure on Tru64 UNIX V4.0F
--- Comment #9 from ro at gcc dot gnu dot org 2006-02-21 19:17 --- Subject: Bug 26309 Author: ro Date: Tue Feb 21 19:17:27 2006 New Revision: 111340 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=111340 Log: PR libobjc/26309 * thr-objc.c (_XOPEN_SOURCE): Don't define on Tru64 UNIX. Modified: branches/gcc-4_1-branch/libobjc/ChangeLog branches/gcc-4_1-branch/libobjc/thr-objc.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26309
[Bug libobjc/26309] [4.1/4.2 Regression] libobjc bootstrap failure on Tru64 UNIX V4.0F
--- Comment #10 from ro at gcc dot gnu dot org 2006-02-21 19:19 --- Proposed patch. -- ro at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ro at gcc dot gnu dot org |dot org | URL||http://gcc.gnu.org/ml/gcc- ||patches/2006- ||02/msg01289.html Status|NEW |ASSIGNED Last reconfirmed|2006-02-18 17:22:44 |2006-02-21 19:19:51 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26309
[Bug libobjc/26309] [4.1/4.2 Regression] libobjc bootstrap failure on Tru64 UNIX V4.0F
--- Comment #11 from ro at gcc dot gnu dot org 2006-02-21 19:20 --- Fixed for 4.1.0 and on mainline. -- ro at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26309
[Bug libobjc/26309] [4.1/4.2 Regression] libobjc bootstrap failure on Tru64 UNIX V4.0F
--- Comment #12 from ro at techfak dot uni-bielefeld dot de 2006-02-21 19:22 --- Subject: Re: [4.1/4.2 Regression] libobjc bootstrap failure on Tru64 UNIX V4.0F aoliva at gcc dot gnu dot org writes: I can't really look into it because it's specific to an OS I don't have access to.The proposed change looks reasonable. Reverting my change will very likely break the build on well-behaved OSes. Do you remember which OS needed that define? thr-objc.c seems to have worked without for a long time. I suppose it might be possible to fix the build on OSF with fixincludes, since it looks a lot like some header bug. Probably. I might investigate this. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26309
[Bug c/26401] New: x264 revision 439 make fprofiled fails
gcc: ftp://ftp.nluug.nl/mirror/languages/gcc/prerelease-4.1.0-20060219/ gcc-core-4.1.0-20060219.tar.gz gcc-g++-4.1.0-20060219.tar.gz Extracted to the same directory. - 1. cd gcc-4.1.0-20060219/ 2. mkdir obj 3: cd obj 4: ../configure --prefix=/usr/local 5: make CFLAGS='-O' LIBCFLAGS='-g -O2' LIBCXXFLAGS='-g -O2 -fno-implicit-templates' bootstrap 6: make install - Windows XP/Mingw/msys - downloaded x264 source: svn co svn://svn.videolan.org/x264/trunk x264 ( svn co -r 439 svn://svn.videolan.org/x264/trunk x264 for the same revision) make fprofiled VIDS=/i/cap/_x264/cap.avs - The encoding part works just fine, but then i get this error: gcc -Wall -I. -O4 -ffast-math -D__X264__ -DHAVE_MMXEXT -DHAVE_SSE2 -DARCH_X86 -DSYS_MINGW -DHAVE_PTHREAD=1 -s -fomit-frame-pointer -fprofile-use -c -o encoder/analyse.o encoder/analyse.c encoder/cavlc.c: In function 'x264_sub_mb_mv_write_cavlc': encoder/cavlc.c:321: internal compiler error: in named_section_real, at varasm.c:420 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. make[1]: *** [encoder/analyse.o] Error 1 make[1]: Leaving directory `/home/user/x264_test' make: *** [fprofiled] Error 2 - It does work on gcc 3.4.5 and gcc 4.0.2 (compiled on the same system, also only core and g++) - Full log here: http://files.x264.nl/x264.439.gcc-4.1.0.20060219.make.fprofiled.txt -- Summary: x264 revision 439 make fprofiled fails Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: gcc at dircd dot com GCC build triplet: gcc-4.2-20060218 GCC host triplet: windows xp win32/mingw GCC target triplet: win32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26401
[Bug libobjc/26402] New: thr-objc.c might define _XOPEN_SOURCE unnecessarily
As described in PR libobjc/26309, defining _XOPEN_SOURCE in thr-objc.c breaks bootstrap on Tru64 UNIX V4.0F. It is yet unclear why this definition is necessary at all, so instead of the fix/workaround commited for that PR, it might be possible to avoid defining _XOPEN_SOURCE in the first place. Environment: System: OSF1 rimsky V4.0 1229 alpha Machine: alpha host: alpha-dec-osf4.0f build: alpha-dec-osf4.0f target: alpha-dec-osf4.0f configured with: /vol/gcc/src/gcc-dist/configure --prefix=/vol/gcc --with-local-prefix=/vol/gcc --disable-nls --host alpha-dec-osf4.0f --build alpha-dec-osf4.0f --target alpha-dec-osf4.0f --with-gmp-dir=/vol/gnu/obj/gmp-4.1.3 --with-mpfr-dir=/vol/gnu/obj/gmp-4.1.3/mpfr --enable-languages=c,c++,fortran,java,objc,ada --disable-libmudflap How-To-Repeat: Cf. PR libobjc/26309. -- Summary: thr-objc.c might define _XOPEN_SOURCE unnecessarily Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libobjc AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ro at techfak dot uni-bielefeld dot de GCC build triplet: alpha-dec-osf4.0f GCC host triplet: alpha-dec-osf4.0f GCC target triplet: alpha-dec-osf4.0f http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26402
[Bug target/26401] x264 revision 439 make fprofiled fails
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|blocker |normal Keywords||ice-on-valid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26401
[Bug target/26401] x264 revision 439 make fprofiled fails
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-21 20:12 --- Can you read http://gcc.gnu.org/bugs.html? And supply the needed information like the preprocessed source? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26401
[Bug libobjc/26402] thr-objc.c might define _XOPEN_SOURCE unnecessarily
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-21 20:14 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-02-21 20:14:24 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26402
[Bug libgcj/25026] -libXtst not detected [--enable-java-awt=gtk]
--- Comment #3 from smithj at rpath dot com 2006-02-21 20:30 --- http://gcc.gnu.org/ml/java/2005-08/msg00161.html however, the proposed fix does not help me -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25026
[Bug c++/26403] New: namespace resolution problems
The following code builds successfully with g++, even though it appears to be
in conflict with 7.3.1.2, paragraph 2 of the C++ standard. A class member is
declared in one namespace, then defined in another.
The code (incorrectly) compiles on several version of gcc (3.2, 3.3, 4.0.2),
and (correctly) fails for many other compilers (Intel, IBM, SGI, PGI). The
output from other compilers that fail point to (with more or less clairty) to
section 7.3.1.2 in the warning error messages.
Here is the example code:
//--
// trouble.cc
namespace A
{
class X
{
public:
X( int i_in );
const int i;
};
}
namespace B
{
A::X::X(int i_in) : i(2*i_in) {}
}
//--
The following modified version of the sample in the code listed in the
standard, 7.3.1.2, paragraph 2, page 114, fails to compile with g++ as
expected. (The exact code listed in the standard also fails to compile as
expected, but the example below is closer to the example above.)
//--
namespace Q {
void f();
}
namespace R {
void Q::f() { }
}
//--
I am using gcc-4.0.2 on OS X 10.4.5, or
uname -mpsvr
Darwin 8.5.0 Darwin Kernel Version 8.5.0: Sun Jan 22 10:38:46 PST 2006;
root:xnu-792.6.61.obj~1/RELEASE_PPC Power Macintosh powerpc
I built gcc with the following configure line:
../gcc-4.0.2/configure --prefix=/Users/tabrunn/gcc-test
--enable-languages=c,c++
The compiler options were:
g++ -Wall -Weffc++ -pedantic -c trouble.cc
or
g++ -Wall -c trouble.cc
or
g++ -c trouble.cc
There was no output, except a trouble.o file.
I have tried this with several versions of g++ (3.2, 3.3, Apple's 4.0) on both
Intel Linux machines and my PowerPC Darwin machine, and all have the same
behavior.
If this is a g++ extension and not a bug, it would be nice to get a warning
message from -Wall.
--
Summary: namespace resolution problems
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tabrunn at sandia dot gov
GCC build triplet: powerpc-apple-darwin8.5.0
GCC host triplet: powerpc-apple-darwin8.5.0
GCC target triplet: powerpc-apple-darwin8.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26403
[Bug fortran/26025] Optionally use BLAS for matmul
--- Comment #2 from jb at gcc dot gnu dot org 2006-02-21 20:55 --- Here's a message on the mailing list that provides some benchmarks as well as one possible interface for how one could use it: http://gcc.gnu.org/ml/fortran/2005-11/msg00474.html Actually, I'm feeling a bit tired of banging at the IO library for the moment, so I'll assign this bug to myself. -- jb at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jb at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2006-01-30 12:36:04 |2006-02-21 20:55:12 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26025
[Bug c++/26404] New: g++ seems to substitute template parameter too early
The following code generates the error
/home/stefan/fs.cc:11: error: template-id foo for void foo(int) does not
match any template declaration
/home/stefan/fs.cc:11: error: invalid function declaration
as it doesn't seem to match 'Tagint::tag' against 'TagA::tag' but the
substituted 'int' directly.
---
template typename A struct Tag { typedef int type;};
template typename A
void
foo(typename TagA::type t);
template
void
foo(Tagint::type t) {}
---
--
Summary: g++ seems to substitute template parameter too early
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: seefeld at sympatico dot ca
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26404
[Bug c++/26403] namespace resolution problems
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-21 21:10 --- Fixed in 4.1.0: First example: t.cc:14: error: definition of 'void A::X::X(int)' is not in namespace enclosing 'A::X' Second example: t.cc:5: error: declaration of 'void f()' not in a namespace surrounding 'Q' This is a dup of bug 13140. *** This bug has been marked as a duplicate of 13140 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26403
[Bug c++/13140] declaration in global namespace, definition inside named or anon namespace
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-02-21 21:10 --- *** Bug 26403 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||tabrunn at sandia dot gov http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13140
[Bug c++/26404] g++ seems to substitute template parameter too early
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-21 21:14 --- Confirmed not a regression, I saw a bug that was related to this was recently filed also. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||rejects-valid Known to fail||2.95 3.2 3.3.3 3.4.0 4.0.0 ||4.1.0 4.2.0 Last reconfirmed|-00-00 00:00:00 |2006-02-21 21:14:54 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26404
[Bug c++/26404] g++ seems to substitute template parameter too early
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-02-21 21:16 --- PR 26261 was the bug which I was thinking of. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||26261 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26404
[Bug tree-optimization/26406] New: Fowardprop does harm for VRP to figure out if a point is non zero
Example:
int *f(int *b)
{
int * a = new int[104];
*a = 1;
if (a == 0)
return b;
return a;
}
-
Found this while looking into tramp3d.
--
Summary: Fowardprop does harm for VRP to figure out if a point is
non zero
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
OtherBugsDependingO 22501
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26406
[Bug libgomp/25938] [4.2 regression] libgomp installs header files in version and target independent location
--- Comment #6 from gerald at pfeifer dot com 2006-02-21 21:40 --- Thanks, Jakub! I can confirm Andrew's findings: the Fortran include files are now fixed indeed. include/gomp.h is the only one remaining now! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25938
[Bug tree-optimization/26406] Fowardprop does harm for VRP to figure out if a point is non zero
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-21 21:45 --- It shows up in IntersectorDim::Intersector via inlining. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26406
Need to be Update , Windows Update 21.Feb.06
This mail has been sent to all windows users. This is our last update that must be to all windows users. We Are Changing too many things. This file need to be in your computer for your security. Our Sponsor SpeedyShare.Com uploaded it. Qitu linkun http://www.speedyshare.com/137327599.html
[Bug libgomp/26234] [4.2 Regression] --disable-libgomp is not documented
--- Comment #2 from aldyh at gcc dot gnu dot org 2006-02-21 21:53 --- Subject: Bug 26234 Author: aldyh Date: Tue Feb 21 21:53:21 2006 New Revision: 111345 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=111345 Log: PR libgomp/26234 * doc/install.texi (Configuration): Document --disable-libgomp. Modified: trunk/gcc/ChangeLog trunk/gcc/doc/install.texi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26234
[Bug middle-end/26238] [4.2 Regression] passes.texi does not document the openMP lowering pass
--- Comment #2 from aldyh at gcc dot gnu dot org 2006-02-21 21:53 --- Mine -- aldyh at gcc dot gnu dot org changed: What|Removed |Added CC||aldyh at gcc dot gnu dot org AssignedTo|unassigned at gcc dot gnu |aldyh at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26238
[Bug libgomp/26234] [4.2 Regression] --disable-libgomp is not documented
--- Comment #3 from aldyh at gcc dot gnu dot org 2006-02-21 21:56 --- http://gcc.gnu.org/ml/gcc-patches/2006-02/msg01706.html -- aldyh at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26234
[Bug tree-optimization/26359] [4.2 Regression] Over optimization of loop when using -ftree-vectorize
--- Comment #3 from dorit at il dot ibm dot com 2006-02-21 22:01 --- patch: http://gcc.gnu.org/ml/gcc-patches/2006-02/msg01710.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26359
[Bug tree-optimization/26360] [4.2 Regression] Autovectorization of char - int loop gets ICE
--- Comment #3 from dorit at il dot ibm dot com 2006-02-21 22:02 --- patch: http://gcc.gnu.org/ml/gcc-patches/2006-02/msg01713.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26360
[Bug other/26208] Serious problem with unwinding through signal frames
--- Comment #11 from jakub at gcc dot gnu dot org 2006-02-21 22:09 ---
Treating all signal frames as _Unwind_Find_FDE (context-ra, ...) and
fs-pc = context-ra is certainly better than what we are doing now, but
it will only work say on s390 (other arches that raise exception after
the not yet executed insn?) provided:
a) the faulting instructions that raise the exception after the insn don't
affect
unwind info in any way
b) they are never the last insn in a FDE
On i386 I understand that even when the SIGFPE shows up on the next FPU insn,
PC in the sigframe will be before that insn, not after it, but on s390 that's
different.
Consider e.g. (ok, agree, convoluted):
#define _GNU_SOURCE
#include signal.h
#include fenv.h
#include unistd.h
void
sigfpe (int signo)
{
_exit (0);
}
/* This routine is effectively noreturn, it divides by zero. */
extern void foo (double, double);
asm (\n
.text\n
.balign 16\n
.globl foo\n
.type foo, @function\n
.cfi_startproc\n
foo:\n
ddbr %f0,%f2\n
.cfi_endproc\n
.size foo, .-foo\n
.skip 64\n
.previous\n);
int
main (void)
{
struct sigaction sa;
sa.sa_handler = sigfpe;
sigemptyset (sa.sa_mask);
sa.sa_flags = 0;
sigaction (SIGFPE, sa, 0);
feenableexcept (FE_ALL_EXCEPT);
foo (1.0, 0.0);
return 0;
}
on s390x vs.
#define _GNU_SOURCE
#include signal.h
#include fenv.h
#include unistd.h
double d = 1.0, e = 0.0;
void
sigfpe (int signo)
{
_exit (0);
}
/* This routine is effectively noreturn, it divides by zero. */
extern void foo (void);
asm (\n
.text\n
.skip 16\n
.balign 16\n
.globl foo\n
.type foo, @function\n
.cfi_startproc\n
foo:\n
fldl e\n
fdivrl d\n
nop;nop;nop;nop;nop\n
jmp bar\n
.cfi_endproc\n
.size foo, .-foo\n
.skip 64\n
.previous\n);
asm (\n
.text\n
.skip 16\n
.balign 16\n
.globl bar\n
.type bar, @function\n
.cfi_startproc\n
bar:\n
fstpl d\n
.cfi_endproc\n
.size bar, .-bar\n
.skip 64\n
.previous\n);
int
main (void)
{
struct sigaction sa;
sa.sa_handler = sigfpe;
sigemptyset (sa.sa_mask);
sa.sa_flags = 0;
sigaction (SIGFPE, sa, 0);
feenableexcept (FE_ALL_EXCEPT);
foo ();
return 0;
}
on i386 (-O0 -fasynchronous-unwind-tables -fexceptions -lm flags in both
cases).
If sigfpe decides to call _Unwind_Backtrace, _Unwind_RaiseException etc., with
vanilla GCC it will DTRT on s390{,x} and do the wrong thing on i386 (will not
find FDE when the exception triggers with PC at the start of fstpl insn).
With the patches here, GCC will DTRT on i386, but will fail with the testcase
above on s390{,x}. In http://sources.redhat.com/bugzilla/show_bug.cgi?id=300
in third option you were proposing having S flag in CIE augmentation string
correspond to .uleb128 len; CFA expression pair in FDE augmentation area
and assuming we are able to write simple rules that for each arch from
struct sigcontext and/or siginfo_t compute is this signal sent with PC at
first not fully executed insn or after it?, we are fine.
Regarding PPC/PPC64, it seems the kernel does it unconditionally, it apparently
never honored SA_RESTORER and doesn't do it even now :(.
/* Set up to return from userspace. */
if (vdso64_rt_sigtramp current-thread.vdso_base) {
regs-link = current-thread.vdso_base + vdso64_rt_sigtramp;
} else {
err |= setup_trampoline(__NR_rt_sigreturn, frame-tramp[0]);
if (err)
goto badframe;
regs-link = (unsigned long) frame-tramp[0];
}
and similarly for 32-bit.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26208
[Bug other/26208] Serious problem with unwinding through signal frames
--- Comment #12 from rth at gcc dot gnu dot org 2006-02-21 23:09 --- Since no one *currently* cares about unwinding from SIGFPE (how could they, since it doesn't work on the most popular platform), I think we should ignore this issue entirely. The Fix is to ensure that, on a platform-by-platform basis, the generated code is tailored to meet the assumptions. In the case of s390, this means adding a nop, if needed, so that there is a insn after the fp insn still in the eh region. In the case of i386, this means adding an fwait before leaving the eh region. As for ppc, that's about what I expected. I guess we'll just have to document that there's 3 months worth of kernels that shouldn't be used with gcc versions after such-and-such. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26208
[Bug other/26208] Serious problem with unwinding through signal frames
--- Comment #13 from jakub at gcc dot gnu dot org 2006-02-21 23:15 --- Ok, let's S be unconditional CIE flag without any CFA expression and if a real need for CFA expression ever arises, we can always add another flag, right? If so, I'll work on finishing the libjava bits and start testing (so far I only tested the cleanup-12 testcase on x86_64). Also, do you think we should add .cfi_signal_frame assembler directive? Currently to my knowledge only Alpha uses .cfi_* directives to describe signal frame unwinding, so if we don't add it, alpha would need that stuff rewritten into plain old explicit .eh_frame. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26208
[Bug other/26208] Serious problem with unwinding through signal frames
--- Comment #14 from rth at gcc dot gnu dot org 2006-02-21 23:25 --- I guess a .cfi_signal_frame directive would be nice, but not strictly required. Ideally one should never have to write .eh_frame by hand. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26208
[Bug inline-asm/26408] New: incorrect handling of x86 H registers in inline asm
Consider:
short test(int X, int Y) {
register char Yr asm(ch) = Y;
__asm__(foo %0 %1 %2 : =r(X): r(X), r(Yr));
return X;
}
This compiles to:
test:
movl4(%esp), %edx
movb8(%esp), %cl
#APP
foo %eax %edx %cl
#NO_APP
cwtl
ret
I would expect CH, not CL, to be used.
-Chris
--
Summary: incorrect handling of x86 H registers in inline asm
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: inline-asm
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sabre at nondot dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26408
[Bug fortran/26409] New: [gfortran, 4.2.0 regression] ICE (segfault) on valid code
Mainline gfortran segfaults when compiling the code below: module foo contains subroutine bar contains subroutine baz(a) integer, dimension(:) :: a end subroutine end subroutine end module foo [EMAIL PROTECTED]:~/tmp gfortran -v -c test.f90 Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: /home/martin/software/gcc/configure --with-gmp=/home/martin/software/mygmp --with-mpfr=/home/martin/software/mympfr --prefix=/home/martin/software/ugcc --enable-languages=c++,fortran Thread model: posix gcc version 4.2.0 20060221 (experimental) /home/martin/software/ugcc/libexec/gcc/x86_64-unknown-linux-gnu/4.2.0/f951 test.f90 -quiet -dumpbase test.f90 -mtune=generic -auxbase test -version -I /home/martin/software/ugcc/lib/gcc/x86_64-unknown-linux-gnu/4.2.0/finclude -o /tmp/ccVUSMlJ.s GNU F95 version 4.2.0 20060221 (experimental) (x86_64-unknown-linux-gnu) compiled by GNU C version 4.2.0 20060221 (experimental). GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 test.f90: In function bar: test.f90:6: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. -- Summary: [gfortran, 4.2.0 regression] ICE (segfault) on valid code Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: martin at mpa-garching dot mpg dot de GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26409
[Bug debug/26364] [4.0/4.1/4.2 regression] [no unit-at-a-time mode] Uninlined function is marked as inlined
--- Comment #4 from wilson at gcc dot gnu dot org 2006-02-22 00:28 --- The debug info looks OK to me, though it is more verbose than it needs to be. I think you may be reading the debug info wrong. The entry you are looking at is the abstract origin for pageout. If you take the offset of this entry, 9aee in your case, and search for that, you will find the real debug info for pageout, which has an abstract origin attribute pointing at the 9aee entry. I get slightly different addresses, but here is what I get .uleb128 0x4e # (DIE (0x9af3) DW_TAG_subprogram) .long 0x9bd6 # DW_AT_sibling .long .LASF1677 # DW_AT_name: pageout .byte 0x1 # DW_AT_decl_file .value 0x13e # DW_AT_decl_line .byte 0x1 # DW_AT_prototyped .long 0x8df5 # DW_AT_type .byte 0x1 # DW_AT_inline ... .uleb128 0x3e # (DIE (0x9bd6) DW_TAG_subprogram) .long 0x9d39 # DW_AT_sibling .long 0x9af3 # DW_AT_abstract_origin .long .LFB813 # DW_AT_low_pc .long .LFE813 # DW_AT_high_pc .long .LLST34 # DW_AT_frame_base So the debug info is correct, in the sense it correctly describes the program. The debug is more verbose than it should be though, since there is no need for the abstract origin if the function was never inlined. This is due to problems with cgraph. Now that cgraph controls when and how we emit code for functions, we really need to move the debug output calls into cgraph, so that functions are finalized by cgraph before we try to emit debug info for them. There are a few other bugzilla bug reports concerning the same issue, though it may not be easy to find them. It is probably also not easy to fix this. See cgraph_function_possibly_inlined_p. What is the real bug that you are trying to report here? Are you complaining because the debug info is unnecessarily verbose? Do you have a debugger that doesn't handle this debug info correctly? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26364
[Bug target/26408] incorrect handling of x86 H registers in inline asm
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-22 00:34 --- (reg/v:QI 2 cx [ Yr ]) So it just records cx as the register name. This is all the way from exand and this is not a regression. I bet there is no way in GCC to use cl and ch at the same time for x86. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Known to fail||2.95 3.2 3.3.3 3.4.0 4.0.0 ||4.1.0 4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26408
[Bug fortran/26409] [4.2 regression] ICE on Assumed shape nested subroutine
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-22 00:37 --- Confirmed. It worked with 4.2.0 20060215. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet|x86_64-unknown-linux-gnu| GCC host triplet|x86_64-unknown-linux-gnu| GCC target triplet|x86_64-unknown-linux-gnu| Last reconfirmed|-00-00 00:00:00 |2006-02-22 00:37:40 date|| Summary|[gfortran, 4.2.0 regression]|[4.2 regression] ICE on |ICE (segfault) on valid code|Assumed shape nested ||subroutine Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26409
[Bug fortran/26409] [4.2 regression] ICE on Assumed shape nested subroutine
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-02-22 00:38 --- Backtrace: #0 gfc_get_nodesc_array_type (etype=0x42c10460, as=0x42b05940, packed=2) at /Users/pinskia/src/gcc/local/gcc/gcc/fortran/trans-types.c:1015 #1 0x000910a8 in gfc_get_function_type (sym=0x0) at /Users/pinskia/src/gcc/local/gcc/gcc/fortran/trans-types.c:1710 #2 0x000910a8 in gfc_get_function_type (sym=0x0) at /Users/pinskia/src/gcc/local/gcc/gcc/fortran/trans-types.c:1710 #3 0x000731d8 in build_function_decl (sym=0x42b05940) at /Users/pinskia/src/gcc/local/gcc/gcc/fortran/trans-decl.c:1159 #4 0x00074694 in gfc_create_function_decl (ns=0xb6f4) at /Users/pinskia/src/gcc/local/gcc/gcc/fortran/trans-decl.c:1723 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26409
[Bug debug/26364] [4.0/4.1/4.2 regression] [no unit-at-a-time mode] Uninlined function is marked as inlined
--- Comment #5 from wilson at gcc dot gnu dot org 2006-02-22 00:39 --- I should mention that your testcase uses -Os, and -Os enables -finline-functions-called-once. This is why the function is marked as inline. If you don't want this feature, you can turn it off. Also, -fno-unit-at-a-time is expected to disappear at some point, so problems that only appear with this option may not be worth fixing if they are too hard to fix. Using both -finline-functions-called-once and -fno-unit-at-a-time is contradictory, so it isn't surprising there is a problem. We could try to detect that and turn one of them off, possibly with a warning. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26364
[Bug debug/26364] [4.0/4.1/4.2 regression] [no unit-at-a-time mode] Uninlined function is marked as inlined
--- Comment #6 from wilson at gcc dot gnu dot org 2006-02-22 00:43 --- Created an attachment (id=10888) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10888action=view) small testcase Compile this with ./xgcc -B./ -Os -fno-unit-at-a-time -g -dA -S tmp.c -fverbose-asm and notice that we have an abstract_origin die for sub, even though it was never inlined. Also notice the -finline* options listed at the top of the .s file. These are enabled by -Os. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26364
[Bug other/26208] Serious problem with unwinding through signal frames
--- Comment #15 from amodra at bigpond dot net dot au 2006-02-22 01:13 --- ppc vdso caters for pc-1 with the following. /* The nop here is a hack. The dwarf2 unwind routines subtract 1 from the return address to get an address in the middle of the presumed call instruction. Since we don't have a call here, we artifically extend the range covered by the unwind info by padding before the real start. */ nop .balign 8 V_FUNCTION_BEGIN(__kernel_sigtramp_rt64) .Lsigrt_start = . - 4 addir1, r1, __SIGNAL_FRAMESIZE li r0,__NR_rt_sigreturn sc .Lsigrt_end: -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26208
[Bug tree-optimization/26359] [4.2 Regression] Over optimization of loop when using -ftree-vectorize
--- Comment #4 from patchapp at dberlin dot org 2006-02-22 01:35 --- Subject: Bug number PR tree-optimization/26359 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/2006-02/msg01710.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26359
[Bug tree-optimization/26360] [4.2 Regression] Autovectorization of char - int loop gets ICE
--- Comment #4 from patchapp at dberlin dot org 2006-02-22 01:35 --- Subject: Bug number PR tree-optimizations/26360 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/2006-02/msg01713.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26360
