[Bug ada/35194] floating point truncation error on intel platform
--- Comment #11 from k-tsubota at ap dot jp dot nec dot com 2009-10-19 06:35 --- I wonder if the bug is caused by errata of core2duo processor because the bug was only reproduced on core2duo and pentium D. (- not on UltraSPARC III) Intel Core2duo processor has errata in its FPU - Errata AI20, AI38 (*1). And, the processor has workarounds of the errata. If these workaround was not implemented in the GCC version, the bug might be caused by these errata. And, Intel Celeron M processor also has similar errata - Errata W34, W56 (*2). - (*1) Core2duo processor Specification Update - http://download.intel.com/design/processor/specupdt/313279.pdf - Errata AI20,AI38 - (*2) Celeron M processor Specification Update - http://download.intel.com/design/mobile/SPECUPDT/300303.pdf - Errata W34,W56 - -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35194
[Bug preprocessor/41748] New: Continued lines are not merged into one long line
This is a testcase (a space before a backslash or after a newline, and two pairs of quotes (or no quotes at all), are important): hello, \ world In GCC 4.5.0 20091015, preprocessor produces this: # 1 stdin # 1 built-in # 1 command-line # 1 stdin hello, world whereas older GCC versions give this: # 1 stdin # 1 built-in # 1 command-line # 1 stdin hello, world Such a new behavior seems to be in contradiction with what the documentation says: the backslash is removed and the following line is joined with the current one. -- Summary: Continued lines are not merged into one long line Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: d dot g dot gorbachev at gmail dot com GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41748
[Bug c/41749] New: non-needed instructions are not removed (not optimized)
int main (void) {return 1; }
Ubuntu Jaunty.
gcc --save-temps -fno-stack-protector -fomit-frame-pointer -Os ./cpuid.c
generates thgis:
--
main:
leal4(%esp), %ecx
andl$-16, %esp
pushl -4(%ecx)
movl$1, %eax
pushl %ecx
popl%ecx
leal-4(%ecx), %esp
ret
--
why i get this:
pushl %ecx
popl%ecx
and other non-needed instructions (for another example)
pushl %ebp
andl$1, %eax
movl%esp, %ebp
pushl %ecx
popl%ecx
popl%ebp
These instructions are not optimized not in -O3, nor in -Os
--
Summary: non-needed instructions are not removed (not optimized)
Product: gcc
Version: 4.3.3
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: socketpair at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41749
[Bug c/41749] non-needed instructions are not removed (not optimized)
--- Comment #1 from socketpair at gmail dot com 2009-10-19 07:14 --- gcc322 generates this: (gcc -Os -fomit-frame-pointer qwe.c --save-temps) main: movl$1, %eax ret WTF? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41749
[Bug c++/37204] [c++0x] reinterpret_castT(v) incorrectly yields an lvalue
--- Comment #7 from jason at gcc dot gnu dot org 2009-10-19 07:41 --- Thanks, though that's not a regression, that's the new PR37204 testcase. The execution test is testing direct binding, which is a separate issue that isn't fixed in 4.4 yet, so I've just disabled the execution test on the 4.4 branch for now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37204
[Bug preprocessor/41748] Continued lines are not merged into one long line
--- Comment #1 from jakub at gcc dot gnu dot org 2009-10-19 08:13 --- The lines are joined into a logical line, that's what the C standard requires. But where do you see requirement that everything on one logical line has to appear on the line in preprocessed output? The reason it is emitted on the next line is to give the second string literal token proper location. The tokens are separate and a compiler compiles both foo bar and foo bar the same (as it doesn't record the line numbers for the string literals at all). See PR41445 for why this change has been made. If you care about this because you use the preprocessed output for something else, consider using -P option. That says you don't care about token locations. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41748
[Bug c/41750] New: gcc 4.50 miscompiles binutils
gcc trunk revision 152931 miscompiles cross binutils x86_64-unknown-linux-gnu
to ia64-unknown-linux-gnu.
Detected during build of cross compiler x86_64-unknown-linux-gnu to
ia64-unknown-linux-gnu. ia64-unknown-linux-gnu-ld segfaults by linking a simple
conftest.
configure:2368: checking for C compiler default output file name
configure:2390: /SCRATCH/tmp.rXGZe12682/gcc-4.5.0/gcc-4.5.0/./gcc/xgcc
-B/SCRATCH/tmp.rXGZe12682/gcc-4.5.0/gcc-4.5.0/./gcc/
-B/opt/devel/gnu/cross-gcc/Linux/x86_64-unknown-linux-gnu/openSUSE_10.3/cross/Linux/i
a64-unknown-linux-gnu/SLC_4.7/gcc-4.5.0/ia64-unknown-linux-gnu/bin/
-B/opt/devel/gnu/cross-gcc/Linux/x86_64-unknown-linux-gnu/openSUSE_10.3/cross/Linux/ia64-unknown-linux-gnu/SLC_4.7/gcc-4.5.0/ia64-unknown-lin
ux-gnu/lib/ -isystem
/opt/devel/gnu/cross-gcc/Linux/x86_64-unknown-linux-gnu/openSUSE_10.3/cross/Linux/ia64-unknown-linux-gnu/SLC_4.7/gcc-4.5.0/ia64-unknown-linux-gnu/include
-isystem /opt/devel/gnu/cross-gcc/
Linux/x86_64-unknown-linux-gnu/openSUSE_10.3/cross/Linux/ia64-unknown-linux-gnu/SLC_4.7/gcc-4.5.0/ia64-unknown-linux-gnu/sys-include
conftest.c 5
collect2: ld terminated with signal 11 [Segmentation fault]
configure:2394: $? = 1
configure:2431: result:
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME
| #define PACKAGE_TARNAME
| #define PACKAGE_VERSION
| #define PACKAGE_STRING
| #define PACKAGE_BUGREPORT
| #define PACKAGE_URL
| /* end confdefs.h. */
|
| int
| main ()
| {
|
| ;
| return 0;
| }
verbose output:
rai...@kasandra-lx:/SCRATCH/tmp.rXGZe12682/gcc-4.5.0/gcc-4.5.0/ia64-unknown-linux-gnu/libada
ia64-unknown-linux-gnu-ld --verbose
--sysroot=/opt/devel/tec/setup/sys-root/Linux/ia64-unknown-linux-gnu/SLC_4.7
-dynamic-linker /lib/ld-linux-ia64.so.2
/opt/devel/tec/setup/sys-root/Linux/ia64-unknown-linux-gnu/SLC_4.7/usr/lib/crt1.o
/opt/devel/tec/setup/sys-root/Linux/ia64-unknown-linux-gnu/SLC_4.7/usr/lib/crti.o
/SCRATCH/tmp.rXGZe12682/gcc-4.5.0/gcc-4.5.0/./gcc/crtbegin.o
-L/SCRATCH/tmp.rXGZe12682/gcc-4.5.0/gcc-4.5.0/./gcc
-L/opt/devel/gnu/cross-gcc/Linux/x86_64-unknown-linux-gnu/openSUSE_10.3/cross/Linux/ia64-unknown-linux-gnu/SLC_4.7/gcc-4.5.0/ia64-unknown-linux-gnu/bin
-L/opt/devel/gnu/cross-gcc/Linux/x86_64-unknown-linux-gnu/openSUSE_10.3/cross/Linux/ia64-unknown-linux-gnu/SLC_4.7/gcc-4.5.0/ia64-unknown-linux-gnu/lib
-L/opt/devel/tec/setup/sys-root/Linux/ia64-unknown-linux-gnu/SLC_4.7/lib
-L/opt/devel/tec/setup/sys-root/Linux/ia64-unknown-linux-gnu/SLC_4.7/usr/lib
conftest.o -lgcc --as-needed -lgcc_s -lunwind --no-as-needed -lc -lgcc
--as-needed -lgcc_s -lunwind --no-as-needed
/SCRATCH/tmp.rXGZe12682/gcc-4.5.0/gcc-4.5.0/./gcc/crtend.o
/opt/devel/tec/setup/sys-root/Linux/ia64-unknown-linux-gnu/SLC_4.7/usr/lib/crtn.o
GNU ld (GNU Binutils) 2.20
Supported emulations:
elf64_ia64
using internal linker script:
==
/* Script for -z combreloc: combine and sort reloc sections */
OUTPUT_FORMAT(elf64-ia64-little, elf64-ia64-little,
elf64-ia64-little)
OUTPUT_ARCH(ia64)
ENTRY(_start)
SEARCH_DIR(=/usr/local/lib); SEARCH_DIR(=/lib); SEARCH_DIR(=/usr/lib);
SECTIONS
{
/* Read-only sections, merged into text segment: */
PROVIDE (__executable_start = SEGMENT_START(text-segment,
0x4000)); . = SEGMENT_START(text-segment, 0x4000) +
SIZEOF_HEADERS;
.interp : { *(.interp) }
.note.gnu.build-id : { *(.note.gnu.build-id) }
.
.
.
.
/* DWARF 3 */
.debug_pubtypes 0 : { *(.debug_pubtypes) }
.debug_ranges 0 : { *(.debug_ranges) }
.gnu.attributes 0 : { KEEP (*(.gnu.attributes)) }
/DISCARD/ : { *(.note.GNU-stack) *(.gnu_debuglink) *(.gnu.lto_*) }
}
==
attempt to open
/opt/devel/tec/setup/sys-root/Linux/ia64-unknown-linux-gnu/SLC_4.7/usr/lib/crt1.o
succeeded
/opt/devel/tec/setup/sys-root/Linux/ia64-unknown-linux-gnu/SLC_4.7/usr/lib/crt1.o
Segmentation fault (core dumped)
Backtrace:
Core was generated by `ia64-unknown-linux-gnu-ld --verbose
--sysroot=/opt/devel/tec/setup/sys-root/Lin'.
Program terminated with signal 11, Segmentation fault.
#0 0x0043f309 in elf64_ia64_check_relocs (abfd=value optimized out,
info=0x6f0d00, sec=value optimized out, relocs=value optimized out) at
elf64-ia64.c:1550
1550 if (s (s-flags SEC_LOAD))
(gdb) where
#0 0x0043f309 in elf64_ia64_check_relocs (abfd=value optimized out,
info=0x6f0d00, sec=value optimized out, relocs=value optimized out) at
elf64-ia64.c:1550
#1 0x0045cfa0 in bfd_elf_link_add_symbols (abfd=value optimized out,
info=value optimized out) at
/opt/devel/gnu/src/gcc/binutils-2.20/bfd/elflink.c:477
#2 0x in ?? ()
(gdb)
--
Summary: gcc 4.50 miscompiles binutils
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy:
[Bug fortran/41494] [4.5 Regression] temp and memcpy used when zeroing array
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-10-19 08:45 --- Subject: Bug 41494 Author: rguenth Date: Mon Oct 19 08:45:43 2009 New Revision: 152973 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=152973 Log: 2009-10-18 Richard Guenther rguent...@suse.de PR fortran/41494 * trans-expr.c (gfc_trans_scalar_assign): Do not call gfc_evaluate_now. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-expr.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41494
[Bug java/41356] Circular dependencies between jars cause errors: jars order shouldn't matter
--- Comment #1 from aph at gcc dot gnu dot org 2009-10-19 08:49 --- We need a standalone test case for this. Please cut the problem down to something fairly simple and cmplete. -- aph at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41356
[Bug java/41372] Symbols in shared library compiled from jar/classes should not be local with -findirect-dispatch
--- Comment #1 from aph at gcc dot gnu dot org 2009-10-19 08:55 --- This is a deliberate design decision. If you really need to refer to classes with dlsym, use -fno-indirect-classes. However, this has a number of restrictions: in particular it fixes the ABI to the specific libgcj that was used at compile time, thus requiring recompilation every time libgcj is updated. -- aph at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41372
[Bug target/41751] New: bad code with arrays as local vars and no optimization
static void R_EdgeDrawing (qboolean Translucent)
{
edge_t ledges[NUMSTACKEDGES + ((CACHE_SIZE - 1) / sizeof(edge_t)) + 1];
surf_t lsurfs[NUMSTACKSURFACES + ((CACHE_SIZE - 1) / sizeof(surf_t)) + 1];
..
(see attached r_main-1.i and r_main-1.s) is incorrectly compiled when
optimizations are turned off (no -O) with gcc-4.x series compilers on
x86_64. -O1, -O2, -O3 and -Os are fine with gcc-4.x, whereas gcc-3.4.6
(as shipped with fedora 10) is fine with or without optimizations.
If those vars are moved to the top of file as static (attached files
r_main-3.i and r_main-3.s), gcc-4.x up to gcc-4.4.3 behave correctly
without optimizations and the compiled program runs expectedly. gcc-3.4
is fine as before. gcc-4.5 is not tested.
--
Summary: bad code with arrays as local vars and no optimization
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sezeroz at gmail dot com
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=41751
[Bug target/41751] bad code with arrays as local vars and no optimization
--- Comment #1 from sezeroz at gmail dot com 2009-10-19 08:59 --- Created an attachment (id=18822) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18822action=view) failing preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41751
[Bug target/41751] bad code with arrays as local vars and no optimization
--- Comment #2 from sezeroz at gmail dot com 2009-10-19 09:00 --- Created an attachment (id=18823) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18823action=view) good preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41751
[Bug target/41751] bad code with arrays as local vars and no optimization
--- Comment #3 from sezeroz at gmail dot com 2009-10-19 09:01 --- Created an attachment (id=18824) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18824action=view) failing asm output -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41751
[Bug target/41751] bad code with arrays as local vars and no optimization
--- Comment #4 from sezeroz at gmail dot com 2009-10-19 09:01 --- Created an attachment (id=18825) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18825action=view) good asm output -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41751
[Bug java/41375] Compiling native executable without -findirect-dispatch causes random SEGVs
--- Comment #3 from aph at gcc dot gnu dot org 2009-10-19 09:01 ---
Works for me on GNU/Linux:
ClassNotFoundException: java.lang.ClassNotFoundException: my.other.class not
found in gnu.gcj.runtime.SystemClassLoader{urls=[file:./],
parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=null}}
Exception in thread main java.lang.ExceptionInInitializerError
at java.lang.Class.initializeClass(libgcj.so.10)
at MyProxy.main(a.out)
Caused by: java.lang.NullPointerException
at MyProxy.clinit(a.out)
at java.lang.Class.initializeClass(libgcj.so.10)
...1 more
--
aph at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||WORKSFORME
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41375
[Bug java/41745] Segmentation fault when ecj.jar is run as a binary compiled by gcj
--- Comment #1 from aph at gcc dot gnu dot org 2009-10-19 09:08 --- Works for me: $ gcj -o ecj --main=org.eclipse.jdt.internal.compiler.batch.Main /usr/share/java/ecj.jar $ ./ecj HelloWorld.java $ java HelloWorld Hello World! -- aph at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41745
[Bug java/41745] Segmentation fault when ecj.jar is run as a binary compiled by gcj
--- Comment #2 from yuri at tsoft dot com 2009-10-19 09:23 --- No, it doesn't work for me on FreeBSD-8.0: /usr/local/gcc/4.4.1-java/bin/gcj -o ecj --main=org.eclipse.jdt.internal.compiler.batch.Main /usr/local/share/java/ecj.jar LD_LIBRARY_PATH=/usr/local/gcc/4.4.1-java/lib ldd ./ecj ./ecj: libgcc_s.so.1 = /usr/local/gcc/4.4.1-java/lib/libgcc_s.so.1 (0x341ba000) libgcj.so.10 = /usr/local/gcc/4.4.1-java/lib/libgcj.so.10 (0x341c6000) libm.so.5 = /lib/libm.so.5 (0x363d9000) libthr.so.3 = /lib/libthr.so.3 (0x363f3000) librt.so.1 = /usr/lib/librt.so.1 (0x36408000) libc.so.7 = /lib/libc.so.7 (0x3640d000) LD_LIBRARY_PATH=/usr/local/gcc/4.4.1-java/lib ./ecj HelloWorld.java Segmentation fault: 11 backtrace: #0 0x364041c7 in __error () from /lib/libthr.so.3 #1 0x36403da8 in __error () from /lib/libthr.so.3 #2 0x36606820 in ?? () #3 0x0008 in ?? () #4 0x0001 in ?? () #5 0x36606800 in ?? () #6 0x in ?? () #7 0xbf9fedd4 in ?? () #8 0x363fe1a5 in pthread_rwlock_unlock () from /lib/libthr.so.3 #9 0x36401fae in pthread_cond_signal () from /lib/libthr.so.3 #10 0x34d217e8 in _Jv_CondWait (cv=0x3639778c, mu=0x36397780, millis=0, nanos=0) at ../../../gcc-4.4.1/libjava/posix-threads.cc:212 #11 0x8c34d070 in ?? () #12 0x3639778c in _ZL5mutex () from /usr/local/gcc/4.4.1-java/lib/libgcj.so.10 #13 0x36397780 in E () from /usr/local/gcc/4.4.1-java/lib/libgcj.so.10 #14 0x in ?? () #15 0x in ?? () #16 0x in ?? () #17 0x0001 in ?? () #18 0x341795a8 in dladdr () from /libexec/ld-elf.so.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41745
[Bug c++/41752] New: Canonical type with variadic templates and CRTP
CRTP does not seem to work together with variadic templates.
On a larger program, type canonization seems to be faulty and leads to a g++
crash.
Source code:
struct a {};
template typename T, typename ENCLOSING
struct base;
template typename ENCLOSING
struct base a, ENCLOSING
{};
template typename... T
struct derived
: public base T, derived T... ...
{};
int main()
{
derived a instance;
base a, derived a a_instance = instance;
}
Output of g++ variadic-crtp.cc -std=c++0x:
variadic-crtp.cc: In function 'int main()':
variadic-crtp.cc:18:41: error: invalid initialization of reference of type
'basea, deriveda ' from expression of type 'deriveda'
Output of g++ -v:
Using built-in specs.
Target: i386-apple-darwin9
Configured with: ../gcc-4.5-20091001/configure --prefix=/opt/local
--build=i386-apple-darwin9 --enable-languages=c,c++,objc,obj-c++
--libdir=/opt/local/lib/gcc45 --includedir=/opt/local/include/gcc45
--infodir=/opt/local/share/info --mandir=/opt/local/share/man
--with-local-prefix=/opt/local --with-system-zlib --disable-nls
--program-suffix=-mp-4.5 --with-gxx-include-dir=/opt/local/include/gcc45/c++/
--with-gmp=/opt/local --with-mpfr=/opt/local
Thread model: posix
gcc version 4.5.0 20091001 (experimental) (GCC)
--
Summary: Canonical type with variadic templates and CRTP
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: alban dot linard at gmail dot com
GCC build triplet: i686-apple-darwin9
GCC host triplet: i686-apple-darwin9
GCC target triplet: i686-apple-darwin9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41752
[Bug fortran/41753] New: OOP - segfault with -O2 using methods as actual arguments
The following produces a segfault at runtime with -O2 and higher
module m
type t
real x
contains
procedure, pass :: a
end type
contains
real function a (arg)
class (t) :: arg
a = arg%x
end function
real function b (arg)
real :: arg
b = arg*2
end function
subroutine s
class(t), allocatable :: z
allocate(z) ! see tree-optimized output
z%x = 42 ! see tree-optimized output
print *, b (z%a()) ! see tree-optimized output
end subroutine
end module
use m
call s
end
With -O0, the marked lines give
bb 2:
D.1348_1 = malloc (4);
if (D.1348_1 == 0B)
goto bb 3;
else
goto bb 4;
bb 3:
_gfortran_os_error (Out of memory[1]{lb: 1 sz: 1});
bb 4:
D.1374_2 = (struct t *) D.1348_1;
z.$data = D.1374_2;
z.$vindex = 2800126;
z.$size = 4;
D.1375_3 = z.$data;
D.1375_3-x = 4.2e+1;
dt_parm.0.common.filename = test.f03[1]{lb: 1 sz: 1};
dt_parm.0.common.line = 22;
dt_parm.0.common.flags = 128;
dt_parm.0.common.unit = 6;
_gfortran_st_write (dt_parm.0);
D.1376_4 = __m_MOD_a (z);
D.1350 = D.1376_4;
D.1377_5 = __m_MOD_b (D.1350);
D.1351 = D.1377_5;
_gfortran_transfer_real (dt_parm.0, D.1351, 4);
_gfortran_st_write_done (dt_parm.0);
whilst with -O2
bb 2:
D.1348_1 = malloc (4);
if (D.1348_1 == 0B)
goto bb 3;
else
goto bb 4;
bb 3:
_gfortran_os_error (Out of memory[1]{lb: 1 sz: 1});
bb 4:
D.1374_2 = (struct t *) D.1348_1;
dt_parm.0.common.filename = test.f03[1]{lb: 1 sz: 1};
dt_parm.0.common.line = 22;
dt_parm.0.common.flags = 128;
dt_parm.0.common.unit = 6;
_gfortran_st_write (dt_parm.0);
arg_21 = (struct .class.t restrict) z;
D.1389_22 = arg_21-$data;
D.1386_23 = D.1389_22-x;
D.1392_26 = D.1386_23 * 2.0e+0;
D.1351 = D.1392_26;
_gfortran_transfer_real (dt_parm.0, D.1351, 4);
_gfortran_st_write_done (dt_parm.0);
ie. the important part of the allocation and the entire assignment disappear!
Since the PRINT then tries to access the data component of the CLASS object,
the segfault results
--
Summary: OOP - segfault with -O2 using methods as actual
arguments
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pault at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41753
[Bug target/41751] bad code with arrays as local vars and no optimization
--- Comment #5 from jakub at gcc dot gnu dot org 2009-10-19 10:20 --- You haven't provide a small self-contained executable testcase, so you need to explain in detail what do you think is wrong on the generated assembly. I don't see anything wrong on it, especially not in the diff between r_main-1.s and r_main-3.s. Far more probable is a code bug, you are saving address of an automatic array into a global pointer, not resetting it afterwards when the function is left, so chances are you are refering to a variable later on even after it went out of scope. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41751
[Bug fortran/41753] OOP - segfault with -O2 using methods as actual arguments
--- Comment #1 from dominiq at lps dot ens dot fr 2009-10-19 10:23 --- Confirmed on (i686|powerpc)-apple-darwin9 revision 152966. On -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41753
[Bug fortran/41494] [4.5 Regression] temp and memcpy used when zeroing array
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-10-19 10:38 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41494
[Bug java/41745] Segmentation fault when ecj.jar is run as a binary compiled by gcj
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-10-19 10:53 --- Sounds more like a BSD threads issue, so you need to debug it more. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added GCC host triplet||freebsd-8.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41745
[Bug bootstrap/41529] [4.5 Regression] LTO configuration should detect if the target is ELF
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-10-19 10:54 --- *** Bug 41746 has been marked as a duplicate of this bug. *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||mckelvey at maskull dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41529
[Bug bootstrap/41746] LTO Fails to bootstrap, stage 2
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-10-19 10:54 --- Indeed. *** This bug has been marked as a duplicate of 41529 *** -- 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=41746
[Bug target/41747] ICEin extract_insn, at recog.c:2091
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-10-19 10:55 --- Target seems broken. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Keywords||build http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41747
[Bug middle-end/41749] non-needed instructions are not removed (not optimized)
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-10-19 10:58 --- It aligns the incoming stack. Fixed in 4.4/4.5. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Component|c |middle-end Known to fail||4.3.4 Known to work||4.4.0 Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41749
[Bug c/41750] gcc 4.5.0 miscompiles binutils
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-10-19 11:00 --- Testcase required. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41750
[Bug target/41751] bad code with arrays as local vars and no optimization
--- Comment #6 from sezeroz at gmail dot com 2009-10-19 11:11 --- (In reply to comment #5) function is left, so chances are you are refering to a variable later on even after it went out of scope. By a closer look, the function is called twice, first by its argument set to true in which case it assigns the pointer, then with the argument set as false where the code seems to assume that the pointer is still valid. So, you are right, the code is buggy and I apologize for the noise. I am amazed, however, how the x86 compilations and/or optimized compilations worked flawlessly since ten years of time... Any hints? -- sezeroz at gmail dot com changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41751
[Bug c/41750] gcc 4.5.0 miscompiles binutils
--- Comment #2 from rainer at emrich-ebersheim dot de 2009-10-19 11:43 --- Subject: Re: gcc 4.5.0 miscompiles binutils -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 rguenth at gcc dot gnu dot org schrieb: --- Comment #1 from rguenth at gcc dot gnu dot org 2009-10-19 11:00 --- Testcase required. Richard, some advice how to create a testcase for this particular issue would be appreciated. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkrcUOMACgkQoUhjsh59BL5teACfQuLfIIXop524bwIJ2XUyjAuK 8kMAoKlEtN8uv1qnV4TsHWEs9eEoVd2P =MQ4R -END PGP SIGNATURE- -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41750
[Bug c/41750] gcc 4.5.0 miscompiles binutils
--- Comment #3 from rainer at emrich-ebersheim dot de 2009-10-19 11:51 --- Forgot to mention that's with binutils 2.20 and binutils head. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41750
[Bug c/41750] gcc 4.5.0 miscompiles binutils
--- Comment #4 from jakub at gcc dot gnu dot org 2009-10-19 12:06 --- For a suspected wrong-code bug, the standard way to create a testcase is to first find out if there are gcc options with which you get the expected result (such as it works when compiled with -O0, doesn't when compiled with -O2), or, if even at -O0 new gcc misbehaves some other compiler version. Then either guess or do a binary search between objects compiled with a known good and known bad options to narrow it down to a particular source file. Then try -fno-inline on that file to see if it is still bad, if it is, it will be far easier, as no inlining is performed and thus fn boundaries are clearer. In any case either guess the miscompiled function or play with attribute optimize (known to have issues though) or splitting source file into several smaller ones to do a binary search to a particular function. Last, find out what arguments it has been called with and try to emulate that inside of a main, just preparing the right arguments (and what they point to etc.), then calling only the problematic function. And, stub all (noninlined) functions the problematic function calls, with something that gives back the right result, use noinline attribute on it and possibly asm volatile (:::memory); to prevent it being optimized. Remove any unnecessary stuff, provide it as preprocessed source, which can be run and show clearly a bad vs. good behavior (say exit 0 in the right case, abort otherwise). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41750
[Bug debug/40521] [4.4/4.5 Regression] -g causes GCC to generate .eh_frame
--- Comment #21 from jakub at gcc dot gnu dot org 2009-10-19 12:15 --- Subject: Bug 40521 Author: jakub Date: Mon Oct 19 12:15:27 2009 New Revision: 152974 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=152974 Log: Backport from mainline: 2009-10-16 Jakub Jelinek ja...@redhat.com PR debug/40521 * debug.h (struct gcc_debug_hooks): Add assembly_start hook. * cgraphunit.c (cgraph_optimize): Call it. * dwarf2out.c (dwarf2out_init): Move .cfi_sections printing into... (dwarf2out_assembly_start): ... here. New hook. (dwarf2out_debug_hooks): Add dwarf2out_assembly_start. * debug.c (do_nothing_debug_hooks): Do nothing for assembly_start hook. * dbxout.c (dbx_debug_hooks, xcoff_debug_hooks): Likewise. * sdbout.c (sdb_debug_hooks): Likewise. * vmsdbgout.c (vmsdbg_debug_hooks): Add vmsdbgout_assembly_start. (vmsdbgout_assembly_start): New hook. 2009-10-09 Jakub Jelinek ja...@redhat.com PR debug/40521 * dwarf2out.c (dwarf2out_init): Test whether HAVE_GAS_CFI_SECTIONS_DIRECTIVE is non-zero instead of checking it is defined. 2009-10-02 Jakub Jelinek ja...@redhat.com PR debug/40521 * configure.ac (HAVE_GAS_CFI_SECTIONS_DIRECTIVE): New test. * configure: Regenerated. * config.in: Regenerated. * dwarf2out.c (dwarf2out_do_cfi_asm): Return false if !HAVE_GAS_CFI_SECTIONS_DIRECTIVE and not emitting .eh_frame. (dwarf2out_init): If HAVE_GAS_CFI_SECTIONS_DIRECTIVE and not emitting .eh_frame, emit .cfi_sections .debug_frame directive. Modified: branches/gcc-4_4-branch/gcc/ChangeLog branches/gcc-4_4-branch/gcc/cgraphunit.c branches/gcc-4_4-branch/gcc/config.in branches/gcc-4_4-branch/gcc/configure branches/gcc-4_4-branch/gcc/configure.ac branches/gcc-4_4-branch/gcc/dbxout.c branches/gcc-4_4-branch/gcc/debug.c branches/gcc-4_4-branch/gcc/debug.h branches/gcc-4_4-branch/gcc/dwarf2out.c branches/gcc-4_4-branch/gcc/sdbout.c branches/gcc-4_4-branch/gcc/vmsdbgout.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40521
[Bug debug/40521] [4.4/4.5 Regression] -g causes GCC to generate .eh_frame
--- Comment #22 from jakub at gcc dot gnu dot org 2009-10-19 12:21 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40521
[Bug preprocessor/41748] Adjust documentation to reflect new (afrer rev. 152599) cpp behavior
--- Comment #2 from d dot g dot gorbachev at gmail dot com 2009-10-19 13:17 --- Ok, thanks for the clarification. I believe this should be documented. -- d dot g dot gorbachev at gmail dot com changed: What|Removed |Added Summary|Continued lines are not |Adjust documentation to |merged into one long line |reflect new (afrer rev. ||152599) cpp behavior http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41748
[Bug c++/41754] New: initializer list internal compiler segfault
This program generates an internal compiler error: Segmentation fault.
#include map
#include string
#include iostream
using namespace std;
int main()
{
mapstring, string m;
m.insert({{t, t}, {y, y}});
return 0;
}
$ g++ -std=c++0x test.cpp
test.cpp: In function 'int main()':
test.cpp:11: 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.
This happens on a compiler built on cygwin from:
svn://gcc.gnu.org/svn/gcc/tags/gcc_4_4_2_release
and
svn://gcc.gnu.org/svn/gcc/branches/gcc-4_4-bra...@152637
with ./configure --prefix=... --disable-sjlj-exceptions
t...@crius ~/tmp
$ /opt/gcc4.4.2/bin/gcc -v
Using built-in specs.
Target: i686-pc-cygwin
Configured with: /home/Tom/svn/gcc4.4.2/configure --prefix=/opt/gcc4.4.2
--disab
le-sjlj-exceptions
Thread model: single
gcc version 4.4.2 (GCC)
$ /opt/gcc4.4/bin/gcc -v
Using built-in specs.
Target: i686-pc-cygwin
Configured with: /home/Tom/svn/gcc/configure --prefix=/opt/gcc4.4
--disable-sjlj
-exceptions
Thread model: single
gcc version 4.4.2 20091011 (prerelease) (GCC)
--
Summary: initializer list internal compiler segfault
Product: gcc
Version: 4.4.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tom dot deseyn at gmail dot com
GCC build triplet: i686-pc-cygwin
GCC host triplet: i686-pc-cygwin
GCC target triplet: i686-pc-cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41754
[Bug fortran/41755] New: Segfault on invalid code
From https://bugzilla.novell.com/show_bug.cgi?id=546031 cat without_comma.f c without comma common /uno/ aa equivalence (aa,a) (bb,cc) end gfortran without_comma.f f951: internal compiler error: Violación de segmento Please submit a full bug report, with preprocessed source if appropriate. -- Summary: Segfault on invalid code Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: ice-on-invalid-code Severity: normal Priority: P3 Component: fortran 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=41755
[Bug fortran/41755] Segfault on invalid code
--- Comment #1 from dominiq at lps dot ens dot fr 2009-10-19 14:08 --- Gives pr41755.f90:2.28: equivalence (aa,a) (bb,cc) 1 Error: Syntax error in EQUIVALENCE statement at (1) with gfortran 4.2.4, and a bus error at compile time with 4.3.4, 4.4.1 and trunk. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41755
[Bug target/41196] The use of ARM NEON vshll_n_u8 intrinsic results in compile error on valid code [4.4 only]
--- Comment #8 from jakub at gcc dot gnu dot org 2009-10-19 14:08 --- 4.4 branch is again open for bugfixes... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41196
[Bug lto/41569] .../prev-gcc/xgcc used for the install step of the lto-plugin
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-10-19 14:19 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||41588 nThis|| Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-10-19 14:19:08 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41569
[Bug target/40134] symbols not resolved when building shared libraries (link with -lgcc_s -lgcc?)
--- Comment #3 from doko at gcc dot gnu dot org 2009-10-19 14:26 --- Subject: Bug 40134 Author: doko Date: Mon Oct 19 14:26:28 2009 New Revision: 152975 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=152975 Log: 2009-10-19 Matthias Klose d...@ubuntu.com PR target/40134 * config.gcc (arm*-*-linux-*eabi): Use config/t-slibgcc-libgcc. Modified: trunk/gcc/ChangeLog trunk/gcc/config.gcc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40134
[Bug fortran/41724] PUREness/ELEMENTAL check missing for ACTUAL/DUMMY conformance
--- Comment #1 from burnus at gcc dot gnu dot org 2009-10-19 14:31 --- Similarly for proc-pointers, cf. PR 41733. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41724
[Bug middle-end/41750] gcc 4.5.0 miscompiles binutils
--- Comment #5 from rainer at emrich-ebersheim dot de 2009-10-19 14:46 --- works when build with -g -O0 and -g -O1. fails when build with -g -O2 and -g -O3. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41750
[Bug lto/41569] .../prev-gcc/xgcc used for the install step of the lto-plugin
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-10-19 15:03 --- Maybe Paolo can help here - copying the usual HACK boilerplate from libssp/Makefile.am into lto-plugin/Makefile.am doesn't help (but libgomp also does not need that). I have no idea how this is supposed to work and do not feel like digging too deep either ;) Btw, the configury and Makefile of lto-plugin seems to be spartan at least. All host libraries apart from zlib do not use automake btw, and zlib is only built statically and not installed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org, bonzini at gnu dot org Severity|normal |major http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41569
[Bug lto/41569] .../prev-gcc/xgcc used for the install step of the lto-plugin
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-10-19 15:18 --- It also builds lto-plugin again at install time. Huh. make[2]: Nothing to be done for `install'. make[2]: Leaving directory `/usr/src/packages/BUILD/gcc-4.5.0-20091018/obj-x86_64-suse-linux/gnattools' make[2]: Entering directory `/usr/src/packages/BUILD/gcc-4.5.0-20091018/obj-x86_64-suse-linux/lto-plugin' /bin/sh ./libtool --tag=CC --mode=compile gcc -DPACKAGE_NAME=\LTO\ plugin\ for\ ld\ -DPACKAGE_TARNAME=\lto-plugin\ -DPACKAGE_VERSION=\0.1\ -DPACKAGE_STRING=\LTO\ plugin\ for\ ld\ 0.1\ -DPACKAGE_BUGREPORT=\\ -DPACKAGE_URL=\\ -DPACKAGE=\lto-plugin\ -DVERSION=\0.1\ -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\.libs/\ -I. -I../../lto-plugin -I../../lto-plugin/../include -I/usr/include/libelf -Wall -Werror -O2 -fmessage-length=0 -D_FORTIFY_SOURCE=2 -funwind-tables -fasynchronous-unwind-tables -g -U_FORTIFY_SOURCE -MT lto-plugin.lo -MD -MP -MF .deps/lto-plugin.Tpo -c -o lto-plugin.lo ../../lto-plugin/lto-plugin.c libtool: compile: gcc -DPACKAGE_NAME=\LTO plugin for ld\ -DPACKAGE_TARNAME=\lto-plugin\ -DPACKAGE_VERSION=\0.1\ -DPACKAGE_STRING=\LTO plugin for ld 0.1\ -DPACKAGE_BUGREPORT=\\ -DPACKAGE_URL=\\ -DPACKAGE=\lto-plugin\ -DVERSION=\0.1\ -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\.libs/\ -I. -I../../lto-plugin -I../../lto-plugin/../include -I/usr/include/libelf -Wall -Werror -O2 -fmessage-length=0 -D_FORTIFY_SOURCE=2 -funwind-tables -fasynchronous-unwind-tables -g -U_FORTIFY_SOURCE -MT lto-plugin.lo -MD -MP -MF .deps/lto-plugin.Tpo -c ../../lto-plugin/lto-plugin.c -fPIC -DPIC -o .libs/lto-plugin.o libtool: compile: gcc -DPACKAGE_NAME=\LTO plugin for ld\ -DPACKAGE_TARNAME=\lto-plugin\ -DPACKAGE_VERSION=\0.1\ -DPACKAGE_STRING=\LTO plugin for ld 0.1\ -DPACKAGE_BUGREPORT=\\ -DPACKAGE_URL=\\ -DPACKAGE=\lto-plugin\ -DVERSION=\0.1\ -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\.libs/\ -I. -I../../lto-plugin -I../../lto-plugin/../include -I/usr/include/libelf -Wall -Werror -O2 -fmessage-length=0 -D_FORTIFY_SOURCE=2 -funwind-tables -fasynchronous-unwind-tables -g -U_FORTIFY_SOURCE -MT lto-plugin.lo -MD -MP -MF .deps/lto-plugin.Tpo -c ../../lto-plugin/lto-plugin.c -o lto-plugin.o /dev/null 21 mv -f .deps/lto-plugin.Tpo .deps/lto-plugin.Plo /bin/sh ./libtool --tag=CC --mode=link gcc -Wall -Werror -O2 -fmessage-length=0 -D_FORTIFY_SOURCE=2 -funwind-tables -fasynchronous-unwind-tables -g -U_FORTIFY_SOURCE -o liblto_plugin.la -rpath /usr/lib64/gcc/x86_64-suse-linux/4.5 lto-plugin.lo -lelf ../libiberty/pic/libiberty.a *** Warning: Linking the shared library liblto_plugin.la against the *** static library ../libiberty/pic/libiberty.a is not portable! libtool: link: rm -fr .libs/liblto_plugin.a .libs/liblto_plugin.la .libs/liblto_plugin.lai .libs/liblto_plugin.so .libs/liblto_plugin.so.0 .libs/liblto_plugin.so.0.0.0 libtool: link: /usr/src/packages/BUILD/gcc-4.5.0-20091018/obj-x86_64-suse-linux/./prev-gcc/xgcc -B/usr/src/packages/BUILD/gcc-4.5.0-20091018/obj-x86_64-suse-linux/./prev-gcc/ -B/usr/x86_64-suse-linux/bin/ -B/usr/x86_64-suse-linux/bin/ -B/usr/x86_64-suse-linux/lib/ -isystem /usr/x86_64-suse-linux/include -isystem /usr/x86_64-suse-linux/sys-include-shared .libs/lto-plugin.o -lelf ../libiberty/pic/libiberty.a-Wl,-soname -Wl,liblto_plugin.so.0 -o .libs/liblto_plugin.so.0.0.0 ./libtool: line 7985: /usr/src/packages/BUILD/gcc-4.5.0-20091018/obj-x86_64-suse-linux/./prev-gcc/xgcc: No such file or directory make[2]: *** [liblto_plugin.la] Error 127 make[2]: Leaving directory `/usr/src/packages/BUILD/gcc-4.5.0-20091018/obj-x86_64-suse-linux/lto-plugin' make[1]: Leaving directory `/usr/src/packages/BUILD/gcc-4.5.0-20091018/obj-x86_64-suse-linux' make: *** [install] Error 2 so, it uses the host compiler here but a weird linker. The Makefile suggests CCLD which is set to CC. I can't really see how it picks up ./prev-gcc/xgcc here ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41569
[Bug target/39247] FAIL: gcc.dg/tree-prof/bb-reorg.c compilation, -fprofile-use -D_PROFILE_USE
--- Comment #4 from rearnsha at gcc dot gnu dot org 2009-10-19 15:18 --- (In reply to comment #3) .text ldr r0, .L30 ... .section.text.unlikely .L30: .word 1819043176 This is broken. We can't reference from .text to .text.unlikely since we can't guarantee that the section will be within 4k of the location doing the load. -- rearnsha at gcc dot gnu dot org changed: What|Removed |Added CC||rearnsha at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39247
[Bug middle-end/41750] gcc 4.5.0 miscompiles binutils
--- Comment #6 from jakub at gcc dot gnu dot org 2009-10-19 15:21 --- Try also -g -O2 -fno-strict-aliasing, if that one works, look for aliasing warnings. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41750
[Bug target/39247] FAIL: gcc.dg/tree-prof/bb-reorg.c compilation, -fprofile-use -D_PROFILE_USE
--- Comment #5 from rearnsha at gcc dot gnu dot org 2009-10-19 15:26 --- (In reply to comment #1) Subject: Re: New: FAIL: gcc.dg/tree-prof/bb-reorg.c compilation, -fprofile-use -D_PROFILE_USE The ARM constant pool code needs to handle a NOTE_INSN_SWITCH_TEXT_SECTIONS note in some way as indicating insns on one side mustn't use constant pool entries on the other side. One possible approach would be treating such a note as an insn of length 4100, but there might be a cleaner way. I don't think there should be such notes on ARM due to the branch-range limitation. We can't arbitrarily jump between sections in Thumb state, for example -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39247
[Bug target/39247] FAIL: gcc.dg/tree-prof/bb-reorg.c compilation, -fprofile-use -D_PROFILE_USE
--- Comment #6 from steven at gcc dot gnu dot org 2009-10-19 15:42 --- You should not depend on NOTE_INSN_SWITCH_TEXT_SECTIONS. There are other ways to see if a jump goes from one section to another: edge-flags EDGE_CROSSING (preferred), and REG_CROSSING_JUMP notes (more reliable in post-pass_free_cfg world). There is no hook to disable the hot-cold partitioning pass right now. For thumb mode, the ARM back end should just set flag_reorder_blocks_and_partition = 0, like Xtensa and MIPS (for MIPS16 mode) already do, for similar reasons. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39247
[Bug middle-end/41753] OOP - segfault with -O2 using methods as actual arguments
--- Comment #2 from pault at gcc dot gnu dot org 2009-10-19 15:46 --- Have cc'd Richi to see if he can shed any light on this. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-10-19 15:46:06 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41753
[Bug target/39247] FAIL: gcc.dg/tree-prof/bb-reorg.c compilation, -fprofile-use -D_PROFILE_USE
--- Comment #7 from rearnsha at gcc dot gnu dot org 2009-10-19 15:50 --- (In reply to comment #6) You should not depend on NOTE_INSN_SWITCH_TEXT_SECTIONS. There are other ways to see if a jump goes from one section to another: edge-flags EDGE_CROSSING (preferred), and REG_CROSSING_JUMP notes (more reliable in post-pass_free_cfg world). There is no hook to disable the hot-cold partitioning pass right now. For thumb mode, the ARM back end should just set flag_reorder_blocks_and_partition = 0, like Xtensa and MIPS (for MIPS16 mode) already do, for similar reasons. Indeed. In fact even for ARM state, we can only support this option if both the insn-address code correctly separates hot and cold addresses (and I suspect it doesn't) and the literal-pool extraction code correctly extracts the above information (which it certainly doesn't). So at present we have no choice but to disable this optimization for all ARM configurations. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39247
[Bug middle-end/41734] ICE in cgraph_mark_functions_to_output, at cgraphunit.c:1137 with -fwhopr
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-10-19 16:03 ---
Papering over this bug gets us as far as reaching
void
cgraph_mark_needed_node (struct cgraph_node *node)
{
node-needed = 1;
gcc_assert (!node-global.inlined_to);
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41734
[Bug middle-end/41750] gcc 4.5.0 miscompiles binutils
--- Comment #7 from rainer at emrich-ebersheim dot de 2009-10-19 16:08 --- Subject: Re: gcc 4.5.0 miscompiles binutils jakub at gcc dot gnu dot org wrote: --- Comment #6 from jakub at gcc dot gnu dot org 2009-10-19 15:21 --- Try also -g -O2 -fno-strict-aliasing, if that one works, look for aliasing warnings. works when build with -g -O2 -fno-ipa-sra and -g -O3 -fno-ipa-sra. So, that's the easy part. Try to get further. Any help appreciated. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41750
[Bug middle-end/41750] gcc 4.5.0 miscompiles binutils
--- Comment #8 from rainer at emrich-ebersheim dot de 2009-10-19 16:19 --- fails when build with -g -O1 -fipa-sra. So, the ipa-sra pass causes the issue, no? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41750
[Bug target/39247] FAIL: gcc.dg/tree-prof/bb-reorg.c compilation, -fprofile-use -D_PROFILE_USE
--- Comment #8 from rearnsha at gcc dot gnu dot org 2009-10-19 16:19 --- Created an attachment (id=18826) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18826action=view) Proposed patch Currently only very lightly tested, but this should solve the issue. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39247
[Bug middle-end/41750] gcc 4.5.0 miscompiles binutils
--- Comment #9 from rainer at emrich-ebersheim dot de 2009-10-19 16:30 --- build with -g -O1 -fipa-sra -fno-inline I get the following backtrace: Core was generated by `ia64-unknown-linux-gnu-ld --verbose --sysroot=/opt/devel/tec/setup/sys-root/Lin'. Program terminated with signal 11, Segmentation fault. #0 0x0043c3e3 in get_got (abfd=0x711300, info=value optimized out) at elf64-ia64.c:2073 2073 return x-addend y-addend ? -1 : x-addend y-addend ? 1 : 0; (gdb) where #0 0x0043c3e3 in get_got (abfd=0x711300, info=value optimized out) at elf64-ia64.c:2073 #1 0x0043c9bc in elf64_ia64_check_relocs (abfd=value optimized out, info=0x6ead00, sec=value optimized out, relocs=value optimized out) at elf64-ia64.c:2073 #2 0x00459a52 in elf_link_add_object_symbols (abfd=value optimized out, info=value optimized out) at /opt/devel/gnu/src/gcc/binutils-2.20/bfd/elflink.c:477 #3 0x00459e85 in bfd_elf_link_add_symbols (abfd=value optimized out, info=value optimized out) at /opt/devel/gnu/src/gcc/binutils-2.20/bfd/elflink.c:477 #4 0x0040f947 in load_symbols (entry=0x6eb1e0, place=value optimized out) at /opt/devel/gnu/src/gcc/binutils-2.20/ld/ldlang.c:353 #5 0x0040fea4 in open_input_bfds (s=0x6eb1e0, force=0) at /opt/devel/gnu/src/gcc/binutils-2.20/ld/ldlang.c:353 #6 0x0041217e in lang_process () at /opt/devel/gnu/src/gcc/binutils-2.20/ld/ldlang.c:353 #7 0x00414cc0 in main (argc=27, argv=0x7fffa21c0d78) at /opt/devel/gnu/src/gcc/binutils-2.20/ld/ldmain.c:1383 (gdb) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41750
[Bug target/39247] FAIL: gcc.dg/tree-prof/bb-reorg.c compilation, -fprofile-use -D_PROFILE_USE
--- Comment #9 from joseph at codesourcery dot com 2009-10-19 16:44 --- Subject: Re: FAIL: gcc.dg/tree-prof/bb-reorg.c compilation, -fprofile-use -D_PROFILE_USE On Mon, 19 Oct 2009, rearnsha at gcc dot gnu dot org wrote: I don't think there should be such notes on ARM due to the branch-range limitation. We can't arbitrarily jump between sections in Thumb state, for example Nowadays GNU ld supports generating long branch stubs on ARM. It's intended for calls in large programs, but shouldn't it be possible to get the compiler to generate jumps between sections within a function that the linker can then make use the long branch stubs if necessary? (Given a solution to the constant pools issue.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39247
[Bug fortran/41755] Segfault on invalid code
--- Comment #2 from kargl at gcc dot gnu dot org 2009-10-19 16:45 --- I'm regression testing a patch at the moment. -- kargl at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |kargl at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-10-19 16:45:52 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41755
[Bug target/39247] FAIL: gcc.dg/tree-prof/bb-reorg.c compilation, -fprofile-use -D_PROFILE_USE
--- Comment #10 from joseph at codesourcery dot com 2009-10-19 16:46 --- Subject: Re: FAIL: gcc.dg/tree-prof/bb-reorg.c compilation, -fprofile-use -D_PROFILE_USE On Mon, 19 Oct 2009, rearnsha at gcc dot gnu dot org wrote: Created an attachment (id=18826) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18826action=view) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18826action=view) Proposed patch Currently only very lightly tested, but this should solve the issue. The diagnostic should not end with .. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39247
[Bug libstdc++/40654] [C++0x] atomic.cc: 'd' is used uninitialized warning
--- Comment #7 from bkoz at gcc dot gnu dot org 2009-10-19 16:46 --- In for gcc-4.4.3 -- bkoz at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.4.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40654
[Bug libstdc++/40826] [C++0x] atomic_flag_{test_and_set,clear}_explicit() are apparently broken
--- Comment #5 from bkoz at gcc dot gnu dot org 2009-10-19 16:47 --- Fixed on trunk and gcc-4_4-branch -- bkoz at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40826
[Bug fortran/41755] Segfault on invalid code
--- Comment #3 from burnus at gcc dot gnu dot org 2009-10-19 16:50 --- I already posted one - http://gcc.gnu.org/ml/fortran/2009-10/msg00172.html I thought I had marked it as ASSIGNED but seemingly I was distracted and didn't :-( -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41755
[Bug lto/41756] New: LTO: -flto -O1 -use-linker-plugin, linking files compiled with -fno-exceptions with ones compiled with exceptions yields error BB 14 can not throw but has an EH edge
$ /home/edwin/inst/bin/g++ -v Using built-in specs. COLLECT_GCC=/home/edwin/inst/bin/g++ COLLECT_LTO_WRAPPER=/home/edwin/inst/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc/configure --enable-lto --enable-languages=c,c++ --enable-gold Thread model: posix gcc version 4.5.0 20091019 (experimental) (GCC) sh -x script + /home/edwin/inst/bin/g++ -fPIC SourceMgr.i -flto -fno-exceptions -O1 -c -o SourceMgr.o + /home/edwin/inst/bin/g++ -fPIC AsmMatcherEmitter.i -flto -O1 -c -o AsmMatcher.o + /home/edwin/inst/bin/g++ -flto -use-linked-plugin -O1 AsmMatcher.o SourceMgr.o -shared In function EmitIsSubclass: lto1: error: BB 14 can not throw but has an EH edge lto1: error: BB 15 can not throw but has an EH edge lto1: error: BB 16 can not throw but has an EH edge lto1: error: BB 18 can not throw but has an EH edge lto1: error: BB 19 can not throw but has an EH edge lto1: error: BB 20 can not throw but has an EH edge lto1: error: BB 22 can not throw but has an EH edge lto1: error: BB 23 can not throw but has an EH edge lto1: error: BB 25 can not throw but has an EH edge lto1: error: BB 26 can not throw but has an EH edge lto1: error: BB 27 can not throw but has an EH edge lto1: error: BB 30 can not throw but has an EH edge lto1: internal compiler error: verify_flow_info failed Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. lto-wrapper: /home/edwin/inst/bin/g++ returned 1 exit status collect2: lto-wrapper returned 1 exit status -- Summary: LTO: -flto -O1 -use-linker-plugin, linking files compiled with -fno-exceptions with ones compiled with exceptions yields error BB 14 can not throw but has an EH edge Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: edwintorok at gmail dot com 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=41756
[Bug lto/41756] LTO: -flto -O1 -use-linker-plugin, linking files compiled with -fno-exceptions with ones compiled with exceptions yields error BB 14 can not throw but has an EH edge
--- Comment #1 from edwintorok at gmail dot com 2009-10-19 16:55 --- Created an attachment (id=18827) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18827action=view) SourceMgr.i preprocessed SourceMgr.i -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41756
[Bug lto/41756] LTO: -flto -O1 -use-linker-plugin, linking files compiled with -fno-exceptions with ones compiled with exceptions yields error BB 14 can not throw but has an EH edge
--- Comment #2 from edwintorok at gmail dot com 2009-10-19 16:56 --- Created an attachment (id=18828) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18828action=view) AsmMatcherEmitter.i.bz2 bzipped preprocessed AsmMatcherEmitter.i -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41756
[Bug lto/41756] LTO: -flto -O1 -use-linker-plugin, linking files compiled with -fno-exceptions with ones compiled with exceptions yields error BB 14 can not throw but has an EH edge
--- Comment #3 from edwintorok at gmail dot com 2009-10-19 16:58 --- ld -v GNU gold (GNU Binutils for Debian 2.20) 1.9 This happens only if I use all of -flto -O1 -use-linker-plugin, not using -O1, or not using -use-linker-plugin hides the bug (and not using -flto too of course). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41756
[Bug lto/41756] LTO: -flto -O1 -use-linker-plugin, linking files compiled with -fno-exceptions with ones compiled with exceptions yields error BB 14 can not throw but has an EH edge
--- Comment #4 from edwintorok at gmail dot com 2009-10-19 16:59 --- (In reply to comment #3) ld -v GNU gold (GNU Binutils for Debian 2.20) 1.9 This happens only if I use all of -flto -O1 -use-linker-plugin, not using -O1, or not using -use-linker-plugin hides the bug (and not using -flto too of course). Actually -use-linker-plugin makes no difference -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41756
[Bug debug/41340] [4.5 Regression] G++ produces different code with and without -g option
--- Comment #7 from jakub at gcc dot gnu dot org 2009-10-19 17:05 ---
Confirmed, for -m32 -march=i686 -O3 -g vs. -g0 generates different code on:
typedef struct { int t; } *T;
struct S1 { unsigned s1; };
struct S2 { struct S1 s2; };
struct S3 { unsigned s3; struct S2 **s4; };
struct S5 { struct S2 *s5; };
extern void fn0 (void) __attribute__ ((__noreturn__));
T fn6 (struct S3);
void fn7 (void);
int
fn1 (const struct S1 *x)
{
return x-s1;
}
int
fn2 (const struct S1 *x, unsigned y)
{
if (y = x-s1)
fn0 ();
return 0;
}
int
fn3 (struct S3 x)
{
return (x.s3 == fn1 (*x.s4 ? (*x.s4)-s2 : 0));
}
int
fn4 (struct S3 x)
{
return fn2 ((*x.s4)-s2, x.s3);
}
int
fn5 (struct S3 x, T *y)
{
if (!fn3 (x))
{
*y = (T) (long) fn4 (x);
return 1;
}
return 0;
}
void
test (struct S5 *x)
{
struct S3 a;
T b;
unsigned char c = 0;
a.s4 = x-s5;
while (fn5 (a, b))
if (!(b-t 8))
c = 1;
a.s4 = x-s5;
while ((b = fn6 (a)))
;
if (!c)
fn7 ();
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41340
[Bug middle-end/41750] gcc 4.5.0 miscompiles binutils
--- Comment #10 from rainer at emrich-ebersheim dot de 2009-10-19 17:06 --- The line numbers in the traceback in comment #9 are completly bogus. I had to upgrade my gdb to version 0.7. Now it looks much better: Core was generated by `ia64-unknown-linux-gnu-ld --verbose --sysroot=/opt/devel/tec/setup/sys-root/Lin'. Program terminated with signal 11, Segmentation fault. #0 get_got (abfd=0x711300, info=value optimized out) at elf64-ia64.c:2418 2418 if (!bfd_set_section_alignment (abfd, got, 3)) (gdb) where #0 get_got (abfd=0x711300, info=value optimized out) at elf64-ia64.c:2418 #1 0x0043c9bc in elf64_ia64_check_relocs (abfd=value optimized out, info=0x6ead00, sec=value optimized out, relocs=value optimized out) at elf64-ia64.c:2973 #2 0x00459a52 in elf_link_add_object_symbols (abfd=value optimized out, info=value optimized out) at /opt/devel/gnu/src/gcc/binutils-2.20/bfd/elflink.c:4774 #3 0x00459e85 in bfd_elf_link_add_symbols (abfd=value optimized out, info=value optimized out) at /opt/devel/gnu/src/gcc/binutils-2.20/bfd/elflink.c:5097 #4 0x0040f947 in load_symbols (entry=0x6eb1e0, place=value optimized out) at /opt/devel/gnu/src/gcc/binutils-2.20/ld/ldlang.c:2707 #5 0x0040fea4 in open_input_bfds (s=0x6eb1e0, force=0) at /opt/devel/gnu/src/gcc/binutils-2.20/ld/ldlang.c:3138 #6 0x0041217e in lang_process () at /opt/devel/gnu/src/gcc/binutils-2.20/ld/ldlang.c:6287 #7 0x00414cc0 in main (argc=27, argv=0x7fffa21c0d78) at /opt/devel/gnu/src/gcc/binutils-2.20/ld/ldmain.c:455 (gdb) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41750
[Bug java/41745] Segmentation fault when ecj.jar is run as a binary compiled by gcj
--- Comment #4 from yuri at tsoft dot com 2009-10-19 17:20 --- I confirm this on FreeBSD-8.0 for gcc-4.5.0.20091001. I notified the maintainer of FreeBSD gcc port. But once the fix will be found it should go into gcj itself, not into port. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41745
[Bug debug/41340] [4.5 Regression] G++ produces different code with and without -g option
--- Comment #8 from jakub at gcc dot gnu dot org 2009-10-19 17:14 --- NONDEBUG_INSN_P differences start appearing in DSE1, looking into it. -- 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|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-10-19 17:14:34 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41340
[Bug middle-end/41750] gcc 4.5.0 miscompiles binutils
--- Comment #11 from rainer at emrich-ebersheim dot de 2009-10-19 17:24 --- verified that compiling only bfd/elf64-ia64.c with -fno-ipa-sra is sufficient to get a working ia64-unknown-linux-gnu-ld. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41750
[Bug lto/41756] LTO: -flto -O1 -use-linker-plugin, linking files compiled with -fno-exceptions with ones compiled with exceptions yields error BB 14 can not throw but has an EH edge
--- Comment #5 from steven at gcc dot gnu dot org 2009-10-19 17:34 --- You can't merge no-exception and exception code, it seems. Should exceptions be enabled per-function for LTO? -- steven at gcc dot gnu dot org changed: What|Removed |Added CC||dnovillo at gcc dot gnu dot ||org, hubicka at gcc dot gnu ||dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-10-19 17:34:08 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41756
[Bug target/39247] FAIL: gcc.dg/tree-prof/bb-reorg.c compilation, -fprofile-use -D_PROFILE_USE
--- Comment #11 from rearnsha at gcc dot gnu dot org 2009-10-19 17:51 --- (In reply to comment #9) Subject: Re: FAIL: gcc.dg/tree-prof/bb-reorg.c compilation, -fprofile-use -D_PROFILE_USE On Mon, 19 Oct 2009, rearnsha at gcc dot gnu dot org wrote: I don't think there should be such notes on ARM due to the branch-range limitation. We can't arbitrarily jump between sections in Thumb state, for example Nowadays GNU ld supports generating long branch stubs on ARM. It's intended for calls in large programs, but shouldn't it be possible to get the compiler to generate jumps between sections within a function that the linker can then make use the long branch stubs if necessary? (Given a solution to the constant pools issue.) The compiler generated stubs are permitted to clobber registers that would not normally be affected (namely IP), so we'd need to build that knowledge into the compiler. Actually, the manual suggests the compiler can deal with this without the need for using the range-limited branches since it will generate indirect jumps. The literal-pool problem still needs to be solved though and that's non-trivial. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39247
[Bug fortran/41755] Segfault on invalid code
--- Comment #4 from burnus at gcc dot gnu dot org 2009-10-19 18:03 --- Subject: Bug 41755 Author: burnus Date: Mon Oct 19 18:03:02 2009 New Revision: 152983 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=152983 Log: 2009-10-19 Tobias Burnus bur...@net-b.de Steven G. Kargl ka...@gcc.gnu.org PR fortran/41755 * symbol.c (gfc_undo_symbols): Add NULL check. * match.c (gfc_match_equivalence): Add check for missing comma. 2009-10-19 Tobias Burnus bur...@net-b.de PR fortran/41755 * gfortran.dg/equiv_8.f90: New test. * gfortran.dg/class_allocate_1.f03: Remove obsolete FIXME. Added: trunk/gcc/testsuite/gfortran.dg/equiv_8.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/match.c trunk/gcc/fortran/symbol.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/class_allocate_1.f03 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41755
[Bug libstdc++/40852] [parallel-mode] parallel sort run time increases ~10 fold when vector size gets over ~4*10^9
--- Comment #6 from jason at gcc dot gnu dot org 2009-10-19 18:07 --- Have you tried selecting a different sort algorithm? The default seems to be the multi-way mergesort, but there are two quicksort options as well. -- jason at gcc dot gnu dot org changed: What|Removed |Added CC||jason at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40852
[Bug debug/41340] [4.5 Regression] G++ produces different code with and without -g option
--- Comment #9 from jakub at gcc dot gnu dot org 2009-10-19 18:35 --- Actually, it is not DSE1 but already loop-invariant.c, and the difference is in max_reg_pressure of the current loop (4 vs. 5 for one of the classes). -- jakub at gcc dot gnu dot org changed: What|Removed |Added CC||vmakarov at gcc dot gnu dot ||org AssignedTo|jakub at gcc dot gnu dot org|unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41340
[Bug fortran/41586] Allocatable _scalars_ are never auto-deallocated
--- Comment #4 from janus at gcc dot gnu dot org 2009-10-19 18:46 --- Mine. Have a patch: http://gcc.gnu.org/ml/fortran/2009-10/msg00171.html -- janus at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|tkoenig at gcc dot gnu dot |janus at gcc dot gnu dot org |org | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41586
[Bug java/41745] Segmentation fault when ecj.jar is run as a binary compiled by gcj
--- Comment #5 from yuri at tsoft dot com 2009-10-19 19:12 --- How to run testsuite for gcj? When I run 'gmake check-gcc' from the build directory it doesn't run gcj tests at all, and gcc/g++ tests summaries are all empty. Not sure what that means. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41745
[Bug fortran/41755] Segfault on invalid code
--- Comment #5 from burnus at gcc dot gnu dot org 2009-10-19 19:18 --- Subject: Bug 41755 Author: burnus Date: Mon Oct 19 19:18:12 2009 New Revision: 152987 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=152987 Log: 2009-10-19 Tobias Burnus bur...@net-b.de Steven G. Kargl ka...@gcc.gnu.org PR fortran/41755 * symbol.c (gfc_undo_symbols): Add NULL check. * match.c (gfc_match_equivalence): Add check for missing comma. 2009-10-19 Tobias Burnus bur...@net-b.de PR fortran/41755 * gfortran.dg/equiv_8.f90: New test. Added: branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/equiv_8.f90 Modified: branches/gcc-4_4-branch/gcc/fortran/ChangeLog branches/gcc-4_4-branch/gcc/fortran/match.c branches/gcc-4_4-branch/gcc/fortran/symbol.c branches/gcc-4_4-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41755
[Bug fortran/41586] Allocatable _scalars_ are never auto-deallocated
--- Comment #5 from janus at gcc dot gnu dot org 2009-10-19 19:21 --- Subject: Bug 41586 Author: janus Date: Mon Oct 19 19:21:18 2009 New Revision: 152988 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=152988 Log: 2009-10-19 Janus Weil ja...@gcc.gnu.org PR fortran/41586 * parse.c (parse_derived): Correctly set 'alloc_comp' and 'pointer_comp' for CLASS variables. * trans-array.c (structure_alloc_comps): Handle deallocation and nullification of allocatable scalar components. * trans-decl.c (gfc_get_symbol_decl): Remember allocatable scalars for automatic deallocation. (gfc_trans_deferred_vars): Automatically deallocate allocatable scalars. 2009-10-19 Janus Weil ja...@gcc.gnu.org PR fortran/41586 * gfortran.dg/auto_dealloc_1.f90: New test case. Added: trunk/gcc/testsuite/gfortran.dg/auto_dealloc_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/parse.c trunk/gcc/fortran/trans-array.c trunk/gcc/fortran/trans-decl.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41586
[Bug fortran/41586] Allocatable _scalars_ are never auto-deallocated
--- Comment #6 from janus at gcc dot gnu dot org 2009-10-19 19:23 --- Fixed with r152988. Closing. -- janus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41586
[Bug fortran/41755] [4.3/4.4/4.5 Regression] Segfault on invalid code
--- Comment #6 from burnus at gcc dot gnu dot org 2009-10-19 19:27 --- CLOSE as FIXED on the trunk (4.5) and the 4.4 branch. (I do not care about 4.3, but I can backport it, if it is deemed to be useful.) Thanks for (forwarding) the report. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||4.2.1 Resolution||FIXED Summary|Segfault on invalid code|[4.3/4.4/4.5 Regression] ||Segfault on invalid code Target Milestone|--- |4.4.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41755
[Bug other/41757] New: Add PLUGIN_FINISH_DECL
The GCC plugin API has a PLUGIN_FINISH_TYPE callback which provides an easy way for plugins to enumerate instantiated types in GCC. Unfortunately no such equivalent exists for decls. Would be great to get a way to get notified when global variable, struct member and static method DECLs are completed in the parser. -- Summary: Add PLUGIN_FINISH_DECL Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tglek at mozilla dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41757
[Bug fortran/41758] New: [Cleanup] Don't resolve expr in gfc_match_allocate
In gfc_match_allocate one finds a call to gfc_resolve_expr, which resolves the optional SOURCE expression. By definition, resolving should be done at resolution stage, and not already when matching the ALLOCATE statement. The canonical way to do it would be to add something like 'gfc_resolve_expr (code-expr3)' in resolve_code, where already code-expr1 and code-expr2 are being resolved (the SOURCE expr is being stored in code-expr3). So, unless there are very good reasons for the resolution to happen in gfc_match_allocate, the call to gfc_resolve_expr should be moved to resolve.c (together with the various checks for the SOURCE expression that follow it). I think the questionable code was committed as part of r151023 by Steve, when he implemented the SOURCE tag in ALLOCATE statements. -- Summary: [Cleanup] Don't resolve expr in gfc_match_allocate Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: janus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41758
[Bug target/41747] arc-elf: ICE in extract_insn, at recog.c:2091
--- Comment #4 from joel at gcc dot gnu dot org 2009-10-19 21:39 --- ../../gcc-4.1.2/gcc/libgcc2.c:1702: internal compiler error: in extract_insn, at recog.c:2084 ../../gcc-4.2.4/gcc/libgcc2.c:747: internal compiler error: in extract_insn, at recog.c:2077 -- joel at gcc dot gnu dot org changed: What|Removed |Added Known to fail|4.4.1 4.3.4 |4.4.1 4.3.4 4.2.4 4.1.2 Summary|ICEin extract_insn, at |arc-elf: ICE in |recog.c:2091|extract_insn, at ||recog.c:2091 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41747
[Bug target/41747] arc-elf: ICE in extract_insn, at recog.c:2091
--- Comment #5 from joel at gcc dot gnu dot org 2009-10-19 21:46 --- ../../gcc-3.4.6/gcc/libgcc2.c:1475: internal compiler error: in extract_insn, at recog.c:2083 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41747
[Bug libstdc++/41759] New: [C++0x] random static_assert phrasing should be positive
This patch: http://gcc.gnu.org/ml/gcc-patches/2009-10/msg00782.html Introduces some compile time diagnostics: - static_assert(__m == 0 || (__a __m __c __m), - template arguments out of bounds -in linear_congruential_engine); + static_assert(std::is_unsigned_UIntType::value, template argument + _UIntType not an unsigned integral type); + static_assert(__m == 0u || (__a __m __c __m), + template argument __m out of bounds); Walter Brown has suggested for positive, not negative phrasing on diagnostics, and indicated that some improvement may be possible. Details are a little fuzzy, but this is a placeholder for that conversation. If we do this for random, then there are other C++0x areas where we could also do this, maybe the atomic bits? -- Summary: [C++0x] random static_assert phrasing should be positive Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bkoz at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41759
[Bug fortran/41758] [Cleanup] Don't resolve expr in gfc_match_allocate
--- Comment #1 from kargl at gcc dot gnu dot org 2009-10-19 22:06 --- (In reply to comment #0) In gfc_match_allocate one finds a call to gfc_resolve_expr, which resolves the optional SOURCE expression. By definition, resolving should be done at resolution stage, and not already when matching the ALLOCATE statement. The canonical way to do it would be to add something like 'gfc_resolve_expr (code-expr3)' in resolve_code, where already code-expr1 and code-expr2 are being resolved (the SOURCE expr is being stored in code-expr3). So, unless there are very good reasons for the resolution to happen in gfc_match_allocate, the call to gfc_resolve_expr should be moved to resolve.c (together with the various checks for the SOURCE expression that follow it). I think the questionable code was committed as part of r151023 by Steve, when he implemented the SOURCE tag in ALLOCATE statements. Yes, I added the call to gfc_resolve_expr. Unfortnately, I can't remember why :( other than tmp-ts.type is not properly set in some situation. If you move this to resolve.c, you'll need to move some or all of the error checking involving tmp-ts.type. Perhaps, your changes to support CLASS and allocatable scalars has removed the need for gfc_resolve_expr here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41758
[Bug fortran/41755] [4.3/4.4/4.5 Regression] Segfault on invalid code
--- Comment #7 from jakub at gcc dot gnu dot org 2009-10-19 22:24 --- Subject: Bug 41755 Author: jakub Date: Mon Oct 19 22:24:28 2009 New Revision: 152999 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=152999 Log: PR fortran/41755 * symbol.c (gfc_undo_symbols): Add NULL check. * match.c (gfc_match_equivalence): Add check for missing comma. PR fortran/41755 * gfortran.dg/equiv_8.f90: New test. Modified: branches/gcc-4_4-branch/gcc/fortran/ChangeLog branches/gcc-4_4-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41755
[Bug fortran/41758] [Cleanup] Don't resolve expr in gfc_match_allocate
--- Comment #2 from kargl at gcc dot gnu dot org 2009-10-19 22:29 ---
Note, simply commenting out gfc_resolve_expr() leads to regressions
in allocate_alloc_opt_4.f90 and allocate_alloc_opt_6.f90. The reduce
testcase from *_4.f90 is
! { dg-do compile }
program a
implicit none
integer m(3,3)
integer, allocatable :: i(:)
m = 42
allocate(i(4), source=m) ! { dg-error must be scalar or have the same rank
}
end program a
which means this chunk of code in gfc_match_allocate isn't triggering.
/* Check C632 and restriction following Note 6.18. */
if (tmp-rank 0 conformable_arrays (tmp, head-expr) == FAILURE)
goto cleanup;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41758
[Bug lto/41159] [LTO] ICE in insert_value_copy_on_edge, at tree-outof-ssa.c:225
--- Comment #6 from pinskia at gcc dot gnu dot org 2009-10-19 23:52 --- I get a similar issue on powerpc with -O3 used on the object file and then -O0 used for the final link. Though the simple example does not show the issue on PPC. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41159
[Bug libstdc++/41759] [C++0x] random static_assert phrasing should be positive
--- Comment #1 from paolo dot carlini at oracle dot com 2009-10-20 02:45 --- In fact, I have only *extended* the existing static_asserts to cover the type too, not just the bounds, thus avoiding the legacy simulated concept checks. In general, I followed the existing practice about negative vs positive. I think the real confusion is that in general we want to talk about *arguments* not *parameters*, therefore we want to say argument substituting _UIntType not an unsigned integral type, and template argument substituting __m out of bounds. I'm in favor of that change. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41759
[Bug libstdc++/41759] [C++0x] random static_assert phrasing should be positive
--- Comment #2 from paolo dot carlini at oracle dot com 2009-10-20 03:13 --- Or, if we really wants positive forms, I would suggest: template parameter _UIntType is an unsigned integral type and template parameter __m has bounds I'm ok with either. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41759
[Bug fortran/41706] [OOP] Calling one TBP as an actual argument of another TBP
--- Comment #1 from pault at gcc dot gnu dot org 2009-10-20 04:17 --- Subject: Bug 41706 Author: pault Date: Tue Oct 20 04:16:02 2009 New Revision: 153004 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=153004 Log: 2009-10-20 Paul Thomas pa...@gcc.gnu.org PR fortran/41706 * resolve.c (resolve_arg_exprs): New function. (resolve_class_compcall): Call the above. (resolve_class_typebound_call): The same. 2009-10-20 Paul Thomas pa...@gcc.gnu.org PR fortran/41706 * gfortran.dg/class_9 : New test. Added: trunk/gcc/testsuite/gfortran.dg/class_9.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41706
[Bug fortran/41706] [OOP] Calling one TBP as an actual argument of another TBP
--- Comment #2 from pault at gcc dot gnu dot org 2009-10-20 04:52 --- Fixed on trunk. Thanks for the report! Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41706
