--- 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
--- 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=17840&action=view)
C test-case for the same problem on x86_64 and i386.
The original C++ test-case does not crash on x86_64 a
mparison 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
Repor
--- 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:S
--- 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
--- 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 40
--- 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=13989&action=view)
Proposed fix for SEGV problem in dwarf2out.c in bug 31899
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31899
--- 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 #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:
--- 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 PROTEC
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
y: 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
R
y: 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
R
--- 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)");
ret
--- 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; f
--- 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
extern int sprintf (char *, const char*, ...);
int
main (void)
{
char buf
--- 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
--- 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
--- 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
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-
--- 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
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
--- 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
--- 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 m
--- 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
--- 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 right
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50194
Doug Kwan changed:
What|Removed |Added
CC||dougkwan at google dot com
--- Comment #2
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
#include
#include
struct b88 {
char
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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.
--- 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 #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
--- 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=13891&action=view)
Patch for fixing byte swap optimization.
I have tested this patch on i486-linux-gnu (C/C++ test suite onl
--- 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
--- 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=13911&action=view)
Updated patch with test case a bug fix.
I've added a test case of the changes. It did find a bug in t
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
--- 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
: 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66411
--- Comment #2 from Doug Kwan ---
(In reply to Richard Biener from comment #1)
> This has been fixed for 4.9.3
Do you know which patch fixes it?
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++
A
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
Comp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49551
--- Comment #1 from Doug Kwan 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.
--- 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]>:
>
--- 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
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
50 matches
Mail list logo
