[Bug c++/66411] False positive in array bound check in a for loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66411 --- Comment #2 from Doug Kwan dougkwan at google dot com --- (In reply to Richard Biener from comment #1) This has been fixed for 4.9.3 Do you know which patch fixes it?
[Bug c++/66411] New: False positive in array bound check in a for loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66411
Bug ID: 66411
Summary: False positive in array bound check in a for loop
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dougkwan at google dot com
Target Milestone: ---
gcc-4.9.2 produces a bogus out of bound warning for the following test case
class A;
class C {
void m_fn1();
A *a_;
};
class A {
public:
void m_fn2();
int elements_[8];
int num_elements_;
};
int a;
void A::m_fn2() {
int b = 0;
if (num_elements_)
++b;
for (int i = b + 1; i num_elements_; ++i) {
if (elements_[i])
++a;
}
}
void C::m_fn1() {
a_-m_fn2();
}
sh-4.3$ ~/gcc-4.9.2/install/bin/g++ -O3 -Werror=array-bounds bug.cc -c -o
/dev/null
bug.cc: In member function ‘void A::m_fn2()’:
bug.cc:21:20: error: array subscript is above array bounds
[-Werror=array-bounds]
if (elements_[i])
^
bug.cc: In member function ‘void C::m_fn1()’:
bug.cc:21:20: error: array subscript is above array bounds
[-Werror=array-bounds]
if (elements_[i])
^
cc1plus: some warnings being treated as errors
sh-4.3$
gcc config:
sh-4.3$ ~/gcc-4.9.2/install/bin/g++ -v
Using built-in specs.
COLLECT_GCC=/usr/local/google/home/dougkwan/gcc-4.9.2/install/bin/g++
COLLECT_LTO_WRAPPER=/usr/local/google/home/dougkwan/gcc-4.9.2/install/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.9.2/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.9.2/configure --enable-languages=c,c++
--disable-bootstrap --disable-multilib
Thread model: posix
gcc version 4.9.2 (GCC)
[Bug target/58838] New: mullw sets condition code incorrectly.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58838
Bug ID: 58838
Summary: mullw sets condition code incorrectly.
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: dougkwan at google dot com
It was observed in 4.7 and trunk that the Power backend generated bad code
involving condition setting mullw. Below is a test case for the problem:
-
#include cassert
#include cstdlib
#include vector
struct b88 {
char data[88];
};
namespace {
inline int int_size(const std::vectorb88 v) {
return v.size();
}
}
int __attribute__ ((noinline))
foo(const std::vectorb88 v) {
if (int_size(v) 0) {
return atoi(1);
}
return 0;
}
int main() {
std::vectorb88 v;
v.push_back(b88());
assert(foo(v) != 0);
return 0;
}
The above test failed with gcc 4.7 and trunk for target powerpc64-linux-gnu
We seem to be fine getting out of the middle-end of gcc-4.7:
;; Function int foo(const std::vectorb88) (_Z3fooRKSt6vectorI3b88SaIS0_EE,
funcdef_no=473, decl_uid=9136, cgraph_uid=102)
int foo(const std::vectorb88) (const struct vector v)
{
int _1;
struct b88 * _4;
struct b88 * _5;
long int _6;
long int _7;
long int _8;
long int _9;
int _10;
long int _11;
int _12;
bb 2:
_4 = MEM[(const struct vector *)v_3(D)];
_5 = MEM[(const struct vector *)v_3(D) + 8B];
_6 = (long int) _5;
_7 = (long int) _4;
_8 = _6 - _7;
_9 = _8 /[ex] 88;
_10 = (int) _9;
if (_10 0)
goto bb 3;
else
goto bb 4;
bb 3:
_11 = strtol (1, 0B, 10);
_12 = (int) _11;
bb 4:
# _1 = PHI _12(3), 0(2)
return _1;
}
RTL expansion looks correct, gcc expands _8 /[ex] 88; into shift and
multiplication.
(_8 3) * 0x2e8ba2e8ba2e8ba3.
Since we know that the _8 is a multiple of 88, we can do this.
0x2e8ba2e8ba2e8ba3 is the multiplicative-inverse of 11 in Z{2^64}.
But the selected PPC instruction is bad:
0x1b80 ._Z3fooRKSt6vectorI3b88SaIS0_EE:lis r9,11915
0x1b84 ._Z3fooRKSt6vectorI3b88SaIS0_EE+4: ld r8,8(r3)
0x1b88 ._Z3fooRKSt6vectorI3b88SaIS0_EE+8: ld r10,0(r3)
0x1b8c ._Z3fooRKSt6vectorI3b88SaIS0_EE+12: ori r9,r9,41704
0x1b90 ._Z3fooRKSt6vectorI3b88SaIS0_EE+16: rldicr r9,r9,32,31
0x1b94 ._Z3fooRKSt6vectorI3b88SaIS0_EE+20: subfr10,r10,r8
0x1b98 ._Z3fooRKSt6vectorI3b88SaIS0_EE+24: orisr9,r9,47662
0x1b9c ._Z3fooRKSt6vectorI3b88SaIS0_EE+28: sradi r10,r10,3
0x1ba0 ._Z3fooRKSt6vectorI3b88SaIS0_EE+32: ori r9,r9,35747
0x1ba4 ._Z3fooRKSt6vectorI3b88SaIS0_EE+36: mullw. r8,r10,r9
note the dot
0x1ba8 ._Z3fooRKSt6vectorI3b88SaIS0_EE+40: ble 0x1bf0
._Z3fooRKSt6vectorI3b88SaIS0_EE+112
mullw correctly computes the lower 32-bits of _9 = _8 /[ex] 88; but it sets
the condition code incorrectly, since signed-comparison is done in 64 bits.
Instead there should be sign extension, ie.
mullw r8,r10,r9
extsw. r8,r8
[Bug target/50194] wrong tail call optimization for mixed arm/thumb mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50194 Doug Kwan dougkwan at google dot com changed: What|Removed |Added CC||dougkwan at google dot com --- Comment #2 from Doug Kwan dougkwan at google dot com 2011-08-29 02:50:20 UTC --- Did you try -fuse-ld=bfd to see if this problem appear in both linkers?
[Bug c/49551] New: common variables and -fdata-sections cause ICE in C front-end.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49551 Summary: common variables and -fdata-sections cause ICE in C front-end. Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: dougk...@google.com The following 2 line cause both gcc-4.6.0 and trunk to crash: ---bug.c--- int x = 1; int x; --- $ arm-unknown-linux-gnueabi-gcc -O -fdata-sections bug.c bug.c:2:1: internal compiler error: in get_variable_section, at varasm.c:1004 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. $ arm-unknown-linux-gnueabi-gcc -v Using built-in specs. COLLECT_GCC=install/bin/arm-unknown-linux-gnueabi-gcc COLLECT_LTO_WRAPPER=/usr/local/google2/home/dougkwan/gcc-trunk-1/install/bin/../libexec/gcc/arm-unknown-linux-gnueabi/4.7.0/lto-wrapper Target: arm-unknown-linux-gnueabi Configured with: ../gcc/configure --target=arm-unknown-linux-gnueabi --disable-bootstrap --enable-languages=c --with-gmp=/home/dougkwan/gcc-lib --with-sysroot=/home/dougkwan/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/sys-root Thread model: posix gcc version 4.7.0 20110607 (experimental) (GCC)
[Bug c/49551] common variables and -fdata-sections cause ICE in C front-end.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49551 --- Comment #1 from Doug Kwan dougkwan at google dot com 2011-06-27 20:47:59 UTC --- The variable x in the test case is should not be a common variable but the DECL_COMMON is set after merging the first and the second declarations. That ultimately leads to an ICE.
[Bug libstdc++/48123] New: bits/cpu_defines.h not installed in freestanding mode.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48123 Summary: bits/cpu_defines.h not installed in freestanding mode. Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: dougk...@google.com Headers like new and typeinfo include c++config.h, which in turn includes bits/cpu_defines.h. However, the header bits/cpu_defines.h is not installed in freestanding mode, causing problems. I believe the fix is to add cpu_defines.h in the rule install-freestanding-headers of libstdc++-v3/include/Makefile.am. gcc configured as: Configured with: ../gcc/configure --build=x86_64-build_unknown-linux-gnu --host=x86_64-build_unknown-linux-gnu --target=arm-unknown-linux-gnueabi --prefix=/tmp/install --with-sysroot=/tmp/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi//sys-root --enable-languages=c,c++ --disable-multilib --with-float=soft --with-pkgversion=crosstool-NG-1.9.0 --disable-sjlj-exceptions --enable-__cxa_atexit --disable-libmudflap --disable-libgomp --disable-libssp --with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm' --with-gmp=/tmp/gcc-lib --with-mpfr=/tmp/gcc-lib --with-ppl=/tmp/gcc-lib --without-cloog --enable-threads=posix --enable-target-optspace --with-local-prefix=/tmp/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/sys-root --disable-nls --enable-symvers=gnu --enable-c99 --enable-long-long --disable-bootstrap --disable-hosted-libstdcxx $ /tmp/install/arm-unknown-linux-gnueabi-g++ rtti-test.cc In file included from /tmp/install/lib/gcc/arm-unknown-linux-gnueabi/4.7.0/../../../../arm-unknown-linux-gnueabi/include/c++/4.7.0/exception:39:0, from /tmp/install/lib/gcc/arm-unknown-linux-gnueabi/4.7.0/../../../../arm-unknown-linux-gnueabi/include/c++/4.7.0/typeinfo:36, from rtti-test.cc:4: /tmp/install/lib/gcc/arm-unknown-linux-gnueabi/4.7.0/../../../../arm-unknown-linux-gnueabi/include/c++/4.7.0/arm-unknown-linux-gnueabi/bits/c++config.h:395:30: fatal error: bits/cpu_defines.h: No such file or directory compilation terminated.
[Bug other/43449] New: sbitmap is broken if gcc is built with -m32 on a 64-bit machine.
We found a problem in sbitmap.c:
bool
sbitmap_range_empty_p (const_sbitmap bmap, unsigned int start, unsigned int n)
{
unsigned int i = start / SBITMAP_ELT_BITS;
SBITMAP_ELT_TYPE elm;
...
/* The bits are totally contained in a single element. */
if (shift + n SBITMAP_ELT_BITS)
elm = ((1 n) - 1);
depending on configuration, SBITMAP_ELT_TYPE can be wider than the int type.
The masking above will mistakenly strip off top bits from elm. The correct
code should be written as:
/* The bits are totally contained in a single element. */
if (shift + n SBITMAP_ELT_BITS)
elm = (((SBITMAP_ELF_BITS) 1 n) - 1);
The same problem appears in another location of the same function. The broken
code is in both 4.4.0 and trunk.
--
Summary: sbitmap is broken if gcc is built with -m32 on a 64-bit
machine.
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dougkwan at google dot com
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu (with -m32)
GCC target triplet: arm-none-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43449
[Bug other/43449] sbitmap is broken if gcc is built with -m32 on a 64-bit machine.
--- Comment #3 from dougkwan at google dot com 2010-03-19 23:09 --- Yes, I lied to configure. So this is not a real bug. -- dougkwan at google dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43449
[Bug rtl-optimization/41574] Distribute floating point expressions causes bad code [4.4 only]
--- Comment #10 from dougkwan at google dot com 2009-10-20 06:22 --- (In reply to comment #9) (In reply to comment #8) This is fixed in trunk but at least gcc-4.4.0, where this bug was found, is still broken. I have no approval rights but can you test ask to backport this to 4.4 branch after the freeze for the 4.4.2 release is lifted ? Sorry about the late reply. Yes, I can prepare a fix for 4.4.2 -Doug -- dougkwan at google dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dougkwan at google dot com |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41574
[Bug rtl-optimization/41574] Distribute floating point expressions causes bad code.
--- Comment #8 from dougkwan at google dot com 2009-10-08 22:20 --- This is fixed in trunk but at least gcc-4.4.0, where this bug was found, is still broken. -- dougkwan at google dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Known to fail||4.4.0 Resolution|FIXED | Version|4.5.0 |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41574
[Bug rtl-optimization/41574] New: Distribute floating point expressions causes bad code.
We found this problem on ARM but I believe the problem affect other platforms
as well. In the function distribute_and_simplify() of combine.c, there is not
check for floating point expressions. Sometimes it incorrectly optimizes a
floating point RTL.
-bug.c
static const double one=1.0;
double
f(double x)
{
/* This is incorrectly transformed to x + x*x */
return x*(one+x);
}
-
$ arm-eabi-gcc -O2 -S -march=armv7-a -mfloat-abi=hard -mfpu=neon
-fno-unsafe-math-optimizations -g0 bug.c
$ cat bug.s
.arch armv7-a
.eabi_attribute 27, 3
.eabi_attribute 28, 1
.fpu neon
.eabi_attribute 20, 1
.eabi_attribute 21, 1
.eabi_attribute 23, 3
.eabi_attribute 24, 1
.eabi_attribute 25, 1
.eabi_attribute 26, 1
.eabi_attribute 30, 2
.eabi_attribute 18, 4
.file bug.c
.text
.align 2
.global f
.type f, %function
f:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
fmacd d0, d0, d0
bx lr
.size f, .-f
.ident GCC: (GNU) 4.5.0 20091005 (experimental)
The expression x*(1.0 + x) above is optmized into x + x * x using the fmacd
instruction, which multiplies and accumlates. The following is part combine
pass dump, note how instruction 13 is modified.:
---
;; Function f (f)
starting the processing of deferred insns
ending the processing of deferred insns
df_analyze called
insn_cost 2: 4
insn_cost 6: 4
insn_cost 7: 4
insn_cost 8: 4
insn_cost 13: 4
insn_cost 16: 0
deferring deletion of insn with uid = 2.
modifying insn i2 7 r138:DF=s0:DF+r139:DF
REG_DEAD: r139:DF
deferring rescan insn with uid = 7.
modifying insn i3 8 r137:DF=r138:DF*s0:DF
REG_DEAD: r138:DF
deferring rescan insn with uid = 8.
deferring deletion of insn with uid = 7.
deferring deletion of insn with uid = 6.
modifying insn i3 8 r137:DF=s0:DF*s0:DF+s0:DF
deferring rescan insn with uid = 8.
deferring deletion of insn with uid = 8.
modifying insn i313 s0:DF=s0:DF*s0:DF+s0:DF
deferring rescan insn with uid = 13.
(note 4 0 2 2 [bb 2] NOTE_INSN_BASIC_BLOCK)
(note 2 4 3 2 NOTE_INSN_DELETED)
(note 3 2 6 2 NOTE_INSN_FUNCTION_BEG)
(note 6 3 7 2 NOTE_INSN_DELETED)
(note 7 6 8 2 NOTE_INSN_DELETED)
(note 8 7 13 2 NOTE_INSN_DELETED)
(insn 13 8 16 2 bug.c:8 (set (reg/i:DF 63 s0)
(plus:DF (mult:DF (reg:DF 63 s0 [ x ])
(reg:DF 63 s0 [ x ]))
(reg:DF 63 s0 [ x ]))) 610 {*muldf3adddf_vfp} (nil))
(insn 16 13 0 2 bug.c:8 (use (reg/i:DF 63 s0)) -1 (nil))
starting the processing of deferred insns
deleting insn with uid = 2.
deleting insn with uid = 6.
deleting insn with uid = 7.
deleting insn with uid = 8.
rescanning insn with uid = 13.
deleting insn with uid = 13.
ending the processing of deferred insns
;; Combiner totals: 10 attempts, 10 substitutions (3 requiring new space),
;; 3 successes.
---
The problem happens in this part of distribute_and_simplify_rtx ():
tmp = apply_distributive_law (simplify_gen_binary (inner_code, mode,
new_op0, new_op1));
if (GET_CODE (tmp) != outer_code
rtx_cost (tmp, SET, optimize_this_for_speed_p)
rtx_cost (x, SET, optimize_this_for_speed_p))
return tmp;
It synthesizes a new expression by distributing one of the sub-expressions and
then call apply_distribute_law. In the test-case above, apply_distribute_law
detects a floating point RTL expression and returns immediately but the
simplified expression generated has a lower RTL-cost than the original
expression. Hence distribute_and_simplify_rtx returns the simplified
expression, eventhough it should not unless -funsafe-math-optimizations is
given.
I think the fix is to add this test at the entrance of the function
distribute_and_simplify_rtx
/* Distributivity is not true for floating point as it can change the
value. So we don't do it unless -funsafe-math-optimizations. */
if (FLOAT_MODE_P (GET_MODE (x))
! flag_unsafe_math_optimizations)
return NULL_RTX;
--
Summary: Distribute floating point expressions causes bad code.
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dougkwan at google dot com
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: arm-none-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41574
[Bug rtl-optimization/41574] Distribute floating point expressions causes bad code.
--- Comment #5 from dougkwan at google dot com 2009-10-05 15:44 --- Subject: Re: Distribute floating point expressions causes bad code. I am aware of the fact the stage one has ended but this is a bug fix, not an experimental new feature. Did I break a code freeze? If so, I am sorry and can back out the fix until the tree is reopen. 2009/10/5 ebotcazou at gcc dot gnu dot org gcc-bugzi...@gcc.gnu.org: --- Comment #4 from ebotcazou at gcc dot gnu dot org 2009-10-05 10:00 --- The ChangeLog entry is wrong. And folks from Google shouldn't feel entitled to break a freeze imposed by other folks from Google even if, yes, it is annoyingly long. :-) -- ebotcazou at gcc dot gnu dot org changed: What |Removed |Added CC| |ebotcazou at gcc dot gnu dot | |org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41574 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41574
[Bug rtl-optimization/41574] Distribute floating point expressions causes bad code.
--- Comment #6 from dougkwan at google dot com 2009-10-05 15:48 --- Subject: Re: Distribute floating point expressions causes bad code. Just saw Diego's e-mail about the me breaking the freeze. Sorry I should have checked that before checking thing in. It was just my bad. 2009/10/5 Doug Kwan (Ãö®¶¼w) dougk...@google.com: I am aware of the fact the stage one has ended but this is a bug fix, not an experimental new feature. Did I break a code freeze? If so, I am sorry and can back out the fix until the tree is reopen. 2009/10/5 ebotcazou at gcc dot gnu dot org gcc-bugzi...@gcc.gnu.org: --- Comment #4 from ebotcazou at gcc dot gnu dot org 2009-10-05 10:00 --- The ChangeLog entry is wrong. And folks from Google shouldn't feel entitled to break a freeze imposed by other folks from Google even if, yes, it is annoyingly long. :-) -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41574 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41574
[Bug target/40153] Long long comparison optimized away incorrectly in Thumb code.
--- Comment #6 from dougkwan at google dot com 2009-05-16 17:46 --- Thanks for fixing this. I also submitted a patch yesterday with the same fix and a test case also. The bug is fixed but I think we still want the test case, right? (In reply to comment #4) Subject: Bug 40153 Author: rearnsha Date: Sat May 16 12:53:22 2009 New Revision: 147613 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=147613 Log: PR target/40153 * arm.md (cstoresi_nltu_thumb1): Use a neg of ltu as the pattern name implies. Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40153
[Bug rtl-optimization/40153] Long long comparison optimized away incorrectly in Thumb code.
--- Comment #1 from dougkwan at google dot com 2009-05-15 07:08 --- This is caused by a typo in arm.md. (define_insn cstoresi_nltu_thumb1 [(set (match_operand:SI 0 s_register_operand =l,l) (neg:SI (gtu:SI (match_operand:SI 1 s_register_operand l,*h) (match_operand:SI 2 thumb1_cmp_operand lI*h,*r] TARGET_THUMB1 cmp\\t%1, %2\;sbc\\t%0, %0, %0 [(set_attr length 4)] ) The instruction cstoresi_nltu_thumb1 is used to compute the expression -(x y) where x and y are unsigned SI-type values. The operand of the NEG RTX should be a LTU RTX instead of a GTU RTX. The incorrected RTX code caused a later CSE pass to substitute this pattern: (set x (neg (gtu a b))) === cstoresi_nltu_thumb1 (set y (neg x)) with (set y (gtu a b)) I tried fixing the RTX code and the test case passed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40153
[Bug target/40153] Long long comparison optimized away incorrectly in Thumb code.
--- Comment #3 from dougkwan at google dot com 2009-05-15 08:28 --- Subject: Re: Long long comparison optimized away incorrectly in Thumb code. I am running regression tests and will submit a patch tomorrow morning after that. -Doug 2009/5/15 ramana at gcc dot gnu dot org gcc-bugzi...@gcc.gnu.org: --- Comment #2 from ramana at gcc dot gnu dot org 2009-05-15 08:26 --- (In reply to comment #1) This is caused by a typo in arm.md. (define_insn cstoresi_nltu_thumb1 [(set (match_operand:SI 0 s_register_operand =l,l) (neg:SI (gtu:SI (match_operand:SI 1 s_register_operand l,*h) (match_operand:SI 2 thumb1_cmp_operand lI*h,*r] TARGET_THUMB1 cmp\\t%1, %2\;sbc\\t%0, %0, %0 [(set_attr length 4)] ) The instruction cstoresi_nltu_thumb1 is used to compute the expression -(x y) where x and y are unsigned SI-type values. The operand of the NEG RTX should be a LTU RTX instead of a GTU RTX. The incorrected RTX code caused a later CSE pass to substitute this pattern: (set x (neg (gtu a b))) === cstoresi_nltu_thumb1 (set y (neg x)) with (set y (gtu a b)) I tried fixing the RTX code and the test case passed. This looks correct. Please submit a patch to gcc-patc...@. -- ramana 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-05-15 08:26:09 date| | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40153 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40153
[Bug rtl-optimization/40153] New: Long long comparison optimized away incorrectly in Thumb code.
Several versions of gcc (trunk, 4.4.0, 4.3.1 and 4.3.3) mis-compiled this test
case.
bug.c
/* compile with -Os -mthumb */
extern void abort (void);
static int llcmp(long long a, long long b);
struct info {
long unsigned ll;
};
int __attribute__((noinline))
cmp(const void *a, const void *b)
{
struct info *pa = *((struct info **)a);
struct info *pb = *((struct info **)b);
return llcmp(pa-ll, pb-ll);
}
static int
llcmp(long long a, long long b)
{
if (a b)
return -1;
if (a b)
return 1;
return 0;
}
int
main ()
{
struct info pa, pb;
struct info *unsorted[2];
unsorted[0] = pa;
unsorted[1] = pb;
pa.ll = 1;
pb.ll = 2;
if (cmp (unsorted[0], unsorted[1]) != -1)
abort();
pa.ll = 2;
pb.ll = 1;
if (cmp (unsorted[0], unsorted[1]) != 1)
abort();
pa.ll = 1;
pb.ll = 1;
if (cmp (unsorted[0], unsorted[1]) != 0)
abort();
return 0;
}
--
sh-3.2$ arm-unknown-linux-gnueabi-gcc -Os -mthumb bug.c
sh-3.2$ /disk2/dougkwan/qemu/install/bin/qemu-arm -L
~/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/sys-root a.out
qemu: uncaught target signal 6 (Aborted) - exiting
sh-3.2$ arm-unknown-linux-gnueabi-gcc -mthumb bug.csh-3.2$
/disk2/dougkwan/qemu/install/bin/qemu-arm -L
~/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/sys-root a.out
sh-3.2$
Below is code generate for the function cmp:
.align 1
.global cmp
.code 16
.thumb_func
.type cmp, %function
cmp:
push{lr}
ldr r3, [r0]
ldr r2, [r1]
ldr r3, [r3]
ldr r2, [r2]
cmp r2, r3
bhi .L6
mov r0, #0
b .L2
.L6:
mov r0, #1
neg r0, r0
.L2:
@ sp needed for prologue
pop {pc}
.size cmp, .-cmp
.align 1
Note that the compiled function only returns 0 and 1 where as the same function
in the source code return values -1, 0 and 1.
--
Summary: Long long comparison optimized away incorrectly in Thumb
code.
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dougkwan at google dot com
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: arm-unknown-linux-gnueabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40153
[Bug tree-optimization/39604] [4.3/4.4/4.5 Regression] tree-ssa-sink breaks stack layout
--- Comment #12 from dougkwan at google dot com 2009-05-10 00:56 --- Created an attachment (id=17840) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17840action=view) C test-case for the same problem on x86_64 and i386. The original C++ test-case does not crash on x86_64 and i386. I compared the generated code and found that ARM EABI requires constructors to return values. That is not common and certainly is not the case on x86_64 and i386. So gcc generates very different code on both targert very early on. The C test-case was created based on the lowered C++ code in the middle-end. It crashes with just -O2 on x86_64 with both 4.3.1 and 4.4.0; it crashes on i386 similarly with 4.3.1. I did not test 4.4.0 on i386. Unfortunately this does not crash on ARM. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39604
[Bug tree-optimization/39604] [4.3/4.4/4.5 Regression] tree-ssa-sink breaks stack layout
--- Comment #11 from dougkwan at google dot com 2009-05-09 01:21 --- We saw this also in gcc-4.3.1 on target arm-none-eabi. -- dougkwan at google dot com changed: What|Removed |Added CC||dougkwan at google dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39604
[Bug middle-end/39378] Multiple inheritence thunk not working with -mthumb
--- Comment #3 from dougkwan at google dot com 2009-03-17 20:20 --- Patch checked into trunk. -- dougkwan at google dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39378
[Bug middle-end/39378] New: Multiple inheritence thunk not working with -mthumb
This simple test case crashed in sim when compiler by arm-eabi-gcc for thumb.
---
class B1
{
public:
virtual void foo1(void) {}
int b1;
};
class B2
{
public:
virtual void foo2 (void) {}
};
class D : public B1, public B2
{
void foo1(void) {}
void foo2(void) {}
};
void __attribute__((noinline))
test(B2* bp)
{
bp-foo2();
}
int
main()
{
D d;
test (d);
return 0;
}
---
$ arm-eabi-g++ -mthumb -mthumb-interwork bug.cc
$ arm-eabi-gdb a.out
GNU gdb 6.7.1
Copyright (C) 2007 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type show copying
and show warranty for details.
This GDB was configured as --host=i686-unknown-linux-gnu --target=arm-eabi...
(gdb) target sim
Connected to the simulator.
(gdb) load a.out
Loading section .init, size 0xc vma 0x8000
Loading section .text, size 0x32b8 vma 0x800c
Loading section .fini, size 0xc vma 0xb2c4
Loading section .rodata, size 0x208 vma 0xb2d0
Loading section .ARM.extab, size 0x90 vma 0xb4d8
Loading section .ARM.exidx, size 0x248 vma 0xb568
Loading section .eh_frame, size 0x4 vma 0xb7b0
Loading section .init_array, size 0x4 vma 0x137b4
Loading section .fini_array, size 0x4 vma 0x137b8
Loading section .jcr, size 0x4 vma 0x137bc
Loading section .data, size 0x930 vma 0x137c0
Start address 0x806c
Transfer rate: 132992 bits in 1 sec.
(gdb) run
Starting program: /usr/local/google/data/dougkwan/arm-elf/test/a.out
Unhandled v6 thumb insn: e92d
sim: exception: Unhandled Instruction '0xe92d4080' at 0x81d0. Stopping.
Program received signal 0, Signal 0.
0x0b90 in ?? ()
(gdb) quit
The program is running. Exit anyway? (y or n) y
$ arm-eabi-g++ -v
Using built-in specs.
Target: arm-eabi
Configured with: /data/dougkwan/arm-elf/src/gcc-trunk/configure
--prefix=/data/dougkwan/arm-elf/install --target=arm-eabi
--build=i686-unknown-linux-gnu --host=i686-unknown-linux-gnu
--with-gmp=/home/dougkwan/gcc-lib/install
--with-mpfr=/home/dougkwan/gcc-lib/install --with-arch=armv5te
--enable-interwork --enable-multilib --with-newlib --with-gnu-as --with-gnu-ld
--enable-languages=c,c++
Thread model: single
gcc version 4.4.0 20090305 (experimental) (GCC)
This works fine in 4.2.x. The problem is that crtl-is_thunk is set during
thunk emission but is not not reset after. So target function of a thunk is
also emitted with crtl-is_thunk set. That cause the function to be emitted in
ARM mode. Below is part of the assembly output of the test above.
.section.text._ZN1D4foo2Ev,axG,%progbits,_ZN1D4foo2Ev,comdat
.align 2
.weak _ZThn8_N1D4foo2Ev
.code 32
.type _ZThn8_N1D4foo2Ev, %function
_ZThn8_N1D4foo2Ev:
.fnstart
ldr r12, .LTHUMBFUNC0
sub r0, r0, #8
bx r12
.align 2
.LTHUMBFUNC0:
.word .LTHUNK0
.fnend
.size _ZThn8_N1D4foo2Ev, .-_ZThn8_N1D4foo2Ev
.align 2
.weak _ZN1D4foo2Ev
.code 32
.type _ZN1D4foo2Ev, %function
_ZN1D4foo2Ev:
.fnstart
.LFB3:
.save {r7, lr}
push{r7, lr}
.LCFI9:
sub sp, sp, #8
.LCFI10:
add r7, sp, #0
.LCFI11:
str r0, [r7, #4]
mov sp, r7
add sp, sp, #8
@ sp needed for prologue
pop {r7, pc}
.LFE3:
.cantunwind
.fnend
.size _ZN1D4foo2Ev, .-_ZN1D4foo2Ev
Note that the function _ZN1D4foo2Ev (unmangled as D::foo2()) is emitted in ARM
mode. However, in the typeinfo for B1, the function is marked as a THUMB
function.
_ZTI2B1:
.word _ZTVN10__cxxabiv117__class_type_infoE+8
.word _ZTS2B1
.thumb_set .LTHUNK0,_ZN1D4foo2Ev
I believe this problem can be fixed by saving and restoring crtl-is_thunk
around the call to the lang-hook callgraph.emit_associated_thunks in
cgraphunit.c
--
Summary: Multiple inheritence thunk not working with -mthumb
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dougkwan at google dot com
GCC build triplet: i686-unknown-linux-gnu
GCC host triplet: i686-unknown-linux-gnu
GCC target triplet: arm-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39378
[Bug target/35965] -fstack-protector produces segfaulting binaries on arm/armel
--- Comment #7 from dougkwan at google dot com 2009-02-25 07:26 --- This is fixed in trunk and will be picked up by 4.4. However, this is broken at least in 4.3.1 and probably in all 4.3 releases. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35965
[Bug target/36480] stack-protector causes bad ARM PIC code generated
--- Comment #2 from dougkwan at google dot com 2009-02-12 09:15 --- *** This bug has been marked as a duplicate of 35965 *** -- dougkwan at google dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36480
[Bug target/35965] -fstack-protector produces segfaulting binaries on arm/armel
--- Comment #5 from dougkwan at google dot com 2009-02-12 09:15 --- *** Bug 36480 has been marked as a duplicate of this bug. *** -- dougkwan at google dot com changed: What|Removed |Added CC||dougkwan at google dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35965
[Bug target/36480] stack-protector causes bad ARM PIC code generated
--- Comment #1 from dougkwan at google dot com 2009-02-12 03:04 ---
I have a test case now. The toolchain is built with gcc trunk, binutils-2.18,
gdb-6.71 and newlib-1.16.0 for target arm-eabi
---
#include stdlib.h
extern int sprintf (char *, const char*, ...);
int
main (void)
{
char buf[10];
sprintf(buf, );
return 0;
}
#
# Test case exits with an error code if compiled with -fstack-protector -fpic
#
sh-3.1$ arm-eabi-gcc -fstack-protector -fpic bug.csh-3.1$ arm-eabi-gdb a.out
GNU gdb 6.7.1
Copyright (C) 2007 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type show copying
and show warranty for details.
This GDB was configured as --host=i686-unknown-linux-gnu --target=arm-eabi...
(gdb) target sim
Connected to the simulator.
(gdb) load a.out
Loading section .init, size 0x18 vma 0x8000
Loading section .text, size 0x2af8 vma 0x8018
Loading section .fini, size 0x18 vma 0xab10
Loading section .rodata, size 0xd4 vma 0xab28
Loading section .ARM.exidx, size 0x8 vma 0xabfc
Loading section .eh_frame, size 0x4 vma 0xac04
Loading section .init_array, size 0x8 vma 0x12c08
Loading section .fini_array, size 0x4 vma 0x12c10
Loading section .jcr, size 0x4 vma 0x12c14
Loading section .got, size 0x10 vma 0x12c18
Loading section .data, size 0x930 vma 0x12c28
Start address 0x80ac
Transfer rate: 109248 bits in 1 sec.
(gdb) run
Starting program: /usr/local/google/data/dougkwan/arm-elf/test/a.out
Program exited with code 0377.
(gdb) quit
#
# It exits normally with -fstack-protector only
#
sh-3.1$ arm-eabi-gcc -fstack-protector bug.c
sh-3.1$ arm-eabi-gdb a.out
GNU gdb 6.7.1
Copyright (C) 2007 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type show copying
and show warranty for details.
This GDB was configured as --host=i686-unknown-linux-gnu --target=arm-eabi...
(gdb) target sim
Connected to the simulator.
(gdb) load a.out
Loading section .init, size 0x18 vma 0x8000
Loading section .text, size 0x2adc vma 0x8018
Loading section .fini, size 0x18 vma 0xaaf4
Loading section .rodata, size 0xd4 vma 0xab0c
Loading section .ARM.exidx, size 0x8 vma 0xabe0
Loading section .eh_frame, size 0x4 vma 0xabe8
Loading section .init_array, size 0x8 vma 0x12bec
Loading section .fini_array, size 0x4 vma 0x12bf4
Loading section .jcr, size 0x4 vma 0x12bf8
Loading section .data, size 0x930 vma 0x12c00
Start address 0x80ac
Transfer rate: 108896 bits in 1 sec.
(gdb) run
Starting program: /usr/local/google/data/dougkwan/arm-elf/test/a.out
Program exited normally.
(gdb) quit
#
# It also exits normally if -O2 is given in addition to -fstack-protector
-fpic
#
sh-3.1$ arm-eabi-gcc -fstack-protector -fpic -O2 bug.c
sh-3.1$ arm-eabi-gdb a.out
GNU gdb 6.7.1
Copyright (C) 2007 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type show copying
and show warranty for details.
This GDB was configured as --host=i686-unknown-linux-gnu --target=arm-eabi...
(gdb) target sim
Connected to the simulator.
(gdb) load a.out
Loading section .init, size 0x18 vma 0x8000
Loading section .text, size 0x2ae0 vma 0x8018
Loading section .fini, size 0x18 vma 0xaaf8
Loading section .rodata, size 0xd4 vma 0xab10
Loading section .ARM.exidx, size 0x8 vma 0xabe4
Loading section .eh_frame, size 0x4 vma 0xabec
Loading section .init_array, size 0x8 vma 0x12bf0
Loading section .fini_array, size 0x4 vma 0x12bf8
Loading section .jcr, size 0x4 vma 0x12bfc
Loading section .got, size 0x10 vma 0x12c00
Loading section .data, size 0x930 vma 0x12c10
Start address 0x80ac
Transfer rate: 109056 bits in 1 sec.
(gdb) run
Starting program: /usr/local/google/data/dougkwan/arm-elf/test/a.out
Program exited normally.
(gdb) quit
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36480
[Bug target/36480] New: stack-protector causes bad ARM PIC code generated
The ARM back-end avoids marking a function as needing PIC in
require_pic_register(). The code there checks if the current IR-type is
IR_GIMPLE or not. The logic does not work when both -fPIC and
-fstack-protector are given. The stack protector prologue is generated very
early in RTL expansion when the IR-type is still IR_GIMPLE. Hence, the current
code ends up using a PIC regiser never gets initialized properly.
---
extern int sprintf (char *, const char*, ...);
void
test (void)
{
char buf[10];
sprintf(buf, );
}
---
compiled using top-of-trunk on 6/9/2008
../install/bin/arm-elf-gcc -O2 -S -fdump-rtl-expand -fpic -fstack-protector
bug.c
Note that vreg 133 is used in insn 4 but never assigned a value.
;;
;; Full RTL generated for this function:
;;
(note 1 0 7 NOTE_INSN_DELETED)
(note 7 1 10 2 [bb 2] NOTE_INSN_BASIC_BLOCK)
(insn 10 7 11 2 bug.c:7 (set (reg:SI 139)
(unspec:SI [
(const:SI (minus:SI (const (symbol_ref:SI
(_GLOBAL_OFFSET_TABLE_)))
(const:SI (plus:SI (unspec:SI [
(const_int 0 [0x0])
] 21)
(const_int 8 [0x8])
] 3)) -1 (nil))
(insn 11 10 12 2 bug.c:7 (set (reg:SI 139)
(unspec:SI [
(plus:SI (reg:SI 139)
(const (plus:SI (pc)
(const_int 8 [0x8]
(const_int 0 [0x0])
] 4)) -1 (nil))
(insn 12 11 2 2 bug.c:7 (use (reg:SI 139)) -1 (nil))
(note 2 12 3 2 NOTE_INSN_FUNCTION_BEG)
(insn 3 2 4 2 bug.c:5 (set (reg:SI 135)
(unspec:SI [
(symbol_ref:SI (__stack_chk_guard) [flags 0x40] var_decl
0xf7ec6f78 __stack_chk_guard)
] 3)) -1 (nil))
(insn 4 3 5 2 bug.c:5 (set (reg/f:SI 134)
(mem/u/c:SI (plus:SI (reg:SI 133)
(reg:SI 135)) [0 S4 A32])) -1 (expr_list:REG_EQUAL
(symbol_ref:SI (__stack_chk_guard) [flags 0x40] var_decl 0xf7ec6f78
__stack_chk_guard)
(nil)))
--
Summary: stack-protector causes bad ARM PIC code generated
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dougkwan at google dot com
GCC build triplet: i686-unknown-linux-gnu
GCC host triplet: i686-unknown-linux-gnu
GCC target triplet: arm-unknown-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36480
[Bug c/34966] New: ICE: verify_ssa fails when optimization trigonometric code
I got an internal compiler error when compiling the following. The function
my_atan is actaully derived from aton expanded from a C libray header. Other
then its name, it is almost identical to atan().
[EMAIL PROTECTED]:~/delta-2006.08.03/verify_ssa$ ./gcc -O2 PJ_geos.4.c
PJ_geos.4.c: In function 'e_forward':
PJ_geos.4.c:22: error: definition in block 2 follows the use
for SSA_NAME: result_9 in statement:
sincostmp.17_15 = __builtin_cexpi (result_9);
PJ_geos.4.c:22: internal compiler error: verify_ssa failed
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
extern double hypot (double, double);
extern double cos (double);
extern double sin (double);
double
my_atan (double x)
{
register double result;
asm volatile (fld1; fpatan
: =t (result)
: 0 (x)
: st(1));
return result;
}
typedef struct {
double phi;
} LP;
void
e_forward(LP lp, double x)
{
lp.phi = my_atan (x);
x = hypot(cos (lp.phi), sin (lp.phi));
}
-
--
Summary: ICE: verify_ssa fails when optimization trigonometric
code
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dougkwan at google dot com
GCC build triplet: i686-unknown-linux-gnu
GCC host triplet: i686-unknown-linux-gnu
GCC target triplet: i686-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34966
[Bug c/34968] New: ICE: verify_ssa fails when optimization trigonometric code
I got an internal compiler error when compiling the following. The function
my_atan is actaully derived from aton expanded from a C libray header. Other
then its name, it is almost identical to atan().
[EMAIL PROTECTED]:~/delta-2006.08.03/verify_ssa$ ./gcc -O2 PJ_geos.4.c
PJ_geos.4.c: In function 'e_forward':
PJ_geos.4.c:22: error: definition in block 2 follows the use
for SSA_NAME: result_9 in statement:
sincostmp.17_15 = __builtin_cexpi (result_9);
PJ_geos.4.c:22: internal compiler error: verify_ssa failed
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
extern double hypot (double, double);
extern double cos (double);
extern double sin (double);
double
my_atan (double x)
{
register double result;
asm volatile (fld1; fpatan
: =t (result)
: 0 (x)
: st(1));
return result;
}
typedef struct {
double phi;
} LP;
void
e_forward(LP lp, double x)
{
lp.phi = my_atan (x);
x = hypot(cos (lp.phi), sin (lp.phi));
}
-
--
Summary: ICE: verify_ssa fails when optimization trigonometric
code
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dougkwan at google dot com
GCC build triplet: i686-unknown-linux-gnu
GCC host triplet: i686-unknown-linux-gnu
GCC target triplet: i686-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34968
[Bug c/34968] ICE: verify_ssa fails when optimization trigonometric code
--- Comment #1 from dougkwan at google dot com 2008-01-25 04:03 ---
Another test case:
extern __inline double atan (double __x)
{
register double __result;
__asm __volatile__ (fld1; fpatan : =t (__result) : 0 (__x) : st(1));
return __result;
}
f(double *p)
{
double theta;
double cos_theta, sin_theta;
theta = atan(*p);
sin_theta = sin(theta);
cos_theta = cos(theta);
*p = atan(sin_theta * cos_theta);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34968
[Bug tree-optimization/34966] [4.3 Regression] ICE: verify_ssa fails when optimization trigonometric code
--- Comment #2 from dougkwan at google dot com 2008-01-25 07:49 ---
(In reply to comment #0)
A slightly simpler test case:
--
extern double sin (double), cos (double);
__inline double
atan (double __x)
{
register double __result;
__asm __volatile__ (fld1; fpatan : =t (__result) : 0 (__x) : st(1));
return __result;
}
double
f(double x)
{
double t = atan (x);
return cos (t) + sin (t);
}
-
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34966
[Bug c++/34846] New: ICE on STL container iterator copy
My copy of top of trunk, which was updated today, ICEd with this piece of code:
--
#include vector // fails with vector and set
void
test()
{
typedef int a;// must be locally defined
std::vectora*::iterator x; // element must be pointer to
// aliased type
std::vectora*::iterator y=x;
}
--
--
Summary: ICE on STL container iterator copy
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dougkwan at google dot com
GCC build triplet: i686-unknown-linux-gnu
GCC host triplet: i686-unknown-linux-gnu
GCC target triplet: i686-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34846
[Bug c++/33960] [4.3 Regression] r129030 breaks -fopenmp -static compile of tramp3d-v4
--- Comment #6 from dougkwan at google dot com 2007-11-02 02:02 --- Richard, I think I know what happened. Could you please do an nm a.out|grep pthread_ or your executable and send that to me? It seems that we need to change glibc unfortunately. Here is code at the end of libc/nptl/pthread_create.c: /* If pthread_create is present, libgcc_eh.a and libsupc++.a expects some other POSIX thread functions to be present as well. */ PTHREAD_STATIC_FN_REQUIRE (pthread_mutex_lock) PTHREAD_STATIC_FN_REQUIRE (pthread_mutex_unlock) PTHREAD_STATIC_FN_REQUIRE (pthread_once) PTHREAD_STATIC_FN_REQUIRE (pthread_cancel) PTHREAD_STATIC_FN_REQUIRE (pthread_key_create) PTHREAD_STATIC_FN_REQUIRE (pthread_setspecific) PTHREAD_STATIC_FN_REQUIRE (pthread_getspecific) When the linker sees pthread_create, it will also bring in pthread_mutex_lock and pthread_mutex_unlock automatically but not pthread_cond_broadcast and pthread_cond_wait. Those two symbols are defined as weak references so they will remain NULL. Apparently the fix is to add dependency of pthread_cond_broadcast and pthread_cond_wait into glibc. A band-aid is removing the #define __GTHREAD_HAS_COND in gthr-posix*.h to diasable the new code temporarily and util glibc is fixed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33960
[Bug c++/33960] [4.3 Regression] r129030 breaks -fopenmp -static compile of tramp3d-v4
--- Comment #5 from dougkwan at google dot com 2007-10-31 18:00 --- Subject: Re: New: [4.3 Regression] r129030 breaks -fopenmp -static compile of tramp3d-v4 I'm looking at that. -Doug 31 Oct 2007 14:52:04 -, rguenth at gcc dot gnu dot org [EMAIL PROTECTED]: Starting with r129030 tramp3d-v4 segfaults on startup if compiled statically with -fopenmp. This can be reproduced with the preprocessed testcase from http://www.suse.de/~rguenther/tramp3d/tramp3d-v4.ii.gz (x86_64) and compiling with -fopenmp -static (optimization does not change the effect). Author: jason Date: Fri Oct 5 05:35:46 2007 New Revision: 129030 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=129030 Log: 2007-09-13 Doug Kwan [EMAIL PROTECTED] * gcc/gthr-posix.h (__gthread_cond_broadcast, __gthread_cond_wait, __gthread_cond_wait_recursive): Add to extend interface for POSIX conditional variables. (__GTHREAD_HAS_COND): Macro defined to signify support of conditional variables. * gcc/gthr-posix95.h (__gthread_cond_broadcast, __gthread_cond_wait, __gthread_cond_wait_recursive): Add to extend interface for POSIX conditional variables. (__GTHREAD_HAS_COND): Macro defined to signify support of conditional variables. * gcc/gthr-single.h (__gthread_cond_broadcast, __gthread_cond_wait, __gthread_cond_wait_recursive): Add to extend interface for POSIX conditional variables. * gcc/gthr.h: Update comments to document new interface. * libstdc++-v3/include/ext/concurrent.h (class __mutex, class __recursive_mutex): Add new method gthread_mutex to access inner gthread mutex. [__GTHREAD_HAS_COND] (class __concurrence_broadcast_error, class __concurrence_wait_error, class __cond): Add. * guard.cc (recursive_push, recursive_pop): Delete. (init_in_progress_flag, set_init_in_progress_flag): Add to replace recursive_push and recursive_pop. (throw_recursive_init_exception): Add. (acquire, __cxa_guard_acquire, __cxa_guard_abort and __cxa_guard_release): [__GTHREAD_HAS_COND] Use a conditional for synchronization of static variable initialization. The global mutex is only held briefly when guards are accessed. [!__GTHREAD_HAS_COND] Fall back to the old code, which deadlocks. * testsuite/thread/guard.cc: Add new test. It deadlocks with the old locking code in libstdc++-v3/libsup++/guard.cc. -- Summary: [4.3 Regression] r129030 breaks -fopenmp -static compile of tramp3d-v4 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: c++ 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=33960 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33960
[Bug libstdc++/33700] FAIL: 17_intro/headers/all_pedantic_errors.cc (test for excess errors)
--- Comment #3 from dougkwan at google dot com 2007-10-08 19:50 --- Subject: Re: FAIL: 17_intro/headers/all_pedantic_errors.cc (test for excess errors) That's strange. I am looking at it. I ran the libstdc++ testsuite before and did not see this problem. -Doug 8 Oct 2007 19:32:42 -, dave at hiauly1 dot hia dot nrc dot ca [EMAIL PROTECTED]: --- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2007-10-08 19:32 --- Subject: Re: FAIL: 17_intro/headers/all_pedantic_errors.cc (test for excess errors) --- Comment #1 from pcarlini at suse dot de 2007-10-08 18:57 --- So the problem is new, right? Has it to do with the recent fixes for the deadlock bug? Looking at the testresults, it appears to have been introduced between 128587 and 128594 in September. The only patch of significance in this period is Jason's 128590. It's not obvious to me why this would have affected the behavior of -pedantic. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33700 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33700
[Bug libstdc++/33700] FAIL: 17_intro/headers/all_pedantic_errors.cc (test for excess errors)
--- Comment #5 from dougkwan at google dot com 2007-10-08 22:35 --- Subject: Re: FAIL: 17_intro/headers/all_pedantic_errors.cc (test for excess errors) I only tested in Linux. -Doug 8 Oct 2007 20:10:51 -, dave at hiauly1 dot hia dot nrc dot ca [EMAIL PROTECTED]: --- Comment #4 from dave at hiauly1 dot hia dot nrc dot ca 2007-10-08 20:10 --- Subject: Re: FAIL: 17_intro/headers/all_pedantic_errors.cc (test for excess errors) That's strange. I am looking at it. I ran the libstdc++ testsuite before and did not see this problem. This is specific to LP64 hpux. Did you test with 11.21 or 11.31? Possibly, sys/pthread.h has been updated. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33700 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33700
[Bug middle-end/29749] [4.0/4.1/4.2/4.3 regression] Missing byte swap optimizations
--- Comment #9 from dougkwan at google dot com 2007-08-23 16:32 --- Subject: Re: [4.0/4.1/4.2/4.3 regression] Missing byte swap optimizations No, FALSE, `(), nil, #f, 0 :) -Doug 23 Aug 2007 14:28:51 -, ubizjak at gmail dot com [EMAIL PROTECTED]: --- Comment #8 from ubizjak at gmail dot com 2007-08-23 14:28 --- (In reply to comment #7) Created an attachment (id=13911) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13911action=view) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13911action=view) [edit] Updated patch with test case a bug fix. I've added a test case of the changes. It did find a bug in the patch and I've fixed that. I did a full bootstap and C/C++/ObjC dejagnu with top of 4.2-branch as of 20070713 and had no problem. Any news with this patch? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29749 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29749
[Bug debug/31899] [4.2/4.3 regression] -g and using declaration causing ICE in reference_to_unused
--- Comment #5 from dougkwan at google dot com 2007-07-27 20:54 --- Created an attachment (id=13989) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13989action=view) Proposed fix for SEGV problem in dwarf2out.c in bug 31899 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31899
[Bug middle-end/29749] [4.0/4.1/4.2/4.3 regression] Missing byte swap optimizations
--- Comment #7 from dougkwan at google dot com 2007-07-13 22:46 --- Created an attachment (id=13911) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13911action=view) Updated patch with test case a bug fix. I've added a test case of the changes. It did find a bug in the patch and I've fixed that. I did a full bootstap and C/C++/ObjC dejagnu with top of 4.2-branch as of 20070713 and had no problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29749
[Bug middle-end/29749] [4.0/4.1/4.2/4.3 regression] Missing byte swap optimizations
--- Comment #6 from dougkwan at google dot com 2007-07-12 06:17 --- Subject: Re: [4.0/4.1/4.2/4.3 regression] Missing byte swap optimizations I misread one of the earlier comments when I typed the reply. So I thought it was reported on the m68k first. I agree that adding test cases is a good idea, I will update re-submit a new patch, this week. -Doug 12 Jul 2007 06:08:50 -, ubizjak at gmail dot com [EMAIL PROTECTED]: --- Comment #5 from ubizjak at gmail dot com 2007-07-12 06:08 --- (In reply to comment #4) bootstrap to be done). The problem was reported on m68k initially but I checked FWIW, the problem was reported on i686-pc-linux-gnu, but it is generic RTL missed-optimization problem. BTW: It would be nice if a testcase (or two) were added to the patch. The added functionality of the patch is complex enough that we should check it... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29749 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29749
[Bug middle-end/29749] [4.0/4.1/4.2/4.3 regression] Missing byte swap optimizations
--- Comment #4 from dougkwan at google dot com 2007-07-11 23:15 --- Created an attachment (id=13891) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13891action=view) Patch for fixing byte swap optimization. I have tested this patch on i486-linux-gnu (C/C++ test suite only, full bootstrap to be done). The problem was reported on m68k initially but I checked that it also appeared on i486. The patched have been tested to work on i486-linux-gnu and powerpc64-unknown-linux-gnu. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29749
[Bug middle-end/29749] [4.0/4.1/4.2/4.3 regression] Missing byte swap optimizations
--- Comment #3 from dougkwan at google dot com 2007-07-10 22:18 --- I'm working on a patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29749
[Bug middle-end/32327] [4.2 Regression] Incorrect stack sharing causing removal of live code
--- Comment #20 from dougkwan at google dot com 2007-06-14 18:05 --- Subject: Re: [4.2 Regression] Incorrect stack sharing causing removal of live code That was my initial opinion too but Diego and Danny told me there is only one scope in the tree SSA form. So it is okay. About your comment of us being lucky, I believe our luck is running out. As we do more and more things in the tree passes, we will be likely to see this problem more often. 14 Jun 2007 17:58:01 -, ian at airs dot com [EMAIL PROTECTED]: --- Comment #19 from ian at airs dot com 2007-06-14 17:57 --- I don't agree with comment #17 from Doug. In the code in comment #16, if f saves c, there is no way that it could validly use it after the block scope exits. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32327
[Bug middle-end/32327] Incorrect stack sharing causing removal of live code
--- Comment #2 from dougkwan at google dot com 2007-06-13 21:25 --- The address of dest has been passed to memcpy() and the alias analysis considers the varaible to escape. So potentially foo() can see the value of dest if memcpy() stash the pointer somewhere. This is impossible but the compiler cannot prove this so it has to be conservative and treat foo() as a potential reader of dest. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32327
[Bug middle-end/32327] [4.2 Regression] Incorrect stack sharing causing removal of live code
--- Comment #6 from dougkwan at google dot com 2007-06-13 21:50 --- Subject: Re: [4.2 Regression] Incorrect stack sharing causing removal of live code Fixing alias analysis in 4.2.0 will make this problem go away but it does not change the underlying issue in the stack local sharing code. 13 Jun 2007 21:42:01 -, pinskia at gcc dot gnu dot org [EMAIL PROTECTED]: --- Comment #5 from pinskia at gcc dot gnu dot org 2007-06-13 21:42 --- (In reply to comment #2) The address of dest has been passed to memcpy() and the alias analysis considers the varaible to escape. So potentially foo() can see the value of dest if memcpy() stash the pointer somewhere. This is impossible but the compiler cannot prove this so it has to be conservative and treat foo() as a potential reader of dest. We remove the call to memcpy (in 4.2) in .064t.fab and then alias5 should have changed it (dest) to be non ADDRESSABLE but it is not for some reason. I think may_alias is messed up in 4.2.0. Also sink maybe should not be sinking stores. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Known to work|4.3.0 |4.3.0 4.1.1 Summary|Incorrect stack sharing |[4.2 Regression] Incorrect |causing removal of live code|stack sharing causing ||removal of live code Target Milestone|--- |4.2.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32327 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32327
[Bug middle-end/32327] [4.2 Regression] Incorrect stack sharing causing removal of live code
--- Comment #8 from dougkwan at google dot com 2007-06-14 00:14 --- Subject: Re: [4.2 Regression] Incorrect stack sharing causing removal of live code I thought like you do initially. But then I was told that in gimple everything is promoted to function scope. So dest is not out of scope. -Doug 13 Jun 2007 21:53:15 -, pinskia at gcc dot gnu dot org [EMAIL PROTECTED]: --- Comment #7 from pinskia at gcc dot gnu dot org 2007-06-13 21:53 --- Is that really true? The underlying issue is sinking the store is causing the variables to in the same scope. I think that is the real underlying issue and nothing to do with local stack sharing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32327 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32327
[Bug middle-end/32327] [4.2 Regression] Incorrect stack sharing causing removal of live code
--- Comment #10 from dougkwan at google dot com 2007-06-14 00:35 --- Subject: Re: [4.2 Regression] Incorrect stack sharing causing removal of live code Talked to Dan Berlin and Diego Novillo here at Google. They told me that all locals are promoted to function scope. In generally, the tree passes can do abitrary transformation like hoisting or loop invariant motion that can move a variable out of its original block scope. If we keep the scopes around. There must be code to fix up all block scoping information before the tree passes end. It may be just a matter to find why the scope of dest is not fixed up properly. 14 Jun 2007 00:28:27 -, pinskia at gcc dot gnu dot org [EMAIL PROTECTED]: Who said that? We keep around the scopes, how else do we get stack sharing in the first place? Also you cannot turn off stack sharing because that would cause some programs no longer to be useful (LLVM is one, the stack would just blow up). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32327
[Bug middle-end/32327] [4.2 Regression] Incorrect stack sharing causing removal of live code
--- Comment #13 from dougkwan at google dot com 2007-06-14 00:46 --- Subject: Re: [4.2 Regression] Incorrect stack sharing causing removal of live code Yes, I saw the code there yesterday and I was wondering if the block scope got fixed up somehow. 14 Jun 2007 00:42:23 -, pinskia at gcc dot gnu dot org [EMAIL PROTECTED]: --- Comment #11 from pinskia at gcc dot gnu dot org 2007-06-14 00:42 --- Look at the code in cfgexpand.c, expand_used_vars, this looks at the source blocks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32327
[Bug middle-end/32327] [4.2 Regression] Incorrect stack sharing causing removal of live code
--- Comment #15 from dougkwan at google dot com 2007-06-14 00:59 --- Subject: Re: [4.2 Regression] Incorrect stack sharing causing removal of live code Then the stack local sharing code is very broken. It should do a real live-range analysis instead of using block scoping information form the source tree. -Doug 14 Jun 2007 00:52:45 -, pinskia at gmail dot com [EMAIL PROTECTED]: It can't because the debugging information will be messed up. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32327
[Bug middle-end/32327] [4.2 Regression] Incorrect stack sharing causing removal of live code
--- Comment #17 from dougkwan at google dot com 2007-06-14 01:09 ---
Subject: Re: [4.2 Regression] Incorrect stack sharing causing removal of live
code
Unless the compiler can prove that f() does not save the pointer to c
and use it later, it cannot share a stack slot for c c1. This is
true regardless of any block scoping in the source. Yeah, it looks
like accessing c outside of the first block was undefined but I was
told me that GIMPLE promote c c1 all the function scope.
-Doug
14 Jun 2007 01:02:48 -, pinskia at gcc dot gnu dot org
[EMAIL PROTECTED]:
--- Comment #16 from pinskia at gcc dot gnu dot org 2007-06-14 01:02
---
The problem is that it needs also source style scoping also:
take:
int f(int *a);
int g(int b)
{
{
int c;
f(c);
}
{
int c1;
f(c1);
}
}
Without source based ones, we don't know if c/c1 can ever be shared.
I have code here at Sony where we actually depend on this behavior with large
structs (and arrays).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32327
--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32327
