Re: [Bug target/40473] -mno-sched-prolog breaks function parameter debug location lists
This option should just be removed. Sent from my iPhone On Jun 17, 2009, at 2:21 AM, amodra at bigpond dot net dot au gcc-bugzi...@gcc.gnu.org wrote: --- Comment #1 from amodra at bigpond dot net dot au 2009-06-17 09:21 --- See http://sourceware.org/bugzilla/show_bug.cgi?id=10231 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40473
Re: [Bug c/40366] New: Array + XOR swap fails
Both of these are undefined. Look up about sequence point rules.
Sent from my iPhone
On Jun 7, 2009, at 12:15 AM, ashutosh dot sharma dot 0204 at gmail
dot com gcc-bugzi...@gcc.gnu.org wrote:
Compiler Version:
gcc (GCC) 4.2.4 (Ubuntu 4.2.4-1ubuntu3)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There
is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.
Sample code:
#include stdio.h
int main() {
int a[2];
a[0]=10;
a[1]=20;
printf(a[0] = %d a[1] = %d\n, a[0], a[1]);
a[0]^=a[1]^=a[0]^=a[1];
printf(a[0] = %d a[1] = %d\n, a[0], a[1]);
return 0;
}
gcc test.c -o test -O2
a[0] = 10 a[1] = 20
a[0] = 20 a[1] = 10
gcc test.c -o test -O0
a[0] = 10 a[1] = 20
a[0] = 0 a[1] = 10
Bug: When compiled with -O0 swap fails.
Swap only fails in case of array. Following code works fine with -O0:
#include stdio.h
int main() {
int a, b;
a=10;
b=20;
printf(a = %d b = %d\n, a, b);
a^=b^=a^=b;
printf(a = %d b = %d\n, a, b);
return 0;
}
--
Summary: Array + XOR swap fails
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ashutosh dot sharma dot 0204 at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40366
Re: [Bug bootstrap/39968] New: [4.5 Regression] ./plugin-version.h:11: error: 'gcc_version' defined but not used
Looks like this failson non elf hosts (well darwin supports dlopen so I don't understand why it fails on darwin). Sent from my iPhone On Apr 29, 2009, at 10:19 AM, dominiq at lps dot ens dot fr gcc-bugzi...@gcc.gnu.org wrote: Yet another bootstrap error on i686-apple-darwin9: ... /opt/gcc/i686-darwin/./prev-gcc/xgcc -B/opt/gcc/i686-darwin/./prev- gcc/ -B/opt/gcc/gcc4.5w/i686-apple-darwin9/bin/ -c -g -O2 -fomit-frame- pointer -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing- prototypes -Wcast-qual -Wold-style-definition -Wc++-compat -Wmissing-format- attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength- strings -Werror -fno-common -DHAVE_CONFIG_H -I. -I. -I../../gcc-4.5-work/gcc -I../../gcc-4.5-work/gcc/. -I../../gcc-4.5-work/gcc/../include - I./../intl -I../../gcc-4.5-work/gcc/../libcpp/include -I/sw/include -I../../gcc-4.5-work/gcc/../libdecnumber -I../../gcc-4.5-work/gcc/../libdecnumber/dpd -I../libdecnumber -I/sw/ include -I/sw/include -DCLOOG_PPL_BACKEND ../../gcc-4.5-work/gcc/pointer- set.c -o pointer-set.o cc1: warnings being treated as errors ./plugin-version.h:11: error: 'gcc_version' defined but not used make[3]: *** [plugin.o] Error 1 make[3]: *** Waiting for unfinished jobs rm gcj-dbtool.pod fsf-funding.pod jcf-dump.pod jv-convert.pod grmic.pod gcov.pod gcj.pod gc-analyze.pod gfdl.pod cpp.pod gij.pod gcc.pod gfortran.pod make[2]: *** [all-stage2-gcc] Error 2 make[1]: *** [stage2-bubble] Error 2 make: *** [all] Error 2 -- Summary: [4.5 Regression] ./plugin-version.h:11: error: 'gcc_version' defined but not used Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dominiq at lps dot ens dot fr 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=39968
Re: [Bug libgcj/39747] [4.4/4.5 Regression] libjavamath is linking against libgmp
Sent from my iPhone On Apr 26, 2009, at 11:54 PM, jakub at gcc dot gnu dot org gcc-bugzi...@gcc.gnu.org wrote: --- Comment #3 from jakub at gcc dot gnu dot org 2009-04-27 06:54 --- This doesn't look like a GCC bug, but user error. It is a gcc bug as this dependency is not documented this way. At least I could not find the documention for this one. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39747
Re: [Bug middle-end/39840] Non-optimal (or wrong) implementation of SSE intrinsics
Gcc 4.4 and above supports different target options on the function
level but not on a basic block level. So you can create an interneral
version for AVX.
Sent from my iPhone
On Apr 21, 2009, at 12:37 PM, drepper at redhat dot com gcc-bugzi...@gcc.gnu.org
wrote:
--- Comment #2 from drepper at redhat dot com 2009-04-21 19:37
---
[I couldn't attach the code as an attachment, bugzilla has a bug.]
The program below has to be compiled with -mavx to allow the AVX
intrinsics
being used. But this also triggers using the use of the vmovss
instruction to
load the parameter for the sin() call from memory.
(Forget the reference to memset in the original report, it's as
simple as
passing floating point parameters that triggers the problem.)
#include math.h
#include stdio.h
#include immintrin.h
static unsigned int eax, ebx, ecx, edx;
static int
has_avx (void)
{
if ((ecx (1 27)) == 0)
/* No OSXSAVE. */
return 0;
unsigned int feat_eax, feat_edx;
asm (xgetbv : =a (feat_eax), =d (feat_edx) : c (0));
if ((feat_eax 6) != 6)
return 0;
return (ecx (1 28)) != 0;
}
template typename T, int N
struct vec {
union {
T n[N];
__v4sf f[N / (sizeof (__v4sf) / sizeof (T))];
__v8sf fa[N / (sizeof (__v8sf) / sizeof (T))];
};
};
template typename T, int N
T
optscalar(const vecT,N src1, const vecT,N src2)
{
T r = 0;
for (int i = 0; i N; ++i)
r += src1[i] * src2[i];
return r;
}
template int N
float
optscalar(const vecfloat,N src1, const vecfloat,N src2)
{
if (has_avx ())
{
__m256 tmp = _mm256_setzero_ps ();
for (int i = 0; i N / 8; ++i)
tmp = _mm256_add_ps (tmp, _mm256_mul_ps (src1.fa[i],
src2.fa[i]));
tmp = _mm256_hadd_ps (tmp, tmp);
tmp = _mm256_hadd_ps (tmp, tmp);
tmp = _mm256_hadd_ps (tmp, tmp);
union
{
__m256 v;
float a[8];
} cvt = { tmp };
return cvt.a[0];
}
else
{
__m128 tmp = _mm_setzero_ps ();
for (int i = 0; i N / 4; ++i)
tmp = _mm_add_ps (tmp, _mm_mul_ps (src1.f[i], src2.f[i]));
tmp = _mm_hadd_ps (tmp, tmp);
tmp = _mm_hadd_ps (tmp, tmp);
return __builtin_ia32_vec_ext_v4sf (tmp, 0);
}
}
#define N 10
#define DEF(type) vectype,N v##type##1, v##type##2; type
type##res, type##cmp
DEF(float);
float g;
int
main ()
{
float f = sinf (g);
printf (%g\n, f);
asm volatile (cpuid
: =a (eax), =b (ebx), =c (ecx), =d (edx)
: 0 (1));
float floatres = optscalar (vfloat1, vfloat2);
printf (%g\n, floatres);
return 0;
}
--
drepper at redhat dot com changed:
What|Removed |Added
---
---
--
Status|WAITING |UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39840
Re: [Bug c/39504] New: Incorrect code at -O2 and -O3
Sent from my iPhone
On Mar 19, 2009, at 8:38 AM, jk500500 at yahoo dot com gcc-bugzi...@gcc.gnu.org
wrote:
The attached test program -- which I extracted and simplified from the
'176.gcc'
SPEC2000 benchmark -- is compiled incorrectly at -O2 and -O3. The
code is
correct at -O1 and -O0.
The bad code I am reporting here is produced by a MIPS gcc-4.3.3
cross-compiler.
However, I see the same problem with an in-house port of gcc-4.3.3
to an
in-house-developed CPU, so I believe the problem is generic to GCC and
not specific to the MIPS version.
I am attaching the complete testcase (a self-contained C file), but
the
problem is specifically with this C code:
rtx
rtx_alloc (enum rtx_code jsk_code_arg) {
rtx rt;
struct obstack *ob = rtl_obstack;
int length;
_obstack_newchunk(ob);
rt = (rtx)ob-object_base;
length = (sizeof (struct rtx_def) - sizeof (rtunion) - 1) /
sizeof (int);
for (; length = 0; length--) {
((int *) rt)[length] = 0;
}
This is undefined code. The code in spec is known to violate C90/C99/C+
+98 aliasing rules.
#ifdef WORKAROUND
/* If enabled, will fix the issue */
__asm__ __volatile__ ( sll r0,r0,0 );
#endif
rt-jsk_code_val = jsk_code_arg;
return rt;
}
The rt-jsk_code_val = jsk_code_arg assignment is incorrectly
dropped
from the generated code. As the comment in the C code indicates, if I
insert a volatile asm statement between the zero'ing of the *rt struct
and the jsk_code_val assignment, correct code results at all
optimization
levels.
At -O2, the MIPS assembly code is below. There is a 'sw' (store 32-
bit word)
instruction near the end that results in the jsk_code_val field being
set to zero rather than to the value of jsk_code_arg.
rtx_alloc:
.frame $sp,16,$31 # vars= 0, regs= 3/0, args=
0, gp= 0
.mask 0x8003,-4
.fmask 0x,0
.setnoreorder
.setnomacro
addiu $sp,$sp,-16
sw $16,4($sp)
lui $16,%hi(rtl_obstack)
addiu $4,$16,%lo(rtl_obstack)
addiu $16,$16,%lo(rtl_obstack)
sw $31,12($sp)
jal _obstack_newchunk
sw $17,8($sp)
lw $2,8($16)
lw $31,12($sp)
lw $17,8($sp)
lw $16,4($sp)
sw $0,4($2)
sw $0,0($2) --- Writes 'jsk_code_val' to zero
j $31
addiu $sp,$sp,16
With the WORKAROUND define enabled, the code becomes as shown
below. Now
there is the correct 'sh' (store 16-bit halfword) instruction to set
jsk_code_arg to the value of jsk_code_val.
rtx_alloc:
.frame $sp,16,$31 # vars= 0, regs= 3/0, args=
0, gp= 0
.mask 0x8003,-4
.fmask 0x,0
addiu $sp,$sp,-16
sw $16,4($sp)
lui $16,%hi(rtl_obstack)
sw $17,8($sp)
move$17,$4
addiu $4,$16,%lo(rtl_obstack)
sw $31,12($sp)
.setnoreorder
.setnomacro
jal _obstack_newchunk
addiu $16,$16,%lo(rtl_obstack)
.setmacro
.setreorder
lw $2,8($16)
sw $0,4($2)
sw $0,0($2)
#APP
# 78 ./gcc0.c 1
sll r0,r0,0
# 0 2
#NO_APP
lw $31,12($sp)
sh $17,0($2)- sets jsk_code_val to
jsk_code_arg
lw $16,4($sp)
lw $17,8($sp)
.setnoreorder
.setnomacro
j $31
addiu $sp,$sp,16
--
Summary: Incorrect code at -O2 and -O3
Product: gcc
Version: 4.3.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jk500500 at yahoo dot com
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: mipsisa32-unknown-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39504
Re: [Bug c/39493] New: [Mips] No space for arguments when implicitely calling __get_tls_addr
Sent from my iPhone
On Mar 18, 2009, at 7:05 AM, joel dot porquet at gmail dot com gcc-bugzi...@gcc.gnu.org
wrote:
Mips ABI specifies to let the space for 4 arguments in stack when
calling a
function. This is not respected when accessing tls variable with a
dynamic
model: gcc implicitely calls __get_tls_addr without making rooms for
the
arguments. The top of the stack is then likely to be erase.
__get_tls_addr is a special function and does not have to follow that
part of the ABI but a different part which should be documented about
tls and dynamic tls.
Here is an example:
- test.c:
extern void* __get_tls_addr(void*);
extern __thread int a;
void func(void)
{
a++;
}
Compiled and linked with:
mipsel-unknown-elf-gcc -fpic -mshared -nostdinc -nostdlib -fno-
builtin -mips2
-EL -mabicalls -G0 -c -o test.o test.c
mipsel-unknown-elf-ld -shared test.o -o test.so
Result in assembly:
5ffe0390 func:
5ffe0390: 3c1c0001lui gp,0x1
5ffe0394: 279c9090addiu gp,gp,-28528
5ffe0398: 0399e021addugp,gp,t9
5ffe039c: 27bdffe8addiu sp,sp,-24
5ffe03a0: afbf0014sw ra,20(sp)
5ffe03a4: afbe0010sw s8,16(sp)
5ffe03a8: afbcsw s0,12(sp)
5ffe03ac: 03a0f021moves8,sp
5ffe03b0: afbcsw gp,0(sp)
5ffe03b4: 8f99802clw t9,-32724(gp)
5ffe03b8: 27848030addiu a0,gp,-32720
5ffe03bc: 0320f809jalrt9
5ffe03c0: nop
5ffe03c4: 8fdclw gp,0(s8)
5ffe03c8: 8c42lw v0,0(v0)
...
We can see than $gp is saved directly at the top of the stack
0($sp), and is
likely to be erase in the callee function.
A temporarily workaround is to insert a real function call in the
same function
which uses a tls variable.
Example:
extern void* __get_tls_addr(void*);
extern __thread int a;
static inline void fake(void){}
void func(void)
{
fake();
a++;
}
This result is then:
5ffe0390 func:
5ffe0390: 3c1c0001lui gp,0x1
5ffe0394: 279c90c0addiu gp,gp,-28480
5ffe0398: 0399e021addugp,gp,t9
5ffe039c: 27bdffd8addiu sp,sp,-40
5ffe03a0: afbf0024sw ra,36(sp)
5ffe03a4: afbe0020sw s8,32(sp)
5ffe03a8: afb0001csw s0,28(sp)
5ffe03ac: 03a0f021moves8,sp
5ffe03b0: afbc0010sw gp,16(sp)
5ffe03b4: 8f828018lw v0,-32744(gp)
5ffe03b8: 24590418addiu t9,v0,1048
5ffe03bc: 0320f809jalrt9
5ffe03c0: nop
5ffe03c4: 8fdc0010lw gp,16(s8)
...
We can now see that $gp is stored at 16($sp), which gives the
required spare
space for the 4 arguments in stack.
--
Summary: [Mips] No space for arguments when implicitely
calling
__get_tls_addr
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: joel dot porquet at gmail dot com
GCC host triplet: i486-linux-gnu
GCC target triplet: mipsel-unknown-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39493
Re: [Bug libfortran/39467] New: [4.4 regression] __iso_c_binding_c_f_procpoin...@gfortran_1.0 missing in libgfortran
Sent from my iPhone On Mar 15, 2009, at 2:02 PM, doko at ubuntu dot com gcc-bugzi...@gcc.gnu.org wrote: The shared library libgfortran.so.3 in 4.3.x has the __iso_c_binding_c_f_procpoin...@gfortran_1.0 symbol exported. This symbol is missing in 4.4.0 20090315. I think this symbol was never used (from the fortran front-end) so removing is ok. Also I think there is a duplicated bug about this already. -- Summary: [4.4 regression] __iso_c_binding_c_f_procpoin...@gfortran_1.0 missing in libgfortran Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: doko at ubuntu dot com GCC target triplet: i486-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39467
Re: [Bug middle-end/39460] New: strange aliasing warnings compiling pymol under gcc 4.4
Sent from my iPhone On Mar 13, 2009, at 9:11 PM, howarth at nitro dot med dot uc dot edu gcc-bugzi...@gcc.gnu.org wrote: There are a number of aliasing warnings coming out of tree-ssa- structalias.c when compiling code in pymol which uses their endianswap.h header at -O3 -Wall. The warnings are of the form... In file included from gromacsplugin.cpp:34: endianswap.h: In function ‘int put_trx_real(md_file*, float)’: endianswap.h:117: warning: dereferencing pointer ‘N’ does break strict-aliasing rules endianswap.h:115: note: initialized from here endianswap.h: In function ‘int trx_real(md_file*, float*)’: endianswap.h:143: warning: dereferencing pointer ‘N’ does break strict-aliasing rules endianswap.h:135: warning: dereferencing pointer ‘N’ does break strict-aliasing rules endianswap.h:128: note: initialized from here endianswap.h:144: warning: dereferencing pointer ‘anonymous’ does break strict-aliasing rules endianswap.h:139: warning: dereferencing pointer ‘anonymous’ does break strict-aliasing rules endianswap.h:139: note: initialized from here endianswap.h: In function ‘int write_trr_timestep(void*, const molfile_timestep_t*)’: endianswap.h:117: warning: dereferencing pointer ‘N’ does break strict-aliasing rules endianswap.h:115: note: initialized from here endianswap.h:117: warning: dereferencing pointer ‘N’ does break strict-aliasing rules endianswap.h:115: note: initialized from here and don't occur under gcc 4.3. I am wondering if these are valid warnings or a bug in gcc 4.4? I am attaching the preprocessed source for gromacsplugin.ii. The weird part is that just compiling the contents of endianswap.h doesn't trigger the warnings. Also many files in pymol use this header and the errors appear rather randomly among them. Also I have never seen the 'does break' warning from tree-ssa-structalias.c, but only the 'will break' warning from c-common.c. Inling causes warning to show up. The warning is correct though as the access is via a short but the original type is float. -- Summary: strange aliasing warnings compiling pymol under gcc 4.4 Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: howarth at nitro dot med dot uc dot edu 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=39460
Re: [Bug driver/39439] The Driver hides undefined reference messages from shared libs (but not object files) in linker phase
Sent from my iPhone On Mar 13, 2009, at 8:54 PM, rob1weld at aol dot com gcc-bugzi...@gcc.gnu.org wrote: --- Comment #2 from rob1weld at aol dot com 2009-03-14 03:54 --- (In reply to comment #1) Subject: Re: New: The Driver hides undefined reference messages from shared libs (but not object files) in linker phase Sent from my iPhone Hurray for Phones with large screens. On Mar 11, 2009, at 9:27 PM, rob1weld at aol dot com gcc-bugzi...@gcc.gnu.org wrote: The Driver hides undefined reference messages from shared libs but not from object files. This seems inconsistent and is not helpful. Why do you think the driver is doing instead of the linker? The linker, upon 'discovering' the problem, simply prints: ../../interfaces/C/.libs/libppl_c.so: undefined reference to `typeinfo for int' collect2: ld returned 1 exit status The linker is suppressing the undefined reference in the first place when creating the .so. I think this is a bug in ppl's make file and not gcc. By using the Objects, instead of the Shared Library, I force it to make the discovery early and report ALL the details instead of trying to unmangle the C++, resulting in this more verbose message: ../../interfaces/C/.libs/ppl_c__BD_Shape_mpq_class.o: In function `sgnParma_Polyhedra_Library::Checked_Number__gmp_expr__mpz_struct [1], __mpz_struct [1], Parma_Polyhedra_Library::Extended_Number_Policy ': /usr/share/src/ppl-build/interfaces/C/../../src/ppl.hh:11187: undefined reference to `typeinfo for int' My ld is: # ld --version GNU ld (GNU Binutils) 2.19.1 I'm building with -g and the Shared Library is not stripped: # file /usr/share/src/ppl-build/interfaces/C/.libs/libppl_c.so /usr/share/src/ppl-build/interfaces/C/.libs/libppl_c.so:ELF 32-bit LSB dynamic lib 80386 Version 1, dynamically linked, not stripped I say it is the Driver and not xgcc / gcc, or ld since if the Driver took the _ridiculous_ step of noticing the Linker error and re-running the compile (using the objects used to create the Shared Library) the the Driver could produce the more verbose output that I RFE'd in favour of. Notice I mentioned that actually implementing that behavior by re-running the compiler is not efficient. Using -g needs to pass _more_ info to the Linker, to be included in the Shared Libraries produced, so that if there is a Linker error then 'ld' can reference the source code where the error was caused and display it. The way we are producing Shared Libraries gives us very terse error messages that seem as though the Shared Library were stripped (when they are not). Is there a problem with the manner in which the PPL source is written ? I'm not very fluent in C++. Rob -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39439
Re: [Bug driver/39439] New: The Driver hides undefined reference messages from shared libs (but not object files) in linker phase
Sent from my iPhone On Mar 11, 2009, at 9:27 PM, rob1weld at aol dot com gcc-bugzi...@gcc.gnu.org wrote: The Driver hides undefined reference messages from shared libs but not from object files. This seems inconsistent and is not helpful. Why do you think the driver is doing instead of the linker? When compiling 'ppl' using the Trunk I'm getting a terse message about undefined reference to `typeinfo for int'. This is not particularly useful since the words are common (can't grep for them) and there is no line number info explaining the location of the code that causes this issue. This page may suggest a reason this error occurs: http://stackoverflow.com/questions/307352/g-undefined-reference-to-typeinfo I'm calling this an RFE since I desire an increase in verbosity but there are no doubt arguments favoring this being a Bug. # gcc -v Using built-in specs. Target: i386-pc-solaris2.11 Configured with: ../gcc_trunk/configure --prefix=/usr/local/gcc4 --enable-languages=ada,c,c++,fortran,java,objc,obj-c++ --enable-shared --disable-static --enable-multilib --enable-decimal-float --with-long-double-128 --with-included-gettext --disable-stage1- checking --enable-checking=release --with-tune=k8 --with-cpu=k8 --with-arch=k8 --with-gnu-as --with-as=/usr/local/bin/as --with-gnu-ld --with-ld=/usr/local/bin/ld --with-gmp=/usr/local --with-mpfr=/usr/ local --without-ppl Thread model: posix gcc version 4.4.0 20090309 (experimental) [trunk revision 144720] (GCC) # gmake ... gmake[4]: Entering directory `/usr/share/src/ppl-build/demos/ ppl_lpsol' gcc -DHAVE_CONFIG_H -I. -I../../../ppl/demos/ppl_lpsol -I../.. -I../../interfaces/C -I/usr/local/include -pedantic -std=gnu89 - Werror -g -O3 -fomit-frame-pointer -march=k8 -frounding-math -W -Wall -MT ppl_lpsol.o -MD -MP -MF .deps/ppl_lpsol.Tpo -c -o ppl_lpsol.o ../../../ppl/demos/ppl_lpsol/ppl_lpsol.c mv -f .deps/ppl_lpsol.Tpo .deps/ppl_lpsol.Po /bin/sh ../../libtool --tag=CXX --mode=link g++ -g -O3 -fomit- frame-pointer -march=k8 -frounding-math -W -Wall -o ppl_lpsol ppl_lpsol.o dummy.o -lglpk ../../interfaces/C/libppl_c.la -lm -L/usr/local/lib -lgmpxx -L/usr/ local/lib -lgmp -R/usr/local/lib -R/usr/local/lib libtool: link: g++ -g -O3 -fomit-frame-pointer -march=k8 -frounding- math -W -Wall -o .libs/ppl_lpsol ppl_lpsol.o dummy.o /usr/local/lib/ libglpk.so -lz ../../interfaces/C/.libs/libppl_c.so -L/usr/local/lib /usr/share/src/ppl-build/src/.libs/libppl.so /usr/local/lib/libstdc+ +.so /usr/local/lib/libgmpxx.so /usr/local/gcc4/lib/libstdc++.so -lm /usr/local/lib/libgmp.so -Wl,-rpath -Wl,/usr/local/lib -Wl,-rpath -Wl,/usr/local/gcc4/lib ../../interfaces/C/.libs/libppl_c.so: undefined reference to `typeinfo for int' collect2: ld returned 1 exit status gmake[4]: *** [ppl_lpsol] Error 1 gmake[4]: Leaving directory `/usr/share/src/ppl-build/demos/ppl_lpsol' If I run that using -v I get this collect command: /usr/local/gcc4/libexec/gcc/i386-pc-solaris2.11/4.4.0/collect2 -V -m elf_i386 -Y P,/usr/ccs/lib:/usr/lib -Qy -o .libs/ppl_lpsol /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/values-Xa.o /usr/local/gcc4/lib/gcc/i386-pc-solaris2.11/4.4.0/crtbegin.o -L/usr/ local/lib -L/usr/local/gcc4/lib/gcc/i386-pc-solaris2.11/4.4.0 -L/usr/local/gcc4/lib/gcc/i386-pc-solaris2.11/4.4.0/../../.. ppl_lpsol.o dummy.o --verbose /usr/local/lib/libglpk.so -lz ../../interfaces/C/.libs/libppl_c.so /usr/share/src/ppl-build/src/.libs/libppl.so /usr/local/lib/libstdc+ +.so /usr/local/lib/libgmpxx.so /usr/local/gcc4/lib/libstdc++.so /usr/local/lib/libgmp.so -rpath /usr/local/lib -rpath /usr/local/ gcc4/lib -lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc /usr/local/gcc4/lib/gcc/i386-pc-solaris2.11/4.4.0/crtend.o /usr/lib/ crtn.o If I run that then I get this simple and useless output: ../../interfaces/C/.libs/libppl_c.so: undefined reference to `typeinfo for int' collect2: ld returned 1 exit status If I run that exact same command but make a simple alteration: - ... -lz ../../interfaces/C/.libs/libppl_c.so + ... -lz ../../interfaces/C/.libs/*.o I can use the Object files that were used to create the Shared Library instead of using the Shared Library. This is useful (due to this Bug or needed RFE) since the error messages printed are by _far_ more useful, see: # /usr/local/gcc4/libexec/gcc/i386-pc-solaris2.11/4.4.0/collect2 -V - m elf_i386 -Y P,/usr/ccs/lib:/usr/lib -Qy -o .libs/ppl_lpsol /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/values-Xa.o /usr/local/gcc4/lib/gcc/i386-pc-solaris2.11/4.4.0/crtbegin.o -L/usr/ local/lib -L/usr/local/gcc4/lib/gcc/i386-pc-solaris2.11/4.4.0 -L/usr/local/gcc4/lib/gcc/i386-pc-solaris2.11/4.4.0/../../.. ppl_lpsol.o dummy.o /usr/local/lib/libglpk.so -lz ../../interfaces/C/.libs/*.o /usr/share/src/ppl-build/src/.libs/libppl.so /usr/local/lib/libstdc+ +.so /usr/local/lib/libgmpxx.so /usr/local/gcc4/lib/libstdc++.so /usr/local/lib/libgmp.so -rpath /usr/local/lib -rpath /usr/local/ gcc4/lib -lstdc++ -lm
Re: [Bug c/39403] Excessive optimization issue
Sent from my iPhone On Mar 9, 2009, at 8:36 AM, rguenth at gcc dot gnu dot org gcc-bugzi...@gcc.gnu.org wrote: --- Comment #1 from rguenth at gcc dot gnu dot org 2009-03-09 15:36 --- You need to specify that the registers are clobbered by the asm. The only way to do that is to use output constraints (+D, +c, etc.) on proper temporaries. int lent = len; char *dstt = dst; char *srct = src; __asm__ __volatile__( cld\n\t rep movsb : +c (lent), +D(dstt), +S(src) ); Otherwise GCC thinks the registers still hold the original value. Oh and mark this inline-ask as clobbering memory. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added --- --- -- Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39403
Re: [Bug c++/39407] Parse error in stack when user declares template-name c
Sent from my iPhone On Mar 9, 2009, at 8:40 AM, rguenth at gcc dot gnu dot org gcc-bugzi...@gcc.gnu.org wrote: --- Comment #7 from rguenth at gcc dot gnu dot org 2009-03-09 15:40 --- I think this is more likely a C++ frontend issue. At least I cannot believe this behavior is mandated by the std ;) Jason? There is a dup of this bug somewhere also. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added --- --- -- CC||jason at redhat dot com Component|libstdc++ |c++ Keywords||rejects-valid http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39407
Re: [Bug other/39400] New: Dist tarball missing file gengtype-lex.c
Sent from my iPhone On Mar 8, 2009, at 1:28 PM, skunk at iskunk dot org gcc-bugzi...@gcc.gnu.org wrote: Bootstrapping gcc-4.4-20090306(.tar.bz2) on Tru64 fails with This is a snapshot so it does not have all of generated files that a release will have. So this bug is invalid. flex -ogengtype-lex.c /tmp/gcc-4.4-20090306/gcc/gengtype-lex.l flex: unknown flag 'o' gmake[3]: [gengtype-lex.c] Error 1 (ignored) cc -std1 -c -g -DIN_GCC-DHAVE_CONFIG_H -DGENERATOR_FILE -I. - Ibuild -I/usr/home/cport/tmp/gcc-4.4-20090306/gcc -I/usr/home/cport/tmp/gcc-4.4-20090306/gcc/build -I/usr/home/cport/tmp/gcc-4.4-20090306/gcc/../include -I/usr/home/cport/tmp/gcc-4.4-20090306/gcc/../libcpp/include -I/tg/freeport/arch/tru64/include -I/tg/freeport/arch/tru64/include -I/usr/home/cport/tmp/gcc-4.4-20090306/gcc/../libdecnumber -I/usr/home/cport/tmp/gcc-4.4-20090306/gcc/../libdecnumber/dpd -I../libdecnumber-o build/gengtype-lex.o gengtype-lex.c cc: Severe: No such file or directory ... file is 'gengtype-lex.c' gmake[3]: *** [build/gengtype-lex.o] Error 1 gmake[3]: Leaving directory `/mnt/scratch/build/gcc-build/gcc' gmake[2]: *** [all-stage1-gcc] Error 2 gmake[2]: Leaving directory `/mnt/scratch/build/gcc-build' gmake[1]: *** [stage1-bubble] Error 2 gmake[1]: Leaving directory `/mnt/scratch/build/gcc-build' gmake: *** [bootstrap] Error 2 gengtype-lex.c should not have to be generated, obviously. P.S.: Here we also see an issue where the system's ancient version of flex (I don't even know the version number, as it doesn't have an option to print it) doesn't work the way that the makefile expects. Should I file a separate bug, for the configure script to check beforehand whether flex supports the -o option? -- Summary: Dist tarball missing file gengtype-lex.c Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: skunk at iskunk dot org GCC build triplet: alphaev56-dec-osf4.0g GCC host triplet: alphaev56-dec-osf4.0g GCC target triplet: alphaev56-dec-osf4.0g http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39400
Re: [Bug middle-end/39333] gcc 4.3.3 miscompiles when -finline-small-functions is used
Sent from my iPhone On Mar 6, 2009, at 8:30 PM, galtgendo at o2 dot pl gcc-bugzi...@gcc.gnu.org wrote: --- Comment #16 from galtgendo at o2 dot pl 2009-03-07 04:30 --- OK, I've done a little test and I'd like to know, if it's results actually mean anything: I've compiled freeciv with CFLAGS=-O2 -finline-functions -fno-guess-branch-probability and it did not crash. Does the above confirm that the problem lies in -fguess-branch- probability ? Not really because that option only generates information used by other optimazations. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39333
Re: [Bug middle-end/39298] Optimize away only set but not used variable
Sent from my iPhone
On Feb 25, 2009, at 1:43 AM, rguenth at gcc dot gnu dot org gcc-bugzi...@gcc.gnu.org
wrote:
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-02-25
09:43 ---
Is there a reason the Fortran frontend gives function local
variables static
storage duration?
Yes, it is larger than the threshhold. Remember fortran has no
recursive functions except for the ones which marked as such.
a ()
{
struct __st_parameter_dt dt_parm.1;
static integer(kind=4) options.0[8] = {68, 255, 0, 0, 0, 1, 0, 1};
static complex(kind=4) foo[2147483647];
bb 2:
_gfortran_set_options (8, options.0);
foo[9] = __complex__ (1.0e+0, 0.0);
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
---
--
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2009-02-25 09:43:40
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39298
Re: [Bug target/39226] New: [4.4 Regression] gcc_assert (verify_initial_elim_offsets ()); ICE
This is mostly likely due to my no micro code patch. I see what causes
it tommorow.
Sent from my iPhone
On Feb 17, 2009, at 11:55 PM, jakub at gcc dot gnu dot org gcc-bugzi...@gcc.gnu.org
wrote:
/* { dg-do compile } */
/* { dg-options -O2 } */
/* { dg-options -O2 -mtune=cell -mminimal-toc { target { powerpc*-
*-* lp64
} } } */
struct A
{
char *a;
unsigned int b : 1;
unsigned int c : 31;
};
struct B
{
struct A *d;
};
void
foo (struct B *x, unsigned long y)
{
if (x-d[y].c)
return;
if (x-d[y].b)
x-d[y].a = 0;
}
ICEs with -m64 -O2 -mtune=cell -mminimal-toc, as elimination offsets
change.
--
Summary: [4.4 Regression] gcc_assert
(verify_initial_elim_offsets
()); ICE
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
GCC target triplet: powerpc64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39226
Re: [Bug c++/39208] New: Incorrect mangled name for function as template argument
Yes this known I forgot the bug number but try with -fabi-version=0.
Sent from my iPhone
On Feb 16, 2009, at 2:07 PM, dgregor at gcc dot gnu dot org gcc-bugzi...@gcc.gnu.org
wrote:
Given the following code:
templateint (p)(int, int) struct X { };
int f(int, int) { }
void g(Xf) { }
GCC produces the mangled name:
_Z1g1XILZ1fiiEE
for the function 'g'. However, the correct mangled name is:
_Z1g1XIL_Z1fiiEE
GCC is missing the '_' prior to the 'Z' in the mangled name of the
template
argument 'f'.
--
Summary: Incorrect mangled name for function as template
argument
Product: gcc
Version: 4.3.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dgregor at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39208
Re: [Bug c++/36607] [4.3/4.4 Regression] Incorrect type diagnostic on substracting casted char pointers
Sent from my iPhone On Feb 3, 2009, at 5:56 AM, bonzini at gnu dot org gcc-bugzi...@gcc.gnu.org wrote: --- Comment #7 from bonzini at gnu dot org 2009-02-03 13:56 --- ping? The patch was just approved last night and I will be applying it when I get into work today. -- bonzini at gnu dot org changed: What|Removed |Added --- --- -- CC||bonzini at gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36607
Re: [Bug libfortran/39083] stage 3 libgfortran build fails
Sent from my iPhone On Feb 2, 2009, at 8:33 PM, tony_eckert at umsl dot edu gcc-bugzi...@gcc.gnu.org wrote: --- Comment #1 from tony_eckert at umsl dot edu 2009-02-03 04:33 --- appears similar to bug 37865, but without --enable-intermodule. Only departure from defaults is --prefix Are you building in the source tree? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39083
Re: [Bug middle-end/39015] [4.3 regression] wrong code building libgsf
Sent from my iPhone On Jan 29, 2009, at 2:01 AM, rguenth at gcc dot gnu dot org gcc-bugzi...@gcc.gnu.org wrote: --- Comment #3 from rguenth at gcc dot gnu dot org 2009-01-29 10:01 --- The best option would be to revert that patch on the branch. Except it alone could not cause wrong code. Some other pass is causing it. And then again with a testcase it is hard to figure out what is going wrong. That patch just disables one small optimization in one case. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added --- --- -- CC||sje at gcc dot gnu dot org, ||rguenth at gcc dot gnu dot ||org Priority|P3 |P1 Target Milestone|--- |4.3.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39015
Re: [Bug c/39036] New: Decimal floating-point exception flags done wrong
Sent from my iPhone
On Jan 29, 2009, at 6:00 PM, tydeman at tybor dot com gcc-bugzi...@gcc.gnu.org
wrote:
Using gcc 4.3.2-7 on Intel Pentium 4 running Linux Fedora Core 10 and
-std=gnu99
There were some dfp fixes on the trunk relating to fp exceptions so
you should try the trunk before reporting any more bugs.
/* DFP TR 24732 == WG14 / N1176, N1312 */
#define __STDC_WANT_DEC_FP__ /* Tell implementation that we want
Decimal FP */
#pragma STDC FENV_ACCESS ON /* will be testing FP exception
flags */
#include stdio.h /* printf() */
#include fenv.h /* fetestexcept(), FE_* */
#include float.h /* DEC*_MIN, DEC*_MAX */
int main(void){
_Decimal64 d10;
int before;
int after;
before = feclearexcept( FE_ALL_EXCEPT );
d10 = 1.0DD;
d10 /= 3.0DD;
after = fetestexcept( FE_ALL_EXCEPT );
if( FE_INEXACT after ){
printf(Inexact raised as expected\n);
}else{
printf(Inexact wrong; after=%i\n, after);
}
before = feclearexcept( FE_ALL_EXCEPT );
d10 = DEC64_MIN;
d10 *= d10;
after = fetestexcept( FE_ALL_EXCEPT );
if( FE_UNDERFLOW after ){
printf(Underflow raised as expected\n);
}else{
printf(Underflow wrong; after=%i\n, after);
}
before = feclearexcept( FE_ALL_EXCEPT );
d10 = DEC64_MAX;
d10 *= d10;
after = fetestexcept( FE_ALL_EXCEPT );
if( FE_OVERFLOW after ){
printf(Overflow raised as expected\n);
}else{
printf(Overflow wrong; after=%i\n, after);
}
before = feclearexcept( FE_ALL_EXCEPT );
d10 = DEC64_MIN;
d10 /= (d10-d10);
after = fetestexcept( FE_ALL_EXCEPT );
if( FE_DIVBYZERO after ){
printf(Divbyzero raised as expected\n);
}else{
printf(Divbyzero wrong; after=%i\n, after);
}
before = feclearexcept( FE_ALL_EXCEPT );
d10 = 0.0e-15DD;
d10 /= d10;
after = fetestexcept( FE_ALL_EXCEPT );
if( FE_INVALID after ){
printf(Invalid raised as expected\n);
}else{
printf(Invalid wrong; after=%i\n, after);
}
printf(%2i = FE_INEXACT\n, FE_INEXACT);
printf(%2i = FE_UNDERFLOW\n, FE_UNDERFLOW);
printf(%2i = FE_OVERFLOW\n, FE_OVERFLOW);
printf(%2i = FE_DIVBYZERO\n, FE_DIVBYZERO);
printf(%2i = FE_INVALID\n, FE_INVALID);
return 0;
}
gets:
Inexact wrong; after=0
Underflow wrong; after=0
Overflow wrong; after=32
Divbyzero wrong; after=0
Invalid wrong; after=0
32 = FE_INEXACT
16 = FE_UNDERFLOW
8 = FE_OVERFLOW
4 = FE_DIVBYZERO
1 = FE_INVALID
--
Summary: Decimal floating-point exception flags done wrong
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tydeman at tybor dot com
GCC host triplet: 4.3.2
GCC target triplet: 4.3.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39036
Re: [Bug tree-optimization/38984] [4.2/4.3/4.4 Regression] NULL pointers always considered distinct by PTA, even with -fno-delete-null-pointer-checks
Sent from my iPhone
On Jan 27, 2009, at 3:02 AM, bonzini at gnu dot org gcc-bugzi...@gcc.gnu.org
wrote:
--- Comment #1 from bonzini at gnu dot org 2009-01-27 11:02
---
This simple patch is not enough:
Index: tree-ssa-structalias.c
===
--- tree-ssa-structalias.c (revision 142960)
+++ tree-ssa-structalias.c (working copy)
@@ -3030,8 +3030,14 @@ get_constraint_for_1 (tree t, VEC (ce_s,
happens below, since it will fall into the default case. The only
case we know something about an integer treated like a pointer is
when it is the NULL pointer, and then we just say it points to
- NULL. */
- if (TREE_CODE (t) == INTEGER_CST
+ NULL.
+
+ Do not do that if -fno-delete-null-pointer-checks though,
because
+ in that case *NULL does not fail, so it _should_ alias
*anything.
+ It is not worth adding a new option or renaming the existing
one,
+ since this case is relatively obscure. */
+ if (flag_delete_null_pointer_checks
+ TREE_CODE (t) == INTEGER_CST
integer_zerop (t))
{
temp.var = nothing_id;
We get:
ANYTHING = ANYTHING
ESCAPED = *ESCAPED
NONLOCAL = ESCAPED
INTEGER = ANYTHING
derefaddrtmp.8 = NONLOCAL
*ESCAPED = derefaddrtmp.8
p = NONLOCAL
...
NULL = { }
ANYTHING = { ANYTHING }
READONLY = { READONLY }
ESCAPED = { }
NONLOCAL = { ESCAPED }
CALLUSED = { }
INTEGER = { ANYTHING }
derefaddrtmp.7 = { ESCAPED }
derefaddrtmp.8 = { NONLOCAL }
p = same as derefaddrtmp.8
...
Updating SSA information for statement a_2 = *p_1(D);
Updating SSA information for statement D.1236_4 = *p_1(D);
...
VUSE operands 2 8b
VDEF operands 0 0b
...
# VUSE SMT.9D.1248_6(D) { SMT.9D.1248 }
aD.1233_2 = *pD.1230_1(D);
*0B ={v} 5;
# VUSE SMT.9D.1248_6(D) { SMT.9D.1248 }
D.1236_4 = *pD.1230_1(D);
D.1235_5 = D.1236_4 == aD.1233_2;
return D.1235_5;
Note there is no vdef, so FRE comes and removes the second load.
If that patch is not enough and the above is happening we are going to
have issues wit volatiles also.
--
bonzini at gnu dot org changed:
What|Removed |Added
---
---
--
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2009-01-27 11:02:25
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38984
Re: [Bug tree-optimization/38985] New: [4.2/4.3/4.4 Regression] missing constraints for pointers accessed directly via their address
Sent from my iPhone
On Jan 27, 2009, at 3:15 AM, bonzini at gnu dot org gcc-bugzi...@gcc.gnu.org
wrote:
This testcase fails:
/* { dg-do compile } */
/* { dg-options -O2 -fdump-tree-optimized } */
int f(int *p)
{
int a = *p;
int *q = (int *)0xDEADBEE0;
*q = 5;
return *p == a;
}
/* { dg-final { scan-tree-dump-times = \\\*p 2 optimized } } */
/* { dg-final { scan-tree-dump-not return 1 optimized } } */
/* { dg-final { cleanup-tree-dump optimized } } */
Unlike PR38984 it does not require -fno-delete-null-pointer-checks.
Volatile addresses also don't have vops on them. As I mentioned in
the other bug. So this is also a bug for volatiles.
--
Summary: [4.2/4.3/4.4 Regression] missing constraints for
pointers accessed directly via their address
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bonzini at gnu dot org
OtherBugsDependingO 38984
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38985
Re: [Bug c/38961] if () block not true but a command in it is still in effect
Sent from my iPhone On Jan 24, 2009, at 2:24 PM, jellegeerts at gmail dot com gcc-bugzi...@gcc.gnu.org wrote: --- Comment #6 from jellegeerts at gmail dot com 2009-01-24 22:24 --- Seems reasonable, though I'd vote for -Wall to include -Winit-self. I actually discovered this because of a bug I found in lxpanel. Now of course it's the fault of those developers not to use -Winit-self, but seen the other options that -Wall enables, it seems reasonable to also enable - Winit-self. Except -Winit-self is there because we decided a long time ago initing the variable by itself is a way to disable the uninitization warning. In fact before 3.4 there was no way to get this warning (oh I added this option:) ). Thanks, Andrew Pinsky -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38961
Re: [Bug middle-end/38932] ICE in set_value_range, at tree-vrp.c:398
Sent from my iPhone On Jan 22, 2009, at 1:00 AM, bonzini at gnu dot org gcc-bugzi...@gcc.gnu.org wrote: --- Comment #4 from bonzini at gnu dot org 2009-01-22 09:00 --- In PRE there is a fold_convert_const_int_from_int call simplifying (signed char) 249 to -7, but setting the TREE_OVERFLOW flag in the meanwhile. I don't think it makes sense to set the overflow flag on a NOP: Yes but changing that right now opens lots of bags of worms. It has been tried before. The simple way to fix this is in pre unset TREE_OVERFLOW because at this point in the IR it does not matter. I hope someone would change vrp to do the correct thing but I guess that won't happen any time soon. Thanks, Andrew Pinski * `The result of, or the signal raised by, converting an integer to a signed integer type when the value cannot be represented in an object of that type (C90 6.2.1.2, C99 6.3.1.3).' For conversion to a type of width N, the value is reduced modulo 2^N to be within range of the type; no signal is raised. (Integers implementation, from the gcc manual). -- bonzini at gnu dot org changed: What|Removed |Added --- --- -- CC||rguenth at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38932
Re: [Bug target/38941] New: CX isn't preserved with shift
Sent from my iPhone
On Jan 22, 2009, at 5:54 PM, hjl dot tools at gmail dot com gcc-bugzi...@gcc.gnu.org
wrote:
On x86, CX is used for shift. If CX is used for a variable, it
may not be preserved with shift:
[...@gnu-9 reg-1]$ cat r.c
extern void abort (void);
void
foo (int x)
{
if (x != 8)
abort ();
}
void
bar (int g)
{
register int x __asm__(ecx);
x = 5;
foo (1 g);
I think this code is undefined as the register variable is not used in
an inline-asm.
if (x != 5)
abort ();
}
int
main ()
{
bar (3);
return 0;
}
[...@gnu-9 reg-1]$ make r0
/export/build/gnu/gcc/build-i686-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-i686-linux/gcc/ -m32 -O0 r.c -o r0
[...@gnu-9 reg-1]$ ./r0
Aborted
[...@gnu-9 reg-1]$
--
Summary: CX isn't preserved with shift
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: ra
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=38941
Re: [Bug target/38941] CX isn't preserved with shift
Sent from my iPhone
On Jan 22, 2009, at 8:34 PM, hjl dot tools at gmail dot com gcc-bugzi...@gcc.gnu.org
wrote:
--- Comment #2 from hjl dot tools at gmail dot com 2009-01-23
04:34 ---
How about this one:
---
extern void abort (void);
void
foo (int x)
{
if (x != 8)
abort ();
}
void
bar (int g)
{
register int x __asm__(ecx);
register int y __asm__(eax);
x = 5;
foo (1 g);
asm (mov %1, %0: =r (y): r (x));
Again still undefined because there is still inbetween the assignment
and the inline-asm.
if (x != 5)
abort ();
if (y != 5)
abort ();
}
int
main ()
{
bar (3);
return 0;
}
---
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
---
---
--
Summary|CX isn't preserved with |CX isn't preserved
with
|shift |shift
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38941
Re: [Bug middle-end/38856] loop iv detection failure
Sent from my iPhone On Jan 16, 2009, at 1:57 AM, rguenth at gcc dot gnu dot org gcc-bugzi...@gcc.gnu.org wrote: --- Comment #5 from rguenth at gcc dot gnu dot org 2009-01-16 09:57 --- I think this boils down to the usual POINTER_PLUS fallout. It failed in 4.1 also so nope :). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38856
Re: [Bug fortran/38823] New: Diagnose and treat (-2.0)**2.0 properly
On Jan 13, 2009, at 3:08 AM, burnus at gcc dot gnu dot org gcc-bugzi...@gcc.gnu.org wrote: Found at: http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/0f1d7da66fa015c2 print *, (-2.0)**2.0 end is invalid. gfortran should print a diagnostic for -std=f95/f2003/ f2008 as NAG f95 does: Error: Negative floating-point value raised to a real power Fortran 2003 in the second sentence of the second paragraph of 7.1.8 Evaluation of Operations: Raising a negative-valued primary of type real to a real power is prohibitted. The question is whether one needs to reject it completely or only with -std=f95. Steve (see thread) thinks the constant folding gets it wrong (- gives 4.0). Current results: - Runtime and compile time evaluation (ifort, gfortran, g95): -2.0**2.0 = 4.0 -2.0**1.9 = NaN - Mathematica: -2^2 = 4, -2.0^2.0 = -4.0 2.0^1.9 = -3.73213 -2.0^1.9 will be a complex number. Maybe we can define it as taking the real part. I don't know if that is better than generating a nan here. Thanks, Andrew Pinski -- Summary: Diagnose and treat (-2.0)**2.0 properly Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38823
Re: [Bug java/38827] New: gcj emitting incorrect code
On Jan 13, 2009, at 8:03 AM, tschwinge at gcc dot gnu dot org gcc-bugzi...@gcc.gnu.org
wrote:
I originally found this problem when trying to compile a Java
package written
by the Universität Stuttgart's institute IKR. I was using Debian's
gcj
package, version 4.3.2-2, but can likewise reproduce this using SVN
trunk, as
well as Debian's 4.2.4-4 package.
I completely reduced the test case to the following:
public class Bug_Class
{
}
public interface Bug_Interface
{
}
public class Bug
{
public X extends Bug_Class Bug_Interface Bug(X x)
{
set(x);
}
public void set(Bug_Interface x)
{
}
}
Directly compiling this will fail as follows:
$ ~/GCC/trunk.build.64.install/bin/gcj -c Bug.java
Bug.java: In class 'Bug':
Bug.java: In constructor '(Bug_Class)':
In file included from built-in:3:
Bug.java:3: error: verification failed at PC=9: incompatible type
on stack
gcj is able to emit a class file, but that one is considered non-
verifying by
the BCEL verifier:
This sounds like a bug in the eclispe source to bytecode compiler
which gcj uses now.
[...]
Pass 3b, method number 0 ['public void init(Bug_Class arg1)
[Signature(E:LBug_Class;:LBug_Interface;(TE;)V)]']:
VERIFIED_REJECTED
Constraint violated in method 'public void init(Bug_Class arg1)
[Signature(E:LBug_Class;:LBug_Interface;(TE;)V)]':
Instruction INVOKEVIRTUAL constraint violated: Expecting a
'Bug_Interface'
but found a 'Bug_Class' on the stack (which is not assignment
compatible).
InstructionHandle:6: invokevirtual[182](3) 13
[...]
What Sun's javac does differently (as per class-file disassembly
inspection) is
emitting a checkcast against class Bug_Interface before calling
invokevirtual.
--
Summary: gcj emitting incorrect code
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tschwinge at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38827
Re: [Bug bootstrap/35211] Dist tarball is missing (Bison-generated) java/parse-scan.c
On Jan 10, 2009, at 3:59 PM, rob1weld at aol dot com gcc-bugzi...@gcc.gnu.org wrote: --- Comment #3 from rob1weld at aol dot com 2009-01-10 23:59 --- (In reply to comment #1) Is this still true in newer GCC releases? Also this was removed in 4.3 and above. Yes, on trunk. Searching for dupe before starting a new Bug Report, came here. We might close this Bug with a comment on the Prerequisites page that you _might_ need bison in the event that you (or a Makefile, broken or otherwise) modify a `.y' file. This webpage does not mention the program bison: Prerequisites for GCC http://gcc.gnu.org/install/prerequisites.html We only require yacc (bison is a yacc) when compiling GCC from the svn or from the snapshots. Plus most os's already contain a yacc. # prev-gcc/xgcc -v Using built-in specs. Target: i386-pc-solaris2.11 Configured with: ../gcc_trunk/configure --enable-languages=ada,c,c++,fortran,java,objc,obj-c++ --enable-shared --disable-static --enable-decimal-float --with-long-double-128 -- enable-nls --with-included-gettext --enable-gather-detailed-mem-stats --with- stabs --enable-debug -enable-largefile --enable-symvers --without-system- zlib --enable-gtk-cairo --enable-qt-peer --enable-xmlj --enable-gconf-peer --enable-gjdoc --enable-java-awt=gtk,xlib,qt,x --enable-gc-debug --enable-libgcj-multifile --enable-libgcj-debug --enable-objc-gc --enable-libstdcxx-debug --enable-stage1-checking --enable- checking=release --without-system-libunwind --with-gnu-as --with-as=/usr/local/bin/as --with-gnu-ld --with-ld=/usr/local/bin/ld Thread model: posix gcc version 4.4.0 20090109 (experimental) (GCC) # gmake ... gmake[3]: Leaving directory `/usr/share/src/gcc_build/libiberty' gmake[3]: Entering directory `/usr/share/src/gcc_build/intl' rm -f stamp-h1 /bin/sh ./config.status config.h config.status: creating config.h config.status: config.h is unchanged test -f config.h || (rm -f stamp-h1 gmake stamp-h1) cp ../../gcc_trunk/intl/libgnuintl.h libintl.h /usr/share/src/gcc_build/./prev-gcc/xgcc ... ... /usr/share/src/gcc_build/./prev-gcc/xgcc -B/usr/share/src/ gcc_build/./prev-gcc/ -B/usr/local/i386-pc-solaris2.11/bin/ -c -fexceptions -g -O2 - fprofile-use -DHAVE_CONFIG_H -I. -I../../gcc_trunk/intl ../../gcc_trunk/intl/ ngettext.c ../../gcc_trunk/intl/ngettext.c: In function ‘libintl_ngettext’: ../../gcc_trunk/intl/ngettext.c:63: note: file /usr/share/src/gcc_build/intl/ngettext.gcda not found, execution counts estimated bison -y --name-prefix=__gettext --output plural.c ../../gcc_trunk/intl/plural.y rm -f plural.h /usr/share/src/gcc_build/./prev-gcc/xgcc -B/usr/share/src/ gcc_build/./prev-gcc/ -B/usr/local/i386-pc-solaris2.11/bin/ -c -fexceptions -g -O2 - fprofile-use -DHAVE_CONFIG_H -I. -I../../gcc_trunk/intl plural.c ... I did not modify a `.y' file or play with this part of the code. The reason that I require bison is either: 1. I 'hit it' with my configure option combination and found an untried path. 2. Typing make distclean removed a file (I did not see that happen). 3. Something is broken and bison was not really needed. 4. The Prerequisites for GCC is incorrect, we do need bison. Rob -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35211
Re: [Bug other/38768] man page: -fschedule-insns documentation
On Jan 8, 2009, at 9:44 AM, tim at klingt dot org gcc-bugzi...@gcc.gnu.org wrote: --- Comment #1 from tim at klingt dot org 2009-01-08 17:44 --- Created an attachment (id=17057) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17057action=view) proposed patch This patch is incorrect as -fschedule-insns is enabled at -O2 and above for most targets except for x86. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38768
Re: [Bug c++/38764] New: bogus 'changes meaning' error?
On Jan 8, 2009, at 4:22 AM, pluto at agmk dot net gcc-bugzi...@gcc.gnu.org
wrote:
following code snipet is reducted testcase from external application.
g++ and comeau online accept/reject source differently.
template class T
struct A
{
};
template class U
struct B
{
#if 1
typedef A float A; // -- accepted by comeau but...
// g++: error: declaration of typedef struct Afloat BU::A
// g++: error: changes meaning of A from struct Afloat
#else
typedef ::A float A; // -- accepted by g++ but...
// comeau: class member typedef may not be redeclared
// typedef ::A float A;
// ^
#endif
};
GCC is correct. This code is invalid but the standard says for this
case no diagnostic is required so both compilers are correct according
to the standard. Just that edg could be enchened to error about this
case.
--
Summary: bogus 'changes meaning' error?
Product: gcc
Version: 4.3.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pluto at agmk dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38764
Re: [Bug c++/38759] New: Incorrect warning/error when compiling with a typedef'ed ptr return type
On Jan 7, 2009, at 12:44 PM, gnu at bluedreamer dot com gcc-bugzi...@gcc.gnu.org
wrote:
When a pointer to type is typedef'ed to a new type gcc incorrectly
warns about
const modifier if new typedef is used in function return type.
gcc info:
dluadrianc:/home/adrianc gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.3.1/configure --prefix=/usr --enable-
languages=c,c++
--enable-shared --enable-threads=posix
Thread model: posix
gcc version 4.3.1 (GCC)
Command line:g++ -save-temps -Wall -ansi -Wextra -pedantic -Werror
const.cc
Error message:
cc1plus: warnings being treated as errors
const.cc:10: error: type qualifiers ignored on function return type
Code
# 1 const.cc
# 1 built-in
# 1 command-line
# 1 const.cc
class Foo { };
const Foo *func1()
{
return 0;
}
typedef Foo* Bar;
const Bar func2()
The const here is applying to the pointer type and not what the
pointer points to so the warning is correct.
{
return 0;
}
int main(int , char *[])
{
func1();
func2();
return 0;
}
--
Summary: Incorrect warning/error when compiling with a
typedef'ed
ptr return type
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gnu at bluedreamer dot com
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38759
Re: [Bug c++/38761] New: %s substituted with regular word can't be properly translated
Well template here might be consider the keyword template. So we either have template argument or just argument. Translating template might cause more confusion. Sent from my iPhone On Jan 7, 2009, at 1:34 PM, goeran at uddeborg dot se gcc-bugzi...@gcc.gnu.org wrote: In gcc/cp/parser.c there is this code in cp_parser_parameter_declaration error (%H%sparameter pack %qD cannot have a default argument, declarator_token_start-location, kind, id_declarator-u.id.unqualified_name); else error (%H%sparameter pack cannot have a default argument, declarator_token_start-location, kind); where kind has previously been assigned either the empty string or the word template followed by a space. There is no way to translate the word template. For this to work in all languages, I suspect the two messages needs to be split up in four complete messages, with and without template, rather than composed from pieces like this. -- Summary: %s substituted with regular word can't be properly translated Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: goeran at uddeborg dot se http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38761
Re: [Bug bootstrap/38693] gcc 4.4.0 20090101 - gcc/config/i386/sol2-10.h uses USE_GAS which is undefined
On Jan 5, 2009, at 7:01 PM, rob1weld at aol dot com gcc-bugzi...@gcc.gnu.org wrote: --- Comment #4 from rob1weld at aol dot com 2009-01-06 03:01 --- (In reply to comment #3) And this is documented in the installation documentation. (Confusion may also result if the compiler finds the GNU assembler but has not been configured with --with-gnu-as.) http://gcc.gnu.org/install/configure.html # ../gcc_trunk/configure --help | grep with-gnu-as It is an option for the gcc subdirctory configure and not the toplevel configure. Since --with-gnu-as is removed from the help I though you were trying to encourage automatic detection (and thus the testing of same) so I left off -with-gnu-as thinking that since configure chose it's as it ought to know which one it picked ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38693
Re: [Bug target/38496] Gcc misaligns arrays when stack is forced follow the x8632 ABI
Sent from my iPhone On Dec 15, 2008, at 1:33 PM, whaley at cs dot utsa dot edu gcc-bugzi...@gcc.gnu.org wrote: --- Comment #15 from whaley at cs dot utsa dot edu 2008-12-15 21:32 --- GCC chose to change the *unwritten* standard for the ABI in use for IA32 GNU/Linux. This is not true. Prior to this change, gcc followed the *written* standard provided by the LSB. LSB was written years after we had already did this back in gcc 3.0. Please check the history before saying gcc followed a written standard when none existed when this change was done. You chose to violate the standard, or to put as you seem to prefer, you chose to declare that you followed no standard, as the written standard previously used by pretty much all OSes on the x86 was suddenly unusable. The SCO document may have been useful before SSE, but processor architecture and language developments have made it problematic for many years. This is not even trivially true. SSE requires no change in the ABI to support: it is purely convenience to start with a known 16-byte alignment: an andb and a register save/restore fixes the problem completely, without abandoning the standard. I believe gcc still abides by this problematic for many years standard in all respects except stack alignment, which is a trivial problem to solve and still abide by the standard. So, you abandoned standard compliance to solve a minor irritant, that you yourself have fixed in the new 4.4 series. From 4.4 on, you broke the standard for no gain at all, since you have now added the minor complexity of manually aligning the stack anyway. Of course the standard seems outdated to us: it is supporting an architecture that is decades old, and that is the strength of it. If you want the shiny new stuff, you go to x86-64. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38496
Re: [Bug c/38453] Output code optimisation excessive use of builtins
Sent from my iPhone On Dec 10, 2008, at 2:51 AM, steven at gcc dot gnu dot org [EMAIL PROTECTED] wrote: --- Comment #3 from steven at gcc dot gnu dot org 2008-12-10 10:51 --- Investigating. There is no reason to investigate. The reason why this change happened was because the hurestic in scev-cp was removed and is now done always. There is another bug about this with respect to the Linux kernel too. Thanks, Andrew Pinski -- steven at gcc dot gnu dot org changed: What|Removed |Added --- --- -- AssignedTo|unassigned at gcc dot gnu |steven at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-12-10 10:51:37 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38453
Re: [Bug middle-end/35560] Missing CSE/PRE for memory operations involved in virtual call.
I think this bug is invalid since the type can change via a placement new which will change the vtable. Sent from my iPhone On Nov 30, 2008, at 4:09 AM, rguenth at gcc dot gnu dot org [EMAIL PROTECTED] wrote: --- Comment #3 from rguenth at gcc dot gnu dot org 2008-11-30 12:09 --- Note that we also do not CSE OBJ_TYPE_REF trees which seem to be valid gimple in place of the call in GIMPLE_CALLs so they do not get a separate value-number. (not that we would do anything useful with them if they were standalone, testcase for that welcome) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35560
Re: [Bug c/25509] can't disable __attribute__((warn_unused_result))
Sent from my iPhone On Nov 22, 2008, at 7:42 AM, thomas at mich dot com [EMAIL PROTECTED] wrote: --- Comment #20 from thomas at mich dot com 2008-11-22 15:42 --- There minimally needs to be a way of turning this warning off in GCC. GCC should not be trying to micromanage coding styles - either of the rest of gnu software or anywhere else, but at least until you clean up every bit of your own code, there should be a way of disabling the warning clutter. Why GCC is not micromanaging at all, it just allows the developer of the API to have the warning. So your complaints here are useless. HUNDREDS OF WARNINGS ARE NO BETTER THAN NO WARNINGS AT ALL. I can't even find errors in the pages bilge that now spews out from a normal compile. It might be and probably is appropriate with -Wall turned on. And I really would like to be able to treat warnings as errors when they are legitimate warnings. For now, I've hexedited cc1 to change the string so it won't be found and have to add -Wno-attributes so I don't get errors from things I might need. I'm getting it even with -Wall turned off (version 4.3.2). And I still should be able to disable it. Somehow GCC and gnu thinks int dummy93857 = fwrite( buf, 1, 1, fp ); is so far superior code to just fwrite( buf, 1, 1, fp ); that it now must enforce it on every possible line. It is not GCC which thinks that, it is the providers of your headers for fwriye that thinks that. Sometimes ignoring returns is the right (or better) thing to do instead of cluttering up the code. Not every line of code is critical kernel or system code that can introduce security holes. Not every call needs to have its exact behavior on the particular instance carefully monitored. Again we just provide the author of the Api to say that. The author of the libraries can often make a bad choice. Yes and you should complain to them instead of us then. And there are hundreds of instances - maybe 99% of them are good, but the bad ones on common functions are causing a great deal of noise. And there is not a pedantic_warn_unused_result (with a -Wunused-result which would promote it), which would be perfect for the instances noted here and more easily made. And perhaps even an error_unused_result. I think it would be easy to argue for the large bodies of code that certain functions have return values that are conventionally ignored so should only warn at a higher level of checking than ordinary warnings. Right now I have to argue each individual case with the only options to keep it (and the pages of new warnings) or remove it (and in the few cases where it might be critical be silent). gcc currently has no middle option. Also this attribute is not on by default in glibc so you are asking to turn on the style based warnings. Sometimes return values are at a point where you can't do anything anyway like the exit example. Somehow, if a printf, or an equivalent fwrite of a formatted string to stdout or stderr fails, what do you do? Errors have both probability and criticality. And there are a lot of highly improbable cases, and lots of non-critical sections. If my CPU is melting down or my memory giving errors, I have worse problems. If the number of parameters doesn't match a function declaration, it is likely an error that will cause things to fail 90% of the time. 99.99% of the time, f//read/write will return the expected value. If fclose fails, what do you do? And fwrite won't return the error, fflush might (but if it doesn't do a sync(), and writes are cached to a failing disk...). Perhaps it is because we don't have a finer gradation (an INFO or MAY equivalent to the SHOULD/WARNING, MUST/ERROR). The lack of checking a return, at least in the cases where the functions are mainly the side-effect (and if fwrite fails, perhaps there should be a signal or exception, and not depend on the return code if it is so critical) doesn't reach the threshold of a PERMANENTLY ENABLED warning. It does reach the threshold of the things I usually check with -pedantic. Like signed-unsigned mismatches. Subtle printf format errors. In my later QC checks I do turn everything on and verify every line of code. I would work on adding a pedantic_* (and maybe error_*) set of attributes, but until then, leave the choice to the author of the program. THIS WARNING IS A *GOOD* THING, but it doesn't apply to every program or every function, or every use of that function. Many functions are used both in critical and noncritical forms, and there are a lot of existing programs that instead of being clear are now cluttered. One of the reasons I don't normally use C++ is the stupidity where I am forced to lower the quality of my code because of what it enforces or doesn't enforce so instead of a concise function, it will only compile a bloated
Re: [Bug fortran/38188] New: Inconsistent function results depending on irrelevant write statement
I don't think INF is the same as infinity. It is most like implict declared variable with an undefined value. Sent from my iPhone On Nov 19, 2008, at 10:52 PM, dojo at masterleep dot com [EMAIL PROTECTED] wrote: I am getting unreliable results from a small function using the latest prepackaged Mac OS build (PPC) available from the wiki download page. The function behaves correctly if an otherwise irrelevant write statement is added. When the statement is removed, the function returns gibberish. This is ancient code which worked on older versions of gfortran, so hopefully I haven't overlooked an obvious problem... $ uname -a Darwin Numenor 9.5.0 Darwin Kernel Version 9.5.0: Wed Sep 3 11:29:43 PDT 2008; root:xnu-1228.7.58~1/RELEASE_I386 i386 $ gfortran --version GNU Fortran (GCC) 4.4.0 20080823 (experimental) [trunk revision 139508] $ cat xx.f program xx real xa(102) do 10 i=1,100 10 xa(i)=float(i) call scale (xa,23.,100,1) write (*,*) xa(101), xa(102) end subroutine scale(arr,axlen,npts,kcycle) real :: arr(*),axlen,minval,maxval,val integer :: npts,kcycle minval = +INF maxval = -INF do i=0,npts-1 val=arr(1+kcycle*i) minval=amin1(val,minval) maxval=amax1(val,maxval) end do arr(npts*kcycle+1)=minval arr(npts*kcycle+kcycle+1)=(maxval-minval)/axlen c If the following line is uncommented, the function will work c write (*,*) 3 end subroutine scale # Correct function result (write statement is left in) $ gfortran -o xx xx.f $ xx 3 0.000 4.3478260 # Incorrect function result (write statement is commented out) $ gfortran -o xx xx.f $ xx -2.13906214E+09 1.86005408E+08 -- Summary: Inconsistent function results depending on irrelevant write statement Product: gcc Version: unknown Status: UNCONFIRMED Severity: major Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dojo at masterleep dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38188
Re: [Bug c/38136] New: vim crashes on startup when compiled with -O3 but works with -O2
Sent from my iPhone On Nov 15, 2008, at 10:05 AM, dominique dot pelle at gmail dot com [EMAIL PROTECTED] wrote: Vim (at least current version vim-7.2.40) crashes on start up when compiled with optimization option -O3 using gcc-4.3.2 (that's the default version that comes with Ubuntu-8.10). Vim works fine when compiled with -O0, -O1 or -O2. Narrowing it down further, compilation options -O2 -finline- functions are enough to trigger the crash. Steps to reproduce: 1/ download vim-7.2.40 $ cvs -z3 -d:pserver:[EMAIL PROTECTED]:/cvsroot/vim checkout -rv7-2-040 vim7 2/ configure and build vim with -O3 optimization level: $ cd vim7 $ ./configure $ make CFLAGS=-O3 3/ run vim and observe crash $ cd src $ ./vim *** buffer overflow detected ***: ./vim terminated === Backtrace: = /lib/tls/i686/cmov/libc.so.6(__fortify_fail+0x48)[0xb77aa558] /lib/tls/i686/cmov/libc.so.6[0xb77a8680] /lib/tls/i686/cmov/libc.so.6(__strcpy_chk+0x44)[0xb77a7944] ./vim[0x8081e8d] ./vim[0x8083521] ./vim[0x808abec] ./vim[0x80950e1] ./vim[0x80b4ba8] ./vim[0x80b72bb] ./vim[0x80a6ffb] ./vim[0x80a7661] ./vim[0x80a4b14] ./vim[0x80a4c18] ./vim[0x80fa68c] /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe5)[0xb76c6685] ./vim[0x8052b31] === Memory map: 08048000-0823c000 r-xp 08:04 879079 /tmp/vim7/src/vim 0823c000-0823d000 r--p 001f3000 08:04 879079 /tmp/vim7/src/vim 0823d000-08249000 rw-p 001f4000 08:04 879079 /tmp/vim7/src/vim 08249000-08251000 rw-p 08249000 00:00 0 0930f000-09393000 rw-p 0930f000 00:00 0 [heap] b731e000-b744d000 rw-p b731e000 00:00 0 b744d000-b7462000 r-xp 08:04 1910133 /lib/tls/i686/cmov/libpthread-2.8.90.so b7462000-b7463000 r--p 00014000 08:04 1910133 /lib/tls/i686/cmov/libpthread-2.8.90.so b7463000-b7464000 rw-p 00015000 08:04 1910133 /lib/tls/i686/cmov/libpthread-2.8.90.so b7464000-b7466000 rw-p b7464000 00:00 0 b7466000-b746a000 r-xp 08:04 2181398/usr/lib/ libXdmcp.so.6.0.0 b746a000-b746b000 rw-p 3000 08:04 2181398/usr/lib/ libXdmcp.so.6.0.0 b746b000-b746c000 rw-p b746b000 00:00 0 b746c000-b746e000 r-xp 08:04 2180573/usr/lib/libXau.so. 6.0.0 b746e000-b746f000 rw-p 1000 08:04 2180573/usr/lib/libXau.so. 6.0.0 b746f000-b747 r-xp 08:04 2181509/usr/lib/libxcb- xlib.so.0.0.0 b747-b7471000 r--p 08:04 2181509/usr/lib/libxcb- xlib.so.0.0.0 b7471000-b7472000 rw-p 1000 08:04 2181509/usr/lib/libxcb- xlib.so.0.0.0 b7472000-b7475000 r-xp 08:04 1892947/lib/libattr.so.1.1.0 b7475000-b7477000 rw-p 3000 08:04 1892947/lib/libattr.so.1.1.0 b7477000-b749f000 r-xp 08:04 1892979/lib/libpcre.so. 3.12.1 b749f000-b74a r--p 00027000 08:04 1892979/lib/libpcre.so. 3.12.1 b74a-b74a1000 rw-p 00028000 08:04 1892979/lib/libpcre.so. 3.12.1 b74a1000-b74c5000 r-xp 08:04 2181526/usr/lib/ libexpat.so.1.5.2 b74c5000-b74c7000 r--p 00023000 08:04 2181526/usr/lib/ libexpat.so.1.5.2 b74c7000-b74c8000 rw-p 00025000 08:04 2181526/usr/lib/ libexpat.so.1.5.2 b74c8000-b74c9000 rw-p b74c8000 00:00 0 b74c9000-b74e r-xp 08:04 2181505/usr/lib/libxcb.so. 1.0.0 b74e-b74e1000 r--p 00016000 08:04 2181505/usr/lib/libxcb.so. 1.0.0 b74e1000-b74e2000 rw-p 00017000 08:04 2181505/usr/lib/libxcb.so. 1.0.0 b74e2000-b74e8000 r-xp 08:04 2182517 /usr/lib/libxcb-render.so.0.0.0 b74e8000-b74e9000 r--p 5000 08:04 2182517 /usr/lib/libxcb-render.so.0.0.0 b74e9000-b74ea000 rw-p 6000 08:04 2182517 /usr/lib/libxcb-render.so.0.0.0 b74ea000-b74ed000 r-xp 08:04 2182519 /usr/lib/libxcb-render-util.so.0.0.0 b74ed000-b74ee000 r--p 2000 08:04 2182519 /usr/lib/libxcb-render-util.so.0.0.0 b74ee000-b74ef000 rw-p 3000 08:04 2182519 /usr/lib/libxcb-render-util.so.0.0.0 b74ef000-b7513000 r-xp 08:04 2261047/usr/lib/ libpng12.so.0.27.0 b7513000-b7515000 rw-p 00023000 08:04 2261047/usr/lib/ libpng12.so.0.27.0 b7515000-b7554000 r-xp 08:04 2179338/usr/lib/ libpixman-1.so.0.12.0 b7554000-b7556000 r--p 0003e000 08:04 2179338/usr/lib/ libpixman-1.so.0.12.0 b7556000-b7557000 rw-p 0004 08:04 2179338/usr/lib/ libpixman-1.so.0.12.0 b7557000-b7558000 rw-p b7557000 00:00 0 b7558000-b756 r-xp 08:04 2180407/usr/lib/ libXcursor.so.1.0.2 b756-b7561000 rw-p 7000 08:04 2180407/usr/lib/ libXcursor.so.1.0.2 b7561000-b7566000 r-xp 08:04 2181117/usr/lib/ libXrandr.so.2.1.0 b7566000-b7567000 r--p 5000 08:04 2181117/usr/lib/ libXrandr.so.2.1.0 b7567000-b7568000 rw-p 6000 08:04 2181117/usr/lib/ libXrandr.so.2.1.0 b7568000-b757 r-xp 08:04 2180995/usr/lib/libXi.so. 6.0.0 b757-b7571000 r--p 7000 08:04 2180995/usr/lib/libXi.so. 6.0.0 b7571000-b7572000 rw-p 8000 08:04 2180995/usr/lib/libXi.so. 6.0.0 b7572000-b7574000 r-xp 08:04 2180450/usr/lib/
Re: [Bug rtl-optimization/38139] New: --enable-checking=all times out during bootstrap
Sent from my iPhone On Nov 15, 2008, at 1:27 PM, edwintorok at gmail dot com [EMAIL PROTECTED] wrote: I tried to build a gcc 4.4.0 with --enable-checking=all but it timed out: Since --enable-checking=all enables gc all the time then yes It will take a long time. Maybe even days. Marking is expensive. $ /home/edwin/gcc-obj/./prev-gcc/xgcc -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../gcc/configure --disable-multilib --disable-static --prefix=/home/edwin/gcc_inst/ --enable-languages=c,c++ --enable- checking=all Thread model: posix gcc version 4.4.0 20081115 (experimental) [trunk revision 141891] (GCC) xgcc: Internal error: Killed (program cc1) Please submit a full bug report. See http://gcc.gnu.org/bugs.html for instructions. make[3]: *** [insn-emit.o] Error 1 make[3]: *** Waiting for unfinished jobs xgcc: Internal error: Killed (program cc1) Please submit a full bug report. See http://gcc.gnu.org/bugs.html for instructions. make[3]: *** [insn-recog.o] Error 1 make[2]: *** [all-stage2-gcc] Error 2 make[1]: *** [stage2-bubble] Error 2 ^it was building insn-emit and insn-recog in parallel, both timed out. I was running it under ulimit with a one hour timeout: ulimit -t 3600 -v 1048576 make -j4 makelog 2makelog2 CPU is Intel(R) Core(TM)2 Quad CPU Q9550 @ 2.83GHz, 4GB RAM. I know that --enable-checking=all is very slow, but it should take less than an hour to compile insn-emit.o, shouldn't it? -- Summary: --enable-checking=all times out during bootstrap Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: edwintorok at gmail dot com GCC build triplet: x86_64-linux-gnu GCC host triplet: x86_64-linux-gnu GCC target triplet: x86_64-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38139
Re: [Bug rtl-optimization/38139] --enable-checking=all times out during bootstrap
Sent from my iPhone On Nov 15, 2008, at 1:59 PM, edwintorok at gmail dot com [EMAIL PROTECTED] wrote: --- Comment #2 from edwintorok at gmail dot com 2008-11-15 21:59 --- (In reply to comment #1) Subject: Re: New: --enable-checking=all times out during bootstrap Sent from my iPhone On Nov 15, 2008, at 1:27 PM, edwintorok at gmail dot com [EMAIL PROTECTED] wrote: I tried to build a gcc 4.4.0 with --enable-checking=all but it timed out: Since --enable-checking=all enables gc all the time then yes It will take a long time. Maybe even days. Marking is expensive. Thanks, this is the 'gcac' flag, right? Yes. What if I build with assert,df,fold,rtl,misc,tree,gc,rtlflag,runtime, would that build within a reasonable amount of time? Rtl checking is also expensive (no way near as expensive as gcac) but it does find real bugs in some cases. Everything else is enabled by default during development of the trunk. And is it worth to build with more checking, than those enabled by default? [i.e. did that expose bugs in the past?] -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38139
Re: [Bug libstdc++/38107] gcc source contains a struct with no data members (actually 1 byte in size) and compiler does not initialize it, resulting in IBM Rational Purify reporting an Uninitialized M
Sent from my iPhone On Nov 14, 2008, at 9:05 AM, efinger at us dot ibm dot com [EMAIL PROTECTED] wrote: --- Comment #4 from efinger at us dot ibm dot com 2008-11-14 17:05 --- (In reply to comment #2) There are going to be other holes in structs in general due to alignment requirements and I don't think the compiler or libstdc++ should change to this because it will slow down the generated code and not really makes a difference in the outcome of the code. Purify already handles pad bytes added for alignment correctly. This is a very specific case, where the pad byte is added to prevent the struct from having size zero, not for alignment. The added code to clear 1 byte, at object constuction time, would not make any significant performance difference. But it can cause code bloat which can cause performance issues because of icache sizes and such. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38107
Re: [Bug c/37995] using stdio.h fails if gcc invoked in a directory which has a subdirectory called gcc
Sent from my iPhone On Nov 14, 2008, at 5:01 PM, mvanier at cs dot caltech dot edu [EMAIL PROTECTED] wrote: --- Comment #10 from mvanier at cs dot caltech dot edu 2008-11-15 01:01 --- (In reply to comment #9) (In reply to comment #8) Is . in your PATH environment variable? As I've already mentioned, it works fine if . is not in the path. Now, one can argue that . should not be in the path anyway, but it doesn't seem to me that gcc should be enforcing this. Still works on darwin and GNU/Linux. It works for me on darwin as well, but with gcc 4.0.1 (which is what MacPorts provides). Which version are you using? I got the problem on gcc 4.3.2 on Arch Linux. I am using 4.3.0, 4.4.0, 4.1.1 and 4.0.2. On all of the above targets/ hosts. Thanks for looking into this. Mike -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37995
Re: [Bug libstdc++/38000] [4.3/4.4 Regression] System header files not found once -isystem /usr/include is used
Hmm, shouldn't the preprocessor just mark the include as a duplicate? Sent from my iPhone On Nov 12, 2008, at 8:50 AM, paolo dot carlini at oracle dot com [EMAIL PROTECTED] wrote: -- 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=38000
Re: [Bug debug/38101] New: dbxout_expand_expr() doesn't check return value of DECL_VALUE_EXPR()
Sent from my iPhone
On Nov 12, 2008, at 8:11 PM, d dot g dot gorbachev at gmail dot com [EMAIL PROTECTED]
wrote:
tree.c:
tree
decl_value_expr_lookup (tree from)
{
...
return NULL_TREE;
}
tree.h:
#define DECL_VALUE_EXPR(NODE) \
(decl_value_expr_lookup (DECL_WRTL_CHECK (NODE)))
dbxout.c:
static rtx
dbxout_expand_expr (tree expr)
{
switch (TREE_CODE (expr))
...
case PARM_DECL:
if (DECL_HAS_VALUE_EXPR_P (expr))
return dbxout_expand_expr (DECL_VALUE_EXPR (expr));
DECL_VALUE_EXPR should not return null if DECL_HAS_VALUE_EXPR_P
returns true.
...
}
--
Summary: dbxout_expand_expr() doesn't check return value of
DECL_VALUE_EXPR()
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
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
GCC target triplet: i386-pc-mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38101
Re: [Bug preprocessor/38013] New: Option to turn off usage of any precompiled header
You can also just do -Dineednopchreallyidont :). Sent from my iPhone On Nov 4, 2008, at 8:23 AM, rguenth at gcc dot gnu dot org [EMAIL PROTECTED] wrote: There is no option to turn off the use of precompiled headers. This makes generating preprocessed source for bugs harder than necessary (you need to manually remove the pchs). -- Summary: Option to turn off usage of any precompiled header Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: preprocessor 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=38013
Re: [Bug c++/35652] [4.2/4.3/4.4 Regression] offset warning should be given in the front-end
Sent from my iPhone
On Nov 2, 2008, at 4:53 AM, manu at gcc dot gnu dot org [EMAIL PROTECTED]
wrote:
--- Comment #10 from manu at gcc dot gnu dot org 2008-11-02
12:53 ---
(In reply to comment #9)
This is my current patch and it works in this testcase. However,
it also
triggers on cases like: const char *p = str + sizeof(str)
Perhaps I am doing this at the wrong place. Any suggestions?
Keep in mind that one-after the string is ok, so ...
Do you mean one after the null character? If you have str = abcd.
Then
sizeof(str) is 5 and str + sizeof(str) points outside the string.
(str[4] is
the null character).
That is still well defined. Taking the address of one element past the
end of the array is well defined. Just you can not derefence it.
Thanks,
Andrew Pinski
@@ -3322,10 +3323,36 @@ pointer_int_sum (enum tree_code resultco
+ {
+ HOST_WIDE_INT max = TREE_STRING_LENGTH (string_cst) - 1;
... the -1 is wrong here.
TREE_STRING_LENGTH is the size of the character array, not the
string. Are you
sure it is wrong?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35652
Re: [Bug rtl-optimization/37948] [4.4 Regression] IRA generates slower code for -mtune=core2
Sent from my iPhone On Oct 29, 2008, at 12:17 AM, bonzini at gnu dot org [EMAIL PROTECTED] wrote: --- Comment #2 from bonzini at gnu dot org 2008-10-29 07:17 --- Subject: Re: [4.4 Regression] IRA generates slower code for -mtune=core2 hjl dot tools at gmail dot com wrote: --- Comment #1 from hjl dot tools at gmail dot com 2008-10-29 05:44 --- It looks like the cost of loading/storing FP values aren't appropriate for Core 2. With this patch: Good. Is regmove still helping (which would be the wrong thing to do, but gives a data point)? I noticed that ira ignores ! part of constraint do you know if the register class would change if ! was not ignored? Thanks, Andrew Pinsky Paolo -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37948
Re: [Bug c/37873] ICE in extract_bit_field_1
Sent from my iPhone On Oct 19, 2008, at 7:39 AM, bernard at brenda-arkle dot me dot uk [EMAIL PROTECTED] wrote: --- Comment #1 from bernard at brenda-arkle dot me dot uk 2008-10-19 14:39 --- I'm really sorry - requesting the form after network problems apparently submits it again! Is this itself a bug in the UI? To some extend it is a bug in the browser which you are using. *** This bug has been marked as a duplicate of 37870 *** -- bernard at brenda-arkle dot me dot uk changed: What|Removed |Added --- --- -- Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37873
Re: [Bug target/37845] gcc ignores FP_CONTRACT pragma set to OFF
Sent from my iPhone On Oct 16, 2008, at 2:42 AM, rguenth at gcc dot gnu dot org [EMAIL PROTECTED] wrote: --- Comment #2 from rguenth at gcc dot gnu dot org 2008-10-16 09:42 --- The fma patterns on ia64 are not guarded properly. They should be off as long as flag_unsafe_math_optimizations is not specified. No that is not true. They should be on by default. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37845
Re: misusing placement new OR possible cxx bug
Sent from my iPhone
On Oct 13, 2008, at 9:10 AM, Ralovich, Kristóf [EMAIL PROTECTED]
m wrote:
Hi GCC developers,
I have a c++ source, that I think is wrong (wrt the c++ standard), but
accepted by g++ (and msvc too)!
int
main(int argc, char** argv)
{
char* d = new char[256, 256];
return 0;
}
Is this the use of 'placement new' in weird syntax I didn't know
before, or is this code wrong and accidentally accepted by gcc? In the
former case, please correct me and sorry for the noise!
This is neither. The code is using the comma operator.
Thanks,
Andrew Pinski
Thanks,
Kristof
PS.: my 'g++ -v' says:
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian
4.3.2-1' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3
--enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc
--enable-mpfr --enable-targets=all --enable-cld
--enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu
--target=i486-linux-gnu
Thread model: posix
gcc version 4.3.2 (Debian 4.3.2-1)
PS2.: Please CC me!
Re: [Bug c++/37804] New: Nested type leaks to global scope
Sent from my iPhone
On Oct 11, 2008, at 5:28 AM, therealfroggey at gmail dot com [EMAIL PROTECTED]
wrote:
GCC versions used:
gcc version 4.1.2
gcc version 4.4.0 20081011 (experimental) (GCC) svn revision 141055
Command line used: g++ -Wall -Wextra bug.cc
The following code should fail to compile as Internal_B is a private
class
within class A.
Both tested version of gcc successfully compile it with no warnings.
template typename T
class A
{
private:
class Internal_A
{
friend class Internal_B;
The above friend class refers to the class in containing namespace and
not to the class inside the class.
};
class Internal_B { };
Internal_A a;
};
Aint a;
Internal_B some_function();
The above should not compile but it is not because the inner class is
leaking though. It is because the friend statement is causing an
injection when it should not.
--
Summary: Nested type leaks to global scope
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: therealfroggey at gmail dot com
GCC build triplet: x86_64-linux-gnu
GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37804
Re: [Bug c++/37773] -Wfatal-errors aborts too early
Sent from my iPhone On Oct 8, 2008, at 9:48 AM, carlo at gcc dot gnu dot org [EMAIL PROTECTED] wrote: --- Comment #1 from carlo at gcc dot gnu dot org 2008-10-08 16:48 --- Here's another one: This expected behaviour of this option. It was not designed for users really to use it. It was designed to make it easier and faster for automatic reduction of ICEs. Thanks, Andrew Pinski ../cwchessboard/PgnDatabase.cc:65: error: no matching function for call to ‘util::MemoryBlockList::append(gssize)’ ../cwchessboard/MemoryBlockList.h:232: note: candidates are: void util::MemoryBlockList::append(Glib::RefPtrutil::MemoryBlockNode, size_t) With -Wfatal-errors the second line is not printed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37773
Re: [Bug c++/37762] Member variable of empty base optimized (EBO) class appears on wrong offset
Iirc there are some pod vs non pod issues here dealing wit padding and the c++ standard and not even the abi. Sent from my iPhone On Oct 7, 2008, at 2:31 AM, david dot rosenborg at pantor dot com [EMAIL PROTECTED] wrote: --- Comment #3 from david dot rosenborg at pantor dot com 2008-10-07 09:31 --- Ah, no, I wasn't aware of that document. I just thought that gcc was treating the Good and Bad cases inconsitently. Now, in layman's terms, is the reason for the padding that no two distinct instances of Empty may share the same address? If that is the case, it would explain the padding and this is not a bug. Sorry, should have investigated more before hitting the commit button. /David -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37762
Re: gcc generates prolog without rsp decrementing, i.e. allocates locals and parameters in free stack without privatising this stack
Sent from my iPhone
On Oct 6, 2008, at 5:09 AM, Denis [EMAIL PROTECTED] wrote:
Hi,
I use gcc:
[EMAIL PROTECTED] ~]$ gcc -v
Using built-in specs.
Target: x86_64-suse-linux
Configured with: ../configure --enable-threads=posix --prefix=/usr --
with-local-prefix=/usr/local --infodir=/usr/share/info --mandir=/usr/
share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64 --enable-
languages=c,c++,objc,fortran,java,ada --enable-checking=release --
with-gxx-include-dir=/usr/include/c++/4.1.0 --enable-ssp --disable-
libssp --enable-java-awt=gtk --enable-gtk-cairo --disable-libjava-
multilib --with-slibdir=/lib64 --with-system-zlib --enable-shared --
enable-__cxa_atexit --enable-libstdcxx-allocator=new --without-
system-libunwind --with-cpu=generic --host=x86_64-suse-linux
Thread model: posix
gcc version 4.1.0 (SUSE Linux)
and trying to compile program:
void plus (long * a, long * b)
{
long aa = 10;
long bb =10;
*a += *b + aa + bb;
}
int main (){
long a = 1;
long b = 2;
long *aa = a;
long *bb = b;
plus(aa,bb);
}
##
[EMAIL PROTECTED] gc]$ gcc -S main.c
But code produced for plus function is incorrect:
.file main.c
.text
.globl plus
.type plus, @function
plus:
.LFB2:
pushq %rbp
.LCFI0:
movq%rsp, %rbp
.LCFI1:
## As you can see here it allocates
parameters and autos into stack minus shifts, that is free stack
space. I.e. it didn.t reservation.
This is ok as the x86_64 ABI has a red zone. If you are running into a
problem, then your kernel is not following the ABI.
movq%rdi, -24(%rbp)
movq%rsi, -32(%rbp)
movq$10, -16(%rbp)
movq$10, -8(%rbp)
movq-24(%rbp), %rax
movq(%rax), %rdx
movq-32(%rbp), %rax
movq(%rax), %rax
addq-16(%rbp), %rax
addq-8(%rbp), %rax
addq%rax, %rdx
movq-24(%rbp), %rax
movq%rdx, (%rax)
leave
ret
.LFE2:
.size plus, .-plus
.globl main
.type main, @function
main:
.LFB3:
pushq %rbp
.LCFI2:
movq%rsp, %rbp
.LCFI3:
# Here it does all correct . firstly
reserve stack frame and then allocates autos and parameters there.
subq$32, %rsp
.LCFI4:
movq$1, -24(%rbp)
movq$2, -32(%rbp)
leaq-24(%rbp), %rax
movq%rax, -16(%rbp)
leaq-32(%rbp), %rax
movq%rax, -8(%rbp)
movq-8(%rbp), %rsi
movq-16(%rbp), %rdi
callplus
leave
ret:
The difference between functions is that main calls other function
and .plus. does not.
In my project I have kernel code that has a function w/o calls
(memcpy) and it is compiled also incorrectly.
And problem is that when *dst = *src executed . pagefault appeared,
this pagefault works on the same stack and rewrites free space, i.e.
rewrites locals of memcpy function.
That results to crash on next read from src.
So probably somebody knows how to solve this problem? I.ve explored
gcc flags and didn.t find anything to solve it.
I.ve also tried another gcc version :
[EMAIL PROTECTED] gc]$ gcc -v
Reading specs from /usr/lib/gcc/x86_64-redhat-linux/3.4.5/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix --
disable-checking --with-system-zlib --enable-__cxa_atexit --disable-
libunwind-exceptions --enable-java-awt=gtk --host=x86_64-redhat-linux
Thread model: posix
gcc version 3.4.5 20051201 (Red Hat 3.4.5-2)
Result is the same.
Thank you in advance,
Denis.
Re: [Bug c++/37721] Segmentation fault
Sent from my iPhone On Oct 3, 2008, at 1:38 AM, ivranos at freemail dot gr [EMAIL PROTECTED] wrote: --- Comment #9 from ivranos at freemail dot gr 2008-10-03 08:38 --- I am sorry but you are not right/specific. At first there is no struct in the code, only class. In C++ structs/classes are the same thing except if it is private or public by defaut. Second, the copy constructor does not copy the passed argument, it ignores it. And that is the bug really. Sort uses the copy construct to swap two elements of the vector. So you will generate random data again and again and the sort becomes confused. Note std::sort uses std::swap which is defined this way. Sorry but there is no bug in the library or GCC. But it initialises its data member the same way as the main constructor. So, there isn't any bug. -- ivranos at freemail dot gr changed: What|Removed |Added --- --- -- Status|RESOLVED|UNCONFIRMED Component|libstdc++ |c++ Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37721
Re: [Bug c++/37728] New: if scoping for declarations
Sent from my iPhone
On Oct 3, 2008, at 11:10 AM, mrs at apple dot com [EMAIL PROTECTED]
wrote:
In:
http://lists.cs.uiuc.edu/pipermail/llvmdev/2008-October/017449.html
we were discussing possible bugs in g++ scoping for if statements.
$ cat t.cc
void foo() {
if (int x = 0) {
int x;
}
}
This is invalid C++ but it is valid C99. There is already a duplicated
bug filed for this too but I am too lazy right now to find it.
$ ./xgcc -B./ -c t.cc
$
they expected this to produce a redeclaration error on the inner
declaration
for X.
Tested on gcc version 4.4.0 20081003 (experimental) [trunk revision
140855]
(GCC)
There were other concerns about for, but, others seem to think gcc
does the
right thing with them.
--
Summary: if scoping for declarations
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mrs at apple dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37728
Re: [Bug c++/37715] New: Different class sizes with public/private and alignments
Sent from my iPhone
On Oct 2, 2008, at 2:09 AM, adam at os dot inf dot tu-dresden dot de
[EMAIL PROTECTED] wrote:
I've been experiencing some (for me) rather unexpected behavior with
some C++
code. The following is a very reduced test case:
This comes down to non pod vs pod and tail filling.
class A
{ private: void *one;
} __attribute__((aligned(16)));
class C {};
class L { public: class M : A { C _c; }; M m; };
L x;
It's about the size of L::M. I.e. if this file is compiled, L::M has
a sizeof
of 16. If the first private is changed to public, the size of L::M
changes to
32 (-Dprivate=public). Is this expected behavior? When removing the
alignment
contraints, the size of L::M is 8 in both cases.
I'm seeing this behavior with all gcc versions tested (3.3, 3.4,
4.1, 4.2, 4.3,
head) as well as with different target architectures (i386, x86_64,
arm).
This is the script use to show the difference:
#! /bin/sh
echo 'print sizeof(L::M)' x.cmd
echo -n orig:
gcc -Wall -g -c x.cc
gdb -x x.cmd -batch x.o
echo -n with define:
gcc -Dprivate=public -Wall -g -c x.cc
gdb -x x.cmd -batch x.o
Thanks
--
Summary: Different class sizes with public/private and
alignments
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: adam at os dot inf dot tu-dresden dot de
GCC build triplet: i486-linux-gnu
GCC host triplet: i486-linux-gnu
GCC target triplet: i486-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37715
Re: [Bug c++/37685] New: C++ over-eager optimization when working with a pointer
Sent from my iPhone
On Sep 30, 2008, at 10:26 AM, jrenggli at gmail dot com [EMAIL PROTECTED]
wrote:
The following code results in an error when optimized using -O2 or -
O3 flag,
but works fine with -O1. I've also been able to confuse the
optimizer by
adding some code just after or before the line iX += pA2-iX; but
I'm not
sure how safe that method is.
-- Full code starts here --
#include iostream
class A
{
private:
int32_t iX;
public:
explicit A(int x) : iX(x) {}
public:
A operator*=(const A a);
public:
int32_t getX() const { return iX; }
};
A A::operator*=(const A B)
{
const A* pA2 = B;
int iBothSigns = 0;
if (iX = 0 pA2-iX = 0)
{
iBothSigns = 1;
}
else if (iX 0 pA2-iX 0)
{
iBothSigns = -1;
}
iX += pA2-iX;
if (iX = 0 iBothSigns == -1) // Expected
Signed interger overflow is undefined.
{
std::cout OK std::endl;
return *this;
}
else if (iX 0 iBothSigns == 1) // Not expected
{
std::cout Unexpected std::endl;
return *this;
}
std::cout Error std::endl;
return *this;
}
int main()
{
A n1(-2147483648);
A n2(-2147483648);
std::cout 1: expected -2147483648, got n1.getX()
std::endl;
std::cout 2: expected -2147483648, got n2.getX()
std::endl;
n1 *= n2;
std::cout 3: expected previous line to be OK std::endl;
return 0;
}
-- end of code --
-- compiler output --
g++ -o bugreport.o -c -v -Wall -O3 -pedantic -ansi -save-temps
bugreport.cpp
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--with-gxx-include-dir=/usr/include/c++/4.2 --program-suffix=-4.2
--enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --
enable-mpfr
--enable-targets=all --enable-checking=release --build=i486-linux-gnu
--host=i486-linux-gnu --target=i486-linux-gnu
Thread model: posix
gcc version 4.2.3 (Ubuntu 4.2.3-2ubuntu7)
/usr/lib/gcc/i486-linux-gnu/4.2.3/cc1plus -E -quiet -v -D_GNU_SOURCE
bugreport.cpp -mtune=generic -ansi -Wall -pedantic -O3 -fpch-
preprocess -o
bugreport.ii
ignoring nonexistent directory /usr/local/include/i486-linux-gnu
ignoring nonexistent directory
/usr/lib/gcc/i486-linux-gnu/4.2.3/../../../../i486-linux-gnu/include
ignoring nonexistent directory /usr/include/i486-linux-gnu
#include ... search starts here:
#include ... search starts here:
/usr/include/c++/4.2
/usr/include/c++/4.2/i486-linux-gnu
/usr/include/c++/4.2/backward
/usr/local/include
/usr/lib/gcc/i486-linux-gnu/4.2.3/include
/usr/include
End of search list.
/usr/lib/gcc/i486-linux-gnu/4.2.3/cc1plus -fpreprocessed
bugreport.ii -quiet
-dumpbase bugreport.cpp -mtune=generic -ansi -auxbase-strip
bugreport.o -O3
-Wall -pedantic -ansi -version -fstack-protector -fstack-protector -o
bugreport.s
GNU C++ version 4.2.3 (Ubuntu 4.2.3-2ubuntu7) (i486-linux-gnu)
compiled by GNU C version 4.2.3 (Ubuntu 4.2.3-2ubuntu7).
GGC heuristics: --param ggc-min-expand=99 --param ggc-min-
heapsize=129349
Compiler executable checksum: 9cf91ba46d80e564052e4fbab0d6561b
bugreport.cpp:55: warning: this decimal constant is unsigned only in
ISO C90
bugreport.cpp:56: warning: this decimal constant is unsigned only in
ISO C90
as --traditional-format -V -Qy -o bugreport.o bugreport.s
GNU assembler version 2.18.0 (i486-linux-gnu) using BFD version (GNU
Binutils
for Ubuntu) 2.18.0.20080103
g++ -o bugreport bugreport.o
--
Summary: C++ over-eager optimization when working with a
pointer
Product: gcc
Version: 4.2.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jrenggli at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37685
Re: [Bug c++/37671] New: can't use iostream library
Sent from my iPhone
On Sep 28, 2008, at 7:44 PM, hadmanysons at gmail dot com [EMAIL PROTECTED]
wrote:
Whenever I try to compile something using the iostream library, gcc
pumps out a
lot of errors. Here's the gcc -v -save-temps screen:
Using built-in specs.
Target: i386-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-
awt=gtk
--disable-dssi --enable-plugin
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile --enable-java-maintainer-mode
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-
multilib
--with-cpu=generic --build=i386-redhat-linux
Thread model: posix
gcc version 4.3.0 20080428 (Red Hat 4.3.0-8) (GCC)
Here's the errors i get get when compile (gcc src/mycode.cpp -o bin/
myprog):
gcc src/reg.cpp -o bin/reg
Use g++ to link instead of gcc.
/tmp/cc8kjHpW.o: In function `main':
reg.cpp:(.text+0x1c): undefined reference to `std::cout'
reg.cpp:(.text+0x21): undefined reference to `std::basic_ostreamchar,
std::char_traitschar std::operator std::char_traitschar
(std::basic_ostreamchar, std::char_traitschar , char const*)'
reg.cpp:(.text+0x29): undefined reference to `std::basic_ostreamchar,
std::char_traitschar std::endlchar, std::char_traitschar
(std::basic_ostreamchar, std::char_traitschar )'
reg.cpp:(.text+0x31): undefined reference to `std::basic_ostreamchar,
std::char_traitschar ::operator(std::basic_ostreamchar,
std::char_traitschar (*)(std::basic_ostreamchar,
std::char_traitschar
))'
/tmp/cc8kjHpW.o: In function
`__static_initialization_and_destruction_0(int,
int)':
reg.cpp:(.text+0x60): undefined reference to
`std::ios_base::Init::Init()'
reg.cpp:(.text+0x65): undefined reference to
`std::ios_base::Init::~Init()'
/tmp/cc8kjHpW.o:(.eh_frame+0x11): undefined reference to
`__gxx_personality_v0'
collect2: ld returned 1 exit status
I know your page said you didn't want a code snippet but I can't
help but think
it's relevant (I might just be overlooking something):
#include iostream
using namespace std;
int main(int argc, char *argv[])
{
std::coutasdfendl;
return 0;
}
Even something that simple won't work.
--
Summary: can't use iostream library
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hadmanysons at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37671
Re: Increment/decrement operator bugs
Sent from my iPhone
On Sep 25, 2008, at 10:39 AM, Miguel A. Quintans [EMAIL PROTECTED]
wrote:
Hello
The result of an expression using pre-decrement or pre-increment
such as:
y = x * n * --n;
Try turning on warnings. That is -Wsquence-points. The above is
specified behavior as there are squence points between the increment
of n and the other access of n.
gives different results in a few cases where x is placed before or
after the rest, or when its value is 1 or not. Please run the
program attached where a comment indicates what we think works
wrong. We obtain:
1.- 16
2.- 16
3.- 16
4.- 40
5.- 20
6.- 16
7.- 40
8.- 32
1.- 36
2.- 36
3.- 36
4.- 60
5.- 30
6.- 36
7.- 60
8.- 72
In contrast, the results we get running it in a AIX Computer with
the native compiler (IBM XL C/C++ Enterprise Edition for AIX, V9.0
Version: 09.00..) is what we expected:
1.- 20
2.- 20
3.- 20
4.- 40
5.- 20
6.- 20
7.- 40
8.- 40
1.- 30
2.- 30
3.- 30
4.- 60
5.- 30
6.- 30
7.- 60
8.- 60
We have experienced this issue in several versions of the gcc
compiler (the ones distributed under fedora cores 6, 7, 8, knoppix
5.0.1 and also in the windows Dev-c++ 4.9.9.2 package compiler)
obtaining the same results, that we think are (obviously) wrong.
We remain expectant of any comment from you.
Best regards
Miguel Ángel Quintáns Virginia Escuder
Professors at the Universidad de Alcalá
Madrid
Spain
#include int main () { int x=2; int p=1; int n=5; int y = n * --n;
printf (1.- %d\n,y); // wrong n=5; y = 1 * n * --n; printf (2.- %d
\n,y); // wrong n=5; y = n * --n * 1; printf (3.- %d\n,y); //
wrong n=5; y = 2 * n * --n; printf (4.- %d\n,y); n=5; y = p * n *
--n; printf (5.- %d\n,y); n=5; y = n * --n * p; printf (6.- %d
\n,y); // wrong n=5; y = x * n * --n; printf (7.- %d\n,y); n=5; y
= n * --n * x; printf (8.- %d\n,y); // wrong n=5; y = n * ++n;
printf (1.- %d\n,y); // wrong n=5; y = 1 * n * ++n; printf (2.- %d
\n,y); // wrong n=5; y = n * ++n * 1; printf (3.- %d\n,y); //
wrong n=5; y = 2 * n * ++n; printf (4.- %d\n,y); n=5; y = p * n * +
+n; printf (5.- %d\n,y); n=5; y = n * ++n * p; printf (6.- %d
\n,y); // wrong n=5; y = x * n * ++n; printf (7.- %d\n,y); n=5; y
= n * ++n * x; printf (8.- %d\n,y); // wrong }
Re: [Bug c/37609] New: Pointer arithmetic yields strange result
Sent from my iPhone On Sep 21, 2008, at 9:00 AM, john dot spelis at 3dlabs dot com [EMAIL PROTECTED] wrote: An expression using ptr arithmetic yields an unusual result unless a cast is applied; The problematic expression; MaxTimings = ((EDIDDetailed *) pExt-checksum) - pDTD; That is a signed division while the below is unsigned. works only when cast as; MaxTimings = (((uintptr_t) pExt-checksum) - ((uintptr_t) pDTD))/sizeof(*pDTD); This occurs on compilers back to 3.0.3 when testing on a x86. It's also present in a cross compiler built using 4.3.0 source Works on a Sun/Solaris compiler. A test program is attached -- Summary: Pointer arithmetic yields strange result Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: john dot spelis at 3dlabs dot com GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37609
Re: [Bug c++/36959] [4.2/4.3/4.4 Regression] C++ front-end causing a static inline function to be emitted
Sent from my iPhone On Sep 20, 2008, at 8:26 AM, rguenth at gcc dot gnu dot org [EMAIL PROTECTED] wrote: --- Comment #1 from rguenth at gcc dot gnu dot org 2008-09-20 15:26 --- What happens if you remove this piece of code? I suspect we merely need to keep the function declaration to emit proper debug information. I only tested disabling it for the non repo case and it worked and got the correct debugging info. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36959
Re: [Bug c++/37590] New: g++ should emit different debug info for variable's type
Sent from my iPhone On Sep 19, 2008, at 10:58 AM, tromey at gcc dot gnu dot org [EMAIL PROTECTED] wrote: Consider this code: #include string std::string s; I compiled this with -g and examined the resulting dwarf. 's' is represented as: 124e8: Abbrev Number: 63 (DW_TAG_variable) 24e9 DW_AT_name: s 24eb DW_AT_decl_file : 1 24ec DW_AT_decl_line : 3 24ed DW_AT_type: 24dd 24f1 DW_AT_external: 1 24f2 DW_AT_location: 5 byte block: 3 0 0 0 0 (DW_OP_addr: 0) The type of s is: 124dd: Abbrev Number: 3 (DW_TAG_typedef) 24de DW_AT_name: (indirect string, offset: 0xf4e): string 24e2 DW_AT_decl_file : 17 24e3 DW_AT_decl_line : 61 24e4 DW_AT_type: f51 However, the declared type is not 'string', it is 'std::string'. No it is string inside the namespace of std. This typedef should be a sibling of a namespace. If it is, then it is the job of the debugger to show the correct thing. I think it would be better to always emit the declared type as it appears in the source. That way, whatis s in gdb will give an answer which is expected by the user, and which is a valid type name at the point of declaration. -- Summary: g++ should emit different debug info for variable's type Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tromey at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37590
Re: [Bug inline-asm/37562] New: [4.2] -funroll-loops destroys inline asm code von powerpc
Sent from my iPhone
On Sep 17, 2008, at 8:42 AM, rbuergel at web dot de [EMAIL PROTECTED]
wrote:
typedef unsigned int UInt32;
typedef unsigned char UInt8;
struct Data
{
UInt8 data[16];
const UInt8* getData() const
{
return data + 4;
}
};
struct Value {
UInt32 value;
static void update (Value signal, const Data source, UInt32
startBit);
};
void Value::update(Value signal, const Data source, UInt32
startByte)
{
UInt32 value = signal.value;
const UInt8* data = source.getData();
asm( lwbrx %0,%1,%2;\n:=r(value): r(data), r(startByte),
m (*(data
+ startByte)) );
}
The second constraint should be using b instead of r as b says
don't use r0.
generated for gcc-4.2.4 on powerpc:
_ZN5Value6updateERS_RK4Dataj:
0: 38 04 00 04 addir0,r4,4
4: 7c 80 2c 2c lwbrx r4,0,r5
8: 90 83 00 00 stw r4,0(r3)
c: 4e 80 00 20 blr
the correct version without -funroll-loops reads:
_ZN5Value6updateERS_RK4Dataj:
0: 38 84 00 04 addir4,r4,4
4: 7c 84 2c 2c lwbrx r4,r4,r5
8: 90 83 00 00 stw r4,0(r3)
c: 4e 80 00 20 blr
lwbrx sums the contents of r4 and r5 and accesses this address,
swaps it's
value and stores it again in r4. The incorrect version accesses an
invalid
address, which leads to a segmentation fault.
this is corrected at least with gcc-4.3.1, there i couldn't
reproduce the
behaviour.
--
Summary: [4.2] -funroll-loops destroys inline asm code von
powerpc
Product: gcc
Version: 4.2.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: inline-asm
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rbuergel at web dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37562
Re: [Bug tree-optimization/37526] [4.4 Regression] ICE using --combine -O2
Sent from my iPhone
On Sep 16, 2008, at 6:20 AM, rguenth at gcc dot gnu dot org [EMAIL PROTECTED]
wrote:
--- Comment #7 from rguenth at gcc dot gnu dot org 2008-09-16
13:20 ---
./cc1 -quiet -O2 t1.i t2.i
t2.i: In function 'Node_print':
t2.i:2: error: non-trivial conversion at assignment
struct _IO_FILE *
struct _IO_FILE *
# LOADS: { stderr }
stderr.0_3 = stderr;
t2.i:2: error: non-trivial conversion at assignment
struct _IO_FILE *
struct _IO_FILE *
# LOADS: { stderr }
stderr.0_4 = stderr;
No those two types should compatible. If they are not then there is a
bug in the middle-end. I think this is why there was the Lang hook in
the first place.
t2.i:2: internal compiler error: verify_stmts failed
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
So we have wrong GIMPLE here. GIGO.
Value numbering stderr.0_3 stmt = stderr.0_3 = stderr;
Setting value number of stderr.0_3 to stderr.0_3
...
Value numbering stderr.0_4 stmt = stderr.0_4 = stderr;
Inserting name stderr.0_17 for expression (struct _IO_FILE *) stderr.
0_3
Setting value number of stderr.0_4 to stderr.0_17
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
---
--
CC||rguenth at gcc dot
gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37526
Re: [Bug driver/37551] New: gcc help should provide subarchitecture details
Sent from my iPhone On Sep 16, 2008, at 7:44 PM, martinrb at google dot com [EMAIL PROTECTED] wrote: How do I find out whether a particular gcc supports a particular subarchitecture, e.g. MMX instructions, by default? If the gcc has been configured --with-arch=, I can get that value using: gcc -v --help 21 | grep 'Configured with' but if the arch has defaulted based on the target triplet, it is less obvious. Is it documented that configure i486-xx is equivalent to configure --with-arch=i486 ? Even better, it would be nice if gcc -v --help said something like: mmx support is enabled (use -mno-mmx to disable it) sse support is disabled (use -msse to enable it) I would have guessed gcc -dumpspecs would give me this kind of information, but it appears not to. This is already done in 4.3.0 where it shows the options and what are enabled already. -- Summary: gcc help should provide subarchitecture details Product: gcc Version: 4.2.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: martinrb at google dot com GCC host triplet: x86_64-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37551
Re: [Bug preprocessor/37550] New: Please document predefined sub-architecture support macros
Sent from my iPhone On Sep 16, 2008, at 7:35 PM, martinrb at google dot com [EMAIL PROTECTED] wrote: The preprocessor symbol __MMX__ indicates whether this gcc includes mmx support. This is extremely useful, but undocumented. I only found out by finding the symbol in other peoples' code. Some targets actually define this based some specifications of the target. Spu and -mcpu=cell on powerpc define __SPU__/__PPU__ as specified by the C/C++ language extension for the cbea document. I bet x86 has this specified in their documentation rather than in GCC's documentation. The particular symbol __MMX__ should be documented in the obvious place, namely where the -mmmx flag is documented in the x86-specific page. And of course, similarly for other such predefined flags. I assume there's one for sse, but I haven't actually tried to find out. Here's a shell transcript, again compiling my favorite source file, /dev/null: ([EMAIL PROTECTED]) ~ $ gcc -mmmx -E -dD -x c /dev/null | sort / tmp/t1 ([EMAIL PROTECTED]) ~ $ gcc -mno-mmx -E -dD -x c /dev/null | sort /tmp/t2 ([EMAIL PROTECTED]) ~ $ diff /tmp/t[12] 92d91 #define __MMX__ 1 -- Summary: Please document predefined sub-architecture support macros Product: gcc Version: 4.2.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: martinrb at google dot com GCC host triplet: x86_64-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37550
Re: [Bug preprocessor/37549] New: gcc -E -dD prints predefined macros, contrary to docs
Sent from my iPhone On Sep 16, 2008, at 7:25 PM, martinrb at google dot com [EMAIL PROTECTED] wrote: The docs for preprocessor -dD flag states `D' Like `M' except in two respects: it does _not_ include the predefined macros I think what it means by predefines are the ones included on the command line that are defined by the user via -D. So one would expect -dD and -dM to differ substantially. But ([EMAIL PROTECTED]) ~ $ gcc -E -dM -x c /dev/null | sort /tmp/t1 ([EMAIL PROTECTED]) ~ $ gcc -E -dD -x c /dev/null | sort /tmp/t2 ([EMAIL PROTECTED]) ~ $ diff /tmp/t[12] 0a1,4 # 1 built-in # 1 command-line # 1 /dev/null # 1 /dev/null ([EMAIL PROTECTED]) ~ $ wc /tmp/t[12] 111 340 3482 /tmp/t1 115 352 3552 /tmp/t2 226 692 7034 total ([EMAIL PROTECTED]) ~ $ gcc --version gcc (GCC) 4.2.3 (Ubuntu 4.2.3-2ubuntu7) -- Summary: gcc -E -dD prints predefined macros, contrary to docs Product: gcc Version: 4.2.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: martinrb at google dot com GCC host triplet: x86_64-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37549
Re: [Bug c++/37518] New: preprocessor failure
Sent from my iPhone On Sep 13, 2008, at 11:02 PM, rwgk at yahoo dot com [EMAIL PROTECTED] wrote: Platform: Fedora release 8 (Werewolf) Linux chevy.lbl.gov 2.6.23.15-137.fc8 #1 SMP Sun Feb 10 17:03:13 EST 2008 x86_64 x86_64 x86_64 GNU/Linux % g++ -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: /net/chevy/raid1/rwgk/gcc_trunk/configure --prefix=/net/cci-filer1/vol1/tmp/rwgk/gcc_trunk_140355_fc8_x86_64 --enable-languages=c,c++,fortran Thread model: posix gcc version 4.4.0 20080914 (experimental) (GCC) % cat boost_mpl_less.cpp #include boost/mpl/less.hpp % g++ -c boost_mpl_less.cpp In file included from /usr/include/boost/mpl/aux_/numeric_op.hpp:22, from /usr/include/boost/mpl/aux_/comparison_op.hpp:27, from /usr/include/boost/mpl/less.hpp:19, from boost_mpl_less.cpp:1: /usr/include/boost/mpl/apply_wrap.hpp:81:31: error: missing binary operator before token ( What is on that line? I think this is invalid code and there is already a dup of this too. /usr/include/boost/mpl/apply_wrap.hpp:173:31: error: missing binary operator before token ( In file included from /usr/include/boost/mpl/aux_/ numeric_cast_utils.hpp:18, from /usr/include/boost/mpl/aux_/numeric_op.hpp:25, from /usr/include/boost/mpl/aux_/comparison_op.hpp:27, from /usr/include/boost/mpl/less.hpp:19, from boost_mpl_less.cpp:1: /usr/include/boost/mpl/apply_wrap.hpp:81:31: error: missing binary operator before token ( /usr/include/boost/mpl/apply_wrap.hpp:173:31: error: missing binary operator before token ( In file included from /usr/include/boost/mpl/aux_/comparison_op.hpp: 27, from /usr/include/boost/mpl/less.hpp:19, from boost_mpl_less.cpp:1: /usr/include/boost/mpl/aux_/numeric_op.hpp:290:31: error: missing binary operator before token ( Observations: g++ -E boost_mpl_less.cpp /dev/null leads to the same error. Many other mpl headers lead to a similar error. Adding -fpermissive doesn't make a difference. Using the boost svn trunk instead of the boost that comes with Fedora 8 leads to the same error. -- Summary: preprocessor failure Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rwgk at yahoo 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=37518
Re: [Bug c/37506] New: attribute section is not working with constant strings
Sent from my iPhone
On Sep 13, 2008, at 2:04 AM, nm127 at freemail dot hu [EMAIL PROTECTED]
wrote:
With the __attribute__ __section__ it is possible to allocate
variables to
different section than the default (
http://gcc.gnu.org/onlinedocs/gcc/Variable-Attributes.html ). In
case of the
following source code I would achieve to allocate both foo bar and
Hello
World! strings into the .xxx_section section:
char x[] __attribute__ ((__section__(.xxx_section))) = foo bar;
char* y __attribute__ ((__section__(.xxx_section))) = Hello
World!;
int main() {
return 0;
}
However, with gcc version 4.3.1 (Debian 4.3.1-9) only the foo bar
string is
stored in .xxx_section:
$ objdump -s a.out
a.out: file format elf32-i386
[...]
Contents of section .rodata:
8048448 0300 01000200 48656c6c 6f20576f Hello Wo
8048458 726c6421 00 rld!.
[...]
Contents of section .xxx_section:
8049568 666f6f20 62617200 50840408 foo bar.P...
--
Summary: attribute section is not working with constant
strings
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: nm127 at freemail dot hu
GCC build triplet: 4.3.1
GCC target triplet: i486-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37506
Re: [Bug c++/37511] ice for simple legal C++ code
Sent from my iPhone On Sep 13, 2008, at 12:58 PM, rguenth at gcc dot gnu dot org [EMAIL PROTECTED] wrote: --- Comment #2 from rguenth at gcc dot gnu dot org 2008-09-13 19:58 --- works for me. Honza, I guess you fixed this recently? I think this was fixed by the pt.c change. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added --- --- -- CC||hubicka at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37511
Re: [Bug rtl-optimization/37408] New: [4.3/4.4 regression] Invalid insn scheduling
Sent from my iPhone On Sep 7, 2008, at 9:47, schwab at suse dot de [EMAIL PROTECTED] wrote: This is broken during sched2 pass. Compiled with -m64 -O2. lwz 10,1492(7) # nargs,--- uninitialized std 9,1272(7)# specpdl.19, li 9,16 # iftmp.21, std 3,1488(7)# nargs, nargs std 4,1496(7)# args, args cmpwi 7,10,3 #, tmp307, Just looking at the assembler suggest an aliasing issue. I had a quick look at the code but I did see anything would give an alaising issue. Though there were some unions. -- Summary: [4.3/4.4 regression] Invalid insn scheduling Product: gcc Version: 4.3.1 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: schwab at suse dot de GCC target triplet: powerpc64-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37408
Re: [Bug target/37390] wrong-code on i486-linux-gnu with -O[12], -O0 works
Sent from my iPhone On Sep 6, 2008, at 10:42, niklaus at gmail dot com [EMAIL PROTECTED] wrote: --- Comment #4 from niklaus at gmail dot com 2008-09-06 17:42 --- On the below version of gcc on cygwin (winXP SP3) i don't have any problems with optimization on or off. They produce consistent correct result. Why is it a problem with linux ? or am i doing something wrong. Because on x86 gnu/Linux, the precision is set to 80bits rather than 64bit like it is on windows. I tried gcc -mfpmath=387 a.c -O2 and without -O2 , still the same correct results on both. Even with -ffloat-store . Is it glibc ? $ gcc -v Reading specs from /usr/lib/gcc/i686-pc-cygwin/3.4.4/specs Configured with: /usr/build/package/orig/test.respin/gcc-3.4.4-3/ configure --verbose --prefix=/usr - -exec-prefix=/usr --sysconfdir=/etc --libdir=/usr/lib --libexecdir=/ usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --enable-languages=c,ada,c+ +,d,f77,pascal,java,objc --enable-nls --without -included-gettext --enable-version-specific-runtime-libs --without-x --enable-libgcj --disable-java- awt --with-system-zlib --enable-interpreter --disable-libgcj-debug --enable-threads=posix --enable-j ava-gc=boehm --disable-win32-registry --enable-sjlj-exceptions --enable-hash-synchronization --enabl e-libstdcxx-debug Thread model: posix gcc version 3.4.4 (cygming special, gdc 0.12, using dmd 0.125) $ -- niklaus at gmail dot com changed: What|Removed |Added --- --- -- CC||niklaus at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37390
Re: [Bug bootstrap/37308] bootstrap hangs in libstdc++
Sent from my iPhone On Sep 1, 2008, at 3:25, paolo dot carlini at oracle dot com [EMAIL PROTECTED] wrote: --- Comment #4 from paolo dot carlini at oracle dot com 2008-09-01 10:25 --- Note that the TLS check code is used in libstdc++-v3, but it's actually part of the general GCC config infrastructure: tls.m4. It's also used in libjava, for example. The other thing is that _thread is emulated on targets that don't support it. -- paolo dot carlini at oracle dot com changed: What|Removed |Added --- --- -- Summary|bootstrap hug on libstdc++.a|bootstrap hangs in libstdc++ http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37308
Re: [Bug tree-optimization/37312] -Os significantly faster than -O2 on test case
This is mostly because of extra register moves that IRA some times introduces. There is another bug about Inline-asm and the return register. Sent from my iPhone On Sep 1, 2008, at 7:36, rguenth at gcc dot gnu dot org [EMAIL PROTECTED] wrote: --- Comment #4 from rguenth at gcc dot gnu dot org 2008-09-01 14:36 --- Well, now -Os -funroll-all-loops doesn't do any unrolling anymore while it did before. With -O2 you get what you ask for - unrolled loops. -funroll-all-loops isn't really a flag to be used in general. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37312
Re: [Bug middle-end/37293] [4.4 Regression] r139762 breaks libstdc++ build on darwin
Sent from my iPhone On Aug 30, 2008, at 21:18, howarth at nitro dot med dot uc dot edu [EMAIL PROTECTED] wrote: --- Comment #7 from howarth at nitro dot med dot uc dot edu 2008-08-31 04:18 --- The proposed patch changes the previous compilation failure into... I will see what I can do about this issue. Mostly we need to look at where we change from weak to non weak and then fix up those call statements. Honza, does that seem correct? Thanks, Andrew Pinski /bin/sh ../libtool --tag CXX --mode=compile /sw/src/fink.build/gcc44-4.3.999-20080830/darwin_objdir/./gcc/xgcc -shared-libgcc -B/sw/src/fink.build/gcc44-4.3.999-20080830/ darwin_objdir/./gcc -nostdinc++ -L/sw/src/fink.build/gcc44-4.3.999-20080830/darwin_objdir/i686-apple- darwin9/libstdc++-v3/src -L/sw/src/fink.build/gcc44-4.3.999-20080830/darwin_objdir/i686-apple- darwin9/libstdc++-v3/src/.libs -B/sw/lib/gcc4.4/i686-apple-darwin9/bin/ -B/sw/lib/gcc4.4/i686-apple-darwin9/lib/ -isystem /sw/lib/gcc4.4/i686-apple-darwin9/include -isystem /sw/lib/gcc4.4/i686-apple-darwin9/sys-include -I/sw/src/fink.build/gcc44-4.3.999-20080830/darwin_objdir/i686-apple- darwin9/libstdc++-v3/include/i686-apple-darwin9 -I/sw/src/fink.build/gcc44-4.3.999-20080830/darwin_objdir/i686-apple- darwin9/libstdc++-v3/include -I/sw/src/fink.build/gcc44-4.3.999-20080830/gcc-4.4-20080830/libstdc+ +-v3/libsupc++ -I/sw/include -fno-implicit-templates -Wall -Wextra -Wwrite-strings - Wcast-qual -fdiagnostics-show-location=once -fvisibility-inlines-hidden -ffunction-sections -fdata-sections -g -O2-c -o bitmap_allocator.lo ../../../../gcc-4.4-20080830/libstdc++-v3/src/bitmap_allocator.cc libtool: compile: /sw/src/fink.build/gcc44-4.3.999-20080830/darwin_objdir/./gcc/xgcc -shared-libgcc -B/sw/src/fink.build/gcc44-4.3.999-20080830/ darwin_objdir/./gcc -nostdinc++ -L/sw/src/fink.build/gcc44-4.3.999-20080830/darwin_objdir/i686-apple- darwin9/libstdc++-v3/src -L/sw/src/fink.build/gcc44-4.3.999-20080830/darwin_objdir/i686-apple- darwin9/libstdc++-v3/src/.libs -B/sw/lib/gcc4.4/i686-apple-darwin9/bin/ -B/sw/lib/gcc4.4/i686-apple-darwin9/lib/ -isystem /sw/lib/gcc4.4/i686-apple-darwin9/include -isystem /sw/lib/gcc4.4/i686-apple-darwin9/sys-include -I/sw/src/fink.build/gcc44-4.3.999-20080830/darwin_objdir/i686-apple- darwin9/libstdc++-v3/include/i686-apple-darwin9 -I/sw/src/fink.build/gcc44-4.3.999-20080830/darwin_objdir/i686-apple- darwin9/libstdc++-v3/include -I/sw/src/fink.build/gcc44-4.3.999-20080830/gcc-4.4-20080830/libstdc+ +-v3/libsupc++ -I/sw/include -fno-implicit-templates -Wall -Wextra -Wwrite-strings - Wcast-qual -fdiagnostics-show-location=once -fvisibility-inlines-hidden -ffunction-sections -fdata-sections -g -O2 -c ../../../../gcc-4.4-20080830/libstdc++-v3/src/bitmap_allocator.cc - fno-common -DPIC -o .libs/bitmap_allocator.o ../../../../gcc-4.4-20080830/libstdc++-v3/src/bitmap_allocator.cc: In member function 'void __gnu_cxx::bitmap_allocator_Tp::_M_deallocate_single_object(_Tp*) [with _Tp = wchar_t]': ../../../../gcc-4.4-20080830/libstdc++-v3/src/bitmap_allocator.cc: 126: error: statement marked for throw, but doesn't T.292 (__diff_74); ../../../../gcc-4.4-20080830/libstdc++-v3/src/bitmap_allocator.cc: 126: internal compiler error: verify_stmts failed Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37293
Re: [Bug c++/37281] New: bad code generation with enum and -m32
This code is undefined as the value of 32 is outside the range of the
enum.
Sent from my iPhone
On Aug 29, 2008, at 9:29, gmorin1 at bloomberg dot net [EMAIL PROTECTED]
wrote:
This is a copy of a Debian report that I made (I thought I might as
well report
it directly here too): http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=496965
g++ generates bad code for this program on an amd64 machine. It
works with
fine in 64-bit and with older versions of gcc.
#include stdlib.h
struct MyTypes {
enum Type {
NOVALUE = 1,
VALUE = 30,
VALUE2 = 31,
VALUE3 = -3
};
static bool isValue(MyTypes::Type value);
};
bool MyTypes::isValue(MyTypes::Type value)
{
switch (value) {
case MyTypes::VALUE:
case MyTypes::VALUE2:
case MyTypes::VALUE3: {
return true;
}
default: {
return false;
}
}
}
int main(int argc, char *argv[])
{
if (true == MyTypes::isValue(MyTypes::Type(32))) {
abort();
}
return 0;
}
[EMAIL PROTECTED]:~$ g++ -m32 -Wall -o e enumtest.cpp
[EMAIL PROTECTED]:~$ ./e
Aborted
[EMAIL PROTECTED]:~$ g++ -Wall -o e enumtest.cpp
[EMAIL PROTECTED]:~$ ./e
[EMAIL PROTECTED]:~$ g++-4.2 -m32 -Wall -o e enumtest.cpp
[EMAIL PROTECTED]:~$ ./e
[EMAIL PROTECTED]:~$ g++-4.1 -m32 -Wall -o e enumtest.cpp
[EMAIL PROTECTED]:~$ ./e
It works with -O2 though (not -O1):
[EMAIL PROTECTED]:~$ g++ -O2 -m32 -Wall -o e enumtest.cpp
[EMAIL PROTECTED]:~$ ./e
-- System Information:
Debian Release: lenny/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable')
Architecture: amd64 (x86_64)
--
Summary: bad code generation with enum and -m32
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gmorin1 at bloomberg dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37281
Re: [Bug c/37103] New: possible integer codegen bug
Note for most targets not printing is correct as char is signed by
default but for most powerpc targets the opposite is true. You should
have explicted included signed for g_99.
Sent from my iPhone
On Aug 12, 2008, at 22:10, regehr at cs dot utah dot edu [EMAIL PROTECTED]
wrote:
This is an interesting one...
Compiling the code below at all common optimization levels, gcc
r139046
generates code that prints hello, as does 4.3.1. Pre-4.3 versions
of gcc emit
code that prints nothing. I'm pretty sure that the older versions
are correct.
#include stdio.h
int func_72 (void);
int func_72 (void)
{
printf (hello\n);
return 0;
}
void func_58 (unsigned short p_65);
void func_58 (unsigned short p_65)
{
char g_99 = -1;
(p_65 != g_99) || (func_72 ());
}
int main (void)
{
func_58 (-1);
return 0;
}
--
Summary: possible integer codegen bug
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: regehr at cs dot utah dot edu
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37103
Re: [Bug rtl-optimization/36998] [4.3/4.4 regression] Ada bootstrap broken on i586-*-*
Sent from my iPhone On Aug 11, 2008, at 2:43, rguenth at gcc dot gnu dot org [EMAIL PROTECTED] wrote: --- Comment #14 from rguenth at gcc dot gnu dot org 2008-08-11 09:43 --- With building the lirc kernel module I am also able to trogger /usr/src/packages/BUILD/lirc-0.8.3/obj/default/lirc_atiusb// lirc_atiusb.c:433: internal compiler error: in compute_barrier_args_size, at dwarf2out.c:1239 Please submit a full bug report, with preprocessed source if appropriate. See http://bugs.opensuse.org/ for instructions. which is slightly different. No testcase yet as the package seems to be broken in different ways anyway (seems to be the same kind of assert though). There is a pr about this failure already. It happens because of combing noreturn calls. -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36998
Re: [Bug middle-end/37078] New: ICE when compiling gmp 4.2.3
Sent from my iPhone On Aug 11, 2008, at 0:35, linuxl4 at sohu dot com [EMAIL PROTECTED] wrote: gcc -v gcc version 4.4.0 20080810 (experimental) (GCC) g++ -DHAVE_CONFIG_H -I. -I../../../tests/cxx -I../.. -I../../.. -I../../../tests -O2 -c -o t-ops.o ../../../tests/cxx/t-ops.cc ../../../tests/cxx/t-ops.cc: In function 'void check_mpz()': ../../../tests/cxx/t-ops.cc:33: internal compiler error: in set_value_range, at tree-vrp.c:396 Please submit a full bug report,with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Can you attach the preprocessed source as requested by the error message? -- Pinski -- Summary: ICE when compiling gmp 4.2.3 Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: linuxl4 at sohu dot com GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37078
Re: [Bug ada/37038] Bogus warning from GCC
Sent from my iPhone On Aug 6, 2008, at 8:39, sam at gcc dot gnu dot org [EMAIL PROTECTED] wrote: --- Comment #2 from sam at gcc dot gnu dot org 2008-08-06 15:39 --- The warning comes from a range check which is emitted by Gigi. The backend knows that this check is useless, and warns about it. As far as I can tell, there is no way to suppress the warning in shorten_compare (c- common.c), except by setting a global option (OPT_Wtype_limits) to false. C-common.c being included by the Ada front-end That is a c front- end file. -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37038
Re: [Bug c/37044] Heisenbug: SVN of gcc throws internal compiler error on PPC
Sent from my iPhone On Aug 6, 2008, at 22:30, contact at multimedia dot cx [EMAIL PROTECTED] wrote: --- Comment #1 from contact at multimedia dot cx 2008-08-07 05:30 --- The same thing happens with gcc SVN-138833 (along with FFmpeg SVN 14654)-- dca.c file compilation crashes but not with -save-temps. Please attach the preprocessed source. This is most likely a GC issue. -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37044
Re: [Bug preprocessor/36906] New: #pragma GNU poison index()
Try the attribute deprecated. Sent from my iPhone On Jul 22, 2008, at 23:50, Dave at Yost dot com [EMAIL PROTECTED] wrote: There should be a way to poison a symbol only when it is used as a function or macro call. I suggest that following a symbol with a pair of parentheses might be a serviceable syntax for this. With this feature, the symbol rindex would still be usable for variables. -- Summary: #pragma GNU poison index() Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: preprocessor AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: Dave at Yost dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36906
