[Bug tree-optimization/20701] New: [tcb] VRP does not eliminate a redundant "if" statement.

[kazu at cs dot umass dot edu]

Consider:

typedef struct {
  int code;
} *rtx;

int
can_combine_p (rtx insn, rtx elt)
{
  rtx set;

  set = 0;
  if (insn->code == 3)
set = insn;
  else
{
  set = elt;
  if (set == 0)
return 0;
}

  if (set == 0)
return 1;

  return 0;
}

Note that the last "if" statement never triggers.  That is, its condition
is always false.

Here is the dump with ASSERT_EXPRs.

can_combine_p (insn, elt)
{
  struct 
  {
int code;
  } * set;
  int D.1138;
  int D.1137;

:
  D.1137_5 = insn_4->code;
  insn_7 = ASSERT_EXPR ;
  if (D.1137_5 == 3) goto ; else goto ;

:;
  if (elt_9 == 0B) goto ; else goto ;

  # set_1 = PHI ;
:;
  if (set_1 == 0B) goto ; else goto ;

:;

  # D.1138_2 = PHI <0(1), 1(3), 0(2)>;
:;
  return D.1138_2;

}

For some reason, VRP does not insert an ASSERT_EXPR for elt_9,
so VRP proper cannot figure out that set_1 != 0B.

This opportunity is picked up by DOM in the form of jump threading.

This function is reduced from combine.c:can_combine_p.

-- 
   Summary: [tcb] VRP does not eliminate a redundant "if" statement.
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P2
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kazu at cs dot umass dot edu
CC: dnovillo at redhat dot com,gcc-bugs at gcc dot gnu dot
org


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

[Bug c++/772] Statement expressions issues

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-31 
07:26 ---
Only a C++ front-end problem now.

-- 
   What|Removed |Added

  Component|c   |c++


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

[Bug target/19139] data referenced as short misplaced in non-short linkonce section

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Target Milestone|--- |4.0.0


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

[Bug target/19139] data referenced as short misplaced in non-short linkonce section

[jbeulich at novell dot com]

--- Additional Comments From jbeulich at novell dot com  2005-03-31 06:44 
---
Correct.

-- 
   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||FIXED


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

[Bug c++/20607] [3.4 Regression] -fstrict-aliasing causes incorrect scheduling

[ebotcazou at libertysurf dot fr]

--- Additional Comments From ebotcazou at libertysurf dot fr  2005-03-31 
06:30 ---
Subject: Re:  [3.4 Regression] -fstrict-aliasing causes incorrect scheduling

> I think it's fixable.  I'm not sure exactly why the C++ front-end is
> inserting the additional operations, but they're certainly not essential
> from a C++ semantics point of view.  Please reassign the bug to me; I'll
> try to take a look.

Thanks, will do.  For the records, here's the tree for the first assignment 
with the C compiler:

 
unit size 
align 64 symtab 0 alias set -1
fields 
DI file ../pr20607.c line 17 size  
unit size 
align 64 offset_align 64
offset 
bit offset  context 
 arguments > 
context >
side-effects
arg 0 

arg 0 
used BLK file ../pr20607.c line 31 size  unit size 
align 64 context 
(mem/s:BLK (plus:SI (reg/f:SI 103 virtual-stack-vars)
(const_int -16 [0xfff0])) [8 conv+0 S8 A64])>
arg 1 
DI file ../pr20607.c line 28 size  
unit size 
align 64 offset_align 64 offset  bit 
offset  context  
arguments  chain >>
arg 1 
used DI file ../pr20607.c line 23 size  
unit size 
align 64 context 
(reg/v:DI 107 [ arg1 ])
chain 
used BLK file ../pr20607.c line 24 size  unit size 
align 64 context 
(mem/s:BLK (plus:SI (reg/f:SI 103 virtual-stack-vars)
(const_int -8 [0xfff8])) [2 result+0 S8 A64])>>>

and with the C++ compiler:

 
unit size 
align 64 symtab 0 alias set 2
fields 
used nonlocal decl_3 DI file ../pr20607.C line 17 size 
 unit size 
align 64 offset_align 64
offset 
bit offset  context 
 arguments  
chain >
X() X(constX&) this=(X&) n_parents 0 use_template=0 interface-unknown
member-functions 
elt 2 
elt 3 
elt 4 >
pointer_to_this  reference_to_this 
 chain >
side-effects
arg 0 

arg 0 

arg 0 

arg 0 

arg 0 

arg 0 
arg 0 >>
arg 1  unit size 
align 64 symtab 0 alias set -1 fields 
X() X(constX&) this=(X&) n_parents 0 use_template=0 
interface-unknown member-functions 
pointer_to_this  reference_to_this 
>
readonly
arg 0 

arg 0 

arg 0 
arg 0 >


Type punning needs a COMPONENT_REF to work (see c_common_get_alias_set).



-- 


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

[Bug c++/20700] x86_64 code bloat on templates

[ms6ep at cs dot virginia dot edu]

--- Additional Comments From ms6ep at cs dot virginia dot edu  2005-03-31 
05:09 ---
Hmm, I am sorry.  I just made some changes to the code, and I got the bloat to
go away.  And now I can't reproduce the version that produces the code bloat.

-- 


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

[Bug c/20689] strict aliasing with temporary variable never gives warnings

[varun0005 at gmail dot com]

--- Additional Comments From varun0005 at gmail dot com  2005-03-31 05:05 
---
please ignore previous code and consider this piece as example ... problem is
same .the exact programs are following and command line was gcc -Wall -O2
test1.c test2.cIn this why test1.c not giving warning but test2.c giving
violation of strict-aliasing warning.
//test1.c
#include 
#include 
int main()
{ int *i;
float **q;
int **r;
i =(int *)malloc(sizeof(int));
r=&i;
q=(float **)r;
return 0;
}
//test2.c
int main(){
int *i;
float **q; 
i =(int *)malloc(sizeof(int));
q= (float **) &i;
return 0;
}

-- 


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

[Bug c++/20700] x86_64 code bloat on templates

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-31 
04:59 ---
Can you provide the preprocessed source?

-- 
   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |WAITING


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

[Bug c++/20700] New: x86_64 code bloat on templates

[ms6ep at cs dot virginia dot edu]

I've got a small piece of C++ code that makes extensive use of templates.  To my
surprize it compiles to en executable of about 20 MBytes on x86_64 architecture.
 When I compiled it on an x86 machine the executable is about 6 Kbytes.  Is code
bloat of this magnitude normal?

The code I'm trying to compile is basically a cut and paste of this:
http://www.boost.org/libs/mpl/doc/tutorial/representing-dimensions.html

-- 
   Summary: x86_64 code bloat on templates
   Product: gcc
   Version: 3.4.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ms6ep at cs dot virginia dot edu
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug libstdc++/20694] [4.1 Regression] make install failure building abi_check with leftover libv3test

[bkoz at gcc dot gnu dot org]

--- Additional Comments From bkoz at gcc dot gnu dot org  2005-03-31 02:35 
---
>I would like to solve this problem by moving the compilation and 
>execution of abi_check.cc into DejaGNU, and check having "make 
>abi_check" invoke DejaGNU appropriate to run just that test.

No, assuming "make check-abi" runs the test. (Assuming typo.)

-benjamin

-- 


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

[Bug java/20697] Invalid Can't find method error on call to super

[daney at gcc dot gnu dot org]

--- Additional Comments From daney at gcc dot gnu dot org  2005-03-30 23:44 
---
Created an attachment (id=8501)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8501&action=view)
Testcase part3


-- 


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

[Bug java/20697] Invalid Can't find method error on call to super

[daney at gcc dot gnu dot org]

--- Additional Comments From daney at gcc dot gnu dot org  2005-03-30 23:43 
---
Created an attachment (id=8500)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8500&action=view)
Testcase part2


-- 


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

[Bug java/20697] Invalid Can't find method error on call to super

[daney at gcc dot gnu dot org]

--- Additional Comments From daney at gcc dot gnu dot org  2005-03-30 23:43 
---
Created an attachment (id=8499)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8499&action=view)
Testcase part1


-- 


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

[Bug tree-optimization/20605] [4.1 Regression] gcc.dg/tree-ssa/loop-4.c scan-tree-dump-times iter 0 fails

[danglin at gcc dot gnu dot org]

-- 
   What|Removed |Added

 CC||danglin at gcc dot gnu dot
   ||org


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

[Bug java/20697] New: Invalid Can't find method error on call to super

[daney at gcc dot gnu dot org]

When the testcase is compiled like this:

$ gcj -o A --main=C A.java B.java C.java
C.java: In class `C':
C.java: In method `C.m()':
C.java:5: error: Can't find method `m()' in type `B'. Candidates are:
  `B.m()' in `B'
  `A$A1.m()' in `A$A1'.
   super.m();
 ^
1 error

We get the error shown above.  However with Sun's javac:
$ javac -g A.java B.java C.java

No errors are obtained.

I will attach the three files A.java B.java and C.java

-- 
   Summary: Invalid Can't find method error on call to super
   Product: gcc
   Version: 3.4.3
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P2
 Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: daney at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu
dot org
 GCC build triplet: i386-redhat-linux
  GCC host triplet: i386-redhat-linux
GCC target triplet: i386-redhat-linux


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

[Bug libstdc++/20694] [4.1 Regression] make install failure building abi_check with leftover libv3test

[mark at codesourcery dot com]

--- Additional Comments From mark at codesourcery dot com  2005-03-30 23:41 
---
Subject: Re:  [4.1 Regression] make install failure building
 abi_check with leftover libv3test

janis at gcc dot gnu dot org wrote:
> --- Additional Comments From janis at gcc dot gnu dot org  2005-03-30 
> 23:33 ---
> Aha!  The failures occur with "make bootstrap" followed by "make check"
> followed by "make install"; without "make check" in between the install
> works fine.

Good!  That's what I expected.  I'll now be able to fix it, I'm sure.



-- 


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

[Bug bootstrap/20698] New: [4.0 Regression] configure broken

[danglin at gcc dot gnu dot org]

The file "compile" lacks execute permissions, or it needs to be executed
using the shell.  This causes various compilations used in header checks
by configure to fail.

-- 
   Summary: [4.0 Regression] configure broken
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: danglin at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: vax-dec-ultrix4.3
  GCC host triplet: vax-dec-ultrix4.3
GCC target triplet: vax-dec-ultrix4.3


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

[Bug libstdc++/20694] [4.1 Regression] make install failure building abi_check with leftover libv3test

[janis at gcc dot gnu dot org]

--- Additional Comments From janis at gcc dot gnu dot org  2005-03-30 23:33 
---
Aha!  The failures occur with "make bootstrap" followed by "make check"
followed by "make install"; without "make check" in between the install
works fine.

-- 


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

[Bug java/20697] Invalid Can't find method error on call to super

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

OtherBugsDependingO||18131
  nThis||


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

[Bug debug/20268] With optimization, generating incomplete debug information

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Target Milestone|--- |4.1.0


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

[Bug target/19139] data referenced as short misplaced in non-short linkonce section

[sje at cup dot hp dot com]

--- Additional Comments From sje at cup dot hp dot com  2005-03-30 23:26 
---
I think this defect is fixed with the patch:

http://gcc.gnu.org/ml/gcc/2005-01/msg00589.html

that was checked in back in January of 2005.

Jan, can you confirm that the defect is fixed?  It looks OK to me on a small
test case I created but since I don't have a specific included test case to
check I would like you to confirm that this is fixed and the defect can be 
closed.

-- 
   What|Removed |Added

 CC||sje at gcc dot gnu dot org
 Status|UNCONFIRMED |WAITING


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

[Bug libmudflap/20696] New: all libmudflap tests fail on mips{,el}-linux

[debian-gcc at lists dot debian dot org]

all libmudflap tests fail on mips{,el}-linux.

/home/doko/gcc/gcc-4.0-4.0ds9/build/mipsel-linux/./libmudflap/.libs/libmudflap.so:
undefined reference to `_start'
collect2: ld returned 1 exit status
compiler exited with status 1
output is:
/home/doko/gcc/gcc-4.0-4.0ds9/build/mipsel-linux/./libmudflap/.libs/libmudflap.so:
undefined reference to `_start'
collect2: ld returned 1 exit status

or these architectures, the symbol should be __start, not _start, suggested by
Thimo Seufer (one of our mipsel porters) ?

-- 
   Summary: all libmudflap tests fail on mips{,el}-linux
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: libmudflap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: debian-gcc at lists dot debian dot org
CC: gcc-bugs at gcc dot gnu dot org
  GCC host triplet: mipsel-linux


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

[Bug java/20697] Invalid Can't find method error on call to super

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-31 
00:24 ---
Confirmed, I think this is a dup of bug 18119.

-- 
   What|Removed |Added

  BugsThisDependsOn||18119
 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-03-31 00:24:37
   date||


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

[Bug debug/20268] With optimization, generating incomplete debug information

[wilson at gcc dot gnu dot org]

--- Additional Comments From wilson at gcc dot gnu dot org  2005-03-30 
23:18 ---
Fixed.

-- 
   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug libstdc++/20694] [4.1 Regression] make install failure building abi_check with leftover libv3test

[mark at codesourcery dot com]

--- Additional Comments From mark at codesourcery dot com  2005-03-31 00:10 
---
Subject: Re:  New: make install failure building abi_check
 with leftover libv3test

janis at gcc dot gnu dot org wrote:
> Nightly mainline bootstraps for powerpc64-linux have been failing
> intermittently since changes went in last week to allow running
> libstc++ tests on installed tools. 

I would like to solve this problem by moving the compilation and 
execution of abi_check.cc into DejaGNU, and check having "make 
abi_check" invoke DejaGNU appropriate to run just that test.

Benjamin, any objections to that plan?



-- 


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

[Bug bootstrap/20698] [4.0 Regression] configure broken

[dave at hiauly1 dot hia dot nrc dot ca]

--- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca  
2005-03-31 00:59 ---
Subject: Re:  [4.0 Regression] configure broken

> --- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-31 
> 00:37 ---
> hmm, what compiler are you using which don't understand -c -o?

The ultrix cc (pcc) doesn't understand -c -o.  I'm using gcc for the
build but:

checking whether gcc and cc understand -c and -o together... no

I'm not sure why the test checks both.

Dave


-- 


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

[Bug c++/20607] [3.4 Regression] -fstrict-aliasing causes incorrect scheduling

[mark at codesourcery dot com]

--- Additional Comments From mark at codesourcery dot com  2005-03-31 00:54 
---
Subject: Re:  [3.4 Regression] -fstrict-aliasing causes incorrect
 scheduling

ebotcazou at gcc dot gnu dot org wrote:
> --- Additional Comments From ebotcazou at gcc dot gnu dot org  2005-03-30 
> 10:53 ---
> Hum... type-punning simply doesn't work in this case with the C++ compiler, 
> but
> does work with the C compiler.  The problem is that:
> 
>   union u {
>   x_uint64_t first;
>   x_uint32_t second;
>   };
>   union u conv;
>   conv.first = arg1;
>   result = conv.second;
> 
> is translated into:
> 
>   *(&conv.first) = *(&arg1);
>   *(&result) = *(&conv.second);
> 
> and type-punning cannot work in this case (that's the counter-example provided
> in the manual).  I guess the problem comes the fields being of aggregate 
> types.
> 
> Mark, is that fixable or should we document the limitation?

I think it's fixable.  I'm not sure exactly why the C++ front-end is 
inserting the additional operations, but they're certainly not essential 
from a C++ semantics point of view.  Please reassign the bug to me; I'll 
try to take a look.

Thanks,



-- 


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

[Bug debug/20268] With optimization, generating incomplete debug information

[wilson at gcc dot gnu dot org]

-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |wilson at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-03-30 23:08:11
   date||


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

[Bug debug/20268] With optimization, generating incomplete debug information

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-03-30 
23:08 ---
Subject: Bug 20268

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-03-30 23:08:23

Modified files:
gcc: ChangeLog dwarf2out.c 

Log message:
Emit DW_AT_ranges for inlined subroutines that contain disjoint blocks.
PR debug/20268
* dwarf2out.c (add_high_low_attributes): New function, extracted from
gen_lexical_block_die.
(gen_lexical_block_die, gen_inlined_subroutine_die): Call it.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.8043&r2=2.8044
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/dwarf2out.c.diff?cvsroot=gcc&r1=1.575&r2=1.576



-- 


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

[Bug c/17855] [4.0/4.1 Regression] modification of function struct return not diagnosed

[jsm28 at gcc dot gnu dot org]

--- Additional Comments From jsm28 at gcc dot gnu dot org  2005-03-30 23:07 
---
Patch posted , awaiting
review.


-- 


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

[Bug java/20697] Invalid Can't find method error on call to super

[daney at gcc dot gnu dot org]

--- Additional Comments From daney at gcc dot gnu dot org  2005-03-30 23:58 
---
Created an attachment (id=8503)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8503&action=view)
Second part of smaller testcase.

New Testcase.  I think it is the same problem.

$ gcj A1.java B1.java
B1.java: In class `B1':
B1.java: In method `B1.n()':
B1.java:10: error: Can't find method `m()' in type `B1'. Candidates are:
  `B1.m()' in `B1'
  `A1$A2.m()' in `A1$A2'.
   m();
   ^
1 error


-- 


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

[Bug java/20697] Invalid Can't find method error on call to super

[daney at gcc dot gnu dot org]

--- Additional Comments From daney at gcc dot gnu dot org  2005-03-30 23:56 
---
Created an attachment (id=8502)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8502&action=view)
First part of smaller testcase.


-- 


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

[Bug java/20697] Invalid Can't find method error on call to super

[daney at gcc dot gnu dot org]

--- Additional Comments From daney at gcc dot gnu dot org  2005-03-30 23:55 
---
If you modify the testcase file A.java so that the inner class A1 is no longer
static, the testcase converts to an ice-on-invalid-code.

-- 


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

[Bug bootstrap/20698] [4.0 Regression] configure broken

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-31 
00:37 ---
hmm, what compiler are you using which don't understand -c -o?

-- 


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

[Bug java/20697] Invalid Can't find method error on call to super

[daney at gcc dot gnu dot org]

--- Additional Comments From daney at gcc dot gnu dot org  2005-03-30 23:45 
---
I should add that I think this is a target independent bug as it also fails for
a mipsel-linux target.

-- 
   What|Removed |Added

  Known to fail||3.4.3 4.0.0


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

[Bug target/16871] missing vector support

[wilson at specifixinc dot com]

--- Additional Comments From wilson at specifixinc dot com  2005-03-30 
22:49 ---
Subject: Re:  missing vector support

steven at gcc dot gnu dot org wrote:
> --- Additional Comments From steven at gcc dot gnu dot org  2005-03-30 
> 11:21 ---
> Is anyone going to work on these intrinsics?  Is there a list somewhere
> of what intrinsics we are talking about here?

See comment #1, which points at patch written by HJ, which needs some 
more work, and probably also a formal review.

As far as I know, the intrinsics are only defined in the Intel compiler 
documentation.  That is the list HJ is working from.  As I understand 
it, there is an intrinsic defined for every IA-64 instruction.  Thus any 
gcc extended asm can be converted into intrinsic calls.  If you know the 
naming scheme, you can probably generate your own list from IA-64 
architecture documentation.

There was also two threads in the gcc list started by Jan Beulich here
 http://gcc.gnu.org/ml/gcc/2005-01/msg00204.html
 http://gcc.gnu.org/ml/gcc/2005-01/msg00276.html
I don't think he was volunteering to do the work, but he did point out 
some issues that need to be considered, such as how vectors should be 
treated as arguments and parameters.


-- 


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

[Bug libstdc++/20694] [4.1 Regression] make install failure building abi_check with leftover libv3test

[mark at codesourcery dot com]

--- Additional Comments From mark at codesourcery dot com  2005-03-30 22:45 
---
Subject: Re:  New: make install failure building abi_check
 with leftover libv3test

janis at gcc dot gnu dot org wrote:
> Nightly mainline bootstraps for powerpc64-linux have been failing
> intermittently since changes went in last week to allow running
> libstc++ tests on installed tools.  For "make bootstrap", abi_check
> is built three times: for 32-bit bit, 64-bit, and 32-bit soft-float.
> "make install" tries to build it again, but a 32-bit build of
> abi_float tries to use the existing libv3test, and the link fails if
> the type of the leftover library (e.g. 64-bit) doesn't match the type
> of the new abi_check.  All of the abi_check builds appear to be done
> in the same directory.

Janis, am I correct in assuming that you're running "make check" between 
"make bootstrap" and "make install"?  If so, I think I understand what's 
happenning, and I can work on fixing it.  Otherwise, I've got to dig a 
little deeper.

Thanks,



-- 


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

[Bug c++/20629] internal compiler error: in cp_tree_equal, at cp/tree.c:1552

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-30 
21:42 ---
(In reply to comment #4)
> I'm still seeing this, but some info...
> a) I'm only seeing this with LANG=C, export LANG=en_US.UTF-8 and there is no 
> crash
> b) compiling the dumped proprocessed code isn't crashing in either LANG

Hmm, that usually means some memory corruption somewhere in GCC or a 
miscompiling of GCC.
Does this happen with a build of GCC with BOOT_CFLAGS="-O0 -g"?

-- 
   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org
   Keywords||ice-on-valid-code


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

[Bug libgcj/20654] exception.o is not included in libgcj.a due to case-insensitivity

[aaronavay62 at aaronwl dot com]

--- Additional Comments From aaronavay62 at aaronwl dot com  2005-03-30 
21:10 ---
Patch here: .


-- 
   What|Removed |Added

   Keywords||patch
   Last reconfirmed|2005-03-28 12:42:10 |2005-03-30 21:10:28
   date||


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

[Bug middle-end/19225] [3.4/4.0/4.1 regression] g++.dg/eh/omit-frame-pointer2.C fails with -fpic/-fPIC on i686-pc-linux-gnu

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Target Milestone|3.4.4   |4.1.0


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

Re: gcc rs6000 target without glibc

[Andrew Pinski]

On Mar 30, 2005, at 3:22 PM, lothar wrote:
Hello,
Michael Meissner redirected me to this list, I contacted him because 
his emailaddress was in rs6000/linux.h. I don't know who currently 
maintains this file

I ran into trouble when trying to build a cross compiler for the 
RS6000 (target=ppc-linux).

Try using cross tools, they help a lot with building a cross compiler 
for
powerpc-linux-gnu (and other linux-gnu targets).

-- Pinski

[Bug middle-end/19225] [3.4/4.0/4.1 regression] g++.dg/eh/omit-frame-pointer2.C fails with -fpic/-fPIC on i686-pc-linux-gnu

[dalej at gcc dot gnu dot org]

--- Additional Comments From dalej at gcc dot gnu dot org  2005-03-30 20:27 
---
Fixed (4.1 only)


-- 
   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug libgcj/20693] javax-imageio.lo failed to build

[hjl at lucon dot org]

--- Additional Comments From hjl at lucon dot org  2005-03-30 20:26 ---
A patch is posted at

http://gcc.gnu.org/ml/gcc-patches/2005-03/msg02792.html

-- 
   What|Removed |Added

 Status|WAITING |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-03-30 20:26:24
   date||


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

gcc rs6000 target without glibc

[lothar]

Hello,
Michael Meissner redirected me to this list, I contacted him because his 
emailaddress was in rs6000/linux.h. I don't know who currently maintains 
this file

I ran into trouble when trying to build a cross compiler for the RS6000 
(target=ppc-linux).

In gcc-3.4.0/gcc/config/rs6000/linux.h there is in line 100:
[--code--]
#include 
/* During the 2.5 kernel series the kernel ucontext was changed, but
the new layout is compatible with the old one, so we just define
and use the old one here for simplicity and compatibility.  */
struct kernel_old_ucontext {
unsigned long uc_flags;
struct ucontext  *uc_link;
stack_t   uc_stack;
struct sigcontext_struct uc_mcontext;
sigset_t  uc_sigmask;
};
[--code--]
since there are several signal.h files (glibc, linux-headers) I tried to 
figure out wichone was needed, I tried to use asm/signal.h which, after 
a few changes to rs6000/linux.h is ok. It shouldn't be any signal.h from 
the glibc, because I configured with the option --without-headers. 
size_t wasn't defined (no glibc), so I added this on too. Maybe this 
should be defined somewhere else...

How I configured:
../gcc-3.4.0/configure --prefix=/home/cross/workspace/cross/out/ 
--target=ppc-linux --enable-languages=c  --disable-nls --disable-shared 
--disable-threads --without-headers --with-newlib

How my rs6000/linux.h looks now:
[--code--]
#ifdef IN_LIBGCC2
#include  /*defines size_t for asm/signal.h*/
#include 
#include  /*defines struct siginfo */
#ifndef sigcontext_struct
/* Kernel headers before 2.1.1 define a struct sigcontext_struct, but
*we need sigcontext.  */
# define sigcontext_struct sigcontext
#include 
#endif
#include 
/* During the 2.5 kernel series the kernel ucontext was changed, but
the new layout is compatible with the old one, so we just define
and use the old one here for simplicity and compatibility.  */
struct kernel_old_ucontext {
unsigned long uc_flags;
struct ucontext*  uc_link;
stack_t   uc_stack;
struct sigcontext_struct uc_mcontext;
sigset_t  uc_sigmask;
};
[--code--]
Maybe someone can take a look at it, I don't know too much about gcc.
Lothar

[Bug middle-end/19225] [3.4/4.0/4.1 regression] g++.dg/eh/omit-frame-pointer2.C fails with -fpic/-fPIC on i686-pc-linux-gnu

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-03-30 
20:21 ---
Subject: Bug 19225

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-03-30 20:21:39

Modified files:
gcc: ChangeLog calls.c 

Log message:
2005-03-30  Dale Johannesen  <[EMAIL PROTECTED]>

PR middle-end/19225
* calls.c (expand_call):  Flush pending deferrals before
throwing call.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.8037&r2=2.8038
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/calls.c.diff?cvsroot=gcc&r1=1.384&r2=1.385



-- 


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

[Bug target/20670] IA-64 exception mechanism erase $f29

[ochem at gnat dot com]

--- Additional Comments From ochem at gnat dot com  2005-03-30 20:13 ---
The test case is ok, I get an abort if I compile it with -O2 option on a 3.4 
compiler. 

-- 


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

[Bug libgcj/20693] javax-imageio.lo failed to build

[hjl at lucon dot org]

--- Additional Comments From hjl at lucon dot org  2005-03-30 20:06 ---
It is a libtool bug, which depends on the order of the output from
"find -name '*.class" -print". On my Linux/i686:

[EMAIL PROTECTED] libjava]$ pwd
/export/build/gnu/gcc/build-i686-linux/i686-pc-linux-gnu/libjava
[EMAIL PROTECTED] libjava]$ find javax/imageio -name '*.class' -print
...
javax/imageio/spi/ServiceRegistry$1.class
[EMAIL PROTECTED] libjava]$

On my Linux/ia64:
[EMAIL PROTECTED] libjava]$ pwd
/export/build/gnu/gcc/build-ia64-linux/ia64-unknown-linux-gnu/libjava
[EMAIL PROTECTED] libjava]$ find javax/imageio -name '*.class' -print
...
javax/imageio/ImageIO$ReaderFormatFilter.class
[EMAIL PROTECTED] libjava]$

On my Linux/x86_64:

[EMAIL PROTECTED] libjava]$ pwd
/export/build/gnu/gcc/build-x86_64-linux/x86_64-unknown-linux-gnu/libjava
[EMAIL PROTECTED] libjava]$ find javax/imageio -name '*.class' -print
...
javax/imageio/ImageIO$ReaderFormatFilter.class
[EMAIL PROTECTED] libjava]$

For some reason, libtool failed to add a `/' before `$' for the last
one on the list.

-- 


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

[Bug c/17913] [4.0/4.1 Regression] ICE jumping into statement expression

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-03-30 
19:59 ---
Subject: Bug 17913

CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED]   2005-03-30 19:59:21

Modified files:
gcc: ChangeLog c-decl.c c-tree.h c-typeck.c 
gcc/doc: extend.texi 
gcc/objc   : ChangeLog objc-act.c 
gcc/testsuite  : ChangeLog 
Added files:
gcc/testsuite/gcc.dg: stmt-expr-label-1.c stmt-expr-label-2.c 
  stmt-expr-label-3.c 
Removed files:
gcc/testsuite/gcc.c-torture/execute: medce-2.c 

Log message:
PR c/772
PR c/17913
* c-tree.h (C_DECL_UNJUMPABLE_STMT_EXPR,
C_DECL_UNDEFINABLE_STMT_EXPR, struct c_label_list, struct
c_label_context, label_context_stack): New.
* c-decl.c (define_label): Check for jumps into statement
expressions.  Add label to list of defined labels.
(start_function): Push context on label_context_stack.
(finish_function): Pop context from label_context_stack.
* c-typeck.c (label_context_stack): New.
(c_finish_goto_label): Check for jumps into statement
expressions.  Add label to list of jumped to labels.
(struct c_switch): Add blocked_stmt_expr.
(c_start_case): Initialize it.
(do_case): Check it.
(c_finish_case): Verify !blocked_stmt_expr.
(c_begin_stmt_expr):  Push context on label_context_stack.
Increment blocked_stmt_expr.  Mark labels jumped to from outside
as undefinable.
(c_finish_stmt_expr): December blocked_stmt_expr.  Mark labels
defined in the statement expression and no longer jumpable to.
Mark labels jumped to from just outside the statement expression
as again definable.  Pop context from label_context_stack.
* doc/extend.texi (Statement Exprs): Update.

objc:
* objc-act.c (objc_start_function): Push context on
label_context_stack.

testsuite:
* gcc.dg/stmt-expr-label-1.c, gcc.dg/stmt-expr-label-2.c,
gcc.dg/stmt-expr-label-3.c : New tests.
* gcc.c-torture/execute/medce-2.c: Remove.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=2.7592.2.97&r2=2.7592.2.98
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-decl.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.630.6.3&r2=1.630.6.4
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-tree.h.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.193.4.1&r2=1.193.4.2
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-typeck.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.419&r2=1.419.2.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/doc/extend.texi.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.240.2.5&r2=1.240.2.6
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/objc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.29&r2=1.29.8.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/objc/objc-act.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.266&r2=1.266.6.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.5084.2.80&r2=1.5084.2.81
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/execute/medce-2.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.1&r2=NONE
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/stmt-expr-label-1.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.2.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/stmt-expr-label-2.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.2.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/stmt-expr-label-3.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.2.1



-- 


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

[Bug c/772] Statement expressions issues

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-03-30 
19:59 ---
Subject: Bug 772

CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED]   2005-03-30 19:59:21

Modified files:
gcc: ChangeLog c-decl.c c-tree.h c-typeck.c 
gcc/doc: extend.texi 
gcc/objc   : ChangeLog objc-act.c 
gcc/testsuite  : ChangeLog 
Added files:
gcc/testsuite/gcc.dg: stmt-expr-label-1.c stmt-expr-label-2.c 
  stmt-expr-label-3.c 
Removed files:
gcc/testsuite/gcc.c-torture/execute: medce-2.c 

Log message:
PR c/772
PR c/17913
* c-tree.h (C_DECL_UNJUMPABLE_STMT_EXPR,
C_DECL_UNDEFINABLE_STMT_EXPR, struct c_label_list, struct
c_label_context, label_context_stack): New.
* c-decl.c (define_label): Check for jumps into statement
expressions.  Add label to list of defined labels.
(start_function): Push context on label_context_stack.
(finish_function): Pop context from label_context_stack.
* c-typeck.c (label_context_stack): New.
(c_finish_goto_label): Check for jumps into statement
expressions.  Add label to list of jumped to labels.
(struct c_switch): Add blocked_stmt_expr.
(c_start_case): Initialize it.
(do_case): Check it.
(c_finish_case): Verify !blocked_stmt_expr.
(c_begin_stmt_expr):  Push context on label_context_stack.
Increment blocked_stmt_expr.  Mark labels jumped to from outside
as undefinable.
(c_finish_stmt_expr): December blocked_stmt_expr.  Mark labels
defined in the statement expression and no longer jumpable to.
Mark labels jumped to from just outside the statement expression
as again definable.  Pop context from label_context_stack.
* doc/extend.texi (Statement Exprs): Update.

objc:
* objc-act.c (objc_start_function): Push context on
label_context_stack.

testsuite:
* gcc.dg/stmt-expr-label-1.c, gcc.dg/stmt-expr-label-2.c,
gcc.dg/stmt-expr-label-3.c : New tests.
* gcc.c-torture/execute/medce-2.c: Remove.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=2.7592.2.97&r2=2.7592.2.98
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-decl.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.630.6.3&r2=1.630.6.4
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-tree.h.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.193.4.1&r2=1.193.4.2
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-typeck.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.419&r2=1.419.2.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/doc/extend.texi.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.240.2.5&r2=1.240.2.6
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/objc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.29&r2=1.29.8.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/objc/objc-act.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.266&r2=1.266.6.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.5084.2.80&r2=1.5084.2.81
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/execute/medce-2.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.1&r2=NONE
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/stmt-expr-label-1.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.2.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/stmt-expr-label-2.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.2.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/stmt-expr-label-3.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.2.1



-- 


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

[Bug c/17913] [4.0/4.1 Regression] ICE jumping into statement expression

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-03-30 
19:56 ---
Subject: Bug 17913

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-03-30 19:56:40

Modified files:
gcc: ChangeLog c-decl.c c-tree.h c-typeck.c 
gcc/doc: extend.texi 
gcc/objc   : ChangeLog objc-act.c 
gcc/testsuite  : ChangeLog 
Added files:
gcc/testsuite/gcc.dg: stmt-expr-label-1.c stmt-expr-label-2.c 
  stmt-expr-label-3.c 
Removed files:
gcc/testsuite/gcc.c-torture/execute: medce-2.c 

Log message:
PR c/772
PR c/17913
* c-tree.h (C_DECL_UNJUMPABLE_STMT_EXPR,
C_DECL_UNDEFINABLE_STMT_EXPR, struct c_label_list, struct
c_label_context, label_context_stack): New.
* c-decl.c (define_label): Check for jumps into statement
expressions.  Add label to list of defined labels.
(start_function): Push context on label_context_stack.
(finish_function): Pop context from label_context_stack.
* c-typeck.c (label_context_stack): New.
(c_finish_goto_label): Check for jumps into statement
expressions.  Add label to list of jumped to labels.
(struct c_switch): Add blocked_stmt_expr.
(c_start_case): Initialize it.
(do_case): Check it.
(c_finish_case): Verify !blocked_stmt_expr.
(c_begin_stmt_expr):  Push context on label_context_stack.
Increment blocked_stmt_expr.  Mark labels jumped to from outside
as undefinable.
(c_finish_stmt_expr): December blocked_stmt_expr.  Mark labels
defined in the statement expression and no longer jumpable to.
Mark labels jumped to from just outside the statement expression
as again definable.  Pop context from label_context_stack.
* doc/extend.texi (Statement Exprs): Update.

objc:
* objc-act.c (objc_start_function): Push context on
label_context_stack.

testsuite:
* gcc.dg/stmt-expr-label-1.c, gcc.dg/stmt-expr-label-2.c,
gcc.dg/stmt-expr-label-3.c : New tests.
* gcc.c-torture/execute/medce-2.c: Remove.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.8036&r2=2.8037
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-decl.c.diff?cvsroot=gcc&r1=1.642&r2=1.643
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-tree.h.diff?cvsroot=gcc&r1=1.198&r2=1.199
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-typeck.c.diff?cvsroot=gcc&r1=1.428&r2=1.429
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/doc/extend.texi.diff?cvsroot=gcc&r1=1.246&r2=1.247
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/objc/ChangeLog.diff?cvsroot=gcc&r1=1.31&r2=1.32
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/objc/objc-act.c.diff?cvsroot=gcc&r1=1.267&r2=1.268
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5237&r2=1.5238
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/execute/medce-2.c.diff?cvsroot=gcc&r1=1.1&r2=NONE
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/stmt-expr-label-1.c.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/stmt-expr-label-2.c.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/stmt-expr-label-3.c.diff?cvsroot=gcc&r1=NONE&r2=1.1



-- 


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

[Bug c/772] Statement expressions issues

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-03-30 
19:56 ---
Subject: Bug 772

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-03-30 19:56:40

Modified files:
gcc: ChangeLog c-decl.c c-tree.h c-typeck.c 
gcc/doc: extend.texi 
gcc/objc   : ChangeLog objc-act.c 
gcc/testsuite  : ChangeLog 
Added files:
gcc/testsuite/gcc.dg: stmt-expr-label-1.c stmt-expr-label-2.c 
  stmt-expr-label-3.c 
Removed files:
gcc/testsuite/gcc.c-torture/execute: medce-2.c 

Log message:
PR c/772
PR c/17913
* c-tree.h (C_DECL_UNJUMPABLE_STMT_EXPR,
C_DECL_UNDEFINABLE_STMT_EXPR, struct c_label_list, struct
c_label_context, label_context_stack): New.
* c-decl.c (define_label): Check for jumps into statement
expressions.  Add label to list of defined labels.
(start_function): Push context on label_context_stack.
(finish_function): Pop context from label_context_stack.
* c-typeck.c (label_context_stack): New.
(c_finish_goto_label): Check for jumps into statement
expressions.  Add label to list of jumped to labels.
(struct c_switch): Add blocked_stmt_expr.
(c_start_case): Initialize it.
(do_case): Check it.
(c_finish_case): Verify !blocked_stmt_expr.
(c_begin_stmt_expr):  Push context on label_context_stack.
Increment blocked_stmt_expr.  Mark labels jumped to from outside
as undefinable.
(c_finish_stmt_expr): December blocked_stmt_expr.  Mark labels
defined in the statement expression and no longer jumpable to.
Mark labels jumped to from just outside the statement expression
as again definable.  Pop context from label_context_stack.
* doc/extend.texi (Statement Exprs): Update.

objc:
* objc-act.c (objc_start_function): Push context on
label_context_stack.

testsuite:
* gcc.dg/stmt-expr-label-1.c, gcc.dg/stmt-expr-label-2.c,
gcc.dg/stmt-expr-label-3.c : New tests.
* gcc.c-torture/execute/medce-2.c: Remove.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.8036&r2=2.8037
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-decl.c.diff?cvsroot=gcc&r1=1.642&r2=1.643
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-tree.h.diff?cvsroot=gcc&r1=1.198&r2=1.199
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-typeck.c.diff?cvsroot=gcc&r1=1.428&r2=1.429
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/doc/extend.texi.diff?cvsroot=gcc&r1=1.246&r2=1.247
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/objc/ChangeLog.diff?cvsroot=gcc&r1=1.31&r2=1.32
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/objc/objc-act.c.diff?cvsroot=gcc&r1=1.267&r2=1.268
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5237&r2=1.5238
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/execute/medce-2.c.diff?cvsroot=gcc&r1=1.1&r2=NONE
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/stmt-expr-label-1.c.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/stmt-expr-label-2.c.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/stmt-expr-label-3.c.diff?cvsroot=gcc&r1=NONE&r2=1.1



-- 


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

[Bug rtl-optimization/20376] The missed-optimization of general induction variables in the new rtl-level loop optimizer cause performance degradation.

[steven at gcc dot gnu dot org]

-- 
   What|Removed |Added

 Status|WAITING |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-03-30 19:54:01
   date||


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

[Bug libstdc++/20694] [4.1 Regression] make install failure building abi_check with leftover libv3test

[bkoz at redhat dot com]

--- Additional Comments From bkoz at redhat dot com  2005-03-30 19:48 
---
Subject: Re:  New: make install failure building
 abi_check with leftover libv3test


> (I didn't actually change this particularly thing; it was probably 
> getting built at make install time all along.  But, my changes are 
> causing the make install rebuild not to work.)

Roger wilco. I did not mean to imply anything else.

-benjamin


-- 


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

[Bug c/20368] [4.0/4.1 Regression] internal compiler error: tree check: expected function_type or method_type, have integer_type in start_function, at c-decl.c:5777

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-03-30 
19:39 ---
Subject: Bug 20368

CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED]   2005-03-30 19:39:35

Modified files:
gcc: ChangeLog c-decl.c 
gcc/testsuite  : ChangeLog 
Added files:
gcc/testsuite/gcc.dg: pr20368-1.c pr20368-2.c pr20368-3.c 

Log message:
PR c/20368
* c-decl.c (start_function): Check for old_decl being
error_mark_node.

testsuite:
* gcc.dg/pr20368-1.c, gcc.dg/pr20368-2.c, gcc.dg/pr20368-3.c: New
tests.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=2.7592.2.96&r2=2.7592.2.97
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-decl.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.630.6.2&r2=1.630.6.3
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.5084.2.79&r2=1.5084.2.80
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/pr20368-1.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.2.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/pr20368-2.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.2.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/pr20368-3.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.2.1



-- 


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

[Bug c/20368] [4.0/4.1 Regression] internal compiler error: tree check: expected function_type or method_type, have integer_type in start_function, at c-decl.c:5777

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-03-30 
19:35 ---
Subject: Bug 20368

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-03-30 19:35:49

Modified files:
gcc: ChangeLog c-decl.c 
gcc/testsuite  : ChangeLog 
Added files:
gcc/testsuite/gcc.dg: pr20368-1.c pr20368-2.c pr20368-3.c 

Log message:
PR c/20368
* c-decl.c (start_function): Check for old_decl being
error_mark_node.

testsuite:
* gcc.dg/pr20368-1.c, gcc.dg/pr20368-2.c, gcc.dg/pr20368-3.c: New
tests.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.8035&r2=2.8036
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-decl.c.diff?cvsroot=gcc&r1=1.641&r2=1.642
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5236&r2=1.5237
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/pr20368-1.c.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/pr20368-2.c.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/pr20368-3.c.diff?cvsroot=gcc&r1=NONE&r2=1.1



-- 


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

[Bug middle-end/20491] [4.0/4.1 Regression] internal compiler error: in subreg_regno_offset, at rtlanal.c:3042

[aoliva at redhat dot com]

--- Additional Comments From aoliva at gcc dot gnu dot org  2005-03-30 
19:28 ---
Subject: Re: [PR middle-end/20491] combine generates bad subregs

On Mar 29, 2005, Alexandre Oliva <[EMAIL PROTECTED]> wrote:

> On Mar 28, 2005, Richard Henderson <[EMAIL PROTECTED]> wrote:
>> On Thu, Mar 24, 2005 at 07:45:44AM -0300, Alexandre Oliva wrote:
>>> * combine.c (subst): Make sure we don't create invalid subregs.

>> Ok.

> As it turned out, the bug seems to have been fixed by some other
> patch, because I no longer get the error in mainline or in the 4.0
> branch.

Or perhaps it never actually failed on x86_64-linux-gnu, which is
where I was trying to trigger it again.  Not even with -m32.  A build
on i686-pc-linux-gnu was enough to trigger it.  Yay me! :-)

So, the patch posted in my previous e-mail still stands, but if you,
like me, find that it's working too hard to avoid such subregs, here's
an alternative patch that also fixes the problem, at least as long as
the X-constrained asm operand is not actually used in the asm output
pattern.

Index: gcc/ChangeLog
from  Alexandre Oliva  <[EMAIL PROTECTED]>

PR middle-end/20491
* final.c (alter_subreg): Don't call subreg_regno for a non-REG.

Index: gcc/final.c
===
RCS file: /cvs/gcc/gcc/gcc/final.c,v
retrieving revision 1.344.12.1
diff -u -p -r1.344.12.1 final.c
--- gcc/final.c 22 Mar 2005 13:39:12 - 1.344.12.1
+++ gcc/final.c 30 Mar 2005 19:21:02 -
@@ -1,6 +1,7 @@
 /* Convert RTL to assembler code and output it, for GNU compiler.
Copyright (C) 1987, 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997,
-   1998, 1999, 2000, 2001, 2002, 2003, 2004 Free Software Foundation, Inc.
+   1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005
+ Free Software Foundation, Inc.
 
 This file is part of GCC.
 
@@ -2638,7 +2639,7 @@ alter_subreg (rtx *xp)
 
   if (new != 0)
*xp = new;
-  else
+  else if (REG_P (y))
{
  /* Simplify_subreg can't handle some REG cases, but we have to.  */
  unsigned int regno = subreg_regno (x);

-- 
Alexandre Oliva http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   [EMAIL PROTECTED], gcc.gnu.org}
Free Software Evangelist  [EMAIL PROTECTED], gnu.org}


-- 


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

[Bug rtl-optimization/20413] VOIDmode LABEL_REFs are generated

[amylaar at gcc dot gnu dot org]

-- 
   What|Removed |Added

OtherBugsDependingO||20695
  nThis||


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

[Bug target/20695] New: sh64-*-* port deos not handle 32 / 64 bit conversions properly

[amylaar at gcc dot gnu dot org]

The sh64-*-* port plays fast and loos with the distinction between 32 and 64 bit
values.  In particular, it pretends a truncation from 64 to 32 bit is a no-op,
while a sign extension is needed, and that the sh5-32media and sh-compact
subtargets can expose the indexed addressing mode directly to the compiler,
which is wrong, too, since this addressing mode uses 64 bit arithmetic and
traps on all existing hardware if the result is not a valid 64 bit address.
On the other hand, sign extensions are usually no-ops.
Moreover, the target address of a branch should not be hardwired to DImode,
but always be Pmode.

The merge I am working on addresses all these issues, but it depends on all
LABEL_REFS to have Pmode; VOIDmode LABEL_REFs cause reload failures.

-- 
   Summary: sh64-*-* port deos not handle 32 / 64 bit conversions
properly
   Product: gcc
   Version: 3.0.4
Status: UNCONFIRMED
  Keywords: wrong-code, missed-optimization
  Severity: normal
  Priority: P2
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: amylaar at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: sh64-*-*
 BugsThisDependsOn: 20413


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

[Bug middle-end/20491] [4.0/4.1 Regression] internal compiler error: in subreg_regno_offset, at rtlanal.c:3042

[aoliva at gcc dot gnu dot org]

--- Additional Comments From aoliva at gcc dot gnu dot org  2005-03-30 
19:00 ---
I'm now sure it wasn't fixed.  Somehow I forgot the problem didn't occur on
x86_64-linux-gnu, not even with -m32, even though it did on i686-pc-linux-gnu. 
I I had only one i686-only bug, and I knew it was a different one.  Sorry about
that, I'll try to come up with a reasonable fix.

-- 


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

[Bug fortran/20460] Nasty extensions that should always warn

[law at redhat dot com]

--- Additional Comments From law at redhat dot com  2005-03-30 18:57 ---
Subject: Re: [PR tree-optimization/20460] add phi args to dests of
dce-redirected edges

On Wed, 2005-03-30 at 02:56 -0300, Alexandre Oliva wrote:
> When remove_dead_stmt() redirects a control stmt, the edge redirection
> reserves space for the phi arg for the new incoming edge in all phi
> nodes, but, instead of filling them in with information obtained from
> the edge redirection, we simply discard this information.  This leaves
> NULL in the phi args, which may cause crashes later on.
> 
> This patch fixes the problem by filling in the phi args using the
> PENDING_STMT list created during edge redirection.  This appears to be
> the intended use for this information, and it is used similarly in
> e.g. loop unrolling.
> 
> Bootstrapping mainline and 4.0 branch on amd64-linux-gnu, and mainline
> on i686-pc-linux-gnu.  Ok to install if bootstrap and regtesting pass?
> 
> The patch below is for the 4.0 branch, but it applies cleanly and
> correctly in mainline as well, since it's just a few lines off.


   /* Redirect the first edge out of BB to reach POST_DOM_BB.  */
   redirect_edge_and_branch (EDGE_SUCC (bb, 0), post_dom_bb);
-  PENDING_STMT (EDGE_SUCC (bb, 0)) = NULL;
+  flush_pending_stmts (EDGE_SUCC (bb, 0));



I'm having trouble seeing how this can be correct.

AFAICT this assumes that EDGE_SUCC (bb, 0)->dest before the redirection
has similar PHI as post_dom_bb and that the PHIs appear in the same
order in both blocks.  I'm not sure you can make that assumption.


This code is triggered rarely, I would expect it to be even rarer still
for POST_DOM_BB to have PHI nodes.  You could probably just ignore dead
control statements where the post dominator has PHI nodes and I doubt
it would ever be noticed.

Jeff



-- 


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

[Bug libgcj/20693] javax-imageio.lo failed to build

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-30 
18:57 ---
Why does this work for me and other people on i686-pc-linux-gnu?
http://gcc.gnu.org/ml/gcc-testresults/2005-03/msg02051.html

-- 
   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |WAITING


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

[Bug bootstrap/20692] configuring libgfortan infinite loop

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-30 
18:54 ---
Looks like not a gfortran bug but a gmp one:
#0  0xdfb7bdac in __gmpn_mul_basecase () from /opt/csw/lib/libgmp.so.3
#1  0xdfb97840 in ?? () from /opt/csw/lib/libgmp.so.3
#2  0x0006 in ?? ()
#3  0x0804759c in ?? ()
#4  0x080475c0 in ?? ()
#5  0x0005 in ?? ()
#6  0xa0cba75d in ?? ()
#7  0xdfb7870d in __gmpn_mul () from /opt/csw/lib/libgmp.so.3

Could you make sure that the installed version of gmp is the correct one and is 
working?

-- 
   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |WAITING


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

[Bug middle-end/20491] [4.0/4.1 Regression] internal compiler error: in subreg_regno_offset, at rtlanal.c:3042

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-30 
18:51 ---
I still can reproduce it also on x86.

-- 
   What|Removed |Added

 Status|REOPENED|ASSIGNED


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

[Bug bootstrap/20692] configuring libgfortan infinite loop

[pfelecan at acm dot org]

--- Additional Comments From pfelecan at acm dot org  2005-03-30 18:49 
---
Created an attachment (id=8496)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8496&action=view)
gdb session, with backtrace, for f951

gdb session running the command f951 for which the wait is done in gfortran.

-- 


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

[Bug bootstrap/20692] configuring libgfortan infinite loop

[pfelecan at acm dot org]

--- Additional Comments From pfelecan at acm dot org  2005-03-30 18:48 
---
Created an attachment (id=8495)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8495&action=view)
verbose output of gfortran

This is the output of gfortran -v as requested. The binary on which we wait is
f951. I will run this in gdb and attach the output in another attachement.

-- 


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

Important m$6h?3p

[tom]

This is a multi-part message in MIME format.
Norman Virus Control a supprimé le message original qui contenait le virus 
[EMAIL PROTECTED]  

[Bug libstdc++/20694] [4.1 Regression] make install failure building abi_check with leftover libv3test

[mark at codesourcery dot com]

--- Additional Comments From mark at codesourcery dot com  2005-03-30 18:32 
---
Subject: Re:  New: make install failure building abi_check
 with leftover libv3test

Benjamin Kosnik wrote:
>>Is it considered desirable behavior to build abi_check at "make install" 
>>time?
> 
> 
> No, this doesn't make any sense, as abi_check is not installed.
> 
> It was/is built at "make all" time. I believe you wanted to build this
> as part of "make check" or "make check-abi" either of which is fine for
> me.

OK, that makes sense.

(I didn't actually change this particularly thing; it was probably 
getting built at make install time all along.  But, my changes are 
causing the make install rebuild not to work.)

I'll see what I can do.



-- 


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

[Bug libstdc++/20694] [4.1 Regression] make install failure building abi_check with leftover libv3test

[bkoz at redhat dot com]

--- Additional Comments From bkoz at redhat dot com  2005-03-30 18:31 
---
Subject: Re:  New: make install failure building
 abi_check with leftover libv3test


> Is it considered desirable behavior to build abi_check at "make install" 
> time?

No, this doesn't make any sense, as abi_check is not installed.

It was/is built at "make all" time. I believe you wanted to build this
as part of "make check" or "make check-abi" either of which is fine for
me.

-benjamin


-- 


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

[Bug libstdc++/20694] [4.1 Regression] make install failure building abi_check with leftover libv3test

[mark at codesourcery dot com]

--- Additional Comments From mark at codesourcery dot com  2005-03-30 18:22 
---
Subject: Re:  New: make install failure building abi_check
 with leftover libv3test

janis at gcc dot gnu dot org wrote:
> Nightly mainline bootstraps for powerpc64-linux have been failing
> intermittently since changes went in last week to allow running
> libstc++ tests on installed tools.  For "make bootstrap", abi_check
> is built three times: for 32-bit bit, 64-bit, and 32-bit soft-float.
> "make install" tries to build it again, but a 32-bit build of
> abi_float tries to use the existing libv3test, and the link fails if
> the type of the leftover library (e.g. 64-bit) doesn't match the type
> of the new abi_check.  All of the abi_check builds appear to be done
> in the same directory.

I will look into this today.

Is it considered desirable behavior to build abi_check at "make install" 
time?



-- 


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

[Bug c/20368] [4.0/4.1 Regression] internal compiler error: tree check: expected function_type or method_type, have integer_type in start_function, at c-decl.c:5777

[jsm28 at gcc dot gnu dot org]

--- Additional Comments From jsm28 at gcc dot gnu dot org  2005-03-30 18:10 
---
Testing a fix.


-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jsm28 at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2005-03-19 13:13:11 |2005-03-30 18:10:15
   date||


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

[Bug c/18715] [4.0/4.1 Regression] warning: "enumeration value not handled in switch" for '...' ranges

[jsm28 at gcc dot gnu dot org]

--- Additional Comments From jsm28 at gcc dot gnu dot org  2005-03-30 18:09 
---
Is there a more recent patch version than that referred to in comment #4,
taking account of Mark's comments on that patch version?


-- 


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

[Bug c/17913] [4.0/4.1 Regression] ICE jumping into statement expression

[jsm28 at gcc dot gnu dot org]

--- Additional Comments From jsm28 at gcc dot gnu dot org  2005-03-30 18:08 
---
Patch at  addresses
the issue for C and noncomputed gotos by disallowing such jumps; awaiting
any comments on the proposed statement expression semantics.  Does not address
the issue for C++ which needs similar changes, and the possibility of computed
gotos means that something like
 but adjusted as
described in that message is needed as well.


-- 


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

[Bug c/17855] [4.0/4.1 Regression] modification of function struct return not diagnosed

[jsm28 at gcc dot gnu dot org]

--- Additional Comments From jsm28 at gcc dot gnu dot org  2005-03-30 18:05 
---
Testing a fix.

-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jsm28 at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2004-12-05 04:32:03 |2005-03-30 18:05:58
   date||


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

[Bug libstdc++/20694] [4.1 Regression] make install failure building abi_check with leftover libv3test

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org
   Severity|normal  |critical
   Keywords||build
Summary|make install failure|[4.1 Regression] make
   |building abi_check with |install failure building
   |leftover libv3test  |abi_check with leftover
   ||libv3test
   Target Milestone|--- |4.1.0


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

[Bug bootstrap/20692] configuring libgfortan infinite loop

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-30 
18:04 ---
#0  0xdfa2b0e0 in _waitid () from /usr/lib/libc.so.1
#1  0xdfa43aeb in _waitpid () from /usr/lib/libc.so.1
#2  0xdfa79957 in waitpid () from /usr/lib/libc.so.1
#3  0x08057a42 in execute () at ../../sources/gcc-4.0-20050326/gcc/gcc.c:2835


Can you try adding -v to see which program we are waiting on?
And then run that program with gdb?

-- 
   What|Removed |Added

   Keywords||build


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

[Bug libstdc++/20694] New: make install failure building abi_check with leftover libv3test

[janis at gcc dot gnu dot org]

Nightly mainline bootstraps for powerpc64-linux have been failing
intermittently since changes went in last week to allow running
libstc++ tests on installed tools.  For "make bootstrap", abi_check
is built three times: for 32-bit bit, 64-bit, and 32-bit soft-float.
"make install" tries to build it again, but a 32-bit build of
abi_float tries to use the existing libv3test, and the link fails if
the type of the leftover library (e.g. 64-bit) doesn't match the type
of the new abi_check.  All of the abi_check builds appear to be done
in the same directory.

-- 
   Summary: make install failure building abi_check with leftover
libv3test
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: janis at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org,mark at codesourcery dot
com
 GCC build triplet: powerpc64-linux
  GCC host triplet: powerpc64-linux
GCC target triplet: powerpc64-linux


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

[Bug libgcj/20693] New: javax-imageio.lo failed to build

[hjl at lucon dot org]

As of Wed Mar 30 00:24:21 UTC 2005, I got

/bin/sh ./libtool --mode=compile
/export/build/gnu/gcc/build-i686-linux/./gcc/gcj
-B/export/build/gnu/gcc/build-i686-linux/./gcc/
-B/usr/gcc-4.1/i686-pc-linux-gnu/bin/ -B/usr/gcc-4.1/i686-pc-linux-gnu/lib/
-isystem /usr/gcc-4.1/i686-pc-linux-gnu/include -isystem
/usr/gcc-4.1/i686-pc-linux-gnu/sys-include -ffloat-store -fno-omit-frame-pointer
-fclasspath=
-fbootclasspath=/export/build/gnu/gcc/build-i686-linux/i686-pc-linux-gnu/libjava':'/net/gnu/export/gnu/src/gcc/gcc/libjava':'/net/gnu/export/gnu/src/gcc/gcc/libjava/external/w3c_dom':'/net/gnu/export/gnu/src/gcc/gcc/libjava/external/sax
--encoding=UTF-8 -Wno-deprecated -g -O2 -findirect-dispatch -c -o 
javax-imageio.lo \
`find javax/imageio -name '*.class' -print`
/export/build/gnu/gcc/build-i686-linux/./gcc/gcj
-B/export/build/gnu/gcc/build-i686-linux/./gcc/
-B/usr/gcc-4.1/i686-pc-linux-gnu/bin/ -B/usr/gcc-4.1/i686-pc-linux-gnu/lib/
-isystem /usr/gcc-4.1/i686-pc-linux-gnu/include -isystem
/usr/gcc-4.1/i686-pc-linux-gnu/sys-include -ffloat-store -fno-omit-frame-pointer
-fclasspath=
-fbootclasspath=/export/build/gnu/gcc/build-i686-linux/i686-pc-linux-gnu/libjava:/net/gnu/export/gnu/src/gcc/gcc/libjava:/net/gnu/export/gnu/src/gcc/gcc/libjava/external/w3c_dom:/net/gnu/export/gnu/src/gcc/gcc/libjava/external/sax
--encoding=UTF-8 -Wno-deprecated -g -O2 -findirect-dispatch -c
javax/imageio/metadata/IIOMetadataFormat.class
javax/imageio/metadata/IIOMetadataController.class
javax/imageio/metadata/IIONodeList.class
javax/imageio/metadata/IIOInvalidTreeException.class
javax/imageio/metadata/IIOMetadataFormatImpl.class
javax/imageio/metadata/IIOAttr.class
javax/imageio/metadata/IIONamedNodeMap.class
javax/imageio/metadata/IIOMetadataNode.class
javax/imageio/metadata/IIOMetadata.class javax/imageio/IIOImage.class
javax/imageio/ImageWriter.class javax/imageio/stream/IIOByteBuffer.class
javax/imageio/stream/ImageOutputStream.class
javax/imageio/stream/FileImageInputStream.class
javax/imageio/stream/MemoryCacheImageInputStream.class
javax/imageio/stream/FileCacheImageOutputStream.class
javax/imageio/stream/ImageInputStream.class
javax/imageio/stream/MemoryCacheImageOutputStream.class
javax/imageio/stream/ImageInputStreamImpl.class
javax/imageio/stream/ImageOutputStreamImpl.class
javax/imageio/stream/FileImageOutputStream.class
javax/imageio/stream/FileCacheImageInputStream.class
javax/imageio/ImageReadParam.class javax/imageio/ImageTranscoder.class
javax/imageio/ImageWriteParam.class javax/imageio/ImageReader.class
javax/imageio/IIOParamController.class
javax/imageio/ImageIO\$WriterFormatFilter.class
javax/imageio/ImageIO\$ImageWriterIterator.class
javax/imageio/ImageIO\$ReaderFormatFilter.class
javax/imageio/ImageIO\$ReaderSuffixFilter.class javax/imageio/ImageIO.class
javax/imageio/ImageTypeSpecifier.class
javax/imageio/ImageIO\$ReaderMIMETypeFilter.class
javax/imageio/ImageIO\$ImageReaderIterator.class javax/imageio/IIOParam.class
javax/imageio/ImageIO\$WriterMIMETypeFilter.class
javax/imageio/ImageIO\$WriterSuffixFilter.class
javax/imageio/event/IIOWriteWarningListener.class
javax/imageio/event/IIOReadUpdateListener.class
javax/imageio/event/IIOReadProgressListener.class
javax/imageio/event/IIOReadWarningListener.class
javax/imageio/event/IIOWriteProgressListener.class
javax/imageio/IIOException.class javax/imageio/spi/ImageReaderWriterSpi.class
javax/imageio/spi/ImageOutputStreamSpi.class
javax/imageio/spi/ImageInputStreamSpi.class
javax/imageio/spi/ServiceRegistry\$2.class
javax/imageio/spi/ServiceRegistry\$Filter.class
javax/imageio/spi/ImageTranscoderSpi.class javax/imageio/spi/IIORegistry.class
javax/imageio/spi/ImageWriterSpi.class
javax/imageio/spi/RegisterableService.class
javax/imageio/spi/ImageReaderSpi.class javax/imageio/spi/ServiceRegistry.class
javax/imageio/spi/IIOServiceProvider.class
javax/imageio/spi/ServiceRegistry$1.class -fPIC -o .libs/javax-imageio.o
javax/imageio/spi/IIOServiceProvider.java:0: fatal error: can't open
javax/imageio/spi/ServiceRegistry-B/export/build/gnu/gcc/build-i686-linux/./gcc/.class:
No such file or directory

It looks like libtool failed to add `\' before $ for
javax/imageio/spi/ServiceRegistry$1.class.

-- 
   Summary: javax-imageio.lo failed to build
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl at lucon dot org
CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu
dot org
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


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

[Bug bootstrap/20692] configuring libgfortan infinite loop

[pfelecan at acm dot org]

--- Additional Comments From pfelecan at acm dot org  2005-03-30 17:37 
---
Created an attachment (id=8494)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8494&action=view)
back trace tentative

I tried to isolate the bug and run in gdb. The issue appears as reported. After
terminating the process I executed a back-trace. Hope that it is helpful.

-- 


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

[Bug bootstrap/20692] configuring libgfortan infinite loop

[pfelecan at acm dot org]

--- Additional Comments From pfelecan at acm dot org  2005-03-30 16:54 
---
Forgot the content of the conftest.F:

  program main
#ifndef __GNUC__
   choke me
#endif

  end


-- 


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

[Bug bootstrap/20692] New: configuring libgfortan infinite loop

[pfelecan at acm dot org]

- bootstraping gcc-4.0-20050326
- system type: SUN LX50: Sol8 x86 server 2 x 1404MHz
- head and tail of the objdir/i386-pc-solaris2.8/libgfortran/config.log:
[...]
It was created by GNU Fortran Runtime Library configure 0.2, which was
generated by GNU Autoconf 2.59.  Invocation command line was

  $
/export/nfs/workarea/pfelecan/CSW/ports/gcc4core-4.0.0REV2005.03.26-SunOS5.8-i386-CSW.pkg/sources/gcc-4.0-20050326/libgfortran/configure
--cache-file=./config.cache --host=i386-pc-solaris2.8 --build=i386-pc-solaris2.8
--prefix=/opt/csw/gcc4 --with-local-prefix=/opt/csw --without-gnu-as
--with-as=/usr/ccs/bin/as --without-gnu-ld --with-ld=/usr/ccs/bin/ld
--enable-threads=posix --enable-shared --enable-multilib --enable-nls
--with-included-gettext --with-libiconv-prefix=/opt/csw --with-x
--enable-java-awt=xlib --with-system-zlib
--with-gcc-version-trigger=/export/nfs/workarea/pfelecan/CSW/ports/gcc4core-4.0.0REV2005.03.26-SunOS5.8-i386-CSW.pkg/sources/gcc-4.0-20050326/gcc/version.c
--enable-languages=c,ada,c++,f95,java,objc --program-transform-name=s,y,y,
--srcdir=../../../sources/gcc-4.0-20050326/libgfortran
--with-target-subdir=i386-pc-solaris2.8

## - ##
## Platform. ##
## - ##

hostname = daedal
uname -m = i86pc
uname -r = 5.8
uname -s = SunOS
uname -v = Generic_117351-16

/usr/bin/uname -p = i386
/bin/uname -X = System = SunOS
Node = daedal
Release = 5.8
KernelID = Generic_117351-16
Machine = i86pc
BusType = 
Serial = 
Users = 
OEM# = 0
Origin# = 1
NumCPU = 2

/bin/arch  = i86pc
/usr/bin/arch -k   = i86pc
/usr/convex/getsysinfo = unknown
hostinfo   = unknown
/bin/machine   = unknown
/usr/bin/oslevel   = unknown
/bin/universe  = unknown

[...]

configure:4487: checking whether we are using the GNU Fortran compiler
configure:4501:
/export/nfs/workarea/pfelecan/CSW/ports/gcc4core-4.0.0REV2005.03.26-SunOS5.8-i386-CSW.pkg/objdir/gcc/gfortran
-B/export/nfs/workarea/pfelecan/CSW/ports/gcc4core-4.0.0REV2005.03.26-SunOS5.8-i386-CSW.pkg/objdir/gcc/
-B/opt/csw/gcc4/i386-pc-solaris2.8/bin/ -B/opt/csw/gcc4/i386-pc-solaris2.8/lib/
-isystem /opt/csw/gcc4/i386-pc-solaris2.8/include -isystem
/opt/csw/gcc4/i386-pc-solaris2.8/sys-include -c   conftest.F >&5

This never ends.

-- 
   Summary: configuring libgfortan infinite loop
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pfelecan at acm dot org
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i386-pc-solaris2.8
  GCC host triplet: i386-pc-solaris2.8
GCC target triplet: i386-pc-solaris2.8


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

[Bug middle-end/20491] [4.0/4.1 Regression] internal compiler error: in subreg_regno_offset, at rtlanal.c:3042

[jsm28 at gcc dot gnu dot org]

--- Additional Comments From jsm28 at gcc dot gnu dot org  2005-03-30 16:21 
---
Are you sure the bug is fixed?  The testcase is failing for me with today's
mainline compiler on i686-pc-linux-gnu, ia64-hp-hpux11.23 and
hppa64-hp-hpux11.{11,23}.

Failure on i686-pc-linux-gnu is that quoted in the bug report (at -O2; not at
-O0 or -O1).  Same failure on ia64-hpux.  On hppa64-hpux get instead, at -O1 and
above,

/home/gcc/nightlies/gcc-mainline-2005-03-30/gcc/testsuite/gcc.dg/torture/asm-subreg-1.c:
In function 'evas_common_convert_yuv_420p_601_rgba':
/home/gcc/nightlies/gcc-mainline-2005-03-30/gcc/testsuite/gcc.dg/torture/asm-subreg-1.c:12:
error: 'asm' operand requires impossible reload

gcc-testresults shows failures on other platforms, including on 4.0 branch.


-- 
   What|Removed |Added

 CC||aoliva at gcc dot gnu dot
   ||org, jsm28 at gcc dot gnu
   ||dot org
 Status|RESOLVED|REOPENED
 Resolution|FIXED   |


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

[Bug c++/9737] [DR150] Partial template specialisation selection failure involving template parameter defaults

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-30 
16:00 ---
*** Bug 20691 has been marked as a duplicate of this bug. ***

-- 
   What|Removed |Added

 CC||sstrasser at systemhaus-
   ||gruppe dot de


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

[Bug c++/20691] accept-invalid template template argument

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-30 
16:00 ---
This is PR 9737 and C++ DR report 150 (which was closed as an extension which 
means that it might 
become part of the standard in the future).

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

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug c++/20691] New: accept-invalid template template argument

[sstrasser at systemhaus-gruppe dot de]

>"Ioannis Vranos" <[EMAIL PROTECTED]> wrote...
>
>> #include 
>>
>>
>> template< template class ContainerTemplate, class ValueType>
>> inline void test(const ValueType &val)
>> {
>> ContainerTemplate container(val);
>> }
>>
>>
>>
>> int main()
>> {
>> using namespace std;
>>
>> test(10);
>> }
>
>
>No, this is not valid for a simple reason that std::vector is a template
>that has more than one argument.  Your 'ContainerTemplate' template
>template argument has only one argument itself.
>
>

-- 
   Summary: accept-invalid template template argument
   Product: gcc
   Version: 3.4.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sstrasser at systemhaus-gruppe dot de
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug c/20689] strict aliasing with temporary variable never gives warnings

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-30 
15:45 ---
Also this is not done because void* cannot be dereferenced.

-- 
   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||INVALID


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

[Bug middle-end/20177] ICE in schedule-insns for -O2 -fmodulo-sched

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-30 
15:39 ---
Fixed in 4.0.0.

-- 
   What|Removed |Added

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


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

[Bug libstdc++/20690] Bug in std::vector

[pcarlini at suse dot de]

-- 
   What|Removed |Added

   Severity|critical|normal
  Component|c++ |libstdc++


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

[Bug c++/20687] namespace bug

[pcarlini at suse dot de]

--- Additional Comments From pcarlini at suse dot de  2005-03-30 15:15 
---
> One more argument is that this feature is required to compile correctly 
> STLport.

*Assuming* this is true, it's a serious problem for STLPort ;) because the 
other 
widespread C++ front-end, used by many commercial compilers, also rejects your
code...

-- 


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

[Bug c++/20690] Bug in std::vector

[pcarlini at suse dot de]

--- Additional Comments From pcarlini at suse dot de  2005-03-30 15:09 
---
Irrespective of the fact that the code compiles or doesn't, I believe it's
*invalid*, because, according to 23.1/8, "All other constructors for these
container types take an Allocator& argument, an allocator whose value type is 
the
same as the container's value type", where Allocator is the type of the second
template parameter of the class, and your snippet violates this requirement; in
other terms, the standard does *not* mandate that the containers do rebinding.
 

-- 


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

[Bug c++/20687] namespace bug

[jozef at syncad dot com]

--- Additional Comments From jozef at syncad dot com  2005-03-30 14:56 
---
Subject: Re:  namespace bug

Hi,

This is not about the same :
7.3.4.5
d1++; // shows that there is a conflict  between a symbol in  your
   // namespace and a symbol imported using using namespace
f(1); // shows that there is a conflict between two symbols;
   // both imported from two namespaces; one directly,
   // the second transitively

None of the errors indicated show that there is a conflict
between a symbol imported from a namespace and a symbol
from a higher level namespace.

But the example in the first paragraph clearly states that
the imported names hide names from the higher levels:
7.3.4.1
i = 5; // OK, C::i visible in B and hides A::i

7.3.4.5 does not conflict with 7.3.4.1. It still looks
  to me reasonable that the names imported using namespace have higher
  precedence than names inherited from a higher level namespace
  (this would be similar to the fact that the names defined
  in a namespace have higher precedence to the names inherited
  from a higher level namespaces).

One more argument is that this feature is required to compile correctly STLport.

pinskia at gcc dot gnu dot org wrote:
> --- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-29 
> 19:51 ---
> The reduced testcase:
> namespace dd {
> struct t1 {};
> }
> namespace ff {
>   using namespace dd;
> }
> struct t1 { };
> namespace ff
> {
>  typedef t1 t2;
> }
> 
> 
> But the use of t1 is ambiguous really as "using namespace" is not as strong 
> as defining the t1 in the 
> namespace ff or doing a "using dd::t1" in the namespace ff.
> 
Can you provide some reference to the standard for this claim, please?

Regards,
Jozef


-- 


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

[Bug rtl-optimization/20376] The missed-optimization of general induction variables in the new rtl-level loop optimizer cause performance degradation.

[canqun at nudt dot edu dot cn]

--- Additional Comments From canqun at nudt dot edu dot cn  2005-03-30 
14:42 ---
(In reply to comment #7)
> Waiting for a test case...

Part 1
! Test sase for address giv (general induction variable) optimization.
subroutine dot_product (sum, a, b, n)
   real*8 a(n), b(n), sum
   sum = 0
   do i = 1, n
 sum = sum + a (i) * b(i)
   end do
end

Part 2
// IA-64 Assembly code generated by GCC without address giv splitting
mov ar.lc = r14
.L4:
// Loop is unrolled, but the address givs are not splitted.
// Register r17, r19 is used to calculate all the addresses
// of the array elements.
.mmb
ldfd f7 = [r17]
ldfd f6 = [r19]
nop 0
.mmi
add r17 = r15, r33
add r19 = r15, r34
shladd r15 = r18, 3, r0
;;
.mmf
nop 0
nop 0
fma.d f8 = f7, f6, f9
.mmi
ldfd f7 = [r17]
ldfd f6 = [r19]
add r17 = r15, r33
.mfi
 nop 0
shladd r15 = r16, 3, r0
;;
.mmf
nop 0
nop 0
fma.d f8 = f7, f6, f8
.mmi
ldfd f7 = [r17]
ldfd f6 = [r19]
add r17 = r15, r33
.mmb
nop 0
add r19 = r15, r34
nop 0
;;
.mmf
nop 0
nop 0
fma.d f8 = f7, f6, f8
.mmb
ldfd f7 = [r17]
ldfd f6 = [r19]
nop 0
;;
.mmf
nop 0
nop 0
fma.d f8 = f7, f6, f8
;;
.mfb
nop 0
mov f9 = f8
br.cloop.sptk.few .L4
...
.endp dot_product__#
.ident  "GCC: (GNU) 4.1.0 20050302 (experimental)"

Part 3
// IA-64 assembly code generated by GCC with address giv splitting
mov ar.lc = r16
.L28:
[.L3:]
[.L2:]
...
// The loop is unrolled, and the address givs are splitted.
// Register r14, r8, r3, r35, r33, r31,r28, r29 is used to
// caculate the address of each array element respectively.
.mmi
ldfd f38 = [r14]
ldfd f39 = [r8]
add r31 = r34, r23
.mmi
ldfd f35 = [r3]
ldfd f37 = [r35]
add r33 = r34, r24
;;
.mmb
ldfd f33 = [r33]
ldfd f34 = [r31]
nop 0
.mmi
add r28 = r30, r23
add r29 = r30, r24
adds r22 = 4, r22
;;
.mmf
ldfd f32 = [r29]
ldfd f15 = [r28]
fma.d f36 = f38, f39, f14
;;
.mmf
nop 0
nop 0
fma.d f13 = f35, f37, f36
;;
.mmf
nop 0
nop 0
fma.d f12 = f33, f34, f13
;;
.mfb
nop 0
fma.d f14 = f32, f15, f12
br.cloop.sptk.few .L28
;;
.L9:
.mfb
stfd [r32] = f14
nop 0
nop 0
...
.endp dot_product__#
.ident  "GCC: (GNU) 3.5-tree-ssa 20031221 (CCRG)"

-- 


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

[Bug c++/20690] New: Bug in std::vector

[michael at xter dot net]

There is no allocator rebinding for some STL containers i.e. std::vector, so the
following code dose not compiled:

#include 
#include 

using namespace std;

typedef std::vector > Vec;

Vec v;

-- 
   Summary: Bug in std::vector
   Product: gcc
   Version: 3.4.3
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: michael at xter dot net
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug middle-end/20177] ICE in schedule-insns for -O2 -fmodulo-sched

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-03-30 
13:14 ---
Subject: Bug 20177

CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED]   2005-03-30 13:13:40

Modified files:
gcc: ChangeLog ddg.c modulo-sched.c passes.c 
Added files:
gcc/testsuite/gcc.dg: 20050321-1.c 20050330-1.c 

Log message:
Fix PR middle-end/20177 and two new test cases.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=2.7592.2.95&r2=2.7592.2.96
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ddg.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.11&r2=1.11.14.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/modulo-sched.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.19&r2=1.19.12.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/passes.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=2.72.2.1&r2=2.72.2.2
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/20050321-1.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.8.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/20050330-1.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.2.1



-- 


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

[Bug c++/19203] [3.4/4.0/4.1 Regression] Partial ordering failure between function reference and generic const reference

[nathan at gcc dot gnu dot org]

--- Additional Comments From nathan at gcc dot gnu dot org  2005-03-30 
13:10 ---
We don't implement DR214 but edg does. 

http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#214

I shall see how tricky it is to implement ...

-- 


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

[Bug c/20689] strict aliasing with temporary variable never gives warnings

[falk at debian dot org]

--- Additional Comments From falk at debian dot org  2005-03-30 12:23 
---
(In reply to comment #2)
> I mean that since in case where you are doing "void *p=(void *)&i" then
> according to strict-aliasing rules we get " warning: dereferencing type-punned
> pointer will break strict-aliasing rules" 

No, you don't. Please provide a *complete* test case, with the command line
you use and the output you get.



-- 


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

[Bug c/20689] strict aliasing with temporary variable never gives warnings

[varun0005 at gmail dot com]

--- Additional Comments From varun0005 at gmail dot com  2005-03-30 12:02 
---
I mean that since in case where you are doing "void *p=(void *)&i" then
according to strict-aliasing rules we get " warning: dereferencing type-punned
pointer will break strict-aliasing rules" , but same thing if done using a
temporary variable then why strict-aliasing warning doesn't appear.. According
to my understanding of strict aliasing if some unqualified version of pointer is
pointing to the address space(in out case void pointer pointing to int address
space) then it is violating  strict aliasing rule. So in second case also void
pointer is pointing to the int address space then why strict aliasing rules are
not violated. If ther is some error in my understanding of strict aliasing then
please inform .

-- 


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

[Bug c++/20584] [4.0/4.1 Regression] inline function used but never defined

[nerijus at users dot sourceforge dot net]

--- Additional Comments From nerijus at users dot sourceforge dot net  
2005-03-30 11:59 ---
It seems I get these warnings only when precompiled headers are not used.

-- 


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

[Bug rtl-optimization/20376] The missed-optimization of general induction variables in the new rtl-level loop optimizer cause performance degradation.

[steven at gcc dot gnu dot org]

--- Additional Comments From steven at gcc dot gnu dot org  2005-03-30 
11:38 ---
Waiting for a test case...

-- 
   What|Removed |Added

 Status|UNCONFIRMED |WAITING


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

[Bug target/16871] missing vector support

[steven at gcc dot gnu dot org]

--- Additional Comments From steven at gcc dot gnu dot org  2005-03-30 
11:21 ---
Is anyone going to work on these intrinsics?  Is there a list somewhere
of what intrinsics we are talking about here?


-- 


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

[Bug c++/20607] [3.4 Regression] -fstrict-aliasing causes incorrect scheduling

[ebotcazou at gcc dot gnu dot org]

--- Additional Comments From ebotcazou at gcc dot gnu dot org  2005-03-30 
10:53 ---
Hum... type-punning simply doesn't work in this case with the C++ compiler, but
does work with the C compiler.  The problem is that:

union u {
x_uint64_t first;
x_uint32_t second;
};
union u conv;
conv.first = arg1;
result = conv.second;

is translated into:

  *(&conv.first) = *(&arg1);
  *(&result) = *(&conv.second);

and type-punning cannot work in this case (that's the counter-example provided
in the manual).  I guess the problem comes the fields being of aggregate types.

Mark, is that fixable or should we document the limitation?


-- 
   What|Removed |Added

 CC|ebotcazou at gcc dot gnu dot|mark at codesourcery dot com
   |org |


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