[Bug rtl-optimization/36111] [4.4 Regression] GCC 4.4.0-20080501 failed to compile openmpi's malloc.c file.
--- Comment #8 from ubizjak at gmail dot com 2008-05-12 06:47 --- This also fixes sse3-* failures with -fpic at http://gcc.gnu.org/ml/gcc-testresults/2008-05/msg01014.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36111
[Bug fortran/36059] -frepack-arrays: symbols w/ TARGET should not be repacked
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2008-05-12 07:55
---
There's only one place -frepack-arrays has an effect on, and it's easy enough
to change:
Index: trans-decl.c
===
--- trans-decl.c(revision 135088)
+++ trans-decl.c(working copy)
@@ -733,7 +733,10 @@ gfc_build_dummy_array_decl (gfc_symbol *
/* Create a descriptorless array pointer. */
as = sym-as;
packed = PACKED_NO;
- if (!gfc_option.flag_repack_arrays)
+
+ /* Even when -frepack-arrays is used, symbols with TARGET attribute
+are not repacked. */
+ if (!gfc_option.flag_repack_arrays || sym-attr.target)
{
if (as-type == AS_ASSUMED_SIZE)
packed = PACKED_FULL;
Do you think there's anything more to do? Other attributes for which we might
want to do the same thing?
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
CC||fxcoudert at gcc dot gnu dot
||org
AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot
|dot org |org
Status|NEW |ASSIGNED
Last reconfirmed|2008-04-30 18:19:22 |2008-05-12 07:55:30
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36059
[Bug fortran/36157] ICE in snapshot of 05/02/08 under FreeBSD i386 with IMPLICIT and function call
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2008-05-12 08:00 --- Can you run it under gdb and provide a backtrace? To do this, follow these steps: 1. Run gdb -args ./libexec/gcc/x86_64-unknown-linux-gnu/4.4.0/f951 o.f90 where o.f90 is your source file and x86_64-unknown-linux-gnu is replaced by your target triplet. 2. Once at the (gdb) prompt, type run. 3. When the segfault happens, you get another (gdb) prompt: type backtrace 4. Just paste everything back here -- 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=36157
[Bug fortran/36140] ICE in snapshot of 05/02/08 under MIPS Linux with IMPLICIT LOGICAL and function call
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2008-05-12 08:00 --- Can you run it under gdb and provide a backtrace? To do this, follow these steps: 1. Run gdb -args ./libexec/gcc/x86_64-unknown-linux-gnu/4.4.0/f951 o.f90 where o.f90 is your source file and x86_64-unknown-linux-gnu is replaced by your target triplet. 2. Once at the (gdb) prompt, type run. 3. When the segfault happens, you get another (gdb) prompt: type backtrace 4. Just paste everything back here -- 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=36140
[Bug tree-optimization/34330] -ftree-parallelize-loops=4 ICE with the vectorizer also
--- Comment #6 from razya at il dot ibm dot com 2008-05-12 09:13 ---
(In reply to comment #0)
/* { dg-do compile } */
/* { dg-options -O3 -ftree-parallelize-loops=4 } */
struct T
{
int t;
struct { short s1, s2, s3, s4 } *s;
};
void
foo (int *a, int *b, int *c, int *d, struct T *e)
{
int i;
for (i = 0; i e-t; i++)
{
e-s[i].s1 = a[i];
e-s[i].s2 = b[i];
e-s[i].s3 = c[i];
e-s[i].s4 = d[i];
}
}
ICEs on x86_64-linux with
test.c: In function 'foo':
test.c:11: internal compiler error: in get_smt_for, at tree-ssa-alias.c:3203
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
I'm getting the same ICE (with r134722) when running spec2006/gobmk on power6.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34330
[Bug tree-optimization/34330] -ftree-parallelize-loops=4 ICE with the vectorizer also
--- Comment #7 from razya at il dot ibm dot com 2008-05-12 09:42 --- (In reply to comment #6) I'm getting the same ICE (with r134722) when running spec2006/gobmk on power6. The same failure appears also for other benchmarks from spec2006: h264ref, gromacs, calculix, tonto, wrf -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34330
[Bug libstdc++/36217] New: gcc-4.2-20080507, target mips64vrel-elf, libmath build failure
//---// configuration: CFLAGS=-O2 $DEPACK_DIR/gcc-4.2-20080507/configure --target=mips64vrel-elf \ --prefix=$PREFIX_DIR --enable-languages=c,c++ --disable-__cxa_atexit \ --with-gnu-as --with-gnu-ld --with-newlib \ --with-gxx-include-dir=$PREFIX_DIR/mips64vrel-elf/include -v \ 21 | tee configure.log //---// host: cygwin-1.5.25-7 on xp sp2 //---// error: mips64vrel-elf-ar rc .libs/libmath.a stubs.o mips64vrel-elf-ranlib .libs/libmath.a creating libmath.la (cd .libs rm -f libmath.la ln -s ../libmath.la libmath.la) make[8]: Leaving directory `/tmp/build-mips64vrel-elf/gcc-20080507/mips64vrel-elf/eb/o32/vr5500/libstdc++-v3/libmath' Making all in src make[8]: Entering directory `/tmp/build-mips64vrel-elf/gcc-20080507/mips64vrel-elf/eb/o32/vr5500/libstdc++-v3/src' /bin/sh ../libtool --tag CXX --mode=compile /tmp/build-mips64vrel-elf/gcc-20080507/./gcc/xgcc -shared-libgcc -B/tmp/build-mips64vrel-elf/gcc-20080507/./gcc -nostdinc++ -L/tmp/build-mips64vrel-elf/gcc-20080507/mips64vrel-elf/eb/o32/vr5500/libstdc++-v3/src -L/tmp/build-mips64vrel-elf/gcc-20080507/mips64vrel-elf/eb/o32/vr5500/libstdc++-v3/src/.libs -nostdinc -B/tmp/build-mips64vrel-elf/gcc-20080507/mips64vrel-elf/eb/o32/vr5500/newlib/ -isystem /tmp/build-mips64vrel-elf/gcc-20080507/mips64vrel-elf/eb/o32/vr5500/newlib/targ-include -isystem /ecostools/src/gcc-4.2-20080507/newlib/libc/include -B/ecostools/mips64vrel-elf-20080509/mips64vrel-elf/bin/ -B/ecostools/mips64vrel-elf-20080509/mips64vrel-elf/lib/ -isystem /ecostools/mips64vrel-elf-20080509/mips64vrel-elf/include -isystem /ecostools/mips64vrel-elf-20080509/mips64vrel-elf/sys-include -EB -mabi=32 -march=vr5500 -I/tmp/build-mips64vrel-elf/gcc-20080507/mips64vrel-elf/eb/o32/vr5500/libstdc++-v3/include/mips64vrel-elf -I/tmp/build-mips64vrel-elf/gcc-20080507/mips64vrel-elf/eb/o32/vr5500/libstdc++-v3/include -I/ecostools/src/gcc-4.2-20080507/libstdc++-v3/libsupc++ -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -g -O2 -EB -mabi=32 -march=vr5500 -c -o bitmap_allocator.lo /ecostools/src/gcc-4.2-20080507/libstdc++-v3/src/bitmap_allocator.cc /tmp/build-mips64vrel-elf/gcc-20080507/./gcc/xgcc -shared-libgcc -B/tmp/build-mips64vrel-elf/gcc-20080507/./gcc -nostdinc++ -L/tmp/build-mips64vrel-elf/gcc-20080507/mips64vrel-elf/eb/o32/vr5500/libstdc++-v3/src -L/tmp/build-mips64vrel-elf/gcc-20080507/mips64vrel-elf/eb/o32/vr5500/libstdc++-v3/src/.libs -nostdinc -B/tmp/build-mips64vrel-elf/gcc-20080507/mips64vrel-elf/eb/o32/vr5500/newlib/ -isystem /tmp/build-mips64vrel-elf/gcc-20080507/mips64vrel-elf/eb/o32/vr5500/newlib/targ-include -isystem /ecostools/src/gcc-4.2-20080507/newlib/libc/include -B/ecostools/mips64vrel-elf-20080509/mips64vrel-elf/bin/ -B/ecostools/mips64vrel-elf-20080509/mips64vrel-elf/lib/ -isystem /ecostools/mips64vrel-elf-20080509/mips64vrel-elf/include -isystem /ecostools/mips64vrel-elf-20080509/mips64vrel-elf/sys-include -EB -mabi=32 -march=vr5500 -I/tmp/build-mips64vrel-elf/gcc-20080507/mips64vrel-elf/eb/o32/vr5500/libstdc++-v3/include/mips64vrel-elf -I/tmp/build-mips64vrel-elf/gcc-20080507/mips64vrel-elf/eb/o32/vr5500/libstdc++-v3/include -I/ecostools/src/gcc-4.2-20080507/libstdc++-v3/libsupc++ -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -g -O2 -EB -mabi=32 -march=vr5500 -c /ecostools/src/gcc-4.2-20080507/libstdc++-v3/src/bitmap_allocator.cc -o bitmap_allocator.o /bin/sh ../libtool --tag CXX --mode=compile /tmp/build-mips64vrel-elf/gcc-20080507/./gcc/xgcc -shared-libgcc -B/tmp/build-mips64vrel-elf/gcc-20080507/./gcc -nostdinc++ -L/tmp/build-mips64vrel-elf/gcc-20080507/mips64vrel-elf/eb/o32/vr5500/libstdc++-v3/src -L/tmp/build-mips64vrel-elf/gcc-20080507/mips64vrel-elf/eb/o32/vr5500/libstdc++-v3/src/.libs -nostdinc -B/tmp/build-mips64vrel-elf/gcc-20080507/mips64vrel-elf/eb/o32/vr5500/newlib/ -isystem /tmp/build-mips64vrel-elf/gcc-20080507/mips64vrel-elf/eb/o32/vr5500/newlib/targ-include -isystem /ecostools/src/gcc-4.2-20080507/newlib/libc/include -B/ecostools/mips64vrel-elf-20080509/mips64vrel-elf/bin/ -B/ecostools/mips64vrel-elf-20080509/mips64vrel-elf/lib/ -isystem /ecostools/mips64vrel-elf-20080509/mips64vrel-elf/include -isystem /ecostools/mips64vrel-elf-20080509/mips64vrel-elf/sys-include -EB -mabi=32 -march=vr5500 -I/tmp/build-mips64vrel-elf/gcc-20080507/mips64vrel-elf/eb/o32/vr5500/libstdc++-v3/include/mips64vrel-elf -I/tmp/build-mips64vrel-elf/gcc-20080507/mips64vrel-elf/eb/o32/vr5500/libstdc++-v3/include -I/ecostools/src/gcc-4.2-20080507/libstdc++-v3/libsupc++ -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -fdiagnostics-show-location=once
[Bug c/32642] Extended Asm modification of a range of bytes
--- Comment #1 from aph at gcc dot gnu dot org 2008-05-12 10:27 --- What on earth is this asm supposed to do? The compiler is quite entitled to complain about this: the memory at char x[10] is being used as an ouput operand, but it is not in scope. The text in the gcc texinfo refers to an input operand. -- aph at gcc dot gnu dot org changed: What|Removed |Added CC||aph at gcc dot gnu dot org Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32642
[Bug ada/36207] [4.4 regression] Ada bootstrap fails in uintp.adb:1595
-- aaronavay62 at aaronwl dot com changed: What|Removed |Added Severity|major |critical http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36207
[Bug fortran/36215] [4.4 regression] Fortran bootstrap fails on _abs_c4.F90
-- aaronavay62 at aaronwl dot com changed: What|Removed |Added Severity|major |critical http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36215
[Bug libgcj/36218] New: [4.4 regression] libgcj causes stack overflow in jc1.exe
Several files in libgcj will cause jc1.exe to exhaust its stack space allocation. This can be worked around by compiling jc1.exe with -Wl,--stack,0x200, which can be accomplished by including it in LDFLAGS when compiling. (This exact size is arbitrary; it's big enough to work, but perhaps much too big.) The cause seems to be massive recursion between find_assert_locations() and find_conditional_asserts(). I'm not sure if this is intended behavior. If this is intended behavior, it's not clear to me what the right thing to do to fix this is. What negative consequences does increasing the default allocation have? Is it possible to adjust this limit at runtime, perhaps as needed? -- Summary: [4.4 regression] libgcj causes stack overflow in jc1.exe Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: build, memory-hog Severity: critical Priority: P3 Component: libgcj AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: aaronavay62 at aaronwl dot com GCC host triplet: i386-pc-mingw32 OtherBugsDependingO 36216 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36218
[Bug libgcj/36218] [4.4 regression] libgcj causes stack overflow in jc1.exe
--- Comment #1 from aaronavay62 at aaronwl dot com 2008-05-12 11:03 --- cipher.o at least fails for this reason. I'm not sure when this last worked, but it at least worked sometime around 2004. -- aaronavay62 at aaronwl dot com changed: What|Removed |Added Known to fail||4.4.0 4.3.0 4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36218
[Bug fortran/35719] pointer to zero sized array not associated
--- Comment #10 from jb at gcc dot gnu dot org 2008-05-12 11:27 --- Time for a what we want to fix with the new array descriptor meta-PR? I started a wiki page for this, with a few issues from the top of my head: http://gcc.gnu.org/wiki/ArrayDescriptorUpdate -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35719
[Bug fortran/36157] ICE in snapshot of 05/02/08 under FreeBSD i386 with IMPLICIT and function call
--- Comment #2 from michael dot a dot richmond at nasa dot gov 2008-05-12 11:41 --- $ gdb -args irun/libexec/gcc/i386-unknown-freebsd7.0/4.4.0/f951 m1.f90 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-marcel-freebsd... (gdb) run Starting program: /usr/home/mrichmon/irun/libexec/gcc/i386-unknown-freebsd7.0/4.4.0/f951 m1.f90 Program received signal SIGSEGV, Segmentation fault. 0x28771303 in strchr () from /lib/libc.so.7 (gdb) backtrace #0 0x28771303 in strchr () from /lib/libc.so.7 #1 0xbfbfe5f4 in ?? () #2 0xbfbfdf88 in ?? () #3 0x287631fa in localeconv () from /lib/libc.so.7 #4 0x286f06e3 in vsnprintf () from /lib/libc.so.7 #5 0x080791b9 in gfc_get_string ( format=0x100 Error reading address 0x100: Bad address) at /home/mrichmon/gcc-4.4-20080502/gcc/fortran/iresolve.c:52 #6 0x0806cb0c in gfc_find_function ( name=0x100 Error reading address 0x100: Bad address) at /home/mrichmon/gcc-4.4-20080502/gcc/fortran/intrinsic.c:702 #7 0x0806bf06 in gfc_procedure_use (sym=0x28863380, ap=0x2886813c, where=0x288680f0) at /home/mrichmon/gcc-4.4-20080502/gcc/fortran/interface.c:2411 #8 0x08097745 in gfc_resolve_expr (e=0x0) at /home/mrichmon/gcc-4.4-20080502/gcc/fortran/resolve.c:1695 #9 0x in ?? () (gdb) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36157
[Bug fortran/36140] ICE in snapshot of 05/02/08 under MIPS Linux with IMPLICIT LOGICAL and function call
--- Comment #2 from michael dot a dot richmond at nasa dot gov 2008-05-12 12:06 --- I would like to make a clarification. Program kmci produces a segfault: f951: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Program summt produces an ICE that is not a segfault: f951: internal compiler error: in resolve_specific_f0, at fortran/resolve.c:1572 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. The gdb listing for kmci is: GNU gdb 6.4.90-debian Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as mips-linux-gnu...Using host libthread_db library /lib/libthread_db.so.1. (gdb) run Starting program: /home/mrichmon/irun/libexec/gcc/mips-unknown-linux-gnu/4.4.0/f951 kmci.f90 Program received signal SIGSEGV, Segmentation fault. 0x2ac6ffb4 in funlockfile () from /lib/libc.so.6 (gdb) backtrace #0 0x2ac6ffb4 in funlockfile () from /lib/libc.so.6 #1 0x2ac54360 in vfprintf () from /lib/libc.so.6 #2 0x2ac7bf78 in vsnprintf () from /lib/libc.so.6 #3 0x0048b1b0 in gfc_get_string (format=0x7fe9045c ) at /home/mrichmon/gcc-4.4-20080502/gcc/fortran/iresolve.c:52 #4 0x0047764c in gfc_find_function ( name=0x7fe902a8 û\200\001\177é\003Ì\177é\003Ì\177é\003Ì\177é\003Ì\177é\003Ì\177é\004K\177é\003Ì\177é\004K) at /home/mrichmon/gcc-4.4-20080502/gcc/fortran/intrinsic.c:702 #5 0x004763f8 in gfc_procedure_use (sym=0xc97480, ap=0xc975f4, where=0xc975dc) at /home/mrichmon/gcc-4.4-20080502/gcc/fortran/interface.c:2411 #6 0x004ba1a0 in gfc_resolve_expr (e=0xc975a8) at /home/mrichmon/gcc-4.4-20080502/gcc/fortran/resolve.c:1695 #7 0x004c04fc in resolve_code (code=0xc977b0, ns=0xc962b8) at /home/mrichmon/gcc-4.4-20080502/gcc/fortran/resolve.c:6198 #8 0x004c4a6c in gfc_resolve_blocks (b=0xc96ae8, ns=0xc962b8) at /home/mrichmon/gcc-4.4-20080502/gcc/fortran/resolve.c:5988 #9 0x004c04cc in resolve_code (code=0xc73b10, ns=0xc962b8) at /home/mrichmon/gcc-4.4-20080502/gcc/fortran/resolve.c:6187 #10 0x004c2438 in resolve_codes (ns=0xc962b8) at /home/mrichmon/gcc-4.4-20080502/gcc/fortran/resolve.c:9121 #11 0x004c2494 in gfc_resolve (ns=0xc962b8) at /home/mrichmon/gcc-4.4-20080502/gcc/fortran/resolve.c:9140 ---Type return to continue, or q return to quit--- #12 0x004ade44 in gfc_parse_file () at /home/mrichmon/gcc-4.4-20080502/gcc/fortran/parse.c:3566 #13 0x004e9488 in gfc_be_parse_file (set_yydebug=value optimized out) at /home/mrichmon/gcc-4.4-20080502/gcc/fortran/f95-lang.c:258 #14 0x0075f79c in toplev_main (argc=value optimized out, argv=value optimized out) at /home/mrichmon/gcc-4.4-20080502/gcc/toplev.c:962 #15 0x2ac25434 in __libc_start_main () from /lib/libc.so.6 #16 0x0044320c in _ftext () at ../sysdeps/mips/elf/start.S:110 (gdb) quit The program is running. Exit anyway? (y or n) y The gdb listing for summt is: GNU gdb 6.4.90-debian Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as mips-linux-gnu...Using host libthread_db library /lib/libthread_db.so.1. (gdb) run Starting program: /home/mrichmon/irun/libexec/gcc/mips-unknown-linux-gnu/4.4.0/f951 summt.f90 f951: internal compiler error: in resolve_specific_f0, at fortran/resolve.c:1572 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Program exited with code 04. (gdb) backtrace No stack. (gdb) quit -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36140
[Bug ada/36207] [4.4 regression] Ada bootstrap fails in uintp.adb:1595
--- Comment #1 from sam at gcc dot gnu dot org 2008-05-12 12:11 ---
Could you post the disassembly of the previous stage get_target_char_size
from targtyps.o? (objdump --source targtyps.o)
On i686-pc-linux-gnu, I get:
Pos
get_target_char_size (void)
{
14: 55 push %ebp
15: 89 e5 mov%esp,%ebp
return CHAR_TYPE_SIZE;
17: b8 08 00 00 00 mov$0x8,%eax
}
1c: 5d pop%ebp
1d: c3 ret
This function is called to initialize Standard_Short_Short_Integer_Size. If
CHAR_TYPE_SIZE is not defined for your target, it defaults to BITS_PER_UNIT
(gigi.h).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36207
[Bug tree-optimization/36119] [4.4 regression] internal compiler error: in vectorizable_assignment, at tree-vect-transform.c:3671
--- Comment #14 from irar at il dot ibm dot com 2008-05-12 12:17 --- Fixed. -- irar at il dot ibm dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36119
[Bug ada/36207] [4.4 regression] Ada bootstrap fails in uintp.adb:1595
--- Comment #2 from sam at gcc dot gnu dot org 2008-05-12 12:18 --- The beginning of objdump --disassemble-all -r ttypes.o should be interesting as well: ttypes___elabs: 0: 55 push %ebp 1: 89 e5 mov%esp,%ebp 3: 83 ec 08sub$0x8,%esp 6: e8 fc ff ff ff call 7 ttypes___elabs+0x7 7: R_386_PC32 get_target_char_size b: 89 04 24mov%eax,(%esp) e: a3 00 00 00 00 mov%eax,0x0 f: R_386_32 ttypes__standard_short_short_integer_size -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36207
[Bug rtl-optimization/36111] [4.4 Regression] GCC 4.4.0-20080501 failed to compile openmpi's malloc.c file.
--- Comment #9 from ubizjak at gmail dot com 2008-05-12 13:12 --- (In reply to comment #6) This patch works for me: Index: recog.c This is not a good solution, since the problem is in if (SWAPPABLE_OPERANDS_P (x)) section, a couple of lines down the code. The patch and an analysis is at patch URL: http://gcc.gnu.org/ml/gcc-patches/2008-05/msg00687.html -- ubizjak at gmail dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ubizjak at gmail dot com |dot org | URL||http://gcc.gnu.org/ml/gcc- ||patches/2008- ||05/msg00687.html Status|NEW |ASSIGNED Last reconfirmed|2008-05-05 04:59:19 |2008-05-12 13:12:00 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36111
[Bug ada/33457] Renaming in context of ragged array
--- Comment #3 from sam at gcc dot gnu dot org 2008-05-12 14:12 --- What compilation option did you use? I cannot reproduce this with Debian's 4.3 compiler or with current SVN trunk. -- sam at gcc dot gnu dot org changed: What|Removed |Added CC||sam at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33457
[Bug c++/35243] [4.3/4.4 regression] ICE with invalid initializer list in variadic template
--- Comment #2 from paolo dot carlini at oracle dot com 2008-05-12 14:20 --- On it. -- paolo dot carlini at oracle dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |paolo dot carlini at oracle |dot org |dot com Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35243
[Bug c++/35331] [4.3/4.4 regression] ICE with invalid specialization of variadic template
--- Comment #4 from paolo at gcc dot gnu dot org 2008-05-12 15:19 --- Subject: Bug 35331 Author: paolo Date: Mon May 12 15:18:52 2008 New Revision: 135216 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=135216 Log: /cp 2008-05-12 Paolo Carlini [EMAIL PROTECTED] PR c++/35331 * semantics.c (begin_class_definition): Extend checks on the first argument. /testsuite 2008-05-12 Paolo Carlini [EMAIL PROTECTED] PR c++/35331 * g++.dg/cpp0x/vt-35331.C: New. * g++.dg/cpp0x/pr32125.C: Adjust. * g++.dg/cpp0x/pr32126.C: Likewise. * g++.dg/cpp0x/pr31438.C: Likewise. * g++.dg/cpp0x/variadic81.C: Likewise. * g++.dg/cpp0x/vt-34055.C: Likewise. * g++.dg/cpp0x/vt-34606.C: Likewise. Added: trunk/gcc/testsuite/g++.dg/cpp0x/vt-35331.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/semantics.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/cpp0x/pr31438.C trunk/gcc/testsuite/g++.dg/cpp0x/pr32125.C trunk/gcc/testsuite/g++.dg/cpp0x/pr32126.C trunk/gcc/testsuite/g++.dg/cpp0x/variadic81.C trunk/gcc/testsuite/g++.dg/cpp0x/vt-34055.C trunk/gcc/testsuite/g++.dg/cpp0x/vt-34606.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35331
[Bug ada/33457] Renaming in context of ragged array
--- Comment #4 from anhvofrcaus at gmail dot com 2008-05-12 15:19 --- Sam, If you look at my comment on 21 January 2008. This problem was fixed starting with gcc-4.3-20080118. That is why you did not see the problem existed. In summary, this PR should be closed around that time. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33457
[Bug c++/35331] [4.3 regression] ICE with invalid specialization of variadic template
-- paolo dot carlini at oracle dot com changed: What|Removed |Added AssignedTo|pcarlini at suse dot de |unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW Summary|[4.3/4.4 regression] ICE|[4.3 regression] ICE with |with invalid specialization |invalid specialization of |of variadic template|variadic template http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35331
[Bug middle-end/35964] ICE with -funroll-loops on arm/arm eabi
--- Comment #12 from jules at gcc dot gnu dot org 2008-05-12 15:27 --- I think this was probably fixed by one of Andrew Jenner's patches in gfortran-armel-updates: http://lists.debian.org/debian-gcc/2008/04/msg00351.html (The Unshare RTX earlier... one). Andrew and I actually did this work (ObjC and Fortran improvements for ARM EABI) primarily against Debian's version of 4.3, with the intention of then forward-porting the patches to FSF mainline -- but, that particular patch hasn't made it to FSF submission yet. If this is a regression, we'll consider submitting the patch for FSF 4.3 as well, when the time comes. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35964
[Bug target/36222] New: x86 fails to optimize out __v4si - __m128i move
[EMAIL PROTECTED] sse-1]$ cat d.c
#include emmintrin.h
__m128i
foo2 (int x1, int x2, int x3, int x4)
{
return _mm_set_epi32 (x1, x2, x3, x4);
}
[EMAIL PROTECTED] sse-1]$ make d.s
/export/build/gnu/gcc-stack-internal/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-stack-internal/build-x86_64-linux/gcc/ -msse4
-march=core2 -m3dnow -msse5 -maes -mpclmul -Wall -O2 -S d.c
[EMAIL PROTECTED] sse-1]$ cat d.s
.file d.c
.text
.p2align 4,,15
.globl foo2
.type foo2, @function
foo2:
.LFB518:
movd%edx, %xmm0
movd%edi, %xmm2
movd%ecx, %xmm1
punpckldq %xmm0, %xmm1
movd%esi, %xmm0
punpckldq %xmm2, %xmm0
movq%xmm1, %xmm2
punpcklqdq %xmm0, %xmm2
movdqa %xmm2, %xmm0 --- Can we optimize it out?
ret
--
Summary: x86 fails to optimize out __v4si - __m128i move
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36222
[Bug target/36090] [4.3/4.4 Regression] ppc64 cacoshl miscompilation
--- Comment #35 from bonzini at gnu dot org 2008-05-12 15:50 --- so you prefer to leave my fix (possibly amended in 4.4+)? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36090
[Bug fortran/36176] TRANSFER of constant substrings
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2008-05-12 15:52 --- Subject: Bug 36176 Author: fxcoudert Date: Mon May 12 15:51:27 2008 New Revision: 135219 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=135219 Log: PR fortran/36176 * target-memory.c (gfc_target_expr_size): Correctly treat substrings. (gfc_target_encode_expr): Likewise. (gfc_interpret_complex): Whitespace change. * gfortran.dg/transfer_simplify_9.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/transfer_simplify_9.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/target-memory.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36176
[Bug target/36222] x86 fails to optimize out __v4si - __m128i move
--- Comment #1 from hjl dot tools at gmail dot com 2008-05-12 15:57 --- Also do we need movq%xmm1, %xmm2? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36222
[Bug ada/36001] $(GNATMAKE) not defined with 'cd gcc make'
--- Comment #1 from bonzini at gnu dot org 2008-05-12 16:25 --- Subject: Bug 36001 Author: bonzini Date: Mon May 12 16:25:07 2008 New Revision: 135220 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=135220 Log: 2008-05-12 Samuel Tardieu [EMAIL PROTECTED] Paolo Bonzini [EMAIL PROTECTED] PR ada/36001 * acx.m4: Add optional parameter to ACX_PROG_GNAT. gcc: 2008-05-12 Samuel Tardieu [EMAIL PROTECTED] Paolo Bonzini [EMAIL PROTECTED] PR ada/36001 * Makefile.in: Substitute GNATMAKE and GNATBIND. * configure.ac: Add call to ACX_PROG_GNAT. Modified: trunk/config/ChangeLog trunk/config/acx.m4 trunk/gcc/ChangeLog trunk/gcc/Makefile.in trunk/gcc/configure trunk/gcc/configure.ac -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36001
[Bug ada/36001] $(GNATMAKE) not defined with 'cd gcc make'
--- Comment #2 from bonzini at gnu dot org 2008-05-12 16:27 --- thanks, fixed! -- bonzini at gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36001
[Bug target/36090] [4.3/4.4 Regression] ppc64 cacoshl miscompilation
--- Comment #36 from dje at gcc dot gnu dot org 2008-05-12 16:32 --- Yes, I suggest keeping the simplify_plus_minus change with the CONST wrapper removed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36090
[Bug middle-end/26635] [4.3/4.4 regression] bogus Storage_Error warning
--- Comment #9 from ebotcazou at gcc dot gnu dot org 2008-05-12 16:42 --- Testcase for mainline to be attached, same underlying problem. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added URL|http://gcc.gnu.org/ml/gcc- | |patches/2006- | |04/msg00080.html| Status|RESOLVED|REOPENED Resolution|WONTFIX | Summary|[4.1 regression] Bogus |[4.3/4.4 regression] bogus |Storage_Error warning |Storage_Error warning http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26635
[Bug middle-end/26635] [4.3/4.4 regression] bogus Storage_Error warning
--- Comment #10 from ebotcazou at gcc dot gnu dot org 2008-05-12 16:43 --- Created an attachment (id=15630) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15630action=view) New reduced Ada testcase. [EMAIL PROTECTED]:~/build/gcc/native32 gcc/xgcc -Bgcc -S p.adb -I gcc/ada/rts p.adb:20:14: warning: Storage_Error will be raised at run-time [EMAIL PROTECTED]:~/build/gcc/native32 gcc/xgcc -v Using built-in specs. Target: i586-suse-linux Configured with: /home/eric/svn/gcc/configure i586-suse-linux --prefix=/home/eric/install/gcc --with-as=/home/eric/build/binutils-2_18-branch/native32/gas/as-new --with-ld=/home/eric/build/binutils-2_18-branch/native32/ld/ld-new --enable-languages=c,c++,ada --enable-checking=yes,rtl --enable-__cxa_atexit --disable-nls--disable-libmudflap Thread model: posix gcc version 4.4.0 20080506 (experimental) [trunk revision 134981] (GCC) -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Attachment #11016|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26635
[Bug middle-end/26635] [4.3/4.4 regression] bogus Storage_Error warning
--- Comment #11 from ebotcazou at gcc dot gnu dot org 2008-05-12 16:44 --- I'll do something in Gigi. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ebotcazou at gcc dot gnu dot |dot org |org Status|REOPENED|ASSIGNED Last reconfirmed|2006-09-12 11:43:28 |2008-05-12 16:44:37 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26635
[Bug target/36090] [4.3/4.4 Regression] ppc64 cacoshl miscompilation
--- Comment #37 from bonzini at gnu dot org 2008-05-12 16:48 --- Ok, I started a bootstrap of the obvious patch on i686-pc-linux-gnu. But I think the obvious patch is not enough if we go this way. The comments in simplify_plus_minus are already not up-to-date, and removing CONST is interesting enough that the comment should be updated with clear explanations (e.g. based on the info H-P gave in PR36182). Would you please do so since you have better hold on this than I do? Otherwise, as I said, I have absolutely no problem going for the target-only fix in 4.4+ too. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36090
[Bug target/36090] [4.3/4.4 Regression] ppc64 cacoshl miscompilation
--- Comment #38 from dje at gcc dot gnu dot org 2008-05-12 16:51 --- I did update the comment when I applied the patch. I will work on this more when I return from travel next week. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36090
[Bug target/36090] [4.3/4.4 Regression] ppc64 cacoshl miscompilation
--- Comment #39 from bonzini at gnu dot org 2008-05-12 16:54 --- Ah, only on 4.3 branch. Ok, I'll go on from here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36090
[Bug rtl-optimization/36111] [4.4 Regression] GCC 4.4.0-20080501 failed to compile openmpi's malloc.c file.
--- Comment #10 from uros at gcc dot gnu dot org 2008-05-12 16:56 --- Subject: Bug 36111 Author: uros Date: Mon May 12 16:55:43 2008 New Revision: 135221 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=135221 Log: PR rtl-optimization/36111 * recog.c (validate_replace_rtx_1): Unshare new RTL expression that was created for swappable operands. testsuite/ChangeLog: PR rtl-optimization/36111 * gcc.dg/pr36111.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr36111.c Modified: trunk/gcc/ChangeLog trunk/gcc/recog.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36111
[Bug rtl-optimization/36111] [4.4 Regression] GCC 4.4.0-20080501 failed to compile openmpi's malloc.c file.
--- Comment #11 from ubizjak at gmail dot com 2008-05-12 16:58 --- Fixed. -- ubizjak at gmail dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36111
[Bug ada/36001] [4.3/4.4 regression] $(GNATMAKE) not defined with 'cd gcc make'
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2008-05-12 17:11 --- It's a regression from earlier versions (probably before toplevel bootstrap). Is the fix safe enough as to be backported to the 4.3 branch? -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org Summary|$(GNATMAKE) not defined with|[4.3/4.4 regression] |'cd gcc make'|$(GNATMAKE) not defined with ||'cd gcc make' http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36001
[Bug middle-end/36191] can't use complex in a eh region if non-call-exceptions is enabled
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2008-05-12 17:21 --- Though -fnon-call-exceptions really is only heavily used in java and java does not use complex types. It is heavily used in Ada as well, but Ada doesn't use complex types either. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36191
[Bug fortran/35937] Wrong type for charlength of function
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2008-05-12 17:44
---
It's not an issue limited to SCAN, it can happen to all functions (intrinsics
or not). Reduced testcase, showing the failure even without
-fdefault-integer-8:
program main
implicit none
print *, len(f5('1'))
contains
function f5 (c)
character(len=1_8) :: c
character(len=scan('123456789', c)) :: f5
end function f5
end program main
The problem is subtle: when the length of f5 is evaluated, it's done outside of
the body of f5 itself. And there, the string length variable is somehow set to
a integer(kind=8), as is specified by its original type. This is a failure in
the complicated mapping mechanism, and a nightmare to track, because we start
with the right type but something somewhere changes it under our feet. After a
long chase, I found it's gfc_finish_interface_mapping() that is not doing its
job properly, and the following patch fixes it:
Index: trans-expr.c
===
--- trans-expr.c(revision 135088)
+++ trans-expr.c(working copy)
@@ -1671,7 +1671,19 @@ gfc_finish_interface_mapping (gfc_interf
gfc_init_se (se, NULL);
gfc_conv_expr (se, expr);
- se.expr = gfc_evaluate_now (se.expr, se.pre);
+ /* Give the string length the right type. If we deal with a
+ simple constant, which is the most common case, we don't need
+ to create a temporary variable. */
+ if (CONSTANT_CLASS_P (se.expr))
+ se.expr = fold_convert (gfc_charlen_type_node, se.expr);
+ else
+ {
+ tree tmp = gfc_create_var (gfc_charlen_type_node, slength);
+ gfc_add_modify_expr (se.pre, tmp,
+fold_convert (gfc_charlen_type_node,
se.expr));
+ se.expr = tmp;
+ }
+
gfc_add_block_to_block (pre, se.pre);
gfc_add_block_to_block (post, se.post);
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keywords||patch
Last reconfirmed|-00-00 00:00:00 |2008-05-12 17:44:16
date||
Summary|char_result_5.f90 / |Wrong type for charlength of
|char_result_6.f90 fail with |function
|-fdefault-integer-8 |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35937
[Bug fortran/35937] Wrong type for charlength of function
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2008-05-12 17:44:16 |2008-05-12 17:44:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35937
[Bug fortran/35940] Array BACK ignored in INDEX intrinsic when other args scalar
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2008-05-12 18:02 --- Patch committed, fixed on mainline. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35940
[Bug fortran/35937] Wrong type for charlength of function
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|fxcoudert at gcc dot gnu dot|unassigned at gcc dot gnu |org |dot org URL||http://gcc.gnu.org/ml/gcc- ||patches/2008- ||05/msg00700.html Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35937
[Bug fortran/35937] Wrong type for charlength of function
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2008-05-12 17:44:23 |2008-05-12 18:26:50 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35937
[Bug rtl-optimization/36223] New: bad interaction between PRE/register allocation/reload
This is a missed-optimization bug. The following reduced test case illustrates
the problem. It doesn't do anything useful, but just compile it with
mipsisa32r2-elfoabi-gcc -S -mtune=24kc -G4096 -O2 example4.c
#define N 511
#define M 9
long A[N];
long B[N];
long AA[N];
long BB[N];
long tA;
long tB;
void foo (unsigned iterations)
{
unsigned loop_cnt;
static long *aLow;
static long *bLow;
static long *aHi;
static long *bHi;
static long n1;
static long n2;
static long l;
static long i;
static long j;
static long k;
for (loop_cnt = 0; loop_cnt iterations; loop_cnt ++) {
/* This is the loop we're interested in. */
for (i = 0; i N; i ++) {
AA[i] = A[i];
BB[i] = B[i];
}
/* The rest of this stuff is just here to add some context to the
outer loop. */
for (k = 1; k = M; k++) {
n1 = 1 k;
n2 = n1 1;
for (j = 0; j n2; j++) {
for (i = j; i N; i += n1) {
l = i + n2;
aLow = A[l];
bLow = B[l];
aHi = A[i];
bHi = B[i];
A[l] = *aHi - tA;
B[l] = *bHi - tB;
A[i] += tA;
B[i] += tB;
}
}
}
}
}
The -G option forces the global variables to use GP-relative addressing, which
involves an extra addition. Thus the first nested loop should be optimized as
if it were written:
{
long *t1 = AA;
long *t2 = A;
long *t3 = BB;
long *t4 = B;
for (i = 0; i N; i++) {
*t1 = *t2;
*t3 = *t4;
t1++; t2++; t3++; t4++;
}
}
In 4.3.1, though, it is producing code with GP-relative addressing inside the
loop, so that the loop body has 9 adds instead of 5. Mainline head does a
better job and at least pulls out the references to A and B (which also appear
in the second nested loop).
PRE is working fine, and pulling the invariant GP-relative addressing of all
four variables all the way out of the outer loop. However, this means the
lifetimes of the corresponding pseudo-registers span the entire outer loop, and
the register allocator is (correctly) giving priority to the more localized
pseudos in the more deeply nested loops that follow. Having failed to allocate
a hardware register to span the entire lifetime of the pseudos, reload stupidly
re-inserts the previously hoisted GP-relative address computation at the point
of reference, inside the first nested loop.
I think what is needed is more smarts to make it understand that it should try
allocating a register just around the inner loop if it can't get one for the
entire outer loop, before giving up. Any thoughts on where the best place for
this to happen would be? Can this be done entirely within the register
allocator or do we need another pass to identify places where we can
potentially shorten the lifetimes of pseudos?
While this example is specific to MIPS with the GP-relative addressing, I can
see that the underlying PRE/register allocation conflict is a more general
problem that probably crops up in lots of other code with similar structure of
outer-loop-containing-multiple-inner-loops.
-Sandra
--
Summary: bad interaction between PRE/register allocation/reload
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sandra at codesourcery dot com
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: mipsisa32r2-elfoabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36223
[Bug rtl-optimization/36223] bad interaction between PRE/register allocation/reload
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Keywords||missed-optimization, ra http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36223
[Bug rtl-optimization/36223] bad interaction between PRE/register allocation/reload
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-05-12 19:02 --- This sounds more like an IV issue rather than a PRE issue. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36223
[Bug target/36223] IV-opt is not optimal for mips
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-05-12 19:09 --- Actually this is an IV-opt issue rather than a RA/PRE issue. For GCC 4.1.1 targeting an internal PPC port, I get the following on the tree level at the end: L1:; D.2011 = (long int *) ivtmp.92; MEM[base: AA, index: D.2011] = MEM[base: A, index: D.2011]; MEM[base: BB, index: D.2011] = MEM[base: B, index: D.2011]; ivtmp.92 = ivtmp.92 + 4B; if (ivtmp.92 != 2044B) goto L1; else goto L49; Which should show that this is IV-opts issue rather than a PRE issue at all. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|rtl-optimization|target Summary|bad interaction between |IV-opt is not optimal for |PRE/register|mips |allocation/reload | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36223
[Bug target/36223] IV-opt is not optimal for mips
--- Comment #3 from sandra at codesourcery dot com 2008-05-12 19:10 --- One other tidbit: the MIPS SDE 3.4.4-based toolchain produced the desired code for this test case. It's really a 4.* regression, not an enhancement. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36223
[Bug target/36222] x86 fails to optimize out __v4si - __m128i move
--- Comment #2 from ubizjak at gmail dot com 2008-05-12 19:23 ---
(In reply to comment #1)
Also do we need movq%xmm1, %xmm2?
We can help RA a bit by emitting RTL sequence that requires less pseudos.
Index: i386.c
===
--- i386.c (revision 135220)
+++ i386.c (working copy)
@@ -23859,14 +23859,14 @@
/* For V4SF and V4SI, we implement a concat of two V2 vectors.
Recurse to load the two halves. */
+ op1 = gen_reg_rtx (half_mode);
+ v = gen_rtvec (2, XVECEXP (vals, 0, 2), XVECEXP (vals, 0, 3));
+ ix86_expand_vector_init (false, op1, gen_rtx_PARALLEL (half_mode, v));
+
op0 = gen_reg_rtx (half_mode);
v = gen_rtvec (2, XVECEXP (vals, 0, 0), XVECEXP (vals, 0, 1));
ix86_expand_vector_init (false, op0, gen_rtx_PARALLEL (half_mode, v));
- op1 = gen_reg_rtx (half_mode);
- v = gen_rtvec (2, XVECEXP (vals, 0, 2), XVECEXP (vals, 0, 3));
- ix86_expand_vector_init (false, op1, gen_rtx_PARALLEL (half_mode, v));
-
use_vec_concat = true;
}
break;
@@ -23883,10 +23883,10 @@
if (use_vec_concat)
{
+ if (!register_operand (op1, half_mode))
+ op1 = force_reg (half_mode, op1);
if (!register_operand (op0, half_mode))
op0 = force_reg (half_mode, op0);
- if (!register_operand (op1, half_mode))
- op1 = force_reg (half_mode, op1);
emit_insn (gen_rtx_SET (VOIDmode, target,
gen_rtx_VEC_CONCAT (mode, op0, op1)));
This patch will produce:
_mm_set_epi32:
.LFB2:
movd%edi, %xmm0
movd%esi, %xmm1
movd%edx, %xmm2
punpckldq %xmm0, %xmm1
movd%ecx, %xmm0
punpckldq %xmm2, %xmm0
punpcklqdq %xmm1, %xmm0
ret
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36222
[Bug target/36224] New: vec_widen_smult_{hi,lo}_v4si generates pmuludq instruction
The vec_widen_smult_{hi,lo}_v4si functions are incorrect, in that they generate
the pmuludq instruction, which does a 32x32-64 unsigned multiply. For
example, multiplying -13 * 15 = gives 64424509245 with the current code, when
it should give -195.
The sse5 instructions pmacsdqh and pmacsdql could do this instruction, but not
anything in the standard sse2 set.
--
Summary: vec_widen_smult_{hi,lo}_v4si generates pmuludq
instruction
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gnu at the-meissners dot org
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=36224
[Bug target/36224] vec_widen_smult_{hi,lo}_v4si generates pmuludq instruction
--- Comment #1 from gnu at the-meissners dot org 2008-05-12 20:00 --- Created an attachment (id=15631) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15631action=view) Test case for bug 36224 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36224
[Bug testsuite/36057] [4.4 Regression] struct-layout-1_generate.c uses non-ISO C '%n$' operand number formats
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-05-12 20:41 --- I saw this too. -- 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 |2008-05-12 20:41:24 date|| Summary|struct-layout-1_generate.c |[4.4 Regression] struct- |uses non-ISO C '%n$' |layout-1_generate.c uses |operand number formats |non-ISO C '%n$' operand ||number formats Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36057
[Bug testsuite/36057] [4.4 Regression] struct-layout-1_generate.c uses non-ISO C '%n$' operand number formats
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-05-12 20:41 --- (In reply to comment #3) I saw this too. On cygwin. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added GCC build triplet|i686-pc-mingw32 | GCC host triplet|i686-pc-mingw32 | GCC target triplet|i686-pc-mingw32 | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36057
[Bug testsuite/36057] [4.3/4.4 Regression] struct-layout-1_generate.c uses non-ISO C '%n$' operand number formats
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.4 Regression] struct-|[4.3/4.4 Regression] struct- |layout-1_generate.c uses |layout-1_generate.c uses |non-ISO C '%n$' operand |non-ISO C '%n$' operand |number formats |number formats Target Milestone|4.4.0 |4.3.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36057
[Bug ada/16087] Legal program rejected, RM 7.3(13)
--- Comment #2 from sam at gcc dot gnu dot org 2008-05-12 21:06 --- This has been fixed in SVN trunk (135230). -- sam at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 Version|3.4.0 |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16087
[Bug target/36225] New: Gcc doesn't mangle fastcall
MS compiler mangles fastcall function names. For void foo (int i): In C++, it is mangled as 1. Wth fastcall: ?foo@@[EMAIL PROTECTED] ^ This an additional I. 2. Without fastcall: ?foo@@[EMAIL PROTECTED] In C, it is mangled as 1. With fastcall: @[EMAIL PROTECTED] 2. Without fastcall: _foo Gcc doesn't mangle fastcall. -- Summary: Gcc doesn't mangle fastcall Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl dot tools at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36225
[Bug target/36225] Gcc doesn't mangle fastcall
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-05-12 21:16 --- GCC does mangle it for win32 based targets, just not gnu/linux. Do you want the mangling for GNU/Linux also? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36225
[Bug ada/36001] [4.3/4.4 regression] $(GNATMAKE) not defined with 'cd gcc make'
--- Comment #4 from sam at gcc dot gnu dot org 2008-05-12 21:21 --- The fix is probably safe, but someone should apply Ralf's patch as well on this branch and check that it builds fine with and without an Ada compiler around (I'm not volunteering). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36001
[Bug ada/33457] Renaming in context of ragged array
--- Comment #5 from sam at gcc dot gnu dot org 2008-05-12 21:24 --- Indeed, I missed the not in your message :) This is great news. Closing. -- sam at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Known to work||4.3.0 Resolution||FIXED Target Milestone|--- |4.3.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33457
[Bug ada/35372] Memory corruption at unchecked deallocation of the interface classwide type
--- Comment #4 from charlet at gcc dot gnu dot org 2008-05-12 21:54 --- Lowering severity -- charlet at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35372
[Bug fortran/35685] UBOUND incorrect for run-time zero-sized section
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot |dot org |org URL||http://gcc.gnu.org/ml/gcc- ||patches/2008- ||05/msg00714.html Status|NEW |ASSIGNED Keywords||patch Last reconfirmed|2008-03-24 22:11:36 |2008-05-12 21:56:55 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35685
[Bug ada/33889] Inefficient code expansion for extended return statement
--- Comment #1 from charlet at gcc dot gnu dot org 2008-05-12 22:05 --- This is not accessibility level which is computed here, but dynamic task master level, in case your interface is a synchronized interface. You can already use pragma Restrictions (No_Task_Hierarchy) if you do not want this code expansion. Arno -- charlet at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33889
[Bug ada/18302] ACATS tests hang: c74004a, c960004, and others
--- Comment #20 from charlet at gcc dot gnu dot org 2008-05-12 22:19 --- This PR is puzzling and confused: the original issue (tests failing on some platform) has been addressed. The new issue which seem the be keeping this PR opened is the ability to run ACATS tests using expect to have a timeout. A patch has been committed to various branches but not under trunk, for no apparent reason. So I am closing this PR on the grounds that the original issue is fixed. In addition, if someone wants to commit/submit the expect change on trunk, it's certainly fine with me. The last report about mingw also has nothing to do with the original report, so should be reported separately (although reporting that n acats tests fail under the same PR is not very helpful since each case may be different). Arno -- charlet at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED Target Milestone|--- |4.3.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18302
[Bug ada/22601] GNAT Command lists many commands as available that are not
--- Comment #3 from charlet at gcc dot gnu dot org 2008-05-12 22:26 --- You do not need to build/install asis to use some of these commands, but that does not make gnatcmd.adb wrong here. In other words, you are assuming that gnatcmd.adb should only refer to tools that come with GCC, which is incorrect. Similarly to e.g. collect2 which calls ld and sometimes objdump, even though ld or objdump are not part of gcc. Arno -- charlet at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22601
[Bug ada/34717] Ada runtime improvements for OpenBSD to enable tasking and related features
--- Comment #3 from charlet at gcc dot gnu dot org 2008-05-12 22:31 --- I'd suggest updating your patch to latest sources, and submit it to gcc-patches, that's the standard procedure. Also, it would be useful to have some kind of commitment from either someone or from soem identified group of people that these files will be tested and maintained in the future, otherwise there's no much point in doing a code drop, and then have the files break silently without people noticing. Arno -- charlet at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34717
[Bug ada/35886] Bad location of error message
--- Comment #1 from charlet at gcc dot gnu dot org 2008-05-12 22:34 --- Well, I must be blind, but I do not see a bad location here: GNAT complains at line 3 that the full declaration defined at line 4 must be tagged, showing indeed the line where type T is declared as tagged. Looks correct to me. Arno -- charlet at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35886
[Bug ada/35789] Ada2WSDL
--- Comment #2 from charlet at gcc dot gnu dot org 2008-05-12 22:35 --- No information, not even a GCC version, so closing. Please reopen once you have more info to feed. Arno -- charlet at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35789
[Bug ada/35464] warning: condition is always False not issued inside generics
--- Comment #3 from charlet at gcc dot gnu dot org 2008-05-12 22:38 --- Right, this is really as intended, to avoid too many false positives. The warning circuitry is not prepared to handle more complex cases, which would require really a different kind of tool, so is out of the scope of the front-end. Arno -- charlet at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35464
[Bug ada/35066] GNAT BUG DETECTED in get_indirect_ref_operands, at tree-ssa-operands.c:1476A
--- Comment #2 from charlet at gcc dot gnu dot org 2008-05-12 22:40 --- No feedback. Note that I suspect GCC 4.3/4.4 build current polyorb fine, so closing this PR. -- charlet at gcc dot gnu dot org changed: What|Removed |Added Severity|major |normal Status|WAITING |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35066
[Bug ada/35284] Branch to 0x0 from Ada run-time
--- Comment #39 from charlet at gcc dot gnu dot org 2008-05-12 22:43 --- Fixed on trunk. Patch pre-approved on active branches if deemed necessary. -- charlet at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35284
[Bug ada/35886] Bad location of error message
--- Comment #2 from sam at gcc dot gnu dot org 2008-05-12 22:43 --- I expect the error message to point at the full declaration itself, not the partial view, as the partial view had been analyzed correctly and had no error so far. When it says full declaration of type T declared at XXX, I expect XXX to designate the partial view, not the other way around. To take a similar situation, consider: package T is X : constant Integer; private X : constant Float := 3.0; end T; GNAT gives the error: 4.X : constant Float := 3.0; | type does not match declaration at line 2 and not: 2.X : constant Integer; | type doesn't match declaration at line 4 I think this is an anomaly, as this doesn't match the behaviour of GNAT in other similar cases (a completion of a declaration not fullfilling the initial promise). -- sam at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35886
[Bug tree-optimization/36226] New: Optimization corrupts volatile function pointer return handling
When using a volatile function pointer and compiling with -O2 optimization, the resulting program will not correctly return from the function pointer but will instead jump to another point of the program. I have been able to reproduce this behavior with gcc 3.4.6, 4.0.2 and the x86 locally hosted 4.1.1 version of gcc. Originally the bug was discovered with: $ powerpc-603-linux-gnu-gcc -v Reading specs from /opt/crosstool/gcc-3.4.5-glibc-2.3.6/powerpc-603-linux-gnu/lib/gcc/powerpc-603-linux-gnu/3.4.5/specs Configured with: /home/mbenedict/src/crosstool-0.43/build/powerpc-603-linux-gnu/gcc-3.4.5-glibc-2.3.6/gcc-3.4.5/configure --target=powerpc-603-linux-gnu --host=i686-host_pc-linux-gnu --prefix=/opt/crosstool/gcc-3.4.5-glibc-2.3.6/powerpc-603-linux-gnu --with-cpu=603 --enable-cxx-flags=-mcpu=603 --with-headers=/opt/crosstool/gcc-3.4.5-glibc-2.3.6/powerpc-603-linux-gnu/powerpc-603-linux-gnu/include --with-local-prefix=/opt/crosstool/gcc-3.4.5-glibc-2.3.6/powerpc-603-linux-gnu/powerpc-603-linux-gnu --disable-nls --enable-threads=posix --enable-symvers=gnu --enable-__cxa_atexit --enable-languages=c --enable-shared --enable-c99 --enable-long-long Thread model: posix gcc version 3.4.5 I will attach the .i file that reproduces this condition in the first comment (I can't seem to attach from the new bug screen). -- Summary: Optimization corrupts volatile function pointer return handling Product: gcc Version: 3.4.5 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mbenedict at aclaratech dot com GCC build triplet: i686-pc-linux-gnu GCC host triplet: powerpc-603-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36226
[Bug ada/33820] Compilation error for macrosub
--- Comment #4 from charlet at gcc dot gnu dot org 2008-05-12 22:47 --- There are really not enough info to guess what is going wrong for sure. It is indeed likely the same as PR29127, so closing on that grounds. Please give me info if you think this is a different issue, thanks. Arno *** This bug has been marked as a duplicate of 29127 *** -- charlet at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33820
[Bug ada/29127] gnatchop-gcc: installation problem, executable not found
--- Comment #6 from charlet at gcc dot gnu dot org 2008-05-12 22:47 --- *** Bug 33820 has been marked as a duplicate of this bug. *** -- charlet at gcc dot gnu dot org changed: What|Removed |Added CC||Markus dot Elfring at web ||dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29127
[Bug tree-optimization/36226] Optimization corrupts volatile function pointer return handling
--- Comment #1 from mbenedict at aclaratech dot com 2008-05-12 22:48 --- Created an attachment (id=15632) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15632action=view) File that reproduces the problem Note also that when optimizing (-O2) the assembly comment # XXX - This assembly line is missing when optimized goes away -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36226
[Bug tree-optimization/36226] Optimization corrupts volatile function pointer return handling
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-05-12 22:49 --- volatile here means no return and no standard C meaning IIRC. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36226
[Bug testsuite/32547] gnat.dg tasking tests fail on IRIX 5.3
--- Comment #2 from charlet at gcc dot gnu dot org 2008-05-12 22:49 --- it's a testsuite/infrastructure issue rather than an Ada issue per se. Arno -- charlet at gcc dot gnu dot org changed: What|Removed |Added Component|ada |testsuite http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32547
[Bug ada/35886] Bad location of error message
--- Comment #3 from charlet at gcc dot gnu dot org 2008-05-12 22:54 --- OK, classifying as an enhancement request, since there's no bug here, the error message is correct. -- charlet at gcc dot gnu dot org changed: What|Removed |Added Severity|minor |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35886
[Bug ada/35886] Bad location of error message
--- Comment #4 from sam at gcc dot gnu dot org 2008-05-12 23:01 --- Given that this happens when currently analyzing Id (and not Prev), posting the error message on Prev instead of Id may be an historical typo (inversion between both parameters in the call to Error_Msg_NE). For example, in the message Error_Msg_NE ( full declaration of } must be a record extension, Prev, Id); it seems more logical to print full declaration of type name defined at ... must be a record extension and have the error point to the full view rather than the opposite. And if you look at the way the error message is expanded, you clearly see that type name defined at ... comes together as one sole entity, namely }, so the grouping is full declaration of (type name defined at ...) must be a record extension rather than (full declaration of type name) defined at ... must be a record extension. And the error location (where the error is posted) already gives a primary location which I expect to be the problematic one. So I'm not sure this should be classified as an enhancement request only, as the grouping due to the expansion of } shows an anomaly. Anyway, a trivial patch has been proposed already, waiting for your approval. -- sam at gcc dot gnu dot org changed: What|Removed |Added Severity|enhancement |minor http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35886
[Bug ada/15479] Ada manual problems
--- Comment #11 from charlet at gcc dot gnu dot org 2008-05-12 23:11 --- This PR seems to be addressed at this point. -- charlet at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15479
[Bug fortran/35682] assignment to run-time zero-sized complex section stores a value
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2008-05-12 23:15
---
Well, that one is subtle, but I think I found it: it's a TRUNC_DIV_EXPR that
should be a FLOOR_DIV_EXPR in gfc_conv_loop_setup(). That simple fix makes all
testcases in this PR run, except when -fbounds-check is added. To fix
-fbounds-check, we need to correctly make all zero-sized section zero-sized,
and not any-negative-sized, which is done by two appropriate MAX_EXPR. The
complete patch is thus:
Index: trans-array.c
===
--- trans-array.c (revision 135088)
+++ trans-array.c (working copy)
@@ -3083,6 +3083,8 @@ gfc_conv_ss_startstride (gfc_loopinfo *
info-start[n]);
tmp = fold_build2 (FLOOR_DIV_EXPR, gfc_array_index_type, tmp,
info-stride[n]);
+ tmp = fold_build2 (MAX_EXPR, gfc_array_index_type, tmp,
+build_int_cst (gfc_array_index_type, 0));
/* We remember the size of the first section, and check all the
others against this. */
if (size[n])
@@ -3435,8 +3437,10 @@ gfc_conv_loop_setup (gfc_loopinfo * loop
for (i = 0; i=last; i++){...}; */
tmp = fold_build2 (MINUS_EXPR, gfc_array_index_type,
loop-to[n], loop-from[n]);
- tmp = fold_build2 (TRUNC_DIV_EXPR, gfc_array_index_type,
+ tmp = fold_build2 (FLOOR_DIV_EXPR, gfc_array_index_type,
tmp, info-stride[n]);
+ tmp = fold_build2 (MAX_EXPR, gfc_array_index_type, tmp,
+build_int_cst (gfc_array_index_type, -1));
loop-to[n] = gfc_evaluate_now (tmp, loop-pre);
/* Make the loop variable start at 0. */
loop-from[n] = gfc_index_zero_node;
Bootstraps OK, I've started regtesting.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot
|dot org |org
Status|NEW |ASSIGNED
Last reconfirmed|2008-03-25 16:37:47 |2008-05-12 23:15:08
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35682
[Bug ada/31808] cross-built gnattools installs vxaddr2line regardless of target triplet
--- Comment #1 from charlet at gcc dot gnu dot org 2008-05-12 23:23 --- It will install it only if it was built (there's an explicit test), and it won't build it for e.g. non vxworks, so things are fine here. Arno -- charlet at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31808
[Bug ada/34358] Dynamic library created in Object_Dir instead of Library_Dir in *-darwin*
--- Comment #2 from charlet at gcc dot gnu dot org 2008-05-12 23:26 --- This is fixed on mainline, where a similar patch has been applied. Arno -- charlet at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34358
[Bug ada/19959] [4.1/4.2/4.3/4.4 Regression] Can't compile gnattools for the cross targets
--- Comment #16 from charlet at gcc dot gnu dot org 2008-05-12 23:35 --- After reviewing this ticket, I am coming to the conclusion that things are working as expected now: due to major changes in the gcc directory structure and makefiles, when you do a make, GCC will always build gnatlib and gnattools, so things are working as expected, except that gnatlib is not working on AVR (which is a different issue). The fix I made to gnattools-cross is still good: gnattools-cross does not depend on gnatlib, unlike the native case. Arno -- charlet at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19959
[Bug ada/31808] cross-built gnattools installs vxaddr2line regardless of target triplet
--- Comment #2 from sam at gcc dot gnu dot org 2008-05-12 23:41 --- it won't build it for e.g. non vxworks, so things are fine here. Are you sure of that? Because it has been built in my April 29 build of a cross-compiler targetting sh4-unknown-linux-gnu (from i686-pc-linux-gnu). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31808
[Bug ada/29127] gnatchop-gcc: installation problem, executable not found
--- Comment #7 from charlet at gcc dot gnu dot org 2008-05-12 23:42 --- Turns out that this PR is the same as PR864 *** This bug has been marked as a duplicate of 864 *** -- charlet at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29127
[Bug ada/864] --program-suffix is ignored (for ada)
--- Comment #7 from charlet at gcc dot gnu dot org 2008-05-12 23:42 --- *** Bug 29127 has been marked as a duplicate of this bug. *** -- charlet at gcc dot gnu dot org changed: What|Removed |Added CC||schwab at suse dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=864
[Bug target/36225] Gcc doesn't mangle fastcall
--- Comment #2 from hjl dot tools at gmail dot com 2008-05-12 23:48 --- (In reply to comment #1) GCC does mangle it for win32 based targets, just not gnu/linux. Do you want the mangling for GNU/Linux also? Since gcc doesn't mangle regparm, I don't know if gcc should mangle fastcall. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36225
[Bug ada/31808] cross-built gnattools installs vxaddr2line regardless of target triplet
--- Comment #3 from charlet at gcc dot gnu dot org 2008-05-12 23:58 --- Subject: Bug 31808 Author: charlet Date: Mon May 12 23:58:11 2008 New Revision: 135239 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=135239 Log: PR ada/31808 * Makefile.in (gnattools-cross): Do not build vxaddr2line Modified: trunk/gnattools/ChangeLog trunk/gnattools/Makefile.in -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31808
[Bug ada/31808] cross-built gnattools installs vxaddr2line regardless of target triplet
--- Comment #4 from charlet at adacore dot com 2008-05-13 00:01 --- Subject: Re: cross-built gnattools installs vxaddr2line regardless of target triplet Are you sure of that? Because it has been built in my April 29 build of a cross-compiler targetting sh4-unknown-linux-gnu (from i686-pc-linux-gnu). Darn, I always forget about the new gnattools/Makefile.in file, which does indeed build wrongly vxaddr2line. Now fixed. Arno -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31808
[Bug libgcj/36218] [4.4 regression] libgcj causes stack overflow in jc1.exe
--- Comment #2 from dannysmith at users dot sourceforge dot net 2008-05-13 03:52 --- (In reply to comment #0) What negative consequences does increasing the default [stack] allocation have? Minimal really, for a single threaded program like jc1.exe. We are just reserving address space not actual memory. In a multithreaded app, each thread reserves the same amount of address space as the primary thread (by default, but the default can be overiden), so too high a stack reserve for main thread can limit what is available for others. Is it possible to adjust this limit at runtime, perhaps as needed? No, not for main thread. It is built into the program header on MS windows. GNAT also bumps stack reserve to 32 MB for non-tasking apps. See system-mingw.ads. In old days, 32 MB was default for win32 in gnu ld. Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36218
[Bug rtl-optimization/36111] [4.4 Regression] GCC 4.4.0-20080501 failed to compile openmpi's malloc.c file.
--- Comment #12 from linuxl4 at sohu dot com 2008-05-13 05:39 --- I compiled openmpi 1.2.6 today, gcc 20080512 works fine. thanks! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36111
