[Bug libfortran/27046] gfortran print flush in dll
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2006-04-25 06:04
---
(In reply to comment #2)
This was fixed for the non windows case for sure.
Yes:
$ cat ftesti.f90
subroutine print_from_gfortran(txt)
implicit none
character :: txt
print *,txt
end subroutine print_from_gfortran
$ ./bin/gfortran -shared -o ftesti.so ftesti.f90
$ cat ctesti.c #include stdio.h
#include dlfcn.h
void print_from_gcc(char* txt) {
printf(%s\n,txt);
}
int main(int argc, char** argv) {
void * hdl = dlopen(./ftesti.so, RTLD_LAZY);
void (*print_from_gfortran)(char *) = dlsym(hdl, print_from_gfortran_);
print_from_gcc (c);
(*print_from_gfortran)(f);
print_from_gcc (c);
(*print_from_gfortran)(f);
dlclose (hdl);
return 0;
}
$ gcc -o ctesti.exe ctesti.c -ldl
$ ./ctesti.exe
c
f
c
f
And this even works when libgfortran is only available as a static library (as
is the case on mingw32). I'll try to look deeper into this, but it looks very
strange...
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
CC||fxcoudert at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27046
[Bug target/27282] [4.2 regression] ICE in final_scan_insn, at final.c:2448 - could not split insn
--- Comment #5 from bonzini at gnu dot org 2006-04-25 06:37 --- Sure. The code meant to do so using trunc_int_for_mode, but it does not work because constop is unsigned. The trunc_int_for_mode was introduced in http://gcc.gnu.org/ml/gcc-patches/2002-01/msg01397.html to cure a similar ICE; and the bug is latent on all branches since it dates back (through various changes, notably r49112 by amodra) to the dawn of the original old-gcc repository. Bootstrapping this patch on i686-pc-linux-gnu, ok if it passes? What about 4.1? Index: gcc-fwprop/gcc/combine.c === --- gcc-fwprop/gcc/combine.c(revision 113024) +++ gcc-fwprop/gcc/combine.c(working copy) @@ -8190,6 +8190,5 @@ simplify_and_const_int_1 (enum machine_m return NULL_RTX; /* Otherwise, return an AND. */ - constop = trunc_int_for_mode (constop, mode); - return simplify_gen_binary (AND, mode, varop, GEN_INT (constop)); + return simplify_gen_binary (AND, mode, varop, gen_int_mode (constop, mode)); } Paolo -- bonzini at gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |bonzini at gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2006-04-25 00:53:57 |2006-04-25 06:37:18 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27282
[Bug tree-optimization/27285] [4.1 regression] ivopts postgresql miscompilation
--- Comment #5 from jakub at gcc dot gnu dot org 2006-04-25 07:37 --- Yes, it fixes it. Will regression test it on a bunch of arches and post to gcc-patches. Thanks. -- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2006-04-24 21:41:37 |2006-04-25 07:37:02 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27285
[Bug tree-optimization/27299] New: gcc 4.1 produces bad code -ftree-vectorize option
Compiling an attached test program on AMD64 using gcc-4.1.0 with '-O -ftree-vectorize' produces a code which segfaults, eg. [EMAIL PROTECTED] ~ $ gcc -O -ftree-vectorize test.c -o test [EMAIL PROTECTED] ~ $ ./test Segmentation fault Compiling it using any -O flags doesn't produce code which segfaults, eg: [EMAIL PROTECTED] ~ $ gcc -O3 test.c -o test [EMAIL PROTECTED] ~ $ ./test [EMAIL PROTECTED] ~ $ I'm using glibc-2.4-r1 (Gentoo) and kernel 2.6.16-beyond2. -- Summary: gcc 4.1 produces bad code -ftree-vectorize option Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: gringo at slonko dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27299
[Bug tree-optimization/27299] gcc 4.1 produces bad code -ftree-vectorize option
--- Comment #1 from gringo at slonko dot net 2006-04-25 08:01 --- Created an attachment (id=11332) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11332action=view) Test source which produces bad code with '-O -ftree-vectorize' -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27299
[Bug ada/27300] New: gnattools/configure.ac selects incorrect body for indepsw on GNU/Linux
gcc/ada/Makefile.in selects indepsw-gnu.adb as the body for indepsw.ads on GNU/Linux. In contrast, gnattools/configure (generated from gnattools/configure.ac) selects indepsw-linux.adb, which no longer exists. The divergence occurred on 2005-07-04 in revision 101581; see gcc/ada/Makefile.in. Patch forthcoming. -- Ludovic Brenta. -- Summary: gnattools/configure.ac selects incorrect body for indepsw on GNU/Linux Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: trivial Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ludovic at ludovic-brenta dot org GCC host triplet: *-*-linux* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27300
[Bug ada/27186] GNAT BUG DETECTED with Booch Components Set_Test_Support
--- Comment #6 from ludovic at ludovic-brenta dot org 2006-04-25 08:30 --- This appears to be the same bug as PR26678. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27186
[Bug inline-asm/27301] New: ICE on convoluted inline asm with m (statement expression)
inline void
foo (void *ptr, long n)
{
__asm__ __volatile__ ( : : m (__extension__
({ struct { char x[n]; } *p = ptr;
*p; })));
}
void
bar (void)
{
char buf[16];
foo (buf, sizeof foo);
}
ICEs in tree_cst_low, apparently GCC attempts to create a VLA through non-VLA
mechanism (expand_one_stack_var).
--
Summary: ICE on convoluted inline asm with m (statement
expression)
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: inline-asm
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
GCC target triplet: i686-linux, x86_64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27301
[Bug middle-end/26823] ICE with OpenMP in add_stmt_to_eh_region_fn, at tree-eh.c:100
--- Comment #9 from martin at mpa-garching dot mpg dot de 2006-04-25 09:09 --- (In reply to comment #7) @Martin: I tried to reduce your testacse a little and got a segfault in can_throw_internal_1. So this is probably the same problem as PR26913. However the original segfault in your code is in duplicate_eh_regions. So maybe there's another bug. But I think that further reduction only makes sense when PR26913 is fixed. OK, I'll watch PR26913 and try again once it it is closed. Thanks! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26823
[Bug tree-optimization/26865] [4.1 Regression] Segmentation fault with -std=c99 -O1 and alloca()
--- Comment #8 from jakub at gcc dot gnu dot org 2006-04-25 09:42 --- Subject: Bug 26865 Author: jakub Date: Tue Apr 25 09:42:41 2006 New Revision: 113242 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113242 Log: PR tree-optimization/26865 * gcc.dg/pr26865.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr26865.c Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26865
[Bug tree-optimization/26865] [4.1 Regression] Segmentation fault with -std=c99 -O1 and alloca()
--- Comment #9 from jakub at gcc dot gnu dot org 2006-04-25 09:45 --- Subject: Bug 26865 Author: jakub Date: Tue Apr 25 09:45:01 2006 New Revision: 113243 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113243 Log: PR tree-optimization/26865 * tree-ssa-structalias.c (find_func_aliases): Check that anyoffsetrhs type is pointer or array type. * gcc.dg/pr26865.c: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/pr26865.c Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/testsuite/ChangeLog branches/gcc-4_1-branch/gcc/tree-ssa-structalias.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26865
[Bug middle-end/27302] New: Fold does not fold i j == j i to 1
For the testcase
int foo(int i, int j)
{
return (i j) == (j i);
}
fold does not fold the expression to 1, but instead to
i j ^ j i
which should be done as a last resort only. fold_comparison does not
handle the original tree either, nor does operand_equal_p see that both
operands of the EQ_EXPR are equal.
--
Summary: Fold does not fold i j == j i to 1
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27302
[Bug c/27303] New: crash at unalign access
Sortly, We have a global variable which is initialized to 1 and named AMLogging. When we compile our source it does not cause any problem but when we change AMLogging = 0; and compile, if at run time we try to access to this variable it is causing system to crash with a floating point exception to 4-byte aligned address. We think that because the location of the variable moves to bss instead of data section compiler makes alignment errors. Following is about our compiler version and options used. bt0puk:/home/mekici/crash/geltbas/acpu mips-gcc -v -save-temps -DLANGUAGE_C -O2 -g -DACPU_SCM -DGELT -DGFI_GM_RUN_TIME -DGM_USE_BPD -DGM_PM_TYPE_PROMPT -nostdlib -I. -I./Includes -nostdinc -fsigned-char -fno-builtin -Wreturn-type -Wuninitialized -Winline -Wswitch -Wchar-subscripts -Wshadow -Wimplicit-function-declaration -DREL_220 -mlong-calls -mdivide-breaks -mfp32 -mhard-float -mdouble-float -march=rm9k -mips4 -EL -G 0 -c ./image-ver.c Reading specs from /project/xana/gcc-3.4.3/bin/../lib/gcc/mips/3.4.3/specs Configured with: ../gcc-3.4.3/configure --prefix=/home/beckers/crossdev --target=mips --disable-threads --with-newlib --disable-shared --enable-languages=c --with-stabs --nfp --with-gnu-as --with-gnu-ld Thread model: single gcc version 3.4.3 /project/xana/gcc-3.4.3/bin/../libexec/gcc/mips/3.4.3/cc1 -E -quiet -nostdinc -v -I. -I./Includes -iprefix /project/xana/gcc-3.4.3/bin/../lib/gcc/mips/3.4.3/ -DLANGUAGE_C -DACPU_SCM -DGELT -DGFI_GM_RUN_TIME -DGM_USE_BPD -DGM_PM_TYPE_PROMPT -DREL_220 ./image-ver.c -G 0 -mel -mlong-calls -mdivide-breaks -mfp32 -mhard-float -mdouble-float -march=rm9k -mips4 -Wreturn-type -Wuninitialized -Winline -Wswitch -Wchar-subscripts -Wshadow -Wimplicit-function-declaration -fsigned-char -fno-builtin -fworking-directory -O2 -o image-ver.i #include ... search starts here: #include ... search starts here: . ./Includes /usr/openwin/lib /ap/local/5.8/include End of search list. /project/xana/gcc-3.4.3/bin/../libexec/gcc/mips/3.4.3/cc1 -fpreprocessed image-ver.i -G 0 -mel -quiet -dumpbase image-ver.c -mlong-calls -mdivide-breaks -mfp32 -mhard-float -mdouble-float -march=rm9k -mips4 -auxbase image-ver -g -O2 -Wreturn-type -Wuninitialized -Winline -Wswitch -Wchar-subscripts -Wshadow -Wimplicit-function-declaration -version -fsigned-char -fno-builtin -o image-ver.s GNU C version 3.4.3 (mips) compiled by GNU C version 2.95.3 20010315 (release). GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 /project/xana/gcc-3.4.3/bin/../lib/gcc/mips/3.4.3/../../../../mips/bin/as -G 0 -EL -mips4 -O2 -g -no-mdebug -32 -march=rm9k -v -o image-ver.o image-ver.s GNU assembler version 050111 (mips) using BFD version 050111 20050111 -- Summary: crash at unalign access Product: gcc Version: 3.4.3 Status: UNCONFIRMED Severity: critical Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mehmet dot ekici at alcatel dot com dot tr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27303
[Bug c++/26846] hidden visibility of static member in class derived from hash_map changes to default visibility
-- laszlo dot szakony at philips dot com changed: What|Removed |Added Severity|normal |critical http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26846
[Bug fortran/27304] New: gfortran: Warn/abort when format in write does not fit passed arguments
Test case:
-
program test
implicit none
integer :: n
n = 1
write(*,'(''n'')') n
end program test
-
gfortran -Wall -o test test1.f90 [4.1.0 (SUSE Linux); 4.2.0 20060423]
Compiles without warning/error and ./test outputs nn.
Expected:
During compile: Bail out with an error message or at least show a warning.
The NAGWare Fortran 95 compiler Release 5.0(414)) for comparison:
f95 -o test test1.f90
Error: test1.f90, line 5: No data-edit descriptor for effective item
[f95 error termination]
--
Summary: gfortran: Warn/abort when format in write does not fit
passed arguments
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tobias dot burnus at physik dot fu-berlin dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27304
[Bug target/27303] crash at unalign access
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-04-25 11:36 --- First, gcc 3.4.3 is no longer in active maintainance, the oldest still maintained version is 4.0.3. Second, please read the bugreporting guidelines and provide a testcase for the problem. Third, this may be as well a linker or assembler bug (or missing feature). -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Component|c |target GCC target triplet||mips Keywords||ABI, wrong-code Summary|crash at unalign access |crash at unalign access http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27303
[Bug c/27305] New: Compiler generates incorrect code when calling functions
Consider the following code:
typedef unsigned int UINT32;
typedef unsigned char BOOL;
#define __SWI_BIOS_ContainerUsage 1234
#define __swicall1(type,name,type1,arg1)\
static inline type name(type1 arg1) { \
register long __r0 __asm__ (r0) = (long)arg1; \
register long __res __asm__ (r0); \
__asm__ __volatile__ (swi\t%2\n\t \
: =r (__res)\
: 0 (__r0), i (__SWI_##name) \
: r1, r2, r3, ip, lr, cc, \
memory); \
return((type)__res);\
}
__swicall1(UINT32,BIOS_ContainerUsage,BOOL,verbose);
int sprintf(char *p, const char *frmt, ...);
void testme(char *tmp)
{
sprintf(tmp, %d%% Containers\n, BIOS_ContainerUsage(1));
sprintf(tmp, %d%% Containers\n, 2 * BIOS_ContainerUsage(1));
}
--
Summary: Compiler generates incorrect code when calling functions
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: blocker
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Eric dot Doenges at betty-tv dot com
GCC host triplet: powerpc-apple-darwin8.5.0
GCC target triplet: arm-elf-unknown
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27305
[Bug c++/27292] [4.2 regression] ICE on casts on bitfields
--- Comment #6 from mueller at gcc dot gnu dot org 2006-04-25 11:46 --- the original testcase still ICEs. however now in gimplify.c:5492 -- mueller at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27292
[Bug c++/27306] New: while and (type *)variable++ causes never ending loop
Following code is not compiled correctly and causes never ending loop. GCC
4.0.2 from GNUARM.org distribution was used.
typedef unsigned short U16;
void * ptr = buffer;
void * end = (U16 *)buffer + num;
while (ptr != end)
{
*((U16 *)ptr)++ = c;
}
dissasebly with intermixed source code:
void * ptr = buffer;
void * end = (U16 *)buffer + num;
924: e2812a02add r2, r1, #8192 ; 0x2000
while (ptr != end)
928: e1520001cmp r2, r1
92c: e50b1038str r1, [fp, #-56]
930: 0a000250beq 948 _ZN7MvbcLSA8InitChipEhh+0x228
934: e3a0mov r0, #0 ; 0x0
938: e1a03001mov r3, r1
{
*((U16 *)ptr)++ = c;
93c: e0c300b2strhr0, [r3], #2
940: 1a00024dbne 93c _ZN7MvbcLSA8InitChipEhh+0x21c
944: e50b3038str r3, [fp, #-56]
}
arm-elf-gcc --ver
Using built-in specs.
Target: arm-elf
Configured with: ../gcc-4.0.2/configure --target=arm-elf
--prefix=/g/gnuarm-4.0.2 --enable-interwork --enable-multilib --with-newlib
--with-headers=../newlib-1.14.0/newlib/libc/include --enable-languages=c,c++
Thread model: single
gcc version 4.0.2
--
Summary: while and (type *)variable++ causes never ending loop
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kalas at unicontrols dot cz
GCC host triplet: cygwin
GCC target triplet: arm-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27306
[Bug tree-optimization/27299] [4.1 Regression] vectorizer generates aligned accesses to unaligned memory
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-04-25 11:49 --- Confirmed. We generate 0x08048475 main+193: movdqu (%edx),%xmm0 0x08048479 main+197: movdqa %xmm0,(%eax) but both %edx and %eax are unaligned: eax0x804a021134520865 ecx0x0 0 edx0x804a009134520841 4.0.3 works, because nothing is vectorized there. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||wrong-code Known to fail||4.1.0 Known to work||4.0.3 Last reconfirmed|-00-00 00:00:00 |2006-04-25 11:49:33 date|| Summary|gcc 4.1 produces bad code - |[4.1 Regression] vectorizer |ftree-vectorize option |generates aligned accesses ||to unaligned memory http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27299
[Bug target/27303] crash at unalign access
--- Comment #2 from mehmet dot ekici at alcatel dot com dot tr 2006-04-25 11:49 --- (In reply to comment #1) First, gcc 3.4.3 is no longer in active maintainance, the oldest still maintained version is 4.0.3. Second, please read the bugreporting guidelines and provide a testcase for the problem. Third, this may be as well a linker or assembler bug (or missing feature). Would you please tell me how I can localize the problem if it is ld or gcc ? -- mehmet dot ekici at alcatel dot com dot tr changed: What|Removed |Added CC||mehmet dot ekici at alcatel ||dot com dot tr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27303
[Bug tree-optimization/27299] [4.1 Regression] vectorizer generates aligned accesses to unaligned memory
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-04-25 11:55 --- mainline doesn't do vectorization here: /tmp/t.c:12: note: === vect_analyze_dependences === /tmp/t.c:12: note: not vectorized: can't determine dependence between *src.1_24 and *dest.0_23 /tmp/t.c:12: note: bad data dependence. while 4.1 peels for alignment (wrongly). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27299
[Bug target/27303] crash at unalign access
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-04-25 12:07 --- Look at the assembly output of gcc (-S) and see if there is an appropriate alignment directive before the entry for AMLogging in the bss section. If there is, the assembler/linker are at fault. Otherwise please attach a testcase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27303
[Bug inline-asm/27305] Compiler generates incorrect code when calling functions
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-04-25 12:11 --- Considering it. What happens? -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Component|c |inline-asm http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27305
[Bug c++/27306] while and (type *)variable++ causes never ending loop
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-04-25 12:15 --- This is not a valid testcase, or even expression. I guess it's invalid anyway because of operator precedence. -- 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=27306
[Bug c++/27306] while and (type *)variable++ causes never ending loop
--- Comment #2 from falk at debian dot org 2006-04-25 12:19 --- It's a valid C++ fragment. However, this code accesses ptr, which is of type void*, via an lvalue of type U16*. This is undefined behavior, so there is no gcc bug here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27306
[Bug c++/27306] while and (type *)variable++ causes never ending loop
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-04-25 12:20 --- Oh, this is just an aliasing issue. Reopening... -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27306
[Bug c++/27306] while and (type *)variable++ causes never ending loop
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-04-25 12:21 --- .. to close as dup of PR21920. *** This bug has been marked as a duplicate of 21920 *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27306
[Bug c/21920] alias violating
--- Comment #93 from rguenth at gcc dot gnu dot org 2006-04-25 12:21 --- *** Bug 27306 has been marked as a duplicate of this bug. *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||kalas at unicontrols dot cz http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21920
[Bug c/27308] New: Compiler generates incorrect code when calling a function with the result of an inline function as parameter
Consider the following code:
typedef unsigned int UINT32;
typedef unsigned char BOOL;
#define __SWI_BIOS_ContainerUsage 1234
#define __swicall1(type,name,type1,arg1) \
static inline type name(type1 arg1) { \
register long __r0 __asm__ (r0) = (long)arg1; \
register long __res __asm__ (r0); \
__asm__ __volatile__ (swi\t%2\n\t \
: =r (__res)
\
: 0 (__r0), i (__SWI_##name)\
: r1, r2, r3, ip, lr, cc,
\
memory);
\
return((type)__res);
\
}
__swicall1(UINT32,BIOS_ContainerUsage,BOOL,verbose);
int sprintf(char *p, const char *frmt, ...);
void testme(char *tmp)
{
sprintf(tmp, %d%% Containers\n, BIOS_ContainerUsage(1));
sprintf(tmp, %d%% Containers\n, 2 * BIOS_ContainerUsage(1));
}
For the first call to sprintf, gcc generates the following assembler code:
mov r0, #1
swi #1234
ldr r5, .L3
mov r0, r4
mov r1, r5
mov r2, r4
bl sprintf
This is clearly wrong, since r2 should hold the result of the swi (which is
returned in r0). For the
second call to sprintf, gcc generates correct code:
mov r0, #1
swi #1234
mov r2, r0, asl #1
mov r1, r5
mov r0, r4
ldmfd sp!, {r4, r5, lr}
b sprintf
--
Summary: Compiler generates incorrect code when calling a
function with the result of an inline function as
parameter
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: blocker
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Eric dot Doenges at betty-tv dot com
GCC host triplet: powerpc-apple-darwin8.5.0
GCC target triplet: arm-elf-unknown
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27308
[Bug c/27308] Compiler generates incorrect code when calling a function with the result of an inline function as parameter
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-04-25 12:38 --- *** Bug 27305 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27308
[Bug inline-asm/27305] Compiler generates incorrect code when calling functions
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-04-25 12:38 --- *** This bug has been marked as a duplicate of 27308 *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27305
[Bug c/27308] Compiler generates incorrect code when calling a function with the result of an inline function as parameter
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-04-25 12:49 --- This is probably a problem with the inline asm constraints. Try removing the __asm__(r0) from the __res variable. Also try simplifying the testcase by storing the result of BIOS_ContainerUsage(1) to memory rather than calling printf. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27308
[Bug c++/27309] New: [4.0/4.1/4.2 regression] ICE on invalid constructor definition
The following invalid testcase causes an ICE since GCC 4.0.0:
=
struct A
{
int i;
A() i() {} // missing colon
};
struct B
{
A a;
};
B b;
=
bug.cc:4: error: expected ';' before 'i'
bug.cc:5: error: expected `;' before '}' token
bug.cc:12: internal compiler error: vector VEC(tree,base) index domain error,
in locate_ctor at cp/method.c:885
Please submit a full bug report, [etc.]
Btw, the code also caused GCC 2.95.x and 3.0.x to crash.
--
Summary: [4.0/4.1/4.2 regression] ICE on invalid constructor
definition
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, error-recovery, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27309
[Bug libstdc++/17373] std::set::erase(const_iterator) doesn't output error on compilation
--- Comment #4 from falk at debian dot org 2006-04-25 13:19 --- The standard doesn't mention set::erase with iterator argument, only with const_iterator. Maybe it is legal for g++ to allow it anyway (even if I cannot find anything in the standard allowing it at the moment), but other compilers don't, so it is a rather useless extension. So I'll reopen this bug. -- falk at debian dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17373
[Bug libstdc++/17373] std::set::erase(const_iterator) doesn't output error on compilation
--- Comment #5 from falk at debian dot org 2006-04-25 13:20 --- (In reply to comment #4) The standard doesn't mention set::erase with iterator argument, only with const_iterator. erm. the other way round, of course. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17373
[Bug libstdc++/17373] std::set::erase(const_iterator) doesn't output error on compilation
--- Comment #6 from rguenth at gcc dot gnu dot org 2006-04-25 13:23 ---
templateclass _Key, class _Compare, class _Alloc
class set
{
...
// _GLIBCXX_RESOLVE_LIB_DEFECTS
// DR 103. set::iterator is required to be modifiable,
// but this allows modification of keys.
typedef typename _Rep_type::const_iteratoriterator;
typedef typename _Rep_type::const_iteratorconst_iterator;
typedef typename _Rep_type::const_reverse_iteratorreverse_iterator;
typedef typename _Rep_type::const_reverse_iterator
const_reverse_iterator;
all iterators are const...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17373
[Bug middle-end/27310] New: ICE in duplicate_eh_regions
The following testcase causes a segfault in duplicate_eh_regions
when compiled with -fopenmp -O:
==
struct A
{
~A();
};
struct B
{
A a1, a2;
};
void foo()
{
A x1, x2;
#pragma omp parallel
B b;
}
==
Reduced from Martin's testcase in PR 26084.
--
Summary: ICE in duplicate_eh_regions
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code, monitored, openmp
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27310
[Bug libstdc++/17373] std::set::erase(const_iterator) doesn't output error on compilation
--- Comment #7 from pcarlini at suse dot de 2006-04-25 13:33 --- Yes, we are simply implementing the resolution of DR 103: set::iterator is a constant iterator type -- pcarlini at suse dot de changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17373
[Bug libmudflap/26446] Running large program compiled with mudflap aborts even before reaching main()
--- Comment #5 from walter dot zimmer at dlr dot de 2006-04-25 14:05 --- The link-time wrapping of malloc is designed precisely so that other uninstrumented libraries that call malloc by name still get registered in the libmudflap runtime. That way, pointers from these libraries may make their way to an instrumented routine, and be used without error. Good idea. Seems to work with g77, but not with gfortran. Is there maybe any known project which uses both g++ and gfortran and still works with mudflap? Does MUDFLAP_OPTIONS=-trace-calls produce anything? Well, it doesn't seem to reach the point where it evaluates MUDFLAP_OPTIONS, as even MUDFLAP_OPTIONS=-help doesn't work. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26446
[Bug target/27282] [4.2 regression] ICE in final_scan_insn, at final.c:2448 - could not split insn
--- Comment #6 from roger at eyesopen dot com 2006-04-25 14:09 --- Paolo's fix looks good to me. The bugzilla PR shows that this is a 4.2 regression, probably due to the more aggressive RTL optimizations on mainline. So I'll preapprove Paolo's fix for mainline (please post the version you commit and a new testcase when you commit it). As for 4.1, do we have an example of a failure or wrong code generation against the branch? I can't tell from bugzilla whether this is safely latent in 4.0 and 4.1, or just hasn't been investigated there yet (known to work is blank, but the summary only lists [4.2]). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27282
[Bug tree-optimization/27299] [4.1 Regression] vectorizer generates aligned accesses to unaligned memory
--- Comment #4 from reichelt at gcc dot gnu dot org 2006-04-25 14:23 --- Richard, you confirmed this. But to me this looks like the code is violating the aliasing rules (which would mean that the PR in invalid): *(uint64_t *)dest = *(uint64_t *)src; but uint8_t *dest const uint8_t *src -- reichelt at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org, reichelt at gcc dot gnu ||dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27299
[Bug target/25514] [m68k] internal consistency failure
--- Comment #4 from rsandifo at gcc dot gnu dot org 2006-04-25 14:23
---
This issue is related to PR22002. I have a patch.
A slightly-more reduced testcase is:
struct node { struct node *next; int value; };
struct node *current_node, global_list;
void
bar (void)
{
struct node *node, *next;
node = current_node;
next = node-next;
if (node != global_list)
current_node = next;
else
{
node = global_list.next;
global_list.value = node-value;
global_list.next = node-next;
}
foo (node);
}
--
rsandifo at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rsandifo at gcc dot gnu dot
|dot org |org
Status|NEW |ASSIGNED
Last reconfirmed|2006-02-02 19:32:25 |2006-04-25 14:23:53
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25514
[Bug tree-optimization/27299] [4.1 Regression] vectorizer generates aligned accesses to unaligned memory
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-04-25 14:27 --- Yes, but the problem appears with -O1 which has -fno-strict-aliasing. Now whether -fno-strict-aliasing makes the testcase valid is another question ;) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27299
[Bug tree-optimization/27299] [4.1 Regression] vectorizer generates aligned accesses to unaligned memory
--- Comment #6 from rguenth at gcc dot gnu dot org 2006-04-25 14:29 --- Changing the function to take both arguments as uint8_t* fixes the problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27299
[Bug c/27308] Compiler generates incorrect code when calling a function with the result of an inline function as parameter
--- Comment #3 from Eric dot Doenges at betty-tv dot com 2006-04-25 14:37 --- Storing the result to memory generates correct code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27308
[Bug c/27308] Compiler generates incorrect code when calling a function with the result of an inline function as parameter
--- Comment #4 from Eric dot Doenges at betty-tv dot com 2006-04-25 14:43 --- Removing the __asm__ (r0) from __res works around the bug - but then I cannot depend on gcc always allocating r0 for __res, can I ? I found no other way to tell gcc which registers it must use. I'm assuming this is a bug in gcc, not the asm constraint, because the same code works flawlessly with gcc-3.4.3. As to simplifying the testcase - storing the result of BIOS_ContainerUsage to memory generates correct code regardless of wether __res is forced to r0 or not, making it worthless as a test case. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27308
[Bug c++/27312] New: excessive stack use for automatic object on stack
compiling the following
--start-code
struct X {
void g();
};
void g();
void f()
{
X x;
x.g();
g();
}
--end-code-
yields (with -O2)
subl$24, %esp
in the prologue. without the empty class only 12 bytes are subtracted,
presumably to preserve stack alignment.
this is wasteful of stack space.
--
Summary: excessive stack use for automatic object on stack
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: avi at argo dot co dot il
GCC build triplet: x86_64-redhat-linux
GCC host triplet: x86_64-redhat-linux
GCC target triplet: i386-redhat-linux (with -m32)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27312
[Bug target/27282] [4.2 regression] ICE in final_scan_insn, at final.c:2448 - could not split insn
--- Comment #7 from dje at watson dot ibm dot com 2006-04-25 15:21 --- Subject: Re: [4.2 regression] ICE in final_scan_insn, at final.c:2448 - could not split insn The patch may be necessary, but does not fix the testcase. The testcase needs the patch that Andrew originally tested: Index: combine.c === --- combine.c (revision 113239) +++ combine.c (working copy) @@ -8210,7 +8209,8 @@ simplify_and_const_int (rtx x, enum mach return tem; if (!x) -x = simplify_gen_binary (AND, GET_MODE (varop), varop, GEN_INT (constop)); +x = simplify_gen_binary (AND, GET_MODE (varop), varop, +gen_int_mode (constop, mode)); if (GET_MODE (x) != mode) x = gen_lowpart (mode, x); return x; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27282
[Bug target/27282] [4.2 regression] ICE in final_scan_insn, at final.c:2448 - could not split insn
--- Comment #8 from roger at eyesopen dot com 2006-04-25 15:41 --- Grr. David's patch is also good. Perhaps better if we follow the usual protocol of posting patches to gcc-patches *after* bootstrap and regression testing, for review and approval. Posting untested patch fragments to bugzilla without ChangeLog entries and asking for preapproval etc... seems to, in this instance at least, demonstrate why GCC has the contribution protocols that it has. Thanks to David for catching this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27282
[Bug c/27308] Compiler generates incorrect code when calling a function with the result of an inline function as parameter
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-04-25 15:45 --- __res should be allocated to the same register as __r0 due to the '0' constraint which tells gcc to use the same register as for =r (__res). Whoops - I obviously meant to remove the __asm__(r0) from the __r0 variable... But maybe it works vice-versa, too. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27308
[Bug c/27313] New: Does not emit conditional moves for stores
int cmov(int* A ,int B ,int C ,int* D ,int* E ,int F ,int g) {
int k,f;
for (k = 1; k = 1000; k++) {
A[k] = B+C;
g = D[k-1] + E[k-1];
if (g A[k]) A[k]=g; /* This is not converted to cmov*/
f += g;
}
return f;
}
In the above code, the if-then statement is not converted to conditional move.
It fails for noce_mem_write_may_trap_or_fault_p () condition in ifcvt.c as
it thinks that there is a chance for A[k] access to trap.
The fact here is that in this case, A[k] will never trap because the A[k] is
already been written once along the path from Entry to the A[k] = g. So it is
safe to convert it to a cmov statement. Though there might be two extra moves
(mem to reg and vice versa) statement, it is still better to avoid the branch
especially if it is unpredictable data like for the eg above.
There is a typical case like this in Spec 2006 456.hmmer benchmark. Using
contional moves will make the code faster by 13%-17%.
-Dwarak
--
Summary: Does not emit conditional moves for stores
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dwarak dot rajagopal at amd dot com
GCC build triplet: x86_64
GCC host triplet: x86_64
GCC target triplet: x86_64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27313
[Bug c++/27312] excessive stack use for automatic object on stack
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-04-25 15:48 --- The empty class has a size of 1. And yes, the ABI requires to preserve stack alignment. -- 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=27312
[Bug tree-optimization/15911] VRP/DOM does not like TRUTH_AND_EXPR
--- Comment #26 from rguenth at gcc dot gnu dot org 2006-04-25 15:55 --- Created an attachment (id=11333) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11333action=view) updated patch This is a cleanup of the patch by Jeff, bootstrapped and regtested on x86_64-unknown-linux-gnu. ca11011 fails for me with the patch, all other languages are fine. I left the basic structure of the patch as it is reasonable. Compile-time / memory checking will be done soon. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Attachment #11259|0 |1 is obsolete|| AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15911
[Bug c++/27312] excessive stack use for automatic object on stack
--- Comment #2 from avi at argo dot co dot il 2006-04-25 15:57 --- But why 24? gcc could place the object in any of the 12 bytes needed for stack alignment. I don't see any reason why the empty object needs to be aligned to more than a byte boundary. What am I missing? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27312
[Bug target/27282] [4.2 regression] ICE in final_scan_insn, at final.c:2448 - could not split insn
--- Comment #9 from dje at gcc dot gnu dot org 2006-04-25 16:09 --- By the way, while Andrew and my patch does produce correct code, it reverts to the original behavior of the constant propagating into the AND between life2 and lreg, not between life1 and combine. Somehow combine is able to form the AND with the wrong constant that does not match the pattern but cannot form the AND with the correct, sign-extended constant. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27282
[Bug fortran/27314] New: ld can't find libgfortran.so.1 on x86-64
Red Hat Enterprise Linux WS release 3 (Taroon Update 6) on Opteron: bar [10:08:42] /baz cat foo.f90 program foo end program foo bar [10:10:01] /baz gfortran foo.f90 -Wl,-rpath,/scr_bar/johan/local/lib -o foo bar [10:10:24] /baz ./foo ./foo: error while loading shared libraries: libgfortran.so.1: cannot open shared object file: No such file or directory bar [10:10:27] /baz which gfortran /scr_bar/johan/local/bin/gfortran bar [10:10:35] /baz gfortran -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../configure --prefix=/scr_bar/johan/local --with-gmp=/scr_bar/johan/local --with-mpfr=/scr_bar/johan/local --enable-languages=c,c++,fortran Thread model: posix gcc version 4.1.0 bar [10:10:43] /baz strings foo | grep bar /scr_bar/johan/local/lib bar [10:11:01] /baz ls -l /scr_bar/johan/local/lib/libgfortran.so.1 lrwxrwxrwx1 johanresearch 20 Apr 25 09:36 /scr_bar/johan/local/lib/libgfortran.so.1 - libgfortran.so.1.0.0* bar [10:11:16] /baz which ld /usr/bin/ld bar [10:12:04] /baz ld -v GNU ld version 2.14.90.0.4 20030523 bar [10:12:06] /baz -- Summary: ld can't find libgfortran.so.1 on x86-64 Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: critical Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dr dot johan at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27314
[Bug c++/27315] New: ICE with ill-placed #pragma omp parallel
The following invalid code snippet causes an ICE when compiled with -fopenmp:
===
struct A
#pragma omp parallel
{
templateint void foo();
};
template void A::foo0();
===
bug.cc:2: error: '#pragma' is not allowed here
bug.cc:7: error: invalid use of incomplete type 'struct A'
bug.cc:1: error: forward declaration of 'struct A'
bug.cc:7: internal compiler error: tree check: expected tree that contains
'decl common' structure, have 'error_mark' in do_decl_instantiation, at
cp/pt.c:11209
Please submit a full bug report, [etc.]
--
Summary: ICE with ill-placed #pragma omp parallel
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, error-recovery, monitored, openmp
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27315
[Bug c++/27316] New: ICE with two ill-placed #pragma omp parallel
The following invalid code snippet causes an ICE when compiled with -fopenmp:
===
struct A {};
struct B : A
#pragma omp parallel
{};
struct B : A
#pragma omp parallel
{};
===
bug.cc:4: error: '#pragma' is not allowed here
bug.cc:5: error: expected unqualified-id before '{' token
bug.cc:7: internal compiler error: in xref_basetypes, at cp/decl.c:9696
Please submit a full bug report, [etc.]
--
Summary: ICE with two ill-placed #pragma omp parallel
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, error-recovery, monitored, openmp
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27316
[Bug fortran/27317] New: built-in:0: internal compiler error: Illegal instruction
C:\Program Files\gfortran\bingfortran -v ch0701.f90 Driving: gfortran -v ch0701.f90 -lgfortranbegin -lgfortran Using built-in specs. Target: i686-pc-mingw32 Configured with: ../gcc/configure --prefix=/mingw --enable-languages=c,fortran - -with-gmp=/home/coudert/local --disable-nls --with-ld=/mingw/bin/ld --with-as=/m ingw/bin/as --disable-werror --enable-bootstrap --enable-threads=win32 --with-wi n32-nlsapi=unicode Thread model: win32 gcc version 4.2.0 20060425 (experimental) c:/program files/gfortran/bin/../libexec/gcc/i686-pc-mingw32/4.2.0/f951.exe ch0 701.f90 -quiet -dumpbase ch0701.f90 -mtune=generic -auxbase ch0701 -version -I c :/program files/gfortran/bin/../lib/gcc/i686-pc-mingw32/4.2.0/finclude -o C:\DOC UME~1\Leroux\LOCALS~1\Temp/ccgN.s GNU F95 version 4.2.0 20060425 (experimental) (i686-pc-mingw32) compiled by GNU C version 4.2.0 20060425 (experimental). GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 built-in:0: internal compiler error: Illegal instruction Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. I downloaded and installed the latest 'native window' installer. It seems not working. Leroux. -- Summary: built-in:0: internal compiler error: Illegal instruction Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: leroux at cameca dot com GCC build triplet: GNU F95 version 4.2.0 20060425 GCC target triplet: i686-pc-mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27317
[Bug target/27287] loading 0 constant causes an ICE (freescale's messy targets)
--- Comment #3 from eliot at sonic dot net 2006-04-25 16:44 --- (In reply to comment #2) Can you try a snapshot of 4.1.1 and/or the mainline? i tried mainline. same crash. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27287
[Bug middle-end/25776] [4.2 Regression] ICE in cgraph after error at -O1 and above
--- Comment #8 from aldot at gcc dot gnu dot org 2006-04-25 17:00 --- Created an attachment (id=11334) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11334action=view) fix typo in errormessage in verify_cgraph_node() Just as a sidenote.. There is a typo in the error message in comment #1. The attached patch fixes this on the 4.1 branch and on trunk. Please apply, TIA. 2006-04-25 Bernhard Fischer [EMAIL PROTECTED] * cgraphunit.c (verify_cgraph_node): Fix typo s/predecesors/predecessors/ in error message. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25776
[Bug fortran/27304] gfortran: Warn/abort when format in write does not fit passed arguments
--- Comment #1 from tobias dot burnus at physik dot fu-berlin dot de
2006-04-25 17:24 ---
Post scriptum:
I actually see two bugs here:
(a) for static format strings, the test should be done at the compile time
(possibly also for c = '(''n'')'; write(*,c) n )
- see NAG compiler
(b) for dynamically created format strings, I think one should crash with a
meaningful error message. At least that is what ifort, g95, NAG and pgf95 do. I
like the error message of g95:
---
At line 5 of file test.f90 (Unit 6)
Fortran runtime error: Exhausted data descriptors in format
('n')
---
(other wording in NAG f95: No data edit descriptor in tail of format
specification after reversion [and no line number])
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27304
[Bug c++/26846] hidden visibility of static member in class derived from hash_map changes to default visibility
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26846
[Bug driver/27276] Option -static-libgcc doesn't work
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-25 17:25 --- Read PR 14704. *** This bug has been marked as a duplicate of 14704 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|normal Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27276
[Bug other/14704] -static-libgcc option appears non-functional under Solaris
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-04-25 17:25 --- *** Bug 27276 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||jkanze at cheuvreux dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14704
[Bug target/27303] crash at unalign access
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-04-25 17:28 --- We need a testcase to go any further. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|normal Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27303
[Bug tree-optimization/27299] [4.1 Regression] vectorizer generates aligned accesses to unaligned memory
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-04-25 17:35 --- (In reply to comment #5) Yes, but the problem appears with -O1 which has -fno-strict-aliasing. Now whether -fno-strict-aliasing makes the testcase valid is another question ;) Nope, unaligned access is different from strict aliasing. With the cast to uint64_t* you say the alignment is correct for that type. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27299
[Bug middle-end/27313] Does not emit conditional moves for stores
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-25 17:38 --- Confirmed, if cvt should have a way to track if a memory write has happened. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|c |middle-end Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-04-25 17:38:13 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27313
[Bug driver/27314] ld can't find libgfortran.so.1 on x86-64
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-25 17:41 --- This works for me and many other people. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|normal Component|fortran |driver http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27314
[Bug fortran/27317] built-in:0: internal compiler error: Illegal instruction
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-25 17:43 --- This is the not form for support for binaries. We only support GCC which was been compiled by your self. -- 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=27317
[Bug fortran/27318] New: gfortran should warn if a interface does not match
Test case: -- module test implicit none interface subroutine hello(n) integer :: n end subroutine hello end interface end module test subroutine hello(n) integer, intent(in) :: n integer :: i do i = 1,n; print *, 'hello'; end do end subroutine hello -- In the interface, n is implicitly intent(inout). gfortran -Wall does not warn, NAG f95 does: Error: test3.f90: Inconsistent INTERFACE block for procedure HELLO from TEST Argument N (no. 1) has a different INTENT [f95 error termination] -- Summary: gfortran should warn if a interface does not match Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tobias dot burnus at physik dot fu-berlin dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27318
[Bug c++/27315] ICE with ill-placed #pragma omp parallel
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-25 18:28 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |minor Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-04-25 18:28:41 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27315
[Bug c++/27316] ICE with two ill-placed #pragma omp parallel
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-25 18:29 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |minor Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-04-25 18:29:01 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27316
[Bug middle-end/27302] Fold does not fold (i j) == (j i) to 1
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-25 18:31 --- Confirmed. -- pinskia 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-04-25 18:31:38 date|| Summary|Fold does not fold i j == |Fold does not fold (i j) |j i to 1 |== (j i) to 1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27302
[Bug c++/27292] [4.2 regression] ICE on casts on bitfields
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27292
[Bug c++/27309] [4.0/4.1/4.2 regression] ICE on invalid constructor definition
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |minor Target Milestone|--- |4.1.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27309
[Bug middle-end/27310] ICE in duplicate_eh_regions
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-25 18:32 --- Confirmed. -- pinskia 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-04-25 18:32:51 date|| Summary|ICE in duplicate_eh_regions |ICE in duplicate_eh_regions http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27310
[Bug fortran/27304] gfortran: Warn/abort when format in write does not fit passed arguments
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-25 18:33 --- Confirmed. -- pinskia 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-04-25 18:33:43 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27304
[Bug target/27308] Compiler generates incorrect code when calling a function with the result of an inline function as parameter
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|blocker |normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27308
[Bug middle-end/27313] Does not emit conditional moves for stores
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-25 18:38 ---
The other way of getting this is to have the code converted so there is only
one store instead of two:
int cmov(int* A ,int B ,int C ,int* D ,int* E ,int F ,int g) {
int k,f;
for (k = 1; k = 1000; k++) {
int t = B+C;
g = D[k-1] + E[k-1];
if (g t) t=g; /* This is not converted to cmov*/
A[K] = t;
f += g;
}
return f;
}
Which is most likely better anyways as one it is smaller.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27313
[Bug driver/27314] ld can't find libgfortran.so.1 on x86-64
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-25 18:38 --- You must be doing something wrong as I know this works for me and many other people. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27314
[Bug fortran/27318] gfortran should warn if a interface does not match
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-25 18:39 --- Confirmed. -- pinskia 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-04-25 18:39:13 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27318
[Bug inline-asm/27301] [4.0/4.1/4.2 Regression] ICE on convoluted inline asm with m (statement expression and vla)
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-25 18:41 --- Confirmed, the ICE is at least a regression. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to fail||4.1.0 4.0.0 4.2.0 Last reconfirmed|-00-00 00:00:00 |2006-04-25 18:41:51 date|| Summary|ICE on convoluted inline asm|[4.0/4.1/4.2 Regression] ICE |with m (statement |on convoluted inline asm |expression and vla) |with m (statement ||expression and vla) Target Milestone|--- |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27301
[Bug c/27301] [4.0/4.1/4.2 Regression] ICE on convoluted inline asm with m (statement expression and vla)
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-25 18:47 ---
Hmm, interesting, we have a TARGET_EXPR before gimplifying:
__asm__ __volatile__(::m TARGET_EXPR D.1284, {
typedef struct
{
char x[0:(unsigned int) ((int) SAVE_EXPR n - 1)];
} struct struct
{
char x[0:(unsigned int) ((int) SAVE_EXPR n - 1)];
};
struct
{
char x[0:(unsigned int) ((int) SAVE_EXPR n - 1)];
} * p = (struct
{
char x[0:(unsigned int) ((int) SAVE_EXPR n - 1)];
} *) ptr;
Which might be the real issue.
The C++ front-end rejects this code as a VLA type is invalid even for GNU C++.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Component|inline-asm |c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27301
[Bug middle-end/27313] Does not emit conditional moves for stores
--- Comment #3 from dwarak dot rajagopal at amd dot com 2006-04-25 19:07
---
Yes this is true. The example I posted was a simplest case where it fails.
Below mmight be a typical case where you have to do two stores.
int cmov(int* A ,int B ,int C ,int* D ,int* E ,int F ,int g) {
int k,f;
for (k = 1; k = 1000; k++) {
A[k] = B+C;
D[k] = C; /* D[k] may alias with A[k] */
g = D[k-1] + E[k-1];
if (g A[k]) A[k]=g; /* This is not converted to cmov*/
f += g;
}
return f;
}
In this case, you cannot reduce the number of stores (becasue D[k] may alias
with A[k]) but you still want the if conversion to take place. I think it is
good to have a mechanism to track if a memory is already been written in ifcvt.
I'm not sure how it can be done at this level though.
-Dwarak
(In reply to comment #2)
The other way of getting this is to have the code converted so there is only
one store instead of two:
int cmov(int* A ,int B ,int C ,int* D ,int* E ,int F ,int g) {
int k,f;
for (k = 1; k = 1000; k++) {
int t = B+C;
g = D[k-1] + E[k-1];
if (g t) t=g; /* This is not converted to cmov*/
A[K] = t;
f += g;
}
return f;
}
Which is most likely better anyways as one it is smaller.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27313
[Bug tree-optimization/22525] tree based value profiling (-fprofile-use) produces mismatch types in conditional
--- Comment #7 from brett dot albertson at stratech dot com 2006-04-25 19:29 --- (In reply to comment #6) Fixed. After this patch was applied onto trunk, the following test started failing on Solaris x86: FAIL: gcc.dg/tree-prof/val-prof-2.c scan-tree-dump n \+ \-1 All the other val-prof-2.c tests PASS. Any ideas? Brett Albertson -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22525
[Bug c++/27319] New: C++ class object destructors are not called for static class objects in a shared library when dlclose is called.
For C++ classes of any type, the class destructor fails to be called under the
following circumstances in the CYGWIN environment (not a problem in linux):
1) A static object of a class is declared within the body of a function which
is part of a shared library.
2) The shared library is loaded with dlopen, the function in question is
called, then the shared library is unloaded with dlclose.
Sample code:
// -
// File mymain.C
// -
#include dlfcn.h
using namespace std;
#include iostream
extern C void printit();
int main()
{
void * LibraryHandle = dlopen(./mylib.sl, RTLD_LAZY);
if(LibraryHandle)
{
void (*Printit)() = ( void (*)() )dlsym(LibraryHandle, printit);
(*Printit)();
coutClose libraryendl;
dlclose(LibraryHandle);
coutLibrary closedendl;
}
else
cout dlerror() endl;
}
// -
// File mylib.C
// -
using namespace std;
#include iostream
extern C void printit();
class KStr
{
public:
KStr(const char*);
~KStr();
char StrBuf[20];
};
KStr::KStr(const char*Str)
{
strcpy(StrBuf, Str);
}
KStr::~KStr()
{
coutStrBufendl;
}
static KStr MyString1(Hello1);
void printit()
{
static KStr MyString2(Hello2);
}
// --
// Build script in cygwin
// --
g++ mymain.C -o mymain
g++ mylib.C -shared -o mylib.sl
// --
// Build script in linux
// --
g++ mymain.C -o mymain -ldl
g++ mylib.C -shared -o mylib.sl
// When running the program in linux the normal output looks as follows:
Close library
Hello2
Hello1
Library closed
// When running the program in cygwin the output is as follows:
Close library
Hello1
Library closed
Segmentation fault (core dumped)
In cygwin the class destructor for Hello2 is not called until the program is
exiting, after the shared library has been unloaded. At that point the memory
for that particular class instance has apparently already been freed by the
dlclose operation resulting in a crash when the destructor is called.
I don't know if this is a gcc problem or a cygwin dlclose problem.
Harry Dellicker
--
Summary: C++ class object destructors are not called for static
class objects in a shared library when dlclose is
called.
Product: gcc
Version: 3.4.4
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hbd_bugreports at earthlink dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27319
[Bug libgomp/25865] [4.2 Regression] libgomp incorrectly detects support for TLS
-- rth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2006-02-02 23:45:50 |2006-04-25 20:54:06 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25865
[Bug libgomp/25865] [4.2 Regression] libgomp incorrectly detects support for TLS
--- Comment #5 from rth at gcc dot gnu dot org 2006-04-25 20:58 --- Subject: Bug 25865 Author: rth Date: Tue Apr 25 20:58:25 2006 New Revision: 113256 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113256 Log: PR libgomp/25865 * configure.ac: Use GCC_CHECK_TLS. * acinclude.m4 (LIBGOMP_CHECK_TLS): Remove. * Makefile.in, aclocal.m4, configure: Regenerate. Modified: trunk/libgomp/ChangeLog trunk/libgomp/Makefile.in trunk/libgomp/acinclude.m4 trunk/libgomp/aclocal.m4 trunk/libgomp/configure trunk/libgomp/configure.ac trunk/libgomp/testsuite/Makefile.in -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25865
[Bug libgomp/25865] [4.2 Regression] libgomp incorrectly detects support for TLS
--- Comment #6 from rth at gcc dot gnu dot org 2006-04-25 21:03 --- Fixed, or if not, moved the point of failure out of libgomp. -- rth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25865
[Bug target/27282] [4.2 regression] ICE in final_scan_insn, at final.c:2448 - could not split insn
--- Comment #10 from janis at gcc dot gnu dot org 2006-04-25 21:16 --- A regression hunt of trunk on powerpc-linux using mini.c with -O2 identified: http://gcc.gnu.org/viewcvs?view=revrev=109016 r109016 | bonzini | 2005-12-23 16:07:53 + (Fri, 23 Dec 2005) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27282
[Bug ada/27186] GNAT BUG DETECTED with Booch Components Set_Test_Support
--- Comment #7 from george dot chapman at lmco dot com 2006-04-25 21:31 --- I agree. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27186
[Bug target/27319] C++ class object destructors are not called for static class objects in a shared library when dlclose is called.
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-25 21:31 --- Yes, this is a target specific issue. If the target does not support atexit, this is what will happen. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|major |normal Status|UNCONFIRMED |NEW Component|c++ |target Ever Confirmed|0 |1 GCC host triplet|CYGWIN (Current version), | |Win 2k | GCC target triplet||win32 Last reconfirmed|-00-00 00:00:00 |2006-04-25 21:31:56 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27319
[Bug ada/27186] GNAT BUG DETECTED with Booch Components Set_Test_Support
--- Comment #8 from george dot chapman at lmco dot com 2006-04-25 21:32 --- *** This bug has been marked as a duplicate of 26678 *** -- george dot chapman at lmco dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27186
[Bug ada/26678] GNAT BUG DETECTED when compiling AWS.
--- Comment #9 from george dot chapman at lmco dot com 2006-04-25 21:32 --- *** Bug 27186 has been marked as a duplicate of this bug. *** -- george dot chapman at lmco dot com changed: What|Removed |Added CC||george dot chapman at lmco ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26678
[Bug c++/27309] [4.0/4.1/4.2 regression] ICE on invalid constructor definition
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-25 21:32 --- Confirmed. -- pinskia 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-04-25 21:32:58 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27309
[Bug rtl-optimization/26725] [4.2 Regression] ICE in check_reg_live, at haifa-sched.c:4645 with -O2 on ia64
--- Comment #5 from rsandifo at gcc dot gnu dot org 2006-04-25 21:34 --- Subject: Bug 26725 Author: rsandifo Date: Tue Apr 25 21:34:48 2006 New Revision: 113257 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113257 Log: gcc/ PR rtl-optimization/26725 * cfgrtl.c (rtl_redirect_edge_and_branch_force): Set the source block's BB_DIRTY flag. gcc/testsuite/ * gcc.c-torture/compile/pr26725.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr26725.c Modified: trunk/gcc/ChangeLog trunk/gcc/cfgrtl.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26725
[Bug c++/27278] [4.0/4.1/4.2 regression] ICE with invalid operator declaration
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2006- ||04/msg00929.html Severity|normal |minor Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||patch Last reconfirmed|-00-00 00:00:00 |2006-04-25 21:34:59 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27278
[Bug c++/27279] [4.0/4.1/4.2 regression] ICE with invalid constructor declaration
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2006- ||04/msg00930.html Severity|normal |minor Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-04-25 21:35:24 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27279
