tr1_impl/functional uses typeid and fails when used with -fno-rtti
It would be more useful if functionality would simply be reduced when -fno-rtti
is used with
#ifdef __GXX_RTTI
used to wrap RTTI code.
$ cat testcase.cpp
#include
$ gcc -std=gnu++0x -fno-rtti -c testcase.cpp
--
mipsisa64-elf-gcc -O2 -S gcc.target/mips/mips16e-extends.c
-DMIPS16='__attribute__((mips16))' -msoftf-float
The output code does not contain the expected ZEB and ZEH instructions. (The
options here select EABI64, but the same problem occurs with other -mlong64
ABIs.)
The problem is that we don't
--- Comment #14 from dominiq at lps dot ens dot fr 2008-12-21 13:34 ---
> This little patch eliminates the misalignment of output characters with -m32
> and gets rid of a many many valgrind errors.
>
> @@ -628,7 +637,7 @@ output_float_FMT_G_ ## x (st_parameter_d
> \
> while (low <= hig
(.text+0x2f): undefined reference to `__m_MOD_g'
collect2: ld returned 1 exit status
$> gfortran-svn --version
GNU Fortran (GCC) 4.4.0 20081221 (experimental)
The problem disappears if F and G are reordered in the module or the contained
G is removed.
--
Summary: module function name
--- Comment #12 from dfeldstern at fastimap dot com 2008-12-21 13:04
---
I'm seeing the same issue, with gcc from debian unstable ("gcc (Debian 4.3.2-1)
4.3.2").
The problem appears either when a 'gcc' directory (other than the "real" gcc
directory) is found through the PATH, or else G
--- Comment #3 from doko at ubuntu dot com 2008-12-21 12:58 ---
precompiled header file at:
http://people.ubuntu.com/~doko/tmp/_precompiled.incl.gch.bz2
--
doko at ubuntu dot com changed:
What|Removed |Added
--- Comment #2 from doko at ubuntu dot com 2008-12-21 12:51 ---
Created an attachment (id=16953)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16953&action=view)
build log
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38593
--- Comment #1 from doko at ubuntu dot com 2008-12-21 12:50 ---
Created an attachment (id=16952)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16952&action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38593
seen with 20081213, on hppa-linux-gnu, building with -g -O2 -fPIC
/home/packages/openjdk/openjdk-6-6b14~pre1/openjdk-ecj/hotspot/src/share/vm/interpreter/bytecodeInterpreter.cpp:
In static member f
unction 'static void BytecodeInterpreter::run(BytecodeInterpreter*)':
/home/packages/openjdk/openjdk
--- Comment #1 from tkoenig at gcc dot gnu dot org 2008-12-21 12:03 ---
To clarify, we could detect that the variable only ever
has the value of 'yes'. We already do the right
thing with constants:
$ cat foo-2.f90
program main
character(len=3), parameter :: a = 'yes'
print *,'yes'
$ cat foo.f90
program main
character(len=3) :: a
a = 'yes'
print *,'yes' == a
end program main
$ gfortran -fdump-tree-optimized -O3 -S foo.f90
$ grep compare_string foo.s
call_gfortran_compare_string
--
Summary: eliminate constant string comparisons
Produc
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-12-21 10:14 ---
This is caused by the optimization which converts C/-a into -C/a for strict
overflow which is why it only happens at -O2 and above (or with
-fstrict-overflow).
Confirmed.
--
pinskia at gcc dot gnu dot org change
Since we started building the 4.3.x compiler on very fast Linux machines (bi-
quad cores) we have observed erratic but consistent comparison failures, say
a handful of times a month. The problematic file is always the same:
Comparing stages 2 and 3
Bootstrap comparison failure!
./sparseset.o diff
--- Comment #3 from jv244 at cam dot ac dot uk 2008-12-21 08:05 ---
(In reply to comment #2)
> Without this patch, (total 3868s).
>
> With the patch, (total 588s).
Great...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38584
101 - 114 of 114 matches
Mail list logo
