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?
: 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
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
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
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
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
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++
.
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
--- 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
--- 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
--- 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
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 my
bad
--- 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
--- 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
--- 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
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
--- 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
--- 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 #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
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
--- 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
--- 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 #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
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
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
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
--- 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
--- 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
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
--- 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
--- 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
--- 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
--- 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 #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
--- 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
--- 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
--- 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 #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
--- 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 #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 #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
--- 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
--- 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
50 matches
Mail list logo
