[Bug middle-end/18424] [3.4/4.0 Regression] ~6x+ performance regression, constant trees not being computed.

[schlie at comcast dot net]

--- Additional Comments From schlie at comcast dot net  2004-12-21 07:59 
---
Problems, with 4.0 avr test results (some good, some bad, some odd);

00c6 :
int main (void){
  c6:   c8 ef   ldi r28, 0xF8   ; 248
  c8:   d0 e1   ldi r29, 0x10   ; 16
  ca:   de bf   out 0x3e, r29   ; 62
  cc:   cd bf   out 0x3d, r28   ; 61

volatile char c;
volatile int i;
volatile long l;

/* char tests */

c = (c & (1 << 4));
  ce:   89 81   ldd r24, Y+1; 0x01
  d0:   80 71   andir24, 0x10   ; 16
; good.
  d2:   89 83   std Y+1, r24; 0x01

if (c & (1 << 4))
  d4:   89 81   ldd r24, Y+1; 0x01
  d6:   84 ff   sbrsr24, 4  
   ; good single bit test & branch
  d8:   03 c0   rjmp.+6 ; 0xe0 
  c = 1;
  da:   81 e0   ldi r24, 0x01   ; 1
  dc:   89 83   std Y+1, r24; 0x01
  de:   01 c0   rjmp.+2 ; 0xe2 
else
  c = 0;
  e0:   19 82   std Y+1, r1 ; 0x01

c = (c & (1 << 4)) ? 1 : 0;
  e2:   89 81   ldd r24, Y+1; 0x01
  e4:   99 27   eor r25, r25
  e6:   44 e0   ldi r20, 0x04   ; 4 ; 
bad, using shift loop. although same as above.
  e8:   96 95   lsr r25
  ea:   87 95   ror r24
  ec:   4a 95   dec r20
  ee:   e1 f7   brne.-8 ; 0xe8 
  f0:   81 70   andir24, 0x01   ; 1
  f2:   89 83   std Y+1, r24; 0x01

c = sizeof(char);
  f4:   81 e0   ldi r24, 0x01   ; 1
  f6:   89 83   std Y+1, r24; 0x01

/* int tests */

i = i & (1 << 10);
  f8:   8a 81   ldd r24, Y+2; 0x02
  fa:   9b 81   ldd r25, Y+3; 0x03
  fc:   80 70   andir24, 0x00   ; 0 ; ok, but 
nicer if recognized only highest byte significant.
  fe:   94 70   andir25, 0x04   ; 4
 100:   8a 83   std Y+2, r24; 0x02
 102:   9b 83   std Y+3, r25; 0x03

if (i & (1 << 10))
 104:   8a 81   ldd r24, Y+2; 0x02
 106:   9b 81   ldd r25, Y+3; 0x03
 108:   9c 01   movwr18, r24   ; shouldn't 
be moving the operand? rest as above.
 10a:   20 70   andir18, 0x00   ; 0
 10c:   34 70   andir19, 0x04   ; 4
 10e:   92 ff   sbrsr25, 2
 110:   05 c0   rjmp.+10; 0x11c 
  i = 1;
 112:   81 e0   ldi r24, 0x01   ; 1
 114:   90 e0   ldi r25, 0x00   ; 0; r1 
= 0 already?, 
 116:   8a 83   std Y+2, r24; 0x02
 118:   9b 83   std Y+3, r25; 0x03
 11a:   02 c0   rjmp.+4 ; 0x120 
else
  i = 0;
 11c:   2a 83   std Y+2, r18; 0x02
 11e:   3b 83   std Y+3, r19; 0x03; wrong, 
r19 = andi r19, 0x04 ?

i = (i & (1 << 10)) ? 1 : 0;
 120:   8a 81   ldd r24, Y+2; 0x02
 122:   9b 81   ldd r25, Y+3; 0x03
 124:   89 2f   mov r24, r25 ; nice, shifts by 
8 first.
 126:   99 27   eor r25, r25
 128:   86 95   lsr r24
 12a:   86 95   lsr r24
 12c:   81 70   andir24, 0x01   ; 1
 12e:   90 70   andir25, 0x00   ; 0  ; but then 
fogets it already set r25 to 0?
 130:   8a 83   std Y+2, r24; 0x02
 132:   9b 83   std Y+3, r25; 0x03

i = sizeof(int);
 134:   82 e0   ldi r24, 0x02   ; 2
 136:   90 e0   ldi r25, 0x00   ; 0
 138:   8a 83   std Y+2, r24; 0x02
 13a:   9b 83   std Y+3, r25; 0x03

/* long tests */

l = (l & ((long)1 << 26));
 13c:   8c 81   ldd r24, Y+4; 0x04
 13e:   9d 81   ldd r25, Y+5; 0x05
 140:   ae 81   ldd r26, Y+6; 0x06
 142:   bf 81   ldd r27, Y+7; 0x07
 144:   80 70   andir24, 0x00   ; 0; ok.
 146:   90 70   andir25, 0x00   ; 0
 148:   a0 70   andir26, 0x00   ; 0
 14a:   b4 70   andir27, 0x04   ; 4
 14c:   8c 83   std Y+4, r24; 0x04
 14e:   9d 83   std Y+5, r25; 0x05
 150:   ae 83   std Y+6, r26; 0x06
 152:   bf 83   std Y+7, r27; 0x07

if (l & ((long)1 << 26))
 154:   8c 81   ldd r24, Y+4; 0x04
 156:   9d 81   ldd r25, Y+5; 0x05
 158:   ae 81   ldd r26, Y+6; 0x06
 15a:   bf 81  

Can You Help Me

[[EMAIL PROTECTED]]

I'm looking for the VP/Director of Customer Care and/or Data Services. 
Can you let me know who this is and how I would 
contact them.

Thank you in advance,

Helen

[Bug c/19099] No warning for uninitialized local variable use

[gopalv82 at dotgnu dot org]

--- Additional Comments From gopalv82 at dotgnu dot org  2004-12-21 07:40 
---
Created an attachment (id=7788)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7788&action=view)
Simple test case

Generates different output with different optimisation levels - but no warnings
at all.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19099

[Bug c/19099] New: No warning for uninitialized local variable use

[gopalv82 at dotgnu dot org]

Code similar to the one below does not give a warning (though one is expected).

int foo()
{
  int x = x;
  return x;
}

Though this code in itself seems stupid - this is how it hid into my codebase 
(in a simplified example).

#include 

#define macro2(imm) \
do {\
int __value = (imm);\
printf("macro2 got %d\n", __value);\
}while(0)

#define macro3(imm) \
do { \
int __value = (imm);\
printf("macro3 got %d\n", __value);\
} while(0);
#define macro1(imm)\
do {\
int __value = (imm);\
printf("macro1 got %d\n", __value);\
macro2(__value);\
macro3(__value);\
}while(0)

int foobar()
{
printf("foobar was called\n");
return 42;
}
int main()
{
macro1(foobar());
return 0;
}

The expected output was 
"""
foobar was called 
macro1 got 42
macro2 got 42
macro3 got 42
"""

But I get
"""
[EMAIL PROTECTED] samples $ gcc -Wall -pedantic -ansi -O3 test.c
[EMAIL PROTECTED] samples $ ./a.out 
foobar was called
macro1 got 42
macro2 got 805441120
macro3 got 805441120
"""

The original code was spread accross 4 files. I think the code 
should generate a valid warning because the variable is as good
as being stack/register junk . 

Tested with "gcc (GCC) 3.4.1 20040803 (Gentoo Linux 3.4.1-r3, ssp-3.4-2,
pie-8.7.6.5)".

-- 
   Summary: No warning for uninitialized local variable use
   Product: gcc
   Version: 3.4.1
Status: UNCONFIRMED
  Severity: minor
  Priority: P2
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gopalv82 at dotgnu dot org
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: powerpc-unknown-linux-gnu
  GCC host triplet: powerpc-unknown-linux-gnu
GCC target triplet: powerpc-unknown-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19099

[Bug tree-optimization/19098] tree-ssa-dom.c has an "if" statement whose condition is probably wrong

[law at redhat dot com]

--- Additional Comments From law at redhat dot com  2004-12-21 07:34 ---
Subject: Re:  New: tree-ssa-dom.c has an "if"
statement whose condition is probably wrong

On Tue, 2004-12-21 at 05:59 +, kazu at cs dot umass dot edu wrote:
> tree-ssa-dom.c has the following
> 
>   if (!e->flags & EDGE_DFS_BACK)
> 
> which is always 0 because !e->flags is always 0 or 1, and
> EDGE_DFS_BACK is 32.
That should be

!(e->flags & EDGE_DFS_BACK)


FWIW, this bug shouldn't affect correctness in any way -- it's merely
avoiding a pessimization.

jef




-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19098

[Bug debug/16792] [4.0 regression] ICE in gen_subprogram_die, at dwarf2out.c:11267

[porten at kde dot org]

--- Additional Comments From porten at kde dot org  2004-12-21 07:14 ---
Re comment #8: my report #18018 was actually in relation to exactly this file
from the Qt package. The test case is a destilled version.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16792

[Bug tree-optimization/19098] tree-ssa-dom.c has an "if" statement whose condition is probably wrong

[bangerth at dealii dot org]

--- Additional Comments From bangerth at dealii dot org  2004-12-21 06:51 
---
Confirmed. This is in line 697 of version 1.20 of that file. This 
should definitely be resolved before 4.0 goes out. 
 
W. 

-- 
   What|Removed |Added

   Severity|normal  |critical
 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2004-12-21 06:51:38
   date||
   Target Milestone|--- |4.0.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19098

[Bug target/16111] generates invalid SSE movdqa instruction (instead of movaps)

[uros at kss-loka dot si]

--- Additional Comments From uros at kss-loka dot si  2004-12-21 06:42 
---
Mainline does not generate movdqa insn anymore. However:

g++ -O1 -msse -mfpmath=sse -fomit-frame-pointer -finline-limit=2000 pr16111.cpp 
./a.out
extents (-27.50 -27.50 -0.00 -0.00)

g++ -O2 -msse -mfpmath=sse -fomit-frame-pointer -finline-limit=2000 pr16111.cpp
./a.out
extents (0.00 0.00 2.018096 2.018096)

g++ -O3 -msse -mfpmath=sse -fomit-frame-pointer -finline-limit=2000 pr16111.cpp 
./a.out
extents (0.00 0.00 36.658997 36.658997)

Result is different, it depends on optimization level.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16111

[Bug tree-optimization/15524] [4.0 Regression] jump threading on trees is slow with switch statements with large # of cases

[law at redhat dot com]

--- Additional Comments From law at redhat dot com  2004-12-21 06:23 ---
Subject: Re:  [4.0 Regression] jump threading
on trees is slow with switch statements with large # of cases

On Mon, 2004-12-20 at 00:51 +, steven at gcc dot gnu dot org wrote:
> --- Additional Comments From steven at gcc dot gnu dot org  2004-12-20 
> 00:51 ---
> I suggest we close this one, 9% is just comparable to the overall 
> slowdown we see in pretty much all code.  This is just noise in 
> the list of regressions.  If nobody objects, I'll close this in a 
> couple of days from now... 
I wouldn't close it.  There's still some significant representational 
issues that need addressing (jump vectors in RTL).  It exposes some
major lamness in invariant code motion (trying to hoist a few thousand
instances of GLOBAL_VAR), and some lameness in our CFG code as well
(the edge cache).

The fact that we're spending so much time redirecting edges at the RTL
level is also an indication that we may not be passing off optimal
trees to the expanders.

In all, there may be another 10% gain for pr15524 waiting for us to
nail down.

These are all issues I want to see examined, but they're lower priority
than fixing the extreme lameness in our aliasing code which is causing
even bigger compile-time regressions in other testcodes.


Jeff





-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15524

[Bug tree-optimization/19098] New: tree-ssa-dom.c has an "if" statement whose condition is probably wrong

[kazu at cs dot umass dot edu]

tree-ssa-dom.c has the following

  if (!e->flags & EDGE_DFS_BACK)

which is always 0 because !e->flags is always 0 or 1, and
EDGE_DFS_BACK is 32.

-- 
   Summary: tree-ssa-dom.c has an "if" statement whose condition is
probably wrong
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kazu at cs dot umass dot edu
CC: gcc-bugs at gcc dot gnu dot org,law at redhat dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19098

[Bug c++/12850] memory consumption for heavy template instantiations tripled since 3.3

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-21 
05:53 ---
Here are the results for -O0, now that PR 18683 is now fixed:
cp/lex.c:716 (copy_decl)1087604: 0.3%  0: 
0.0%5906492:10.6%  0: 0.0%  
56404
cp/pt.c:3978 (coerce_template_parms)   41586524: 9.6%  0: 
0.0% 136540: 0.2%
3865680: 7.4%1138236


Though we do create a lot:
cp/parser.c:278 (cp_lexer_new_main)   0: 0.0%   
22585856:36.1%  0: 0.0%
6332928:12.1%  5

Which is mostly a ggc_realloc of a buffer of all the tokens, maybe there is a 
better way of allocating this 
buffer as it seems like we create a lot of overhead because ot it.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12850

[Bug tree-optimization/18813] not vectorizing obvious loop

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-21 
05:44 ---
Note we are unrolling this loop now so that should help SPEC.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18813

[Bug middle-end/12454] large number of if ();else if cause

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-21 
05:02 ---
The testcase is now fixed but the fundamental problem with the gimplifier still 
exists.  So this is no 
longer a regression.

-- 
   What|Removed |Added

   Keywords|xfail   |
Summary|[4.0 Regression] [tree-ssa] |large number of if ();else
   |Regression in   |if cause
   |g++.dg/parse/stack1.C   |
   Target Milestone|4.0.0   |---


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12454

[Bug libgcj/15719] GIJ Interpeter: Problem with NaN / infinity comparisons

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-21 
03:58 ---
Hmm, I also get true on the mainline on powerpc-darwin.

-- 
   What|Removed |Added

   Last reconfirmed|2004-05-29 01:06:33 |2004-12-21 03:58:24
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15719

[Bug target/16111] generates invalid SSE movdqa instruction (instead of movaps)

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-21 
03:41 ---
Hmm, I wonder if this is fixed now.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16111

[Bug c++/12850] memory consumption for heavy template instantiations tripled since 3.3

[pinskia at gcc dot gnu dot org]

-- 
Bug 12850 depends on bug 18683, which changed state.

Bug 18683 Summary: [4.0 Regression] seg fault in local allocate
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18683

   What|Old Value   |New Value

 Status|NEW |RESOLVED
 Resolution||FIXED

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12850

[Bug middle-end/18683] [4.0 Regression] seg fault in local allocate

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-21 
03:33 ---
Fixed, thanks Roger.

-- 
   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18683

[Bug middle-end/18683] [4.0 Regression] seg fault in local allocate

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-12-21 
03:18 ---
Subject: Bug 18683

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2004-12-21 03:18:51

Modified files:
gcc: ChangeLog 
gcc/config/rs6000: rs6000.c 

Log message:
PR middle-end/18683
* config/rs6000/rs6000.c (current_file_function_operand): Only check
current_function_decl's DECL_RTL if it has already been set.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.6905&r2=2.6906
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/rs6000/rs6000.c.diff?cvsroot=gcc&r1=1.765&r2=1.766



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18683

[Bug tree-optimization/19096] Wrong code with -ftree-vectorize

[bangerth at dealii dot org]

--- Additional Comments From bangerth at dealii dot org  2004-12-21 02:40 
---
This works for me, too, with a snapshot from 2004-12-14, or at least it 
doesn't abort and returns a return code of 1. What do you see, and what 
flags exactly do you use? I tried with 
  -march=pentium4 -mmmx -msse -msse2 -mfpmath=sse -O1 -ftree-vectorize x.c 
 
W. 

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19096

[Bug rtl-optimization/19097] Lots of else ifs take forever to compile

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-21 
02:39 ---
I think DOM is "fixing" the compile-time/memory-hog on the mainline :).

-- 
   What|Removed |Added

   Keywords||compile-time-hog, memory-hog


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19097

[Bug rtl-optimization/19097] New: Lots of else ifs take forever to compile

[phython at gcc dot gnu dot org]

The following bit of code doesn't compile on my laptop (at -O2) because gcc gets
killed. This happens with gcc 3.3.5 and gcc 3.4.3 and gcc 4.0

#define CL0(a) else if (b == a) { f(); }
#define CL1(a) CL0(a##0) CL0(a##1) CL0(a##2) CL0(a##3) CL0(a##4) CL0(a##5) \
 CL0(a##6) CL0(a##7) CL0(a##8) CL0(a##9)
#define CL2(a) CL1(a##0) CL1(a##1) CL1(a##2) CL1(a##3) CL1(a##4) CL1(a##5) \
 CL1(a##6) CL1(a##7) CL1(a##8) CL1(a##9)
#define CL3(a) CL2(a##0) CL2(a##1) CL2(a##2) CL2(a##3) CL2(a##4) CL2(a##5) \
 CL2(a##6) CL2(a##7) CL2(a##8) CL2(a##9)
#define CL4(a) CL3(a##0) CL3(a##1) CL3(a##2) CL3(a##3) CL3(a##4) CL3(a##5) \
 CL3(a##6) CL3(a##7) CL3(a##8) CL3(a##9)
#define CL5(a) CL4(a##0) CL4(a##1) CL4(a##2) CL4(a##3) CL4(a##4) CL4(a##5) \
 CL4(a##6) CL4(a##7) CL4(a##8) CL4(a##9)

void f();

void a() {
  int b;
  if (b == 1) { f(); }
  CL4(1)
}

 Changing if (b == 1) to if (b) fixes the large compile time on gcc 4.0, but
keeps the large compile time problem with gcc 3.3 and 3.4.

-- 
   Summary: Lots of else ifs take forever to compile
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: phython at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19097

[Bug middle-end/18683] [4.0 Regression] seg fault in local allocate

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-12-21 
01:37 ---
Subject: Bug 18683

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2004-12-21 01:37:35

Modified files:
gcc: ChangeLog function.c 
gcc/testsuite  : ChangeLog 
Added files:
gcc/testsuite/g++.dg/opt: pr18683-1.C 

Log message:
PR middle-end/18683
* function.c (pop_function_context_from): Don't reset reg_renumber.

* g++.dg/opt/pr18683-1.C: New test case.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.6904&r2=2.6905
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/function.c.diff?cvsroot=gcc&r1=1.593&r2=1.594
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.4787&r2=1.4788
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/opt/pr18683-1.C.diff?cvsroot=gcc&r1=NONE&r2=1.1



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18683

[Bug tree-optimization/19096] Wrong code with -ftree-vectorize

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-21 
01:28 ---
This works for me on ppc-darwin.
In .vect, I get "number of iterations cannot be computed".

-- 
   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19096

[Bug target/18916] [4.0 Regression] mis-aligned vector code with copy memory (-maltivec)

[fjahanian at apple dot com]

--- Additional Comments From fjahanian at apple dot com  2004-12-21 01:25 
---
My last patch also had problems, in that it changed alignment of local vector 
variables on  stack.
This alignment cannot be changed because AltiVec intrincics expect 128bit 
alignment. So,
I conclude that only tempoaries with expected 128bit or more alignments are not 
aligned
properly. The safest fix would be to simply change the alignment at the rtl 
level when
temporaries of 128bit alignment need be generated. This requires change to the 
middle end.
Following patch shows the concept and is not an FSF ready patch (which requires 
target-hook or
some such). This patch essentially says that if 128 alignment of local 
temporaries on stack can not
be guaranteed (or changed), then set the alignment value in the rtl to what can 
be guaranteed. 
With this patch, emit_block_move will not generate lvx/stvx for these cases.

Index: expr.c
===

RCS file: /cvs/gcc/gcc/gcc/expr.c,v
retrieving revision 1.761
diff -c -p -r1.761 expr.c
*** expr.c  18 Dec 2004 14:38:31 -  1.761
--- expr.c  21 Dec 2004 01:23:27 -
*** emit_push_insn (rtx x, enum machine_mode
*** 3457,3463 
 to record the alignment of the stack slot.  */
  /* ALIGN may well be better aligned than TYPE, e.g. due to
 PARM_BOUNDARY.  Assume the caller isn't lying.  */
! set_mem_align (target, align);
  
  emit_block_move (target, xinner, size, BLOCK_OP_CALL_PARM);
}
--- 3457,3469 
 to record the alignment of the stack slot.  */
  /* ALIGN may well be better aligned than TYPE, e.g. due to
 PARM_BOUNDARY.  Assume the caller isn't lying.  */
!   /* powerpc-darwin currently does not enforce 128 bit alignment of 
!  temporaries on the stack. To do so, requires changes which will 
break
!  ABI compatibility. On the other hand, Leaving this unchanged 
generates 
!  incorrect code in cases where block move is implemented using
!  AltiVec instructions whose src and dest must be 128 bit aligned
!  (expand_block_move implementation in rs6000.c). */ 
!   set_mem_align (target, align >= 128 ? PARM_BOUNDARY : align);
  
  emit_block_move (target, xinner, size, BLOCK_OP_CALL_PARM);
}
*** store_expr (tree exp, rtx target, int ca
*** 4206,4214 
emit_group_load (target, temp, TREE_TYPE (exp),
 int_size_in_bytes (TREE_TYPE (exp)));
else if (GET_MODE (temp) == BLKmode)
!   emit_block_move (target, temp, expr_size (exp),
!(call_param_p
! ? BLOCK_OP_CALL_PARM : BLOCK_OP_NORMAL));
else
{
  temp = force_operand (temp, target);
--- 4212,4224 
emit_group_load (target, temp, TREE_TYPE (exp),
 int_size_in_bytes (TREE_TYPE (exp)));
else if (GET_MODE (temp) == BLKmode)
! {
!   /* See previous comment. */
!   set_mem_align (temp, MEM_ALIGN (temp) >= 128 ? PARM_BOUNDARY : 
MEM_ALIGN (temp));
!   emit_block_move (target, temp, expr_size (exp),
!(call_param_p
! ? BLOCK_OP_CALL_PARM : BLOCK_OP_NORMAL));
! }
else
{
  temp = force_operand (temp, target);




(In reply to comment #6)
> And this is the patch that I had in mind. Can this break ABI compatibily? My 
> limited testing shows
> that it does not.
> 
> Index: rs6000.c
> 
===
> 
> RCS file: /cvs/gcc/gcc/gcc/config/rs6000/rs6000.c,v
> retrieving revision 1.332.2.46.2.84
> diff -c -p -r1.332.2.46.2.84 rs6000.c
> *** rs6000.c16 Dec 2004 03:23:30 -  1.332.2.46.2.84
> --- rs6000.c18 Dec 2004 01:44:28 -
> *** function_arg_boundary (enum machine_mode
> *** 5190,5195 
> --- 5190,5201 
>|| (type && TREE_CODE (type) == VECTOR_TYPE
>&& int_size_in_bytes (type) >= 16))
>   return 128;
> +   else if (DEFAULT_ABI == ABI_DARWIN && mode == BLKmode
> +  && TYPE_ALIGN (type) >= 128)
> + {
> +   TYPE_ALIGN (type) = PARM_BOUNDARY;
> +   return PARM_BOUNDARY;
> + }
> else
>   return PARM_BOUNDARY;
>   }
> 

-- 
   What|Removed |Added

 CC||dalej at apple dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18916

[Bug other/19095] testsuite/gcc.dg/vect/vect.exp is not precise enough

[janis187 at us dot ibm dot com]

--- Additional Comments From janis187 at us dot ibm dot com  2004-12-21 
01:16 ---
We're not supposed to use TCL code in test cases, so the proper syntax is

  /* { dg-require-effective-target keyword } */

I like the idea of running the vect tests multiple times for targets that have
multiple variants of vector support.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19095

[Bug other/19095] testsuite/gcc.dg/vect/vect.exp is not precise enough

[steven at gcc dot gnu dot org]

--- Additional Comments From steven at gcc dot gnu dot org  2004-12-21 
01:13 ---
For target support bits, there is some in lib/target-supports.exp, and some 
more in gcc.dg/i386-cpuid.h.  For x86, probably the cpuid check should somehow 
be made available to tcl, and then let the test cases do [check_x86_cpuid sse] 
or [check_x86_cpuid sse2 3dnow].  This would allow us to replace all the code 
*in the testcases* in gcc.dg/i386-*.c with more specific tests: 
 
 { dg-require [is-effective-target ...] } 
 
 

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2004-12-21 01:13:19
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19095

[Bug tree-optimization/19096] New: Wrong code with -ftree-vectorize

[belyshev at lubercy dot com]

use "-O1 -ftree-vectorize" to reproduce:
--
extern void abort (void);

static unsigned int prime_tab[] = {7, 127};

int main (void)
{
  unsigned int n, low, mid, high;

  n = 64;
  low = 0;
  high = 1;
  while (low != high)
{
  mid = low + (high - low) / 2;
  if (n > prime_tab[mid])
low = mid + 1;
  else
high = mid;
}
  
  if (n > prime_tab[low])
abort ();
  return low;
}
--

-- 
   Summary: Wrong code with -ftree-vectorize
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P2
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: belyshev at lubercy dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: i386-pc-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19096

[Bug other/19095] New: testsuite/gcc.dg/vect/vect.exp is not precise enough

[steven at gcc dot gnu dot org]

- For x86* it should not just set -sse2, but look for mmx/3dNow!/sse1 also 
- For all targets, when the instruction set is not available, we should 
  still compile with the instruction set, just not run.  See the powerpc 
  and alpha for examples of what it *should* look like.

-- 
   Summary: testsuite/gcc.dg/vect/vect.exp is not precise enough
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: steven at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19095

[Bug libgcj/15001] [3.4 only] Using JNI with interpreter and interface methods yields SIGSEGV

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-12-21 
00:49 ---
Subject: Bug 15001

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2004-12-21 00:49:46

Modified files:
libjava: ChangeLog 
Added files:
libjava/testsuite/libjava.jni: iface.c iface.java iface.out 

Log message:
PR java/15001
* testsuite/libjava.jni/iface.c: New file.
* testsuite/libjava.jni/iface.out: New file.
* testsuite/libjava.jni/iface.java: New file.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/ChangeLog.diff?cvsroot=gcc&r1=1.3263&r2=1.3264
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/testsuite/libjava.jni/iface.c.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/testsuite/libjava.jni/iface.java.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/testsuite/libjava.jni/iface.out.diff?cvsroot=gcc&r1=NONE&r2=1.1



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15001

[Bug fortran/17675] [Regression w.r.t. g77] Alignment constraints not honored in EQUIVALENCE

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-21 
00:39 ---
Patch here: .

-- 
   What|Removed |Added

  GCC build triplet|sparc*-*-*  |
   GCC host triplet|sparc*-*-*  |
 GCC target triplet|sparc*-*-*  |sparc*-*-*, ia64-*-*,
   ||alpha*-*-*
   Keywords||patch


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17675

[Bug target/18749] GCC fails to mark stack-popping instruction in unwind-info

[steven at gcc dot gnu dot org]

--- Additional Comments From steven at gcc dot gnu dot org  2004-12-21 
00:21 ---
"xgcc (GCC) 4.0.0 20041220 (experimental)" produces this: 
$ ./xgcc -c -B. -O2 bug.c 
$ objdump -d bug.o 
 
bug.o: file format elf64-x86-64 
 
Disassembly of section .text: 
 
 : 
   0:   48 89 5c 24 e0  mov%rbx,0xffe0(%rsp) 
   5:   48 89 6c 24 e8  mov%rbp,0xffe8(%rsp) 
   a:   89 fb   mov%edi,%ebx 
   c:   4c 89 64 24 f0  mov%r12,0xfff0(%rsp) 
  11:   4c 89 6c 24 f8  mov%r13,0xfff8(%rsp) 
  16:   48 81 ec 28 10 00 00sub$0x1028,%rsp 
  1d:   85 ff   test   %edi,%edi 
  1f:   7f 36   jg 57  
  21:   89 d8   mov%ebx,%eax 
  23:   48 8b ac 24 10 10 00mov0x1010(%rsp),%rbp 
  2a:   00 
  2b:   4c 8b a4 24 18 10 00mov0x1018(%rsp),%r12 
  32:   00 
  33:   c1 e8 1fshr$0x1f,%eax 
  36:   4c 8b ac 24 20 10 00mov0x1020(%rsp),%r13 
  3d:   00 
  3e:   01 d8   add%ebx,%eax 
  40:   48 8b 9c 24 08 10 00mov0x1008(%rsp),%rbx 
  47:   00 
  48:   d1 f8   sar%eax 
  4a:   48 98   cltq 
  4c:   8b 04 84mov(%rsp,%rax,4),%eax 
  4f:   48 81 c4 28 10 00 00add$0x1028,%rsp 
  56:   c3  retq 
  57:   44 8d 6b ff lea0x(%rbx),%r13d 
  5b:   45 31 e4xor%r12d,%r12d 
  5e:   48 89 e5mov%rsp,%rbp 
  61:   44 89 efmov%r13d,%edi 
  64:   41 ff c4inc%r12d 
  67:   e8 00 00 00 00  callq  6c  
  6c:   89 45 00mov%eax,0x0(%rbp) 
  6f:   48 83 c5 04 add$0x4,%rbp 
  73:   44 39 e3cmp%r12d,%ebx 
  76:   7f e9   jg 61  
  78:   eb a7   jmp21  
 
 
$ readelf -wf bug.o 
The section .eh_frame contains: 
 
 0014  CIE 
  Version:   1 
  Augmentation:  "" 
  Code alignment factor: 1 
  Data alignment factor: -8 
  Return address column: 16 
 
  DW_CFA_def_cfa: r7 ofs 8 
  DW_CFA_offset: r16 at cfa-8 
  DW_CFA_nop 
  DW_CFA_nop 
  DW_CFA_nop 
  DW_CFA_nop 
  DW_CFA_nop 
  DW_CFA_nop 
 
0018 0024 001c FDE cie= pc=..007a 
  DW_CFA_advance_loc: 10 to 000a 
  DW_CFA_offset: r6 at cfa-32 
  DW_CFA_offset: r3 at cfa-40 
  DW_CFA_advance_loc: 19 to 001d 
  DW_CFA_def_cfa_offset: 4144 
  DW_CFA_offset: r13 at cfa-16 
  DW_CFA_offset: r12 at cfa-24 
  DW_CFA_nop 
  DW_CFA_nop 
  DW_CFA_nop 
 

-- 
   What|Removed |Added

  Known to fail|3.3.3 3.4.2 |3.3.3 3.4.2 4.0.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18749

[Bug target/18749] GCC fails to mark stack-popping instruction in unwind-info

[steven at gcc dot gnu dot org]

-- 
   What|Removed |Added

 Status|WAITING |NEW
 Ever Confirmed||1
   Keywords||EH, wrong-code
  Known to fail||3.3.3 3.4.2
   Last reconfirmed|-00-00 00:00:00 |2004-12-21 00:16:39
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18749

[Bug fortran/18998] Gfortran produces wrong output (c/f to g77)

[Tobias dot Schlueter at physik dot uni-muenchen dot de]

--- Additional Comments From Tobias dot Schlueter at physik dot 
uni-muenchen dot de  2004-12-21 00:04 ---
Subject: Re:  Gfortran produces wrong output (c/f to g77)

Deji Akingunola wrote:
>>--- Additional Comments From tobi at gcc dot gnu dot org  2004-12-20 
>>22:40 ---
>>The problem is an out-of-bounds array access to sa, note its dimensions and 
>>the
>>values the loop index takes on.
>>
> 
> I'm sorry I don't get the above, what do you mean by 'out-of-bound array
> access to sa' (what's sa). I wonder why it's tagged invalid while other
> compilers does successfully execute the same code. Does it mean one has
> to pass some special options to gfortran to produce the right result.
> Thanks.

The code has a bug.  It's not gfortran's fault that it doesn't work with
gfortran.  'sa' is an array in that code.  It is accessed out of bounds in the
loop of the main program.  This is caught at runtime, if the code is compiled
with '-fbounds-check'.  The problem only appears on i686 by hazard.  'The code
works if compiled with other compilers' doesn't mean 'the code is correct and
bug-free', unfortunately.

If you're still not convinced, lean back, look at the following five lines of
code (which are extracted from your testcase), and try to figure out what the
code means for all possible values of 'i'.
  parameter(n=8)
  real sa(n)
  do 20,i=1,2*n-1,2
 sa(i)=a(i)**2+a(i+1)**2
 20   continue

Regards,
- Tobi

ps I think you really want that loop to look like
  do i=2, 2*n, 2
  sa(i/2) = a(i-1)**2 + a(i)**2
  end do
or something similar.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18998

[Bug middle-end/12454] [4.0 Regression] [tree-ssa] Regression in g++.dg/parse/stack1.C

[steven at gcc dot gnu dot org]

--- Additional Comments From steven at gcc dot gnu dot org  2004-12-20 
23:26 ---
Is this still an issue, and if so, is it fixable for GCC 4.0? 

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12454

[Bug other/19082] [4.0 Regression] build/genattrtab: out of memory allocating 151568 bytes after a total of 4161651196 bytes

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Keywords|ice-on-valid-code   |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19082

[Bug middle-end/18776] [4.0 Regression] Libgfortran doesn't build again

[ebotcazou at gcc dot gnu dot org]

--- Additional Comments From ebotcazou at gcc dot gnu dot org  2004-12-20 
23:07 ---
See http://gcc.gnu.org/ml/gcc-patches/2004-12/msg01386.html


-- 
   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18776

[Bug other/16513] Libiberty doesn't honor the multi-os-directory settings

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-20 
23:05 ---
Confirmed.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
  Known to work||3.3.5 3.4.0 4.0.0
   Last reconfirmed|-00-00 00:00:00 |2004-12-20 23:05:26
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16513

[Bug middle-end/18776] [4.0 Regression] Libgfortran doesn't build again

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-12-20 
23:04 ---
Subject: Bug 18776

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2004-12-20 23:04:42

Modified files:
gcc: ChangeLog expr.c 

Log message:
PR middle-end/18776
* expr.c (write_complex_part): Use a subreg if the original object
is a hard reg that spans an even number of regs or a MEM.
(read_complex_part): Likewise.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.6903&r2=2.6904
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/expr.c.diff?cvsroot=gcc&r1=1.762&r2=1.763



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18776

[Bug ada/19094] bootstrap errors

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-20 
23:02 ---
If I recall correctly Ada cannot be bootstrapped with a new version than itself 
but I could be wrong.
Do you need to build Ada, if not do --enable-languages=c,c++,java,objc,f77 and 
this will disable Ada.  
And most likely this bug will be closed.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19094

[Bug c++/19043] [3.3/3.4 regression] -fpermissive gives bad loop initializations

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Severity|normal  |minor
 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2004-12-20 23:00:56
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19043

[Bug fortran/18918] Eventually support the co-array f95 extension in gfortran

[tobi at gcc dot gnu dot org]

--- Additional Comments From tobi at gcc dot gnu dot org  2004-12-20 22:44 
---
This might be interesting, even though I think it's far out of reach currently.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2004-12-20 22:44:28
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18918

[Bug fortran/18998] Gfortran produces wrong output (c/f to g77)

[tobi at gcc dot gnu dot org]

--- Additional Comments From tobi at gcc dot gnu dot org  2004-12-20 22:40 
---
Forgot to say: this bug is caught by -fbounds-check.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18998

[Bug fortran/18998] Gfortran produces wrong output (c/f to g77)

[tobi at gcc dot gnu dot org]

--- Additional Comments From tobi at gcc dot gnu dot org  2004-12-20 22:40 
---
The problem is an out-of-bounds array access to sa, note its dimensions and the
values the loop index takes on.

-- 
   What|Removed |Added

 CC||tobi at gcc dot gnu dot org
 Status|NEW |RESOLVED
 Resolution||INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18998

[Bug libobjc/12035] [3.4/4.0 Regression] Patch for libobjc/gc.c that fixes compilation error of Objective-C with garbage collector enabled

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-20 
22:37 ---
Fixed with a slightly different patch that I added before.

-- 
   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12035

[Bug libobjc/13946] ObjC configured --with-objc-gc needs external Boehm gc

[pinskia at gcc dot gnu dot org]

-- 
Bug 13946 depends on bug 12035, which changed state.

Bug 12035 Summary: [3.4/4.0 Regression] Patch for libobjc/gc.c that fixes 
compilation error of Objective-C with garbage collector enabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12035

   What|Old Value   |New Value

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13946

[Bug libobjc/12035] [3.4/4.0 Regression] Patch for libobjc/gc.c that fixes compilation error of Objective-C with garbage collector enabled

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-12-20 
22:35 ---
Subject: Bug 12035

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2004-12-20 22:35:08

Modified files:
libobjc: ChangeLog 

Log message:
change the changelog entry to:
2004-12-20  Andrew Pinski  <[EMAIL PROTECTED]>

PR libobjc/12035
* gc.c: Remove definition of LOGWL, modWORDSZ, and divWORDSZ since
they are not used.
Include limits.h and stdlib.h.
Define BITS_PER_WORD.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libobjc/ChangeLog.diff?cvsroot=gcc&r1=1.156&r2=1.157



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12035

[Bug libobjc/12035] [3.4/4.0 Regression] Patch for libobjc/gc.c that fixes compilation error of Objective-C with garbage collector enabled

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-12-20 
22:34 ---
Subject: Bug 12035

CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-3_4-branch
Changes by: [EMAIL PROTECTED]   2004-12-20 22:34:18

Modified files:
libobjc: ChangeLog gc.c 

Log message:
2004-12-20  Andrew Pinski  <[EMAIL PROTECTED]>

PR libobjc/12035
* gc.c: Remove definition of LOGWL, modWORDSZ, and divWORDSZ since
they are not used.
Include limits.h and stdlib.h.
Define BITS_PER_WORD.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libobjc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.106.2.6&r2=1.106.2.7
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libobjc/gc.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.6&r2=1.6.16.1



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12035

[Bug libobjc/12035] [3.4/4.0 Regression] Patch for libobjc/gc.c that fixes compilation error of Objective-C with garbage collector enabled

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-12-20 
22:32 ---
Subject: Bug 12035

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2004-12-20 22:32:42

Modified files:
libobjc: ChangeLog gc.c 

Log message:
2004-12-20  Andrew Pinski  <[EMAIL PROTECTED]>

PR libobjc/12035
* gc.c: Remove definition of LOGWL, modWORDSZ, and divWORDSZ since
they are not used.  Include limits.h and stdlib.h.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libobjc/ChangeLog.diff?cvsroot=gcc&r1=1.155&r2=1.156
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libobjc/gc.c.diff?cvsroot=gcc&r1=1.6&r2=1.7



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12035

[Bug target/18749] GCC fails to mark stack-popping instruction in unwind-info

[davidm at hpl dot hp dot com]

--- Additional Comments From davidm at hpl dot hp dot com  2004-12-20 22:13 
---
(In reply to comment #1)
> Without a test case, nobody can give this bug a proper look.  Can you  
> provide an example of how this fails for you?

Sorry, that was sloppy of me.  I'll attach a minimal test-case (bug.c).  With
that file:

$ gcc -v 2>&1|grep version
gcc version 3.4.2 20041017 (Red Hat 3.4.2-6.fc3)
$ gcc -c -O2 bug.c
$ objdump -d bug.o |tail -2
  76:   48 81 c4 28 10 00 00add$0x1028,%rsp
  7d:   c3  retq   
$ readelf -wf bug.o 
The section .eh_frame contains:

 0014  CIE
  Version:   1
  Augmentation:  ""
  Code alignment factor: 1
  Data alignment factor: -8
  Return address column: 16

  DW_CFA_def_cfa: r7 ofs 8
  DW_CFA_offset: r16 at cfa-8
  DW_CFA_nop
  DW_CFA_nop
  DW_CFA_nop
  DW_CFA_nop
  DW_CFA_nop
  DW_CFA_nop

0018 0024 001c FDE cie= pc=..007e
  DW_CFA_advance_loc: 5 to 0005
  DW_CFA_offset: r6 at cfa-32
  DW_CFA_advance_loc: 24 to 001d
  DW_CFA_def_cfa_offset: 4144
  DW_CFA_offset: r13 at cfa-16
  DW_CFA_offset: r3 at cfa-40
  DW_CFA_offset: r12 at cfa-24

While the code came out slightly differently, the same problem exists: the
DWARF2 frame info fails to describe the effect of popping the stack in the
second-last instruction.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18749

[Bug libobjc/12035] [3.4/4.0 Regression] Patch for libobjc/gc.c that fixes compilation error of Objective-C with garbage collector enabled

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-20 
21:55 ---
I think there is a better patch:
Index: gc.c
===

RCS file: /cvs/gcc/gcc/libobjc/gc.c,v
retrieving revision 1.6
diff -u -p -r1.6 gc.c
--- gc.c23 May 2003 20:04:58 -  1.6
+++ gc.c20 Dec 2004 21:51:20 -
@@ -40,18 +40,6 @@ Boston, MA 02111-1307, USA.  */
 typedef GC_word word;
 typedef GC_signed_word signed_word;
 
-#if BITS_PER_WORD == 32
-# define LOGWL 5
-# define modWORDSZ(n) ((n) & 0x1f)/* n mod size of word
*/
-#endif
-
-#if BITS_PER_WORD == 64
-# define LOGWL 6
-# define modWORDSZ(n) ((n) & 0x3f)/* n mod size of word
*/
-#endif
-
-#define divWORDSZ(n) ((n) >> LOGWL)   /* divide n by size of word  */
-
 #include 
 
 /* The following functions set up in `mask` the corresponding pointers.


Which just removes the use of BITS_PER_WORD which are not used anywhere else.

-- 
   What|Removed |Added

Summary|Patch for libobjc/gc.c that |[3.4/4.0 Regression] Patch
   |fixes compilation error of  |for libobjc/gc.c that fixes
   |Objective-C with garbage|compilation error of
   |collector enabled   |Objective-C with garbage
   ||collector enabled
   Target Milestone|--- |3.4.4


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12035

[Bug c++/19092] g++ accepts code that violates 14.6.4.2

[bangerth at dealii dot org]

--- Additional Comments From bangerth at dealii dot org  2004-12-20 21:30 
---
Actually, we can make this a rejects-valid like so: 
-- 
namespace NS1 { 
  struct X {}; 
  void foo(X); 
} 
 
namespace NS2 { 
  static void foo(NS1::X); 
   
  template  
  void bar() { 
foo(T()); 
  } 
} 
 
template void NS2::bar (); 
--- 
Since NS2::foo is static, it isn't an eligible overload, so NS1::foo 
should be called. However, gcc doesn't realize this: 
 
g/x> c++ x.cc ; ./a.out ; echo $? 
x.cc: In function `void NS2::bar() [with T = NS1::X]': 
x.cc:15:   instantiated from here 
x.cc:11: error: call of overloaded `foo(NS1::X)' is ambiguous 
x.cc:7: error: candidates are: void NS2::foo(NS1::X) 
x.cc:3: error: void NS1::foo(NS1::X) 
 
This fails with all versions of gcc I have. 
 
W. 

-- 
   What|Removed |Added

   Keywords||rejects-valid
  Known to fail||2.95.3 3.2.3 3.3.1 3.3.4
   ||3.4.3 4.0.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19092

[Bug other/19093] g++.dg/opt/max1.C fails on ia64 and x86_64

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-20 
21:12 ---
Fixed.

-- 
   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19093

[Bug other/19093] g++.dg/opt/max1.C fails on ia64 and x86_64

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-12-20 
21:12 ---
Subject: Bug 19093

CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-3_3-branch
Changes by: [EMAIL PROTECTED]   2004-12-20 21:12:34

Modified files:
gcc/testsuite  : ChangeLog 
gcc/testsuite/g++.dg/opt: max1.C 

Log message:
2004-12-20  Andrew Pinski  <[EMAIL PROTECTED]>

PR other/19093
* g++.dg/opt/max1.C: Fix for 64bit targets.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_3-branch&r1=1.2261.2.391&r2=1.2261.2.392
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/opt/max1.C.diff?cvsroot=gcc&only_with_tag=gcc-3_3-branch&r1=1.2.2.1&r2=1.2.2.2



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19093

[Bug other/19093] g++.dg/opt/max1.C fails on ia64 and x86_64

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-12-20 
21:09 ---
Subject: Bug 19093

CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-3_4-branch
Changes by: [EMAIL PROTECTED]   2004-12-20 21:09:37

Modified files:
gcc/testsuite  : ChangeLog 
gcc/testsuite/g++.dg/opt: max1.C 

Log message:
2004-12-20  Andrew Pinski  <[EMAIL PROTECTED]>

PR other/19093
* g++.dg/opt/max1.C: Fix for 64bit targets.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.3389.2.333&r2=1.3389.2.334
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/opt/max1.C.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.1.2.1&r2=1.1.2.2



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19093

[Bug other/19093] g++.dg/opt/max1.C fails on ia64 and x86_64

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-12-20 
21:07 ---
Subject: Bug 19093

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2004-12-20 21:07:14

Modified files:
gcc/testsuite  : ChangeLog 
gcc/testsuite/g++.dg/opt: max1.C 

Log message:
2004-12-20  Andrew Pinski  <[EMAIL PROTECTED]>

PR other/19093
* g++.dg/opt/max1.C: Fix for 64bit targets.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.4786&r2=1.4787
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/opt/max1.C.diff?cvsroot=gcc&r1=1.2&r2=1.3



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19093

[Bug libstdc++/17140] Floating point output is slow

[jlquinn at gcc dot gnu dot org]

--- Additional Comments From jlquinn at gcc dot gnu dot org  2004-12-20 
21:01 ---
Trying on a power4 aix 5.2 box, in the testsuite,
27_io/basic_ostream/inserts_arithmetic/char/1.cc fails, because of a segfault in
frexp(long double, int).  In gdb, the args look fine.  The int seems to be a
valid pointer, since I can set the value without problem.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17140

[Bug rtl-optimization/18942] Do loop is not as optimized as 3.3.2

[rakdver at gcc dot gnu dot org]

--- Additional Comments From rakdver at gcc dot gnu dot org  2004-12-20 
20:49 ---
Fixed.

-- 
   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18942

[Bug rtl-optimization/18942] Do loop is not as optimized as 3.3.2

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-12-20 
20:49 ---
Subject: Bug 18942

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2004-12-20 20:48:54

Modified files:
gcc: ChangeLog simplify-rtx.c 

Log message:
PR rtl-optimization/18942
* simplify-rtx.c (simplify_relational_operation_1): Simplify
x + cst1 == cst2 to x == cst2 - cst1.  Made static.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.6901&r2=2.6902
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/simplify-rtx.c.diff?cvsroot=gcc&r1=1.216&r2=1.217



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18942

[Bug tree-optimization/19067] ICE in tree-if-conv

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-20 
20:43 ---
Cool thanks Devang for testing the patch.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2004-12-20 20:43:39
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19067

[Bug c++/19092] g++ accepts code that violates 14.6.4.2

[bangerth at dealii dot org]

--- Additional Comments From bangerth at dealii dot org  2004-12-20 20:43 
---
Indeed. It seems as if I am not the only one who wasn't aware of the 
restriction that dependent function calls can only be to functions with 
external linkage. 
 
This should be low priority, since we only accept invalid code. 
 
W. 

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19092

[Bug c++/19044] Alternate asm name for atan ignored when calling __builtin_atan

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-20 
20:40 ---
Fixed.

-- 
   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.0.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19044

[Bug ada/19094] bootstrap errors

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

  Component|bootstrap   |ada


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19094

[Bug tree-optimization/19067] ICE in tree-if-conv

[dpatel at apple dot com]

--- Additional Comments From dpatel at apple dot com  2004-12-20 20:32 
---
Subject: Re:  ICE in tree-if-conv


On Dec 18, 2004, at 10:28 AM, pinskia at gcc dot gnu dot org wrote:

> I don't know but could possible the patch in here: 
>  msg00514.html> which is already on the tcb branch help here?

Yes, this patch helps.



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19067

[Bug bootstrap/19094] New: bootstrap errors

[niorio19 at yahoo dot com]

2 questions:
during make bootstrap, on RedHat 3.3.3-7, there errors occur at the end:

make[3]: Entering directory `/usr/local/bin/gcc-3.2.3/gcc/ada'
gcc -c -g  -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-Wtraditional -pedantic -Wno-long-long -W -Wall -gnatpg -gnata -g -O1 
-fno-inline \
 -I- -I. -I. a-except.adb
a-except.adb:109:04: warning: named number "Address_Image_Length" is not 
referenced
make[3]: *** [a-except.o] Error 1
make[3]: Leaving directory `/usr/local/bin/gcc-3.2.3/gcc/ada'
make[2]: *** [gnat1] Error 2
make[2]: Leaving directory `/usr/local/bin/gcc-3.2.3/gcc'
make[1]: *** [stage1_build] Error 2
make[1]: Leaving directory `/usr/local/bin/gcc-3.2.3/gcc'
make: *** [bootstrap] Error 2

Also, I'm trying to install this 3.2.3 version of gcc on this Linux OS that came
with gcc 3.3.3 (I need an older version).  Once 3.2.3 is installed, how do I
make it the default compiler?  Right now, it looks like this:

gcc -v
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--disable-checking --disable-libunwind-exceptions --with-system-zlib
--enable-__cxa_atexit --host=i386-redhat-linux
Thread model: posix
gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7)

thanks for the help - nick

-- 
   Summary: bootstrap errors
   Product: gcc
   Version: 3.2.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: niorio19 at yahoo dot com
CC: gcc-bugs at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19094

[Bug target/18987] [4.0 regression] [ia64] Extra '.restore sp' in tail call

[davidm at hpl dot hp dot com]

--- Additional Comments From davidm at hpl dot hp dot com  2004-12-20 20:12 
---
(In reply to comment #6)
> Jim, David, can one of you look at this, and maybe revert the patch
> for PR13158 because it causes this regression?

Reverting the patch doesn't sound like a good idea, because it will only replace
a noticable code-generation bug with a hard to notice one.

The real question is why anyone would use -fno-omit-frame-pointer on ia64.  That
sounds like a bug.  Is the code coming from pine?  If so, we should see about
getting that fixed.

In any case, I'll attach a patch that fixes the problem for the test-case.  Jim
is in a better position to say whether that's a reasonable way of solving the
problem.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18987

[Bug c++/19044] Alternate asm name for atan ignored when calling __builtin_atan

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-12-20 
20:11 ---
Subject: Bug 19044

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2004-12-20 20:11:42

Modified files:
gcc: ChangeLog c-common.c c-common.h c-decl.c 
gcc/cp : ChangeLog decl.c 
gcc/testsuite  : ChangeLog 
Added files:
gcc/testsuite/g++.dg/ext: builtin6.C 

Log message:
PR c++/19044

* c-common.c (set_builtin_user_assembler_name): New.
* c-common.h (set_builtin_user_assembler_name): Declare.
* c-decl.c (finish_decl): Use set_builtin_user_assembler_name

* decl.c (make_rtl_for_nonlocal_decl): Use 
set_builtin_user_assembler_name

* g++.dg/ext/builtin6.C: New

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.6900&r2=2.6901
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-common.c.diff?cvsroot=gcc&r1=1.594&r2=1.595
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-common.h.diff?cvsroot=gcc&r1=1.272&r2=1.273
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-decl.c.diff?cvsroot=gcc&r1=1.616&r2=1.617
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&r1=1.4543&r2=1.4544
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/decl.c.diff?cvsroot=gcc&r1=1.1342&r2=1.1343
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.4785&r2=1.4786
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/ext/builtin6.C.diff?cvsroot=gcc&r1=NONE&r2=1.1



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19044

[Bug tree-optimization/19067] ICE in tree-if-conv

[dpatel at apple dot com]

--- Additional Comments From dpatel at apple dot com  2004-12-20 20:05 
---
Subject: Re:  ICE in tree-if-conv

I'll verify whether TCB patch works here or not.



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19067

[Bug libstdc++/17243] Test failures due to missing C99 symbols

[pcarlini at suse dot de]

--- Additional Comments From pcarlini at suse dot de  2004-12-20 20:02 
---
*** Bug 19086 has been marked as a duplicate of this bug. ***

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17243

[Bug libstdc++/19086] libstdc++ testsuite fails due to missing C99 functions

[pcarlini at suse dot de]

--- Additional Comments From pcarlini at suse dot de  2004-12-20 20:02 
---


*** This bug has been marked as a duplicate of 17243 ***

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19086

[Bug other/19093] g++.dg/opt/max1.C fails on ia64 and x86_64

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-20 
20:00 ---
Actually it is just the testcase is invalid for 64bit targets (woops, my fault 
since I made it).
This patch should fix the problem:
Index: g++.dg/opt/max1.C
===

RCS file: /cvs/gcc/gcc/gcc/testsuite/g++.dg/opt/max1.C,v
retrieving revision 1.2
diff -u -p -r1.2 max1.C
--- g++.dg/opt/max1.C   19 Dec 2004 20:11:15 -  1.2
+++ g++.dg/opt/max1.C   20 Dec 2004 19:59:13 -
@@ -10,7 +10,7 @@ long fff[10];
 void f(long a)
 {
   int i;
-  a =  *((long*)(a+5)) >? *((long*)(a+1)); 
+  a =  *((long*)(a+1+sizeof(long))) >? *((long*)(a+1)); 
 
   for(i=0;i<10;i++)
fff[i] = a;


I will apply it to all the branches where this is effected, 3.3, 3.4, and the 
mainline when I get home later 
today.

-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |pinskia at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
  Component|middle-end  |other
 Ever Confirmed||1
   Keywords|wrong-code  |
   Last reconfirmed|-00-00 00:00:00 |2004-12-20 20:00:59
   date||
   Target Milestone|--- |3.3.6


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19093

[Bug libfortran/19032] modulo generates wrong result for divisor 1 and -1

[tobi at gcc dot gnu dot org]

--- Additional Comments From tobi at gcc dot gnu dot org  2004-12-20 19:56 
---
Updated patch here: http://gcc.gnu.org/ml/gcc-patches/2004-12/msg01563.html

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19032

[Bug middle-end/19068] [3.3 only] Wrong code for MIN_EXPR and MAX_EXPR

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-20 
19:56 ---
Please next time file a new bug since the orginal bug was fixed, I filed PR 
19093 for the new bug.

-- 
   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19068

[Bug middle-end/19093] New: g++.dg/opt/max1.C fails on ia64 and x86_64

[pinskia at gcc dot gnu dot org]

g++.dg/opt/max1.C still failed on both Linux/ia64 and Linux/x86_64:

http://gcc.gnu.org/ml/gcc-testresults/2004-12/msg00919.html
http://gcc.gnu.org/ml/gcc-testresults/2004-12/msg00923.html

They are both 64bit targets.

-- 
   Summary: g++.dg/opt/max1.C fails on ia64 and x86_64
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P2
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19093

[Bug middle-end/19068] [3.3 only] Wrong code for MIN_EXPR and MAX_EXPR

[hjl at lucon dot org]

--- Additional Comments From hjl at lucon dot org  2004-12-20 19:54 ---
g++.dg/opt/max1.C still failed on both Linux/ia64 and Linux/x86_64:

http://gcc.gnu.org/ml/gcc-testresults/2004-12/msg00919.html
http://gcc.gnu.org/ml/gcc-testresults/2004-12/msg00923.html

They are both 64bit targets.

-- 
   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19068

[Bug tree-optimization/19038] [4.0 Regression] out-of ssa causing loops to have more than one BB

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-20 
19:47 ---
(In reply to comment #8)
> The reduced testcase (well heavely modified) looks like:
Here is the resulting loop asm (on x86 where shows up worse than ppc which is 
the same because
the RA does its work better there):
.L7:
movl%edx, %ecx
.L3:
movl%ecx, %edx
movl%ebx, %eax
imull   %edi, %edx
imull   %esi, %eax
imull   %esi, %ecx
subl%eax, %edx
movl%ebx, %eax
movl%ecx, %ebx
imull   %edi, %eax
addl%eax, %ebx
je  .L7

Compared to 3.4.0:
.L2:
movl16(%ebp), %ebx
movl%eax, %ecx
movl%esi, %edx
imull   16(%ebp), %eax
imull   %edi, %ecx
imull   %esi, %ebx
imull   %edi, %edx
movl%ebx, %esi
subl%ecx, %esi
addl%edx, %eax
je  .L2

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19038

[Bug tree-optimization/19038] [4.0 Regression] out-of ssa causing loops to have more than one BB

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-20 
19:23 ---
This also causes a compile time issue as the RTL optimizers and the register 
allocator have to do more 
work.

-- 
   What|Removed |Added

   Keywords||compile-time-hog


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19038

[Bug libfortran/19032] modulo generates wrong result for divisor 1 and -1

[tobi at gcc dot gnu dot org]

-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |tobi at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2004-12-16 14:30:16 |2004-12-20 19:08:48
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19032

[Bug tree-optimization/19038] [4.0 Regression] out-of ssa causing loops to have more than one BB

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-20 
19:04 ---
The reduced testcase (well heavely modified) looks like:
int
f (int temp2, int temp3, int xlvj_, int zlvj_, int yv1j_, int yv2j_)
{
  int temp1, temp5;

  for(;;) {
temp1 = temp2*xlvj_ - temp3*zlvj_;
temp3 = temp2*zlvj_ + temp3*xlvj_;
temp5 = temp2;
temp2 = temp1;
if (temp3)
  break;
  }
  return yv1j_ * yv2j_;
}

Before the tree-ssa we would produce one BB when creating RTL but after out of 
ssa produces an extra 
BB to hold "  temp2 = temp1;"

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19038

[Bug c++/19092] g++ accepts code that violates 14.6.4.2

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-20 
18:50 ---
Confirmed.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Keywords||accepts-invalid
   Last reconfirmed|-00-00 00:00:00 |2004-12-20 18:50:01
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19092

[Bug rtl-optimization/19078] [4.0 Regression] Poor quality code after loop unrolling.

[rakdver at gcc dot gnu dot org]

--- Additional Comments From rakdver at gcc dot gnu dot org  2004-12-20 
18:44 ---
Patch:

http://gcc.gnu.org/ml/gcc-patches/2004-12/msg01554.html

-- 
   What|Removed |Added

   Keywords||patch


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19078

[Bug c++/19092] g++ accepts code that violates 14.6.4.2

[bagnara at cs dot unipr dot it]

--- Additional Comments From bagnara at cs dot unipr dot it  2004-12-20 
18:32 ---
Created an attachment (id=7784)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7784&action=view)
Small program that allows to reproduce the problem


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19092

[Bug c++/19092] New: g++ accepts code that violates 14.6.4.2

[bagnara at cs dot unipr dot it]

The attached snippet should not compile, since foo() has internal linkage.
Instead, g++ compiles it happily and without a warning even when given
-Wall -W -pedantic.

-- 
   Summary: g++ accepts code that violates 14.6.4.2
   Product: gcc
   Version: 3.4.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bagnara at cs dot unipr dot it
CC: gcc-bugs at gcc dot gnu dot org
  GCC host triplet: i686-pc-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19092

[Bug tree-optimization/19038] [4.0 Regression] out-of ssa causing loops to have more than one BB

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-20 
18:25 ---
After getting access to sixtrack sources, steven and I found this is a problem 
in out of ssa committing 
on a new BB, I almost have a patch but it has one issue in that we could be the 
new statement's results 
in the control flow statement as we insert before it.

-- 
   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org
   Severity|enhancement |minor
 Status|UNCONFIRMED |NEW
  Component|rtl-optimization|tree-optimization
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2004-12-20 18:25:23
   date||
Summary|Loop header copying |[4.0 Regression] out-of ssa
   ||causing loops to have more
   ||than one BB
   Target Milestone|--- |4.0.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19038

[Bug tree-optimization/19080] [4.0 regression] ICE while compiling linux kernel

[dnovillo at gcc dot gnu dot org]

--- Additional Comments From dnovillo at gcc dot gnu dot org  2004-12-20 
18:23 ---

Fix: http://gcc.gnu.org/ml/gcc-patches/2004-12/msg01551.html

-- 
   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19080

[Bug tree-optimization/19080] [4.0 regression] ICE while compiling linux kernel

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-12-20 
18:18 ---
Subject: Bug 19080

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2004-12-20 18:18:37

Modified files:
gcc: ChangeLog tree-flow-inline.h tree-ssa-alias.c 
gcc/testsuite  : ChangeLog 
Added files:
gcc/testsuite/gcc.c-torture/compile: pr19080.c 

Log message:
PR tree-optimization/19080

Merge from tree-cleanup-branch

* tree-flow-inline.h (clear_call_clobbered): New function.
* tree-ssa-alias.c (init_alias_info): Call it.

testsuite/ChangeLog

PR tree-optimization/19080
* gcc.c-torture/compile/pr19080.c: New test.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.6899&r2=2.6900
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-flow-inline.h.diff?cvsroot=gcc&r1=2.27&r2=2.28
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-ssa-alias.c.diff?cvsroot=gcc&r1=2.63&r2=2.64
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.4784&r2=1.4785
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/compile/pr19080.c.diff?cvsroot=gcc&r1=NONE&r2=1.1



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19080

[Bug target/19087] Overflowed address in dwarf debug line information

[ericw at evcohs dot com]

--- Additional Comments From ericw at evcohs dot com  2004-12-20 17:44 
---
(In reply to comment #5)
> Hmm, on the mainline I get an error about dwarf2 not being supported:
> t.c:1: error: target system does not support the "dwarf-2" debug format
> 

If you're talking about HEAD/4.0, then a seperate bug report needs to be filed.
The avr port needs to be able to be configured for DWARF2 debug info. (Yes, I
know that the avr port of GDB only uses stabs, but other tools use DWARF2.)

The OP is using 3.4.1.


-- 
   What|Removed |Added

 CC||ericw at evcohs dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19087

[Bug tree-optimization/17617] Micro-optimize INTEGRAL_TYPE_P (or tree.def rather)

[bangerth at dealii dot org]

--- Additional Comments From bangerth at dealii dot org  2004-12-20 17:14 
---
The question raised in several of the messages in that discussion 
is whether an enumeration of equality checks is converted into a 
range check if the tested values are consecutive. 
 
Here is the answer: 
 
enum E  
{ 
  eins = 1, 
  zwei = 2, 
  drei = 3, 
  vier = 4, 
  fuenf= 5, 
  sechs= 6 
}; 
 
bool test_range (E e) 
{ 
  return e==drei || e==vier || e==fuenf; 
} 
 
 
This is indeed compiled into a range check: 
_Z10test_range1E: 
pushl   %ebp 
movl%esp, %ebp 
movl8(%ebp), %eax 
popl%ebp 
subl$3, %eax 
cmpl$2, %eax 
setbe   %al 
movzbl  %al, %eax 
ret 
 
W. 

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17617

[Bug c++/17648] [3.3/3.4 Regression] template destructor was not called for inherited classes

[SWElef at post dot sk]

--- Additional Comments From SWElef at post dot sk  2004-12-20 17:09 ---
(In reply to comment #13)
> Here's a condensed version of Wolfgang's testcase:
> 
> int i=1;
> class A;
> template struct B
> {
> A *p;
> ~B()
> {
> --i;
> p=0;
> if(p) delete p;
> }
> };
> class C : B<0> {};
> class A { C c; };
> int main()
> {
> { C c; }
> return i;
> }

This is not a "condensed version of Wolfgang's testcase". While Wolfgang's
testcase is well-formed, your is ill-formed. The difference is that it uses
a pointer to object of _non-dependent_ incomplete type, i.e. it is invalid
according to tc1:14.6/7:

  Knowing which names are type names allows the syntax of every template
  definition to be checked. No diagnostic shall be issued for a template
  definition for which a valid specialization can be generated. If no valid
  specialization can be generated for a template definition, and that
  template is not instantiated, the template definition is ill-formed,
  no diagnostic required. If a type used in a non-dependent name is
  incomplete at a point at which a template is defined but is complete
  at the point at which an instantiation is done, and if the completeness
  of that type affects whether or not the program is well-formed or affects
  the semantics of the program, the program is ill-formed; no diagnostic
  required. [Note: ...]

The details are very subtle because the template definition is not ill-formed
by itself. std:5.3.5/5 says

  If the object being deleted has incomplete class type at the point of
  deletion and the complete class has a non-trivial destructor or a
  deallocation function, the behavior is undefined.

Thus, it would be well defined if the class A was later completed with
trivial destructor and no class specific deallocation function.

It is ill-formed because class A was incomplete at the point of definition
of B::~B(), it was later defined with non-trivial destructor _and_
B<0>::~B() (with "delete p;") was instantiated. For example the snippet from
comment #14 _as short as it is_ is AFAICT well-formed.

In this context it might be important to note that starting from gcc3.4
we have the two phase lookup. gcc3.4+ should be able to issue the same
warning for the expression "delete p;" as for an ordinary delete expression
involving an incomplete type.

Regards,
Vladimir Marko


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17648

[Bug tree-optimization/17617] Micro-optimize INTEGRAL_TYPE_P (or tree.def rather)

[bangerth at dealii dot org]

--- Additional Comments From bangerth at dealii dot org  2004-12-20 17:08 
---
A patch (with following long discussion) has been proposed here: 
  http://gcc.gnu.org/ml/gcc-patches/2004-12/msg01495.html 
 
W. 

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17617

[Bug tree-optimization/13761] [tree-ssa] component refs to the same struct should not alias

[dberlin at gcc dot gnu dot org]

--- Additional Comments From dberlin at gcc dot gnu dot org  2004-12-20 
16:35 ---
The structure-aliasing branch now has code (or will as soon as cvs finishes
committing) that will fix dale's testcaes to the extent  i can.

We produce identical code for both loops, now.


I haven't quite fixed dan n's testcase yet, because it involves indirect_refs.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13761

[Bug libfortran/19071] complex formatted output has too many items

[tobi at gcc dot gnu dot org]

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2004-12-20 16:10:36
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19071

[Bug rtl-optimization/13366] ICE using MMX/SSE builtins with -O

[uros at kss-loka dot si]

--- Additional Comments From uros at kss-loka dot si  2004-12-20 15:39 
---
Equivalent SSE2 version works OK:
typedef int v8hi __attribute__ ((mode (V8HI)));

int
f (unsigned short n)
{
  v8hi vec = { 0, 0, 0, 0, 0, 0, 1, n };
  v8hi hw = __builtin_ia32_pmulhw128 (vec, vec);
  return (__builtin_ia32_pextrw128 (hw, 0));
}

SSE2 example produces following RTL:
(insn 13 11 15 1 (set (reg/v:V8HI 59 [ vec ])
(const_vector:V8HI [
(const_int 0 [0x0])
(const_int 0 [0x0])
(const_int 0 [0x0])
(const_int 0 [0x0])
(const_int 0 [0x0])
(const_int 0 [0x0])
(const_int 0 [0x0])
(const_int 0 [0x0])
])) -1 (nil)
(nil))

(insn 15 13 16 1 (parallel [
(set (subreg:SI (reg/v:V8HI 59 [ vec ]) 12)
(and:SI (subreg:SI (reg/v:V8HI 59 [ vec ]) 12)
(const_int -65536 [0x])))
(clobber (reg:CC 17 flags))
]) -1 (nil)
(nil))
...

and MMX version produces:

(insn 13 11 15 1 (clobber (reg/v:V4HI 59 [ vec ])) -1 (nil)
(nil))

(insn 15 13 17 1 (parallel [
(set (subreg:SI (reg/v:V4HI 59 [ vec ]) 0)
(and:SI (subreg:SI (reg/v:V4HI 59 [ vec ]) 0)
(const_int -65536 [0x])))
(clobber (reg:CC 17 flags))
]) -1 (nil)
(nil))
...

The trouble is in (insn 13). There is no setting of reg 59 to zero.

Also, mainline does not ICE for
v4hi vec = { 0, 0, 0, n };
and its SSE2 equivalent as suggested in comment #6 for both MMX and SSE2 
versions.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13366

[Bug libstdc++/19091] problem with string to double conversion (overflow situation)

[pcarlini at suse dot de]

--- Additional Comments From pcarlini at suse dot de  2004-12-20 15:35 
---
Indeed, *it overflows*. Try changing you testcase like this:

  istringstream s("+4E308");
  s >> r;
  if (!s.fail())
cout << r << endl;

What happens, is just that overflows and r is left unchanged; by chance, is
a very small number.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19091

[Bug c++/19043] [3.3/3.4 regression] -fpermissive gives bad loop initializations

[bangerth at dealii dot org]

--- Additional Comments From bangerth at dealii dot org  2004-12-20 15:34 
---
Confirmed. It works in 2.95 and mainline, but nothing in between (I 
tested 3.2.3, 3.3.4, 3.4.3). It is thus a regression, although I 
believe not a very serious one given that the code is in fact invalid 
and only compiles if you give the -fpermissive flag. 
 
W. 

-- 
   What|Removed |Added

  Known to fail|3.3.2   |3.3.2 3.2.3 3.4.3 3.3.4
   ||3.3.3
  Known to work|4.0.0   |4.0.0 2.95
Summary|[3.4/3.3 only] -fpermissive |[3.3/3.4 regression] -
   |gives bad loop  |fpermissive gives bad loop
   |initializations |initializations
   Target Milestone|--- |3.4.4


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19043

[Bug other/19082] [4.0 Regression] build/genattrtab: out of memory allocating 151568 bytes after a total of 4161651196 bytes

[segher at kernel dot crashing dot org]

-- 
   What|Removed |Added

 CC||segher at kernel dot
   ||crashing dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19082

[Bug rtl-optimization/19078] [4.0 Regression] Poor quality code after loop unrolling.

[pcarlini at suse dot de]

--- Additional Comments From pcarlini at suse dot de  2004-12-20 15:22 
---
More seriously, I think that we (the libstdc++-v3 people) should more carefully
test the effect of the new optimizations on std::algorithm: indeed, we are 
talking
about benchmarks, not pointless microbenchmarks: std:algorithm is *full* of 
small
loops like this one.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19078

[Bug libstdc++/19091] New: problem with string to double conversion (overflow situation)

[stefan dot becuwe at ua dot ac dot be]

Following conversion should overflow, and not return 8.02393e-308.  Same
problem, although different output, when reading "4E308" from standard input.

#include 
#include 
using namespace std;
int main()
{
  double r;
  istringstream s("+4E308");
  s >> r;
  cout << r << endl;
}

-- 
   Summary: problem with string to double conversion (overflow
situation)
   Product: gcc
   Version: 3.3.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: stefan dot becuwe at ua dot ac dot be
CC: gcc-bugs at gcc dot gnu dot org
  GCC host triplet: i386 linux


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19091

[Bug c++/19076] Pointer to member function not matched to pointer to member template

[bangerth at dealii dot org]

--- Additional Comments From bangerth at dealii dot org  2004-12-20 15:15 
---
This last testcase indeed still shows the problem. It doesn't compile 
with gcc, but does with icc. 
W. 

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19076

[Bug rtl-optimization/19078] [4.0 Regression] Poor quality code after loop unrolling.

[pcarlini at suse dot de]

--- Additional Comments From pcarlini at suse dot de  2004-12-20 15:13 
---
;) Well, many people believe I look too *often* at microbenchmarks... ;)

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19078

[Bug target/10395] [x86] vector types are incorrectly aligned causing crash in multi-threaded apps or when using in main, plus other times

[bangerth at dealii dot org]

--- Additional Comments From bangerth at dealii dot org  2004-12-20 15:13 
---
An attribute could work. I doubt that a general flag would be useful, 
since one in general doesn't know which functions are thread entry 
points, so the compiler would have to emit such stack alignment code 
into the prolog of each function it finds. 
 
W. 

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10395