Take the following code:
typedef struct dw_cfi_oprnd_struct {
unsigned long reg;
} dw_cfa_location;
dw_cfa_location loc;
void def_cfa_1 (void) {
loc.reg = loc.reg;
}
We don't remove the store/load to loc.rec on the tree level. We even don't
remove PIC startup code for
ppc-darwin either:
_
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-17
22:45 ---
Fixed, I filed the missed optimization under PR 22538.
--
What|Removed |Added
St
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-17
22:48 ---
PR 22538 is another testcase.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21000
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-17
22:52 ---
Only f and f2 are fixed. comment #3 is fixed too.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21000
--
What|Removed |Added
CC||zadeck at naturalbridge dot
||com
http://gcc.gnu.org/bugzilla/s
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com
|dot org |
Status|UNCONFIRMED
Compiling this:
#define SIZE 2u << 31 - 2
int main() {
char a[SIZE], b[SIZE];
}
Gives this compilation error:
bigcp.c: In function `main':
bigcp.c:7: error: unrecognizable insn:
(insn/f 34 33 35 (parallel [
(set (reg/f:SI 7 sp)
(plus:SI (reg/f:SI 7 sp)
) ../gcc/configure --enable-languages=c,c++ --prefix=/home/xxx/tmp
Thread model: posix
gcc version 4.1.0 20050717 (experimental)
The following code is rejected:
class A
{
public:
static void foo() {}
static int i;
};
class B : private A
{
};
class C : public B
{
public
--
What|Removed |Added
Component|c |target
GCC build triplet|FreeBSD 5.4-RELEASE i386|
GCC host triplet|FreeBSD 5.4-RELEASE i386|
GCC
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-17
23:58 ---
4.1 is correct.
private inherited base class means make that class's field all private in the
class, even if they were
public to begin with.
>From 3.4.0 and above correctly rejects this code.
--
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-18
00:01 ---
Confirmed. We should be producing a warning/error message for this like we do
on PowerPC.
t.c: In function 'main':
t.c:5: warning: stack frame too large
--
What|Removed
--- Additional Comments From mckelvey at maskull dot com 2005-07-18 01:00
---
Subject: Re: Bootstrap ICE on latest CVS: tree check: tree-ssa
On Sunday 17 July 2005 00:48 am, pinskia at gcc dot gnu dot org wrote:
> --- Additional Comments From pinskia at gcc dot gnu dot org 2005-07
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-18
01:02 ---
Can you try bootstrapping without using GCC 4.1 since I think your compiler
which you are building
with is before that patch?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22517
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-18
01:27 ---
Some new discussion from the C standards committee:
http://www.open-std.org/jtc1/sc22/wg14/
www/docs/n.htm
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22534
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-18
01:37 ---
I wonder if this is the recent regression in eon again.
--
What|Removed |Added
Last reconf
--- Additional Comments From jbucata at tulsaconnect dot com 2005-07-18
04:42 ---
For me, with -march=athlon-xp, -funroll-loops on 4.0.0 did indeed pessimize
slightly. However, -fprofile-{generate,use} pessimized more on top of that. So
there's still a problem with regard to the PO.
I
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-18
05:17 ---
The reason why eustore does not remove it is because we have a loop and a PHI
intbetween the load
and store:
# d_15 = V_MUST_DEF ;
d = s_2;
# d_18 = V_MAY_DEF ;
f (s_9);
# VUSE ;
s_16 = d
When building gcc-3.4.3 or gcc-4.x into a clean $PREFIX,
the configure script happily copies the glibc include files from include to
sys-include;
here's the line from the log file (with $PREFIX instead of the real prefix):
Copying $PREFIX/i686-unknown-linux-gnu/include to
$PREFIX/i686-unknown-lin
--- Additional Comments From uros at kss-loka dot si 2005-07-18 06:36
---
(In reply to comment #1)
> With last night's compiler I get:
Strange...
I have tested gcc snapshot 'gcc version 4.1.0 20050716 (experimental)',
with 'gcc -O2 -ftree-vectorize -msse2' and it still produces code w
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-18
06:43 ---
Created an attachment (id=9298)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9298&action=view)
patch which I need to test
This patch which needs more comments but should be complete otherwise. This
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-18
06:49 ---
(In reply to comment #2)
> I have tested gcc snapshot 'gcc version 4.1.0 20050716 (experimental)',
> with 'gcc -O2 -ftree-vectorize -msse2' and it still produces code with both %
> eax and %edx used.
>
> A
101 - 121 of 121 matches
Mail list logo
