[Bug other/19300] [4.0 Regression] PCH failures on sparc-linux

[christian dot joensson at gmail dot com]

--- Additional Comments From christian dot joensson at gmail dot com  
2005-01-10 07:32 ---
These PCH problems does not occur on the current 3.4 branch:

See test results at http://gcc.gnu.org/ml/gcc-testresults/2005-01/msg00353.html

-- 


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

[Bug target/19326] [4.0 Regression] gcc.c-torture/execute/simd-6.c fails on x86-64

[uros at kss-loka dot si]

--- Additional Comments From uros at kss-loka dot si  2005-01-10 06:49 
---
Is this PR related to PR 13366?

-- 


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

[Bug c++/19288] No more possible to have a template function that uses a nested class of a template class

[jean-pierre dot chevallet at imag dot fr]

--- Additional Comments From jean-pierre dot chevallet at imag dot fr  
2005-01-10 05:56 ---
(In reply to comment #7)
> You are trying to overload operator<<(std::ostream, float). That 
> can't work, since there is already an overload for that. 
>  
> W. 

I don't think so, I try to define un fonction like this :

operator<<(std::ostream, C1::nested&) with is not an overload of
operator<<(std::ostream, float).

The lesson I learn from all your replies : 
nested class of a template wich have no template
parametrer are difficult to use due to the notion nondeducible context.
I think it is better to avoid non template nested class, or adding a
explicit template parameter to the nested class, like :

template  class C1 {
public:
  T V;
  C1(T v) : V(v) {};
  
  template 
  class nested {
  public:
U W;
nested(U w) : W(w) {};
  };  
};
// Template version of operator using nested temptate class
template 
ostream&  operator << (ostream& out,typename C1::nested& c) {return
out<::nested n(3.5);

  cout

[Bug c++/15485] [tree-ssa] The C++ front-end generates a lot of (void) casts for statements

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-10 
05:45 ---
(In reply to comment #9)
> Maybe a better walker which then is able to remove statements in a 
> STATEMENT_LIST.

In fact doing this will reduce the memory usage for the most common C++ code as 
it shows up even in 
the STL headers as shown by my reduced testcase.

-- 


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

[Bug c++/15485] [tree-ssa] The C++ front-end generates a lot of (void) casts for statements

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-10 
05:42 ---
(In reply to comment #8)
> A more reduced testcase:
This comes from finalize_nrv_r.  There might be a better way of doing that.
  else
init = build_empty_stmt ();
  SET_EXPR_LOCUS (init, EXPR_LOCUS (*tp));
  *tp = init;

Maybe a better walker which then is able to remove statements in a 
STATEMENT_LIST.

-- 


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

[Bug c++/19317] [4.0 Regression] removing a temporary return value when we cannot

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-10 
05:03 ---
Also we only remove the temporary variable if the size is "large" which seems 
wrong.
Here is another example and the reason why it works with the C front-end is 
because we don't do NRV 
until late:
extern "C" void abort( void );

typedef struct A
{
int width;
int width1;
int width3;
int width5;
}A;

A bb( const A*this1, const A *r )
{
A tmp;
tmp.width = -1;
tmp.width += this1->width < r->width ? this1->width : r->width;
return tmp;
}
int main()
{
A a;
a.width = ( 10 );
A b;
b.width = (100);
a = bb( &b, &a );
if ( a.width != 9 )
   abort();
}

-- 


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

[Bug c++/19317] [4.0 Regression] removing a temporary return value when we cannot

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-10 
04:52 ---
Yes this is defind. As 12.2P1 says:
"Temporaries of class types are created in various contexts: ... returning an 
rvalue (6.6.3) ..."
"Even when the creation of the temporary object is avoided (12.8), all semantic 
restrictions must be 
respected as if the temporary object was created".

So we have to create a temporary variable for this return value in all three of 
my examples.  Hmm, the c 
example for all three does the correct thing and create a temporary variable.

-- 


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

[Bug fortran/5900] [g77 & gfortran] Lapack regressions since g77 2.95.2

[jvdelisle at verizon dot net]

--- Additional Comments From jvdelisle at verizon dot net  2005-01-10 04:46 
---
I have managed to reduce one of the test sets, for CLS Drivers to a case of 3
failures out of 108 tests.  Looking at the test report I am able to narrow down
to three test drivers, cqrt12.f, cqrt16.f, and cqrt17.f.

Analyzing those narrows it down to the following showing the usage of each
routine in the three tests:

12  16  17
CLANGE  1   1   1
SASUM   1   
SLAMCH  1   1   1
SNRM2   1   
CGEBD2  1   
CLASCL  1   1
CLASET  1   
SAXPY   1   
SBDSQR  1   
SLABAD  1   
LSAME   1   1
SCASUM  1   
CGEMM   1   1
CLACPY  1
XERBLA  1   1
SLASCL  1   

I have checked out slamch and it seems to be working OK. Using grep I am getting
a count of how many other places some of thes eroutines are used.  For example
xerbla is used all over.  I think it is less likely to be the problem.  And so
it goes, a process of elimination. :)

-- 


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

[Bug c++/19288] No more possible to have a template function that uses a nested class of a template class

[gdr at integrable-solutions dot net]

--- Additional Comments From gdr at integrable-solutions dot net  
2005-01-10 04:39 ---
Subject: Re:  No more possible to have a template function that uses a nested 
class of a template class

"jean-pierre dot chevallet at imag dot fr" <[EMAIL PROTECTED]> writes:

| > Giving explicit template arguments for template operators works 
| > the same way: write 
| >   x.operator<<  (abc) 
| > instead of 
| >   x << abc 
| >  
| 
| Ok, I have test it but with a function operator : it doesn't seems to work.
| So what is wrong ??
| 
| #include 
| 
| using namespace std;
| 
| template  class C1 {
| public:
|   T V;
|   C1(T v) : V(v) {};
|   
|   class nested {
|   public:
| T W;
| nested(T w) : W(w) {};
|   };
|   
| };
| 
| // Template version of operator using nested temptate class
| template 
| ostream&  operator << (ostream& out,typename C1::nested& c) {return 
out<::nested& c) {return 
out< (cout,n);
|   // Never work !! but it should ???

Yes.

-- Gaby


-- 


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

[Bug middle-end/19327] [4.0 Regression] FAIL: gcc.c-torture/execute/921215-1.c compilation, -O3 -g

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-10 
04:32 ---
Hmm, the funny part is if I add -fdump-tree-all, it works which means we are 
setting the DECL_RTL 
twice and over writting it once or something like that.

-- 
   What|Removed |Added

  Known to fail||4.0.0
  Known to work||3.4.0


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

[Bug c++/19288] No more possible to have a template function that uses a nested class of a template class

[bangerth at dealii dot org]

--- Additional Comments From bangerth at dealii dot org  2005-01-10 04:21 
---
You are trying to overload operator<<(std::ostream, float). That 
can't work, since there is already an overload for that. 
 
W. 

-- 


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

[Bug rtl-optimization/19354] [3.4 Regression] -O3 -Wunreachable-code failing

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-10 
03:59 ---
Broke for 3.4.0: Search converges between 2003-04-03-trunk (#220) and 
2003-04-06-trunk (#221).
Fixed for 4.0.0 (by the merge of the tree-ssa):
: Search converges between 2004-05-11-trunk (#454) and 2004-05-14-trunk (#455).
Fixed on the tree-ssa branch:
: Search converges between 2003-10-25-ssa (#115) and 2003-10-26-ssa (#116).

Confirmed.

-- 
   What|Removed |Added

   Severity|normal  |minor
 Status|UNCONFIRMED |NEW
  Component|c   |rtl-optimization
 Ever Confirmed||1
   Keywords||diagnostic
  Known to fail||3.4.0
  Known to work||3.3.3 4.0.0
   Last reconfirmed|-00-00 00:00:00 |2005-01-10 03:59:20
   date||
Summary|-O3 -Wunreachable-code  |[3.4 Regression] -O3 -
   |failing |Wunreachable-code failing
   Target Milestone|--- |3.4.4


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

[Bug tree-optimization/18519] [4.0 Regression] ICE: Segmentation fault with optimization

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-01-10 
03:57 ---
Subject: Bug 18519

CVSROOT:/cvs/gcc
Module name:gcc
Branch: apple-gcc_os_35-branch
Changes by: [EMAIL PROTECTED]   2005-01-10 03:57:26

Modified files:
gcc: tree-cfg.c tree-dfa.c tree-flow-inline.h 
 tree-flow.h tree-pretty-print.c 
 tree-ssa-loop-im.c tree-ssa-loop-manip.c 
 tree-ssa-operands.c tree-ssa-operands.h 
 tree-vectorizer.c tree-pass.h tree-ssa-ccp.c 
 tree-ssa-loop-ch.c tree-ssa-loop.c 
 tree-ssa-phiopt.c tree-into-ssa.c 
 tree-optimize.c tree-ssa.c tree-ssa-dce.c 
 ChangeLog.apple-ppc 

Log message:
2005-01-09  Dale Johannesen  <[EMAIL PROTECTED]>

Radar 3941146
Following patches from mainline:
2004-10-27  Daniel Berlin <[EMAIL PROTECTED]>

Fix PR tree-optimization/17133

* tree-cfg.c (rewrite_to_new_ssa_names_bb): Also rewrite must
def kill operand.

* tree-flow-inline.h: V_MUST_DEF_OP became V_MUST_DEF_RESULT.
(get_v_must_def_result_ptr): Modify for new structure of
v_must_defs array.
(get_v_must_def_kill_ptr): New.
(op_iter_next_use): Add support for the kill that occurs in V_MUST_DEFs.
(op_iter_next_tree): Ditto. Also V_MAY_DEF_OP became V_MAY_DEF_RESULT.
(op_iter_next_def): V_MAY_DEF_OP became V_MAY_DEF_RESULT.
(op_iter_init): Initialize new mustu members.
(op_iter_next_mustdef): New function.
(op_iter_init_mustdef): Ditto.

* tree-flow.h (rewrite_def_def_chains): New function.

* tree-into-ssa.c (mark_def_sites): Handle mustdefkill operands.
(ssa_mark_def_sites): Ditto.
(rewrite_stmt): Ditto.
(ssa_rewrite_stmt): Ditto.
(rewrite_blocks): Factor out from rewrite_into_ssa.
(mark_def_block_sites): Ditto.
(rewrite_def_def_chains): New function, just rewrites def-def
chains without phi node insertion.

* tree-pass.h (TODO_fix_def_def_chains): New todo flag.

* tree-optimize.c (execute_todo): Handle TODO_fix_def_def_chains.

* tree-pretty-print.c (dump_vops): Print out MUST_DEF's so that
they include the rhs now.

* tree-ssa-ccp.c (visit_assignment): V_MUST_DEF_OP became
V_MUST_DEF_RESULT.

* tree-ssa-dce.c (mark_operand_necessary): Add phionly argument.
Update callers.
(mark_really_necessary_kill_operand_phis): New function.
(perform_tree_ssa_dce): Call it.
(pass_dce): Add TODO_fix_def_def_chains.
(pass_cd_dce): Ditto.

* tree-ssa-loop-im.c (determine_max_movement): Look at kills as
well.
(rewrite_mem_refs): Ditto.

* tree-ssa-loop-manip.c (find_uses_to_rename_stmt): Look at kills
as well.

* tree-ssa-operands.c (allocate_v_may_def_optype):
v_may_def_operand_type_t became v_def_use_operand_type_t.
(allocate_v_must_def_optype) Ditto.
(finalize_ssa_v_must_defs): Update for new operand type, as well
as setting the use portion as well.
(copy_virtual_operands): Copy the kill operand as well.
(create_ssa_artficial_load_stmt): V_MUST_DEF_OP became
V_MUST_DEF_RESULT.

* tree-ssa-operands.h (v_may_def_operand_type): Renamed to
v_def_use_operand_type.
(v_must_def_optype_d): Use v_def_use_operand_type.
(V_MUST_DEF_OP_*): Renamed to V_MUST_DEF_RESULT_*
(V_MUST_DEF_KILL_*): New macros.
(struct ssa_operand_iterator_d): Add num_v_mustu and v_mustu_i
members.
Rename existing must_i and num_v_must members to mustd_i and
num_v_mustd.
(SSA_OP_VMUSTDEFKILL): New flag.
(SSA_OP_VIRTUAL_KILLS): New flag.
(SSA_OP_ALL_OPERANDS): Add in SSA_OP_ALL_KILLS.
(SSA_OP_ALL_KILLS): New flag.
(FOR_EACH_SSA_MUSTDEF_OPERAND): New macro.

* tree-ssa.c (verify_ssa): Verify virtual kills as well.

* tree-vectorizer.c (vect_create_data_ref_ptr): V_MUST_DEF_OP
became V_MUST_DEF_RESULT.
(rename_variables_in_bb): Rename kill pointer as well.

* tree-dfa.c (compute_immediate_uses_for_stmt): Add kills into the
immediate uses.

2004-10-28  Daniel Berlin  <[EMAIL PROTECTED]>

* tree-into-ssa.c (rewrite_virtual_phi_arguments): New function.
(rewrite_blocks): Modify argument, and use it to decide which
function to call.
(rewrite_def_def_chains): Call rewrite_blocks with true here.
(rewrite_into_ssa): and call it with false here.

2004-1

[Bug tree-optimization/17133] [4.0 Regression] wrong code with -ftree-lim

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-01-10 
03:57 ---
Subject: Bug 17133

CVSROOT:/cvs/gcc
Module name:gcc
Branch: apple-gcc_os_35-branch
Changes by: [EMAIL PROTECTED]   2005-01-10 03:57:26

Modified files:
gcc: tree-cfg.c tree-dfa.c tree-flow-inline.h 
 tree-flow.h tree-pretty-print.c 
 tree-ssa-loop-im.c tree-ssa-loop-manip.c 
 tree-ssa-operands.c tree-ssa-operands.h 
 tree-vectorizer.c tree-pass.h tree-ssa-ccp.c 
 tree-ssa-loop-ch.c tree-ssa-loop.c 
 tree-ssa-phiopt.c tree-into-ssa.c 
 tree-optimize.c tree-ssa.c tree-ssa-dce.c 
 ChangeLog.apple-ppc 

Log message:
2005-01-09  Dale Johannesen  <[EMAIL PROTECTED]>

Radar 3941146
Following patches from mainline:
2004-10-27  Daniel Berlin <[EMAIL PROTECTED]>

Fix PR tree-optimization/17133

* tree-cfg.c (rewrite_to_new_ssa_names_bb): Also rewrite must
def kill operand.

* tree-flow-inline.h: V_MUST_DEF_OP became V_MUST_DEF_RESULT.
(get_v_must_def_result_ptr): Modify for new structure of
v_must_defs array.
(get_v_must_def_kill_ptr): New.
(op_iter_next_use): Add support for the kill that occurs in V_MUST_DEFs.
(op_iter_next_tree): Ditto. Also V_MAY_DEF_OP became V_MAY_DEF_RESULT.
(op_iter_next_def): V_MAY_DEF_OP became V_MAY_DEF_RESULT.
(op_iter_init): Initialize new mustu members.
(op_iter_next_mustdef): New function.
(op_iter_init_mustdef): Ditto.

* tree-flow.h (rewrite_def_def_chains): New function.

* tree-into-ssa.c (mark_def_sites): Handle mustdefkill operands.
(ssa_mark_def_sites): Ditto.
(rewrite_stmt): Ditto.
(ssa_rewrite_stmt): Ditto.
(rewrite_blocks): Factor out from rewrite_into_ssa.
(mark_def_block_sites): Ditto.
(rewrite_def_def_chains): New function, just rewrites def-def
chains without phi node insertion.

* tree-pass.h (TODO_fix_def_def_chains): New todo flag.

* tree-optimize.c (execute_todo): Handle TODO_fix_def_def_chains.

* tree-pretty-print.c (dump_vops): Print out MUST_DEF's so that
they include the rhs now.

* tree-ssa-ccp.c (visit_assignment): V_MUST_DEF_OP became
V_MUST_DEF_RESULT.

* tree-ssa-dce.c (mark_operand_necessary): Add phionly argument.
Update callers.
(mark_really_necessary_kill_operand_phis): New function.
(perform_tree_ssa_dce): Call it.
(pass_dce): Add TODO_fix_def_def_chains.
(pass_cd_dce): Ditto.

* tree-ssa-loop-im.c (determine_max_movement): Look at kills as
well.
(rewrite_mem_refs): Ditto.

* tree-ssa-loop-manip.c (find_uses_to_rename_stmt): Look at kills
as well.

* tree-ssa-operands.c (allocate_v_may_def_optype):
v_may_def_operand_type_t became v_def_use_operand_type_t.
(allocate_v_must_def_optype) Ditto.
(finalize_ssa_v_must_defs): Update for new operand type, as well
as setting the use portion as well.
(copy_virtual_operands): Copy the kill operand as well.
(create_ssa_artficial_load_stmt): V_MUST_DEF_OP became
V_MUST_DEF_RESULT.

* tree-ssa-operands.h (v_may_def_operand_type): Renamed to
v_def_use_operand_type.
(v_must_def_optype_d): Use v_def_use_operand_type.
(V_MUST_DEF_OP_*): Renamed to V_MUST_DEF_RESULT_*
(V_MUST_DEF_KILL_*): New macros.
(struct ssa_operand_iterator_d): Add num_v_mustu and v_mustu_i
members.
Rename existing must_i and num_v_must members to mustd_i and
num_v_mustd.
(SSA_OP_VMUSTDEFKILL): New flag.
(SSA_OP_VIRTUAL_KILLS): New flag.
(SSA_OP_ALL_OPERANDS): Add in SSA_OP_ALL_KILLS.
(SSA_OP_ALL_KILLS): New flag.
(FOR_EACH_SSA_MUSTDEF_OPERAND): New macro.

* tree-ssa.c (verify_ssa): Verify virtual kills as well.

* tree-vectorizer.c (vect_create_data_ref_ptr): V_MUST_DEF_OP
became V_MUST_DEF_RESULT.
(rename_variables_in_bb): Rename kill pointer as well.

* tree-dfa.c (compute_immediate_uses_for_stmt): Add kills into the
immediate uses.

2004-10-28  Daniel Berlin  <[EMAIL PROTECTED]>

* tree-into-ssa.c (rewrite_virtual_phi_arguments): New function.
(rewrite_blocks): Modify argument, and use it to decide which
function to call.
(rewrite_def_def_chains): Call rewrite_blocks with true here.
(rewrite_into_ssa): and call it with false here.

2004-1

[Bug c/19354] New: -O3 -Wunreachable-code failing

[alex at ergens dot op dot het dot net]

When combining "-Wunreachable-code" with any optimizing above zero, "warning:
will never be executed" under certain circumstances.

I've managed to create a small program that does show this bug, unless "nobug"
is defined when compiling.

$ gcc -v
Reading specs from /usr/lib/gcc/i386-redhat-linux/3.4.2/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--disable-checking --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-java-awt=gtk --host=i386-redhat-linux
Thread model: posix
gcc version 3.4.2 20041017 (Red Hat 3.4.2-6.fc3)

$ make
cc -O3 -Wunreachable-code -save-tempstest.c   -o test
test.c: In function `x':
test.c:5: warning: will never be executed

$ cat test.i
# 1 "test.c"
# 1 ""
# 1 ""
# 1 "test.c"
int x(int i,int *j) {
 *j = i;

 if (*j > 31) {
  printf("statement is executed\n");
 } else {



  return 1;
 }
 return 0;
}

int main(int argc,char *argv[]) {
 int i,j,k;

 if (argc != 2) {
  printf("Usage: test \n");
  return 1;
 } else {
  i=atoi(argv[1]);
 }

 k=x(i,&j);
 printf("j is now:  %i\n",j);
}




$ ./test 123
statement is executed
j is now:  123
$ ./test 1
j is now:  1


rm test
mv test.i test.i.old


$ cc -O3 -Wunreachable-code -save-tempstest.c   -o test -Dnobug
$ diff test.i test.i.old
12c12
<   printf("statement is not executed\n");
---
>



In case it isn't clear:  my test.c program contains:

} else {
#ifdef nobug
printf("statement is not executed\n");
#endif
return 1;
}

-- 
   Summary: -O3 -Wunreachable-code failing
   Product: gcc
   Version: 3.4.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: alex at ergens dot op dot het dot net
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug c++/19288] No more possible to have a template function that uses a nested class of a template class

[jean-pierre dot chevallet at imag dot fr]

--- Additional Comments From jean-pierre dot chevallet at imag dot fr  
2005-01-10 03:04 ---
(In reply to comment #3)
> Giving explicit template arguments for template operators works 
> the same way: write 
>   x.operator<<  (abc) 
> instead of 
>   x << abc 
>  

Ok, I have test it but with a function operator : it doesn't seems to work.
So what is wrong ??

#include 

using namespace std;

template  class C1 {
public:
  T V;
  C1(T v) : V(v) {};
  
  class nested {
  public:
T W;
nested(T w) : W(w) {};
  };
  
};

// Template version of operator using nested temptate class
template 
ostream&  operator << (ostream& out,typename C1::nested& c) {return 
out<::nested& c) {return out<::nested n(3.5);
  cout< (n);
  // Never works : because << is a function and not a member function

  //operator<<  (cout,n);
  // Never work !! but it should ???
}

-- 


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

[Bug driver/19353] Faulty handling of startfile_prefix_spec

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-10 
02:52 ---
Patch to remove STARTFILE_PREFIX_SPEC support:
.


-- 


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

[Bug c/19090] Non-useful warnings included in -Wall

[ak at muc dot de]

--- Additional Comments From ak at muc dot de  2005-01-10 02:39 ---
Created an attachment (id=7915)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7915&action=view)
Patch to add -Wno-pointer-sign


This patch adds a new flag to disable this warning. With that the kernel
compilation is down to a few hundred warnings only.


-- 


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

[Bug driver/19353] Faulty handling of startfile_prefix_spec

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-10 
02:36 ---
Hmm, this SPEC should be removed from the mainline, it is unused in GCC at all.
Most of the use of this was removed when this patch was applied:
.

In fact it was added only for Multi-lib places:
.

-- 


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

[Bug driver/19353] New: Faulty handling of startfile_prefix_spec

[gschafer at zip dot com dot au]

This test case is about the spec `startfile_prefix_spec', tho' I suspect the
problem might actually be a generic specs problem, but am not sure.

Scenario:
Say you want to link executables with startfiles different from those in the
default location on your system. Sure, I can use -B, but there are times when
you want this hardwired into the compiler's specs, so this bug is about specs
handling.

To reproduce the problem, follow these steps:

1. Copy some startfiles to /tmp
 cp /usr/lib/{crt1.o,crti.o,crtn.o} /tmp

2. GCC-4 no longer installs a specs file so we'll create a temporary one:
 gcc -dumpspecs > /tmp/specs

3. Now edit /tmp/specs so that startfile_prefix_spec points at /tmp/

4. Compile a dummy binary with -v and note that it DOES NOT pick up our start
files in /tmp:

$ echo 'main(){}' | cc -x c -specs=/tmp/specs -v -
Using built-in specs.
Reading specs from /tmp/specs
Configured with: ../gcc-20050106T052249/configure --libexecdir=/usr/lib
--enable-shared --enable-languages=c,c++ --enable-clocale=gnu
--enable-threads=posix --enable-__cxa_atexit --disable-checking
Thread model: posix
gcc version 4.0.0 20050106 (experimental)
 /usr/lib/gcc/i686-pc-linux-gnu/4.0.0/cc1 -quiet -v - -quiet -dumpbase -
-mtune=pentiumpro -auxbase - -version -o /tmp/ccsb8sUR.s
ignoring nonexistent directory "/usr/local/include"
ignoring nonexistent directory
"/usr/lib/gcc/i686-pc-linux-gnu/4.0.0/../../../../i686-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/i686-pc-linux-gnu/4.0.0/include
 /usr/include
End of search list.
GNU C version 4.0.0 20050106 (experimental) (i686-pc-linux-gnu)
compiled by GNU C version 4.0.0 20050106 (experimental).
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
 as -V -Qy -o /tmp/ccQlh4py.o /tmp/ccsb8sUR.s
GNU assembler version 2.15.94.0.2 (i686-pc-linux-gnu) using BFD version
2.15.94.0.2 20041220
 /usr/lib/gcc/i686-pc-linux-gnu/4.0.0/collect2 --eh-frame-hdr -m elf_i386
-dynamic-linker /lib/ld-linux.so.2
/usr/lib/gcc/i686-pc-linux-gnu/4.0.0/../../../crt1.o
/usr/lib/gcc/i686-pc-linux-gnu/4.0.0/../../../crti.o
/usr/lib/gcc/i686-pc-linux-gnu/4.0.0/crtbegin.o
-L/usr/lib/gcc/i686-pc-linux-gnu/4.0.0 -L/usr/lib/gcc/i686-pc-linux-gnu/4.0.0
-L/usr/lib/gcc/i686-pc-linux-gnu/4.0.0/../../.. /tmp/ccQlh4py.o -lgcc
--as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed
/usr/lib/gcc/i686-pc-linux-gnu/4.0.0/crtend.o
/usr/lib/gcc/i686-pc-linux-gnu/4.0.0/../../../crtn.o


5. This time we'll try again, with the difference being that we'll place a specs
file in GCC's default location:

gcc -dumpspecs > `gcc -print-search-dirs | head -n 1 | awk '{ print $2 }'`specs

6. Now edit this one as above ie: place /tmp/ into the startfile_prefix_spec

7. Again, compile a dummy binary with -v and note that this time it DOES pick up
our start files in /tmp:

$ echo 'main(){}' | cc -x c -v -
Reading specs from /usr/lib/gcc/i686-pc-linux-gnu/4.0.0/specs
Configured with: ../gcc-20050106T052249/configure --libexecdir=/usr/lib
--enable-shared --enable-languages=c,c++ --enable-clocale=gnu
--enable-threads=posix --enable-__cxa_atexit --disable-checking
Thread model: posix
gcc version 4.0.0 20050106 (experimental)
 /usr/lib/gcc/i686-pc-linux-gnu/4.0.0/cc1 -quiet -v - -quiet -dumpbase -
-mtune=pentiumpro -auxbase - -version -o /tmp/cchIqhHa.s
ignoring nonexistent directory "/usr/local/include"
ignoring nonexistent directory
"/usr/lib/gcc/i686-pc-linux-gnu/4.0.0/../../../../i686-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/i686-pc-linux-gnu/4.0.0/include
 /usr/include
End of search list.
GNU C version 4.0.0 20050106 (experimental) (i686-pc-linux-gnu)
compiled by GNU C version 4.0.0 20050106 (experimental).
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
 as -V -Qy -o /tmp/ccevdSNe.o /tmp/cchIqhHa.s
GNU assembler version 2.15.94.0.2 (i686-pc-linux-gnu) using BFD version
2.15.94.0.2 20041220
 /usr/lib/gcc/i686-pc-linux-gnu/4.0.0/collect2 --eh-frame-hdr -m elf_i386
-dynamic-linker /lib/ld-linux.so.2 /tmp/crt1.o /tmp/crti.o
/usr/lib/gcc/i686-pc-linux-gnu/4.0.0/crtbegin.o
-L/usr/lib/gcc/i686-pc-linux-gnu/4.0.0 -L/usr/lib/gcc/i686-pc-linux-gnu/4.0.0
-L/tmp /tmp/ccevdSNe.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc
--as-needed -lgcc_s --no-as-needed /usr/lib/gcc/i686-pc-linux-gnu/4.0.0/crtend.o
/tmp/crtn.o


The bug is that startfile_prefix_spec is not being used when I specify another
specs file using -specs=/tmp/specs. I can modify other specs (eg:
dynamic_linker) using the above technique and it works fine.

I tried 3.4.3 and 4.0 and this bug is present in both.

Thankyou

-- 
   Summary: Faulty handling of startfile_prefix_spec
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: driver
AssignedTo: unassig

[Bug rtl-optimization/8361] [3.3/3.4/4.0 regression] C++ compile-time performance regression

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-10 
01:35 ---
I am now getting results which say at -O1, we are now faster than 3.3.2, could 
someone test to make 
sure that they get close results to mine?

-- 


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

[Bug fortran/19352] Recursive IO functions are not allowed (F2003)

[pbrook at gcc dot gnu dot org]

--- Additional Comments From pbrook at gcc dot gnu dot org  2005-01-10 
01:28 ---
This is a f2003 feature, and not legal f95.

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

-- 
   What|Removed |Added

   Severity|normal  |enhancement
   Keywords|wrong-code  |
Summary|Recursive IO functions are  |Recursive IO functions are
   |not allowed |not allowed (F2003)


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

[Bug tree-optimization/16220] [4.0 Regression] Jump pessimization

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-10 
01:05 ---
Fixed by:
2005-01-08  Roger Sayle  <[EMAIL PROTECTED]>

* ifcvt.c (find_if_case_1): Reinstate 2005-01-04 change, now that
the latent bug in rtl_delete_block has been resolved.
aka
2005-01-04  Roger Sayle  <[EMAIL PROTECTED]>

* ifcvt.c (find_if_case_1): Avoid creating an empty forwarder block,
if deleting the then-block allows the test-block to fallthru to the
else-block.

-- 
   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug target/19307] [4.0 Regression] ICE with -msse2 -mno-80387

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-10 
00:52 ---
It also worked with 2004-12-11.

-- 


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

[Bug c++/19311] [3.4/4.0 Regression] ICE in resolve_overloaded_unification

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-10 
00:50 ---
I almost think this was caused by:
2004-07-18  Kriang Lerdsuwanakij  <[EMAIL PROTECTED]>
2004-07-28  Kriang Lerdsuwanakij  <[EMAIL PROTECTED]>

PR c++/13092

Because that is when the date matches up for the regression hunter's dates on 
both the 3.4 branch and 
the mainline.

-- 
   What|Removed |Added

 CC||lerdsuwa at users dot
   ||sourceforge dot net


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

[Bug regression/19174] wrong code regression or library problem in gcc-4.0-20041226

[andre dot maute at gmx dot de]

--- Additional Comments From andre dot maute at gmx dot de  2005-01-10 
00:00 ---
tried gcc-4.0-20050109 compile with gcc-3.4.3 
the problem still appears 

-- 


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

[Bug fortran/18977] LAPACK test xeigtsts segfaults with optimization

[ebotcazou at gcc dot gnu dot org]

-- 
Bug 18977 depends on bug 17675, which changed state.

Bug 17675 Summary: [Regression w.r.t. g77] Alignment constraints not honored in 
EQUIVALENCE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17675

   What|Old Value   |New Value

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |

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

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

[ebotcazou at gcc dot gnu dot org]

--- Additional Comments From ebotcazou at gcc dot gnu dot org  2005-01-09 
23:16 ---
> Should be fixed now.

Unfortunately not all of them:

FAIL: gfortran.dg/g77/980628-10.f  -O0  execution test
FAIL: gfortran.dg/g77/980628-10.f  -O1  execution test
FAIL: gfortran.dg/g77/980628-10.f  -O2  execution test
FAIL: gfortran.dg/g77/980628-10.f  -O3 -fomit-frame-pointer  execution test
FAIL: gfortran.dg/g77/980628-10.f  -O3 -fomit-frame-pointer -funroll-loops 
execution test
FAIL: gfortran.dg/g77/980628-10.f  -O3 -fomit-frame-pointer -funroll-all-loops
-finline-functions  execution test
FAIL: gfortran.dg/g77/980628-10.f  -O3 -g  execution test
FAIL: gfortran.dg/g77/980628-10.f  -Os  execution test
FAIL: gfortran.dg/g77/980628-7.f  -O0  execution test
FAIL: gfortran.dg/g77/980628-7.f  -O1  execution test
FAIL: gfortran.dg/g77/980628-7.f  -O2  execution test
FAIL: gfortran.dg/g77/980628-7.f  -O3 -fomit-frame-pointer  execution test
FAIL: gfortran.dg/g77/980628-7.f  -O3 -fomit-frame-pointer -funroll-loops 
execution test
FAIL: gfortran.dg/g77/980628-7.f  -O3 -fomit-frame-pointer -funroll-all-loops
-finline-functions  execution test
FAIL: gfortran.dg/g77/980628-7.f  -O3 -g  execution test
FAIL: gfortran.dg/g77/980628-7.f  -Os  execution test
FAIL: gfortran.dg/g77/980628-8.f  -O0  execution test
FAIL: gfortran.dg/g77/980628-8.f  -O1  execution test
FAIL: gfortran.dg/g77/980628-8.f  -O2  execution test
FAIL: gfortran.dg/g77/980628-8.f  -O3 -fomit-frame-pointer  execution test
FAIL: gfortran.dg/g77/980628-8.f  -O3 -fomit-frame-pointer -funroll-loops 
execution test
FAIL: gfortran.dg/g77/980628-8.f  -O3 -fomit-frame-pointer -funroll-all-loops
-finline-functions  execution test
FAIL: gfortran.dg/g77/980628-8.f  -O3 -g  execution test
FAIL: gfortran.dg/g77/980628-8.f  -Os  execution test
FAIL: gfortran.dg/g77/980628-9.f  -O0  execution test
FAIL: gfortran.dg/g77/980628-9.f  -O1  execution test
FAIL: gfortran.dg/g77/980628-9.f  -O2  execution test
FAIL: gfortran.dg/g77/980628-9.f  -O3 -fomit-frame-pointer  execution test
FAIL: gfortran.dg/g77/980628-9.f  -O3 -fomit-frame-pointer -funroll-loops 
execution test
FAIL: gfortran.dg/g77/980628-9.f  -O3 -fomit-frame-pointer -funroll-all-loops
-finline-functions  execution test
FAIL: gfortran.dg/g77/980628-9.f  -O3 -g  execution test
FAIL: gfortran.dg/g77/980628-9.f  -Os  execution test
FAIL: gfortran.dg/g77/980701-1.f  -O0  execution test
FAIL: gfortran.dg/g77/980701-1.f  -O1  execution test
FAIL: gfortran.dg/g77/980701-1.f  -O2  execution test
FAIL: gfortran.dg/g77/980701-1.f  -O3 -fomit-frame-pointer  execution test
FAIL: gfortran.dg/g77/980701-1.f  -O3 -fomit-frame-pointer -funroll-loops 
execution test
FAIL: gfortran.dg/g77/980701-1.f  -O3 -fomit-frame-pointer -funroll-all-loops
-finline-functions  execution test
FAIL: gfortran.dg/g77/980701-1.f  -O3 -g  execution test
FAIL: gfortran.dg/g77/980701-1.f  -Os  execution test

Note that Steve's patch fixes all of them.


-- 
   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |


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

[Bug fortran/19292] [metabug] g77 features lacking in gfortran

[ebotcazou at gcc dot gnu dot org]

-- 
Bug 19292 depends on bug 17675, which changed state.

Bug 17675 Summary: [Regression w.r.t. g77] Alignment constraints not honored in 
EQUIVALENCE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17675

   What|Old Value   |New Value

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |

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

[Bug c++/19351] operator new[] can return heap blocks which are too small

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-09 
23:11 ---
(In reply to comment #6)
> There's no multiplication in the source code.  The multiplication is an
> implementation detail.  You can hardly use it to justify the semantics of the
> operation.

Actually the multiplication is not an implementation detail.
The standard says what opator new[] should be passed, just the multiplication 
is included.
sizeof(int[i]) (well if it was valid C++, it is valid C99) is defined as a 
multiplication so it is not an 
implemenation detail.

-- 


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

[Bug c++/19351] operator new[] can return heap blocks which are too small

[fw at deneb dot enyo dot de]

--- Additional Comments From fw at deneb dot enyo dot de  2005-01-09 23:07 
---
There's no multiplication in the source code.  The multiplication is an
implementation detail.  You can hardly use it to justify the semantics of the
operation.

I would expect that std::bad_alloc is thrown.  But I agree that the C++ standard
isn't very clear in this area.  The implementation must ensure that the
postcondition in 5.3.4(10) holds, but the standard doesn't provide a means to
signal failure.  I'm going to post a note to comp.std.c++ on this matter, but
hopefully this will be fixed in GCC as a quality of implementation issue.

The necessary overflow check is should be very cheap because the multiplication
is always by a constant.

-- 


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

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

[pbrook at gcc dot gnu dot org]

--- Additional Comments From pbrook at gcc dot gnu dot org  2005-01-09 
22:59 ---
Should be fixed now.

-- 
   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug fortran/18977] LAPACK test xeigtsts segfaults with optimization

[pbrook at gcc dot gnu dot org]

-- 
Bug 18977 depends on bug 17675, which changed state.

Bug 17675 Summary: [Regression w.r.t. g77] Alignment constraints not honored in 
EQUIVALENCE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17675

   What|Old Value   |New Value

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

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

[Bug fortran/19292] [metabug] g77 features lacking in gfortran

[pbrook at gcc dot gnu dot org]

-- 
Bug 19292 depends on bug 17675, which changed state.

Bug 17675 Summary: [Regression w.r.t. g77] Alignment constraints not honored in 
EQUIVALENCE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17675

   What|Old Value   |New Value

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

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

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

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-01-09 
22:57 ---
Subject: Bug 17675

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-01-09 22:57:45

Modified files:
gcc/fortran: ChangeLog trans-common.c 
gcc/testsuite  : ChangeLog 
Added files:
gcc/testsuite/gfortran.dg: common_2.f90 common_3.f90 

Log message:
2005-01-09  Paul Brook  <[EMAIL PROTECTED]>

PR fortran/17675
* trans-common.c (current_common, current_offset): Remove.
(create_common): Add head argument.
(align_segment): New function.
(apply_segment_offset): New function.
(translate_common): Merge code from new_segment.  Handle alignment.
(new_segment): Remove.
(finish_equivalences): Ensure proper alignment.
testsuite/
* gfortran.dg/common_2.f90: New file.
* gfortran.dg/common_3.f90: New file.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/ChangeLog.diff?cvsroot=gcc&r1=1.288&r2=1.289
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-common.c.diff?cvsroot=gcc&r1=1.18&r2=1.19
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.4874&r2=1.4875
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/common_2.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/common_3.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1



-- 


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

[Bug fortran/19352] Recursive IO functions are not allowed

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-09 
22:53 ---
If I remember correctly to fix this correctly you also need to fix PR 14943.

-- 
   What|Removed |Added

  BugsThisDependsOn||14943
 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-01-09 22:53:28
   date||


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

[Bug fortran/19352] New: Recursive IO functions are not allowed

[pinskia at gcc dot gnu dot org]

In this is both a fortran and a libfortran problem.

Take the following code and try to run it and you will get an internal error:
module mymod
contains
  function mystring ()
character(len=4) :: mystring
write (unit=mystring,fmt='(A)') ''
  end function mystring
end module mymod

program main
  use mymod
  write (unit=*,fmt='(A)') mystring()
end program main

-- 
   Summary: Recursive IO functions are not allowed
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P2
 Component: fortran
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=19352

[Bug c++/19351] operator new[] can return heap blocks which are too small

[bangerth at dealii dot org]

--- Additional Comments From bangerth at dealii dot org  2005-01-09 22:48 
---
I also wonder what the semantics are that you are expecting? I mean,  
you try to allocate an array that is so large that you can't address  
the individual bytes using a size_t, in other words one that is larger   
than the address space the OS provides to your program. That clearly  
doesn't make any sense.  
  
That being said, I understand that the behavior of this is security  
relevant and that any attempt to allocate more memory than is available  
will necessarily have to fail. Thus, our present implementation isn't  
standards conforming, since it returns a reasonable pointer even in  
the case that the allocation should have failed. I would therefore agree  
that this is a problem, and given that memory allocation is an expensive  
operation, one overflow check isn't really time critical.  
  
Unfortunately, the situation is not restricted to libstdc++'s implementation  
of operator new[], since that operator only gets the total size of  
the memory to be allocation, not the size per element and the number of  
elements. Therefore, by the time we get into the implementation of this  
operator, it is already too late. In other words, the overflow check has  
to happen in compiler-generated code, not in the libstdc++ implementation.  
  
I would support the introduction of such code, if necessary guarded by  
some flag, or unconditionally, as a matter of quality of implemetation.  
  
W.  

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-01-09 22:48:34
   date||


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

[Bug c++/19351] operator new[] can return heap blocks which are too small

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-09 
22:47 ---
I would get a clearification from the standards comittee if I were you.  
multiplying a large unsigned 
number by 16 and getting an overflow is werid case but again, the developer 
should be checking the 
size for reality, if they don't it can cause other problems like a seg fault as 
malloc on linux does not 
return null when running out of memory.

-- 


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

[Bug c++/19351] operator new[] can return heap blocks which are too small

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-09 
22:45 ---
But the C++ standard does not say anything about this case.

-- 
   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|WONTFIX |


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

[Bug c++/19351] operator new[] can return heap blocks which are too small

[fw at deneb dot enyo dot de]

--- Additional Comments From fw at deneb dot enyo dot de  2005-01-09 22:35 
---
Why is this undefined behavior?  Would you quote chapter and verse, please?

GCC's behavior violates 5.3.4(10):

"A new-expression passes the amount of space requested to the allocation
function as the first argument of type std::size_t.  That argument shall be no
less than the size of the object being created; [...]"

In this case, the passed value is 16, which is much smaller than the size of the
array.

-- 


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

[Bug c++/19351] operator new[] can return heap blocks which are too small

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-09 
22:25 ---
This is undefined behavor. 

Really there is nothing we can do, just think about this again, the programmer 
should catch this when 
they read in the length.

-- 
   What|Removed |Added

   Severity|normal  |enhancement
 Status|UNCONFIRMED |RESOLVED
 Resolution||WONTFIX


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

[Bug tree-optimization/19333] [4.0 Regression] Compilation SEGFAULTs with -O1 -finline-functions on the x86_64 architecture.

[rakdver at gcc dot gnu dot org]

-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rakdver at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED


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

[Bug c++/19351] New: operator new[] can return heap blocks which are too small

[fw at deneb dot enyo dot de]

operator new[] sometimes returns pointers to heap blocks which are too small. 
When a new array is allocated, the C++ run-time has to calculate its size.  The
product may exceed the maximum value which can be stored in a machine register.
 This error is ignored, and the truncated value is used for the heap allocation.

This may lead to heap overflows and therefore security bugs.  (See
http://cert.uni-stuttgart.de/advisories/calloc.php for further references.)

The test case below uses a user-defined operator new[] to test for the presence
of this problem.  However, the problem itself occurs also with the default
operator new[], but it is probably harder to write a portable test case.

#include 

struct foo
{
  char data[16];
  void* operator new[] (size_t size)
  {
VERIFY(size != sizeof(foo));
VERIFY (false);
return malloc(size);
  }
};

int
main()
{
  size_t size = size_t (-1) / sizeof(foo) + 2;
  try
{
  foo* f = new foo[size];
  VERIFY (f == 0);
  VERIFY (false);
}
  catch(std::bad_alloc&)
{
  return 0;
}
}

-- 
   Summary: operator new[] can return heap blocks which are too
small
   Product: gcc
   Version: 3.4.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fw at deneb dot enyo dot de
CC: gcc-bugs 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=19351

[Bug tree-optimization/18519] [4.0 Regression] ICE: Segmentation fault with optimization

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-01-09 
22:05 ---
Subject: Bug 18519

CVSROOT:/cvs/gcc
Module name:gcc
Branch: apple-ppc-branch
Changes by: [EMAIL PROTECTED]   2005-01-09 22:05:17

Modified files:
gcc: tree-cfg.c tree-dfa.c tree-flow-inline.h 
 tree-flow.h tree-pretty-print.c 
 tree-ssa-loop-im.c tree-ssa-loop-manip.c 
 tree-ssa-operands.c tree-ssa-operands.h 
 tree-vectorizer.c tree-pass.h tree-ssa-ccp.c 
 tree-ssa-loop-ch.c tree-ssa-loop.c 
 tree-ssa-phiopt.c tree-into-ssa.c 
 tree-optimize.c tree-ssa.c tree-ssa-dce.c 
 ChangeLog.apple-ppc 

Log message:
2005-01-09  Dale Johannesen  <[EMAIL PROTECTED]>

Radar 3941146
Following patches from mainline:
2004-10-27  Daniel Berlin <[EMAIL PROTECTED]>

Fix PR tree-optimization/17133

* tree-cfg.c (rewrite_to_new_ssa_names_bb): Also rewrite must
def kill operand.

* tree-flow-inline.h: V_MUST_DEF_OP became V_MUST_DEF_RESULT.
(get_v_must_def_result_ptr): Modify for new structure of
v_must_defs array.
(get_v_must_def_kill_ptr): New.
(op_iter_next_use): Add support for the kill that occurs in V_MUST_DEFs.
(op_iter_next_tree): Ditto. Also V_MAY_DEF_OP became V_MAY_DEF_RESULT.
(op_iter_next_def): V_MAY_DEF_OP became V_MAY_DEF_RESULT.
(op_iter_init): Initialize new mustu members.
(op_iter_next_mustdef): New function.
(op_iter_init_mustdef): Ditto.

* tree-flow.h (rewrite_def_def_chains): New function.

* tree-into-ssa.c (mark_def_sites): Handle mustdefkill operands.
(ssa_mark_def_sites): Ditto.
(rewrite_stmt): Ditto.
(ssa_rewrite_stmt): Ditto.
(rewrite_blocks): Factor out from rewrite_into_ssa.
(mark_def_block_sites): Ditto.
(rewrite_def_def_chains): New function, just rewrites def-def
chains without phi node insertion.

* tree-pass.h (TODO_fix_def_def_chains): New todo flag.

* tree-optimize.c (execute_todo): Handle TODO_fix_def_def_chains.

* tree-pretty-print.c (dump_vops): Print out MUST_DEF's so that
they include the rhs now.

* tree-ssa-ccp.c (visit_assignment): V_MUST_DEF_OP became
V_MUST_DEF_RESULT.

* tree-ssa-dce.c (mark_operand_necessary): Add phionly argument.
Update callers.
(mark_really_necessary_kill_operand_phis): New function.
(perform_tree_ssa_dce): Call it.
(pass_dce): Add TODO_fix_def_def_chains.
(pass_cd_dce): Ditto.

* tree-ssa-loop-im.c (determine_max_movement): Look at kills as
well.
(rewrite_mem_refs): Ditto.

* tree-ssa-loop-manip.c (find_uses_to_rename_stmt): Look at kills
as well.

* tree-ssa-operands.c (allocate_v_may_def_optype):
v_may_def_operand_type_t became v_def_use_operand_type_t.
(allocate_v_must_def_optype) Ditto.
(finalize_ssa_v_must_defs): Update for new operand type, as well
as setting the use portion as well.
(copy_virtual_operands): Copy the kill operand as well.
(create_ssa_artficial_load_stmt): V_MUST_DEF_OP became
V_MUST_DEF_RESULT.

* tree-ssa-operands.h (v_may_def_operand_type): Renamed to
v_def_use_operand_type.
(v_must_def_optype_d): Use v_def_use_operand_type.
(V_MUST_DEF_OP_*): Renamed to V_MUST_DEF_RESULT_*
(V_MUST_DEF_KILL_*): New macros.
(struct ssa_operand_iterator_d): Add num_v_mustu and v_mustu_i
members.
Rename existing must_i and num_v_must members to mustd_i and
num_v_mustd.
(SSA_OP_VMUSTDEFKILL): New flag.
(SSA_OP_VIRTUAL_KILLS): New flag.
(SSA_OP_ALL_OPERANDS): Add in SSA_OP_ALL_KILLS.
(SSA_OP_ALL_KILLS): New flag.
(FOR_EACH_SSA_MUSTDEF_OPERAND): New macro.

* tree-ssa.c (verify_ssa): Verify virtual kills as well.

* tree-vectorizer.c (vect_create_data_ref_ptr): V_MUST_DEF_OP
became V_MUST_DEF_RESULT.
(rename_variables_in_bb): Rename kill pointer as well.

* tree-dfa.c (compute_immediate_uses_for_stmt): Add kills into the
immediate uses.

2004-10-28  Daniel Berlin  <[EMAIL PROTECTED]>

* tree-into-ssa.c (rewrite_virtual_phi_arguments): New function.
(rewrite_blocks): Modify argument, and use it to decide which
function to call.
(rewrite_def_def_chains): Call rewrite_blocks with true here.
(rewrite_into_ssa): and call it with false here.

2004-11-16  

[Bug tree-optimization/17133] [4.0 Regression] wrong code with -ftree-lim

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-01-09 
22:05 ---
Subject: Bug 17133

CVSROOT:/cvs/gcc
Module name:gcc
Branch: apple-ppc-branch
Changes by: [EMAIL PROTECTED]   2005-01-09 22:05:17

Modified files:
gcc: tree-cfg.c tree-dfa.c tree-flow-inline.h 
 tree-flow.h tree-pretty-print.c 
 tree-ssa-loop-im.c tree-ssa-loop-manip.c 
 tree-ssa-operands.c tree-ssa-operands.h 
 tree-vectorizer.c tree-pass.h tree-ssa-ccp.c 
 tree-ssa-loop-ch.c tree-ssa-loop.c 
 tree-ssa-phiopt.c tree-into-ssa.c 
 tree-optimize.c tree-ssa.c tree-ssa-dce.c 
 ChangeLog.apple-ppc 

Log message:
2005-01-09  Dale Johannesen  <[EMAIL PROTECTED]>

Radar 3941146
Following patches from mainline:
2004-10-27  Daniel Berlin <[EMAIL PROTECTED]>

Fix PR tree-optimization/17133

* tree-cfg.c (rewrite_to_new_ssa_names_bb): Also rewrite must
def kill operand.

* tree-flow-inline.h: V_MUST_DEF_OP became V_MUST_DEF_RESULT.
(get_v_must_def_result_ptr): Modify for new structure of
v_must_defs array.
(get_v_must_def_kill_ptr): New.
(op_iter_next_use): Add support for the kill that occurs in V_MUST_DEFs.
(op_iter_next_tree): Ditto. Also V_MAY_DEF_OP became V_MAY_DEF_RESULT.
(op_iter_next_def): V_MAY_DEF_OP became V_MAY_DEF_RESULT.
(op_iter_init): Initialize new mustu members.
(op_iter_next_mustdef): New function.
(op_iter_init_mustdef): Ditto.

* tree-flow.h (rewrite_def_def_chains): New function.

* tree-into-ssa.c (mark_def_sites): Handle mustdefkill operands.
(ssa_mark_def_sites): Ditto.
(rewrite_stmt): Ditto.
(ssa_rewrite_stmt): Ditto.
(rewrite_blocks): Factor out from rewrite_into_ssa.
(mark_def_block_sites): Ditto.
(rewrite_def_def_chains): New function, just rewrites def-def
chains without phi node insertion.

* tree-pass.h (TODO_fix_def_def_chains): New todo flag.

* tree-optimize.c (execute_todo): Handle TODO_fix_def_def_chains.

* tree-pretty-print.c (dump_vops): Print out MUST_DEF's so that
they include the rhs now.

* tree-ssa-ccp.c (visit_assignment): V_MUST_DEF_OP became
V_MUST_DEF_RESULT.

* tree-ssa-dce.c (mark_operand_necessary): Add phionly argument.
Update callers.
(mark_really_necessary_kill_operand_phis): New function.
(perform_tree_ssa_dce): Call it.
(pass_dce): Add TODO_fix_def_def_chains.
(pass_cd_dce): Ditto.

* tree-ssa-loop-im.c (determine_max_movement): Look at kills as
well.
(rewrite_mem_refs): Ditto.

* tree-ssa-loop-manip.c (find_uses_to_rename_stmt): Look at kills
as well.

* tree-ssa-operands.c (allocate_v_may_def_optype):
v_may_def_operand_type_t became v_def_use_operand_type_t.
(allocate_v_must_def_optype) Ditto.
(finalize_ssa_v_must_defs): Update for new operand type, as well
as setting the use portion as well.
(copy_virtual_operands): Copy the kill operand as well.
(create_ssa_artficial_load_stmt): V_MUST_DEF_OP became
V_MUST_DEF_RESULT.

* tree-ssa-operands.h (v_may_def_operand_type): Renamed to
v_def_use_operand_type.
(v_must_def_optype_d): Use v_def_use_operand_type.
(V_MUST_DEF_OP_*): Renamed to V_MUST_DEF_RESULT_*
(V_MUST_DEF_KILL_*): New macros.
(struct ssa_operand_iterator_d): Add num_v_mustu and v_mustu_i
members.
Rename existing must_i and num_v_must members to mustd_i and
num_v_mustd.
(SSA_OP_VMUSTDEFKILL): New flag.
(SSA_OP_VIRTUAL_KILLS): New flag.
(SSA_OP_ALL_OPERANDS): Add in SSA_OP_ALL_KILLS.
(SSA_OP_ALL_KILLS): New flag.
(FOR_EACH_SSA_MUSTDEF_OPERAND): New macro.

* tree-ssa.c (verify_ssa): Verify virtual kills as well.

* tree-vectorizer.c (vect_create_data_ref_ptr): V_MUST_DEF_OP
became V_MUST_DEF_RESULT.
(rename_variables_in_bb): Rename kill pointer as well.

* tree-dfa.c (compute_immediate_uses_for_stmt): Add kills into the
immediate uses.

2004-10-28  Daniel Berlin  <[EMAIL PROTECTED]>

* tree-into-ssa.c (rewrite_virtual_phi_arguments): New function.
(rewrite_blocks): Modify argument, and use it to decide which
function to call.
(rewrite_def_def_chains): Call rewrite_blocks with true here.
(rewrite_into_ssa): and call it with false here.

2004-11-16  

[Bug other/18720] collect2 uses wrong search order if -brtl specified

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-01-09 
22:02 ---
Subject: Bug 18720

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-01-09 22:01:49

Modified files:
gcc: ChangeLog collect2.c 

Log message:
PR target/18720
* collect2.c (main): Set aixrtl_flag for -brtl option.
(resolve_lib_name): Search for .so file extension before .a
if aixrtl_flag set.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.7076&r2=2.7077
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/collect2.c.diff?cvsroot=gcc&r1=1.167&r2=1.168



-- 


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

[Bug target/19350] Compilation with -O1 -ftree-vectorize gives unrecognizable insn on x86.

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-09 
21:26 ---
I get a different error with today's compiler but that is because I am not 
compiling with --disable-
checking.
t.c:7: internal compiler error: in simplify_binary_operation, at 
simplify-rtx.c:2178

WTF:
(set (reg:V4SI 94)
(vec_concat:V4SF (mem:V2SF (reg:SI 64 [ ivtmp.66 ]) [0 S8 A8])
(vec_select:V2SF (reg:V4SI 94)
(parallel [
(const_int 2 [0x2])
(const_int 3 [0x3])
]

Which comes from the expansion of 
;; *(vect_p.22 + (vector int *) D.1440 * 16B - 16B) = M*ivtmp.66{misalignment: 
0}


-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Keywords||ice-on-valid-code
   Last reconfirmed|-00-00 00:00:00 |2005-01-09 21:26:45
   date||


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

[Bug target/19350] New: Compilation with -O1 -ftree-vectorize gives unrecognizable insn on x86.

[drab at kepler dot fjfi dot cvut dot cz]

Following test code

-- test.c ---
typedef struct { int x; int y[16]; } ta;
typedef struct { int y[16]; } tb;
void f (tb *b)
{
int i, j; ta *a;
for (i=0, j=a->x; iy[i] = a->y[i];
}
-

when compiled with

-
gcc -O1 -ftree-vectorize -S test.c -o test.s
-

using

-
$ gcc -v
Using built-in specs.
Configured with: ../../../gcc-CVS-20050107/gcc-CVS-20050107/configure
--host=i786-pc-linux-gnu --prefix=/usr/local/opt/gcc-4.0
--exec-prefix=/usr/local/opt/gcc-4.0 --sysconfdir=/etc
--libdir=/usr/local/opt/gcc-4.0/lib --libexecdir=/usr/local/opt/gcc-4.0/libexec
--sharedstatedir=/var --localstatedir=/var --program-suffix=-4.0
--with-x-includes=/usr/X11R6/include --with-x-libraries=/usr/X11R6/lib
--enable-shared --enable-static --with-gnu-as --with-gnu-ld --with-stabs
--enable-threads=posix --enable-version-specific-runtime-libs --disable-coverage
--enable-gather-detailed-mem-stats --disable-libgcj --disable-checking
--enable-multilib --with-x --enable-cmath --enable-libstdcxx-debug
--enable-fast-character --enable-hash-synchronization --with-system-zlib
--with-libbanshee --with-demangler-in-ld --with-arch=athlon-xp --enable-libada
--enable-languages=c,c++,f95,objc,ada
Thread model: posix
gcc version 4.0.0 20050107 (experimental)
$
-

gives

-
test.c: In function 'f':
test.c:7: error: unrecognizable insn:
(insn 69 68 70 6 (set (reg:V4SI 94)
(vec_concat:V4SF (mem:V2SF (reg:SI 64 [ ivtmp.66 ]) [0 S8 A8])
(vec_select:V2SF (reg:V4SI 94)
(parallel [
(const_int 2 [0x2])
(const_int 3 [0x3])
] -1 (insn_list:REG_DEP_TRUE 68 (nil))
(nil))
test.c:7: internal compiler error: in extract_insn, at recog.c:2020
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
-

Works on x86_64 arch. (compiled by the native gcc compiled from the same sources
as the one mentioned above).

-- 
   Summary: Compilation with -O1 -ftree-vectorize gives
unrecognizable insn on x86.
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P1
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: drab at kepler dot fjfi dot cvut dot cz
CC: gcc-bugs 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=19350

[Bug c++/19349] New: Valgrind errors compiling libjava c++ sources

[mark at gcc dot gnu dot org]

When configuring with --enable-checking=assert,misc,tree,gc,rtlflag,valgrind
compilation of some c++ source files in the libjava directory give the 
following  
invalid reads:

/home/mark/src/gcc-obj/gcc/xgcc -shared-libgcc -B/home/mark/src/gcc-obj/gcc/
-nostdinc++ -L/home/mark/src/gcc-obj/i686-pc-linux-gnu/libstdc++-v3/src
-L/home/mark/src/gcc-obj/i686-pc-linux-gnu/libstdc++-v3/src/.libs
-B/usr/local/gcc40/i686-pc-linux-gnu/bin/
-B/usr/local/gcc40/i686-pc-linux-gnu/lib/ -isystem
/usr/local/gcc40/i686-pc-linux-gnu/include -isystem
/usr/local/gcc40/i686-pc-linux-gnu/sys-include -DHAVE_CONFIG_H -I.
-I../../../gcc/libjava -I./include -I./gcj -I../../../gcc/libjava -Iinclude
-I../../../gcc/libjava/include -I../../../gcc/libjava/../boehm-gc/include
-I../boehm-gc/include -I../../../gcc/libjava/libltdl
-I../../../gcc/libjava/libltdl -I../../../gcc/libjava/.././libjava/../gcc
-I../../../gcc/libjava/../zlib -I../../../gcc/libjava/../libffi/include
-I../libffi/include -O2 -g -O2 -fno-rtti -fnon-call-exceptions
-fdollars-in-identifiers -Wswitch-enum -D_FILE_OFFSET_BITS=64 -ffloat-store
-fno-omit-frame-pointer -I/usr/X11R6/include -Wextra -Wall -D_GNU_SOURCE
-DPREFIX=\"/usr/local/gcc40\" -DLIBDIR=\"/usr/local/gcc40/lib\"
-DBOOT_CLASS_PATH=\"/usr/local/gcc40/share/java/libgcj-4.0.0.jar\"
-DJAVA_EXT_DIRS=\"/usr/local/gcc40/share/java/ext\" -g -O2 -D_GNU_SOURCE -MT
prims.lo -MD -MP -MF .deps/prims.Tpo -c ../../../gcc/libjava/prims.cc  -fPIC
-DPIC -o .libs/prims.o
==28413== Invalid read of size 1
==28413==at 0x814DA3B: pushdecl_namespace_level (name-lookup.c:3027)
==28413==by 0x81188C5: do_friend (friend.c:546)
==28413==by 0x8072546: grokdeclarator (decl.c:8084)
==28413==by 0x80D07D4: grokfield (decl2.c:845)
==28413==  Address 0x1C32087C is not stack'd, malloc'd or (recently) free'd

-- 
   Summary: Valgrind errors compiling libjava c++ sources
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mark at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug target/19334] darwin backend places some CONST_DECLs in the wrong section

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-09 
20:07 ---
Patch here: .

-- 
   What|Removed |Added

   Keywords||patch


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

[Bug target/13891] [3.4/4.0 Regression] support for openbsd 3.4 nonexistent

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Severity|enhancement |minor
Summary|support for openbsd 3.4 |[3.4/4.0 Regression] support
   |nonexistent |for openbsd 3.4 nonexistent
   Target Milestone|--- |4.0.0


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

[Bug target/19334] darwin backend places some CONST_DECLs in the wrong section

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-09 
19:31 ---
(In reply to comment #14)
> (In reply to comment #12)
> > The output from gfortran -fdump-tree-gimple (I hope this was the right 
> > thing to
> > do)
> 
> -fdump-tree-original gives you the output of the frontend, so if the frontend
> produces crap, it will be in this dump.  In your case it didn't make a
> difference, but usually the gimple dump is much harder to read because the
> originial generic gets converted to ssa form (single static assignment).  
> IIUC,
> of course.

Actually -fdump-tree-gimple dumps gimple form which is a lowered form of 
generic (not all the way 
down but slightly more, in that gimple have a simplified grammar per statement 
and generic).

-- 


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

[Bug target/19334] darwin backend places some CONST_DECLs in the wrong section

[tobi at gcc dot gnu dot org]

--- Additional Comments From tobi at gcc dot gnu dot org  2005-01-09 19:28 
---
(In reply to comment #12)
> The output from gfortran -fdump-tree-gimple (I hope this was the right thing 
> to
> do)

-fdump-tree-original gives you the output of the frontend, so if the frontend
produces crap, it will be in this dump.  In your case it didn't make a
difference, but usually the gimple dump is much harder to read because the
originial generic gets converted to ssa form (single static assignment).  IIUC,
of course.

-- 


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

[Bug rtl-optimization/18853] [4.0 Regression] ICE: genautomata.c:5238, error: verify_flow_info: Incorrect fallthru

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-09 
19:25 ---
This works on the 3.4 branch so it is a regression from there.

-- 
   What|Removed |Added

  Component|bootstrap   |rtl-optimization
  Known to work|3.3.2   |3.3.2 3.4.4


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

[Bug target/19334] darwin backend places some CONST_DECLs in the wrong section

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-09 
19:21 ---
Here is a reduced testcase now without ISHFT:
  call c_i1(0_1)
  end



-- 
   What|Removed |Added

Summary|ISHFT has the wrong type for|darwin backend places some
   |constant values |CONST_DECLs in the wrong
   ||section


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

[Bug libgcj/15560] SimpleTimeZone doesn't handle on-or-before/after at ends of month

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-09 
19:06 ---
Patch here: .

-- 
   What|Removed |Added

   Keywords||patch


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

[Bug ada/18817] ACATS c380004 fails at run time

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-09 
19:01 ---
Confirmed, via the testsuite run and moving to minor as this is a off in left 
field case.

-- 
   What|Removed |Added

   Severity|normal  |minor
 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-01-09 19:01:45
   date||


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

[Bug libgcj/17069] InetAddress.getLocalHost() returns broken InetAddress object if hostname not set

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-09 
18:59 ---
Fixed on the mainline (aka for 4.0.0).

-- 
   What|Removed |Added

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


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

[Bug other/19075] [4.0 regression] mmix-knuth-mmixware testsuite failure: gcc.dg/tree-ssa/loop-4.c arr_base

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-09 
18:59 ---
And that patch was committed so this is fixed.

-- 
   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug other/19075] [4.0 regression] mmix-knuth-mmixware testsuite failure: gcc.dg/tree-ssa/loop-4.c arr_base

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-09 
18:58 ---
The only regression here is the testsuite failure.

-- 
   What|Removed |Added

  Component|target  |other


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

[Bug libgcj/17069] InetAddress.getLocalHost() returns broken InetAddress object if hostname not set

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-01-09 
18:57 ---
Subject: Bug 17069

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-01-09 18:57:33

Modified files:
libjava: ChangeLog 
libjava/java/net: InetAddress.java 

Log message:
2005-01-09  Michael Koch  <[EMAIL PROTECTED]>

PR libgcj/17069
* java/net/InetAddress.java (getLocalHost):
Throw UnknownHostException if local hostname cannot be determined.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/ChangeLog.diff?cvsroot=gcc&r1=1.3275&r2=1.3276
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/java/net/InetAddress.java.diff?cvsroot=gcc&r1=1.34&r2=1.35



-- 


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

[Bug target/19075] [4.0 regression] mmix-knuth-mmixware testsuite failure: gcc.dg/tree-ssa/loop-4.c arr_base

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-09 
18:56 ---
Confirmed, this is not a missed-optimization after all.
Patch here to fix the testcase: 
.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Keywords|missed-optimization |patch
   Last reconfirmed|-00-00 00:00:00 |2005-01-09 18:56:58
   date||


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

[Bug middle-end/19084] [4.0 Regression] ICE: internal consistency failure

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-09 
18:53 ---
Confirmed, I don't know if this is a regression or not but I am going to assume 
so as I could not 
reproduce this before.
Reduced testcase:
unsigned long long
__lcong48_r (unsigned short param)
{
  return ((unsigned long long) param << 32);
}


-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-01-09 18:53:53
   date||
Summary|ICE: internal consistency   |[4.0 Regression] ICE:
   |failure |internal consistency failure
   Target Milestone|--- |4.0.0


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

[Bug c/19346] [4.0 Regression] Wrong warnings about undefined aliases

[rth at gcc dot gnu dot org]

--- Additional Comments From rth at gcc dot gnu dot org  2005-01-09 18:49 
---
Indeed, they DO NOT work, and never have.  The warning is correct.

-- 
   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||INVALID


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

[Bug rtl-optimization/19348] [4.0 Regression] internal consistency error while compiling linux kernel

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-09 
18:49 ---
(In reply to comment #2)
> This might be a duplicate of PR19084. 
I don't think it is but it is related.
This one can be reproduced with a native 32bit compiler while PR 19084 I cannot.

-- 


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

[Bug c/19346] [4.0 Regression] Wrong warnings about undefined aliases

[rth at gcc dot gnu dot org]

--- Additional Comments From rth at gcc dot gnu dot org  2005-01-09 18:46 
---
I hadn't realized aliases to COMMON symbols ever worked...

-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rth at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED


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

[Bug rtl-optimization/19348] [4.0 Regression] internal consistency error while compiling linux kernel

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-09 
18:45 ---
Confirmed.
: Search converges between 2004-09-12-trunk (#538) and 2004-09-14-trunk (#539).
Reduced testcase:
unsigned int encode_float(unsigned long long value)
{
 unsigned u;

 if (value==0) return 0;
 u = (unsigned int)(value >> 32);
 return u;
}


-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
 GCC target triplet|i386-linux (actually x86_64 |i686-linux
   |-m32)   |
   Keywords||ice-on-valid-code
   Last reconfirmed|-00-00 00:00:00 |2005-01-09 18:45:09
   date||
Summary|internal consistency error  |[4.0 Regression] internal
   |while compiling linux kernel|consistency error while
   ||compiling linux kernel
   Target Milestone|--- |4.0.0


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

[Bug ada/19337] [4.0 Regression] ada does not compile

[laurent at guerby dot net]

--- Additional Comments From laurent at guerby dot net  2005-01-09 18:22 
---
Could you paste the 10 last compile lines of your log? We cannot say wether it's
stage2, 3 or part of gnattools that is failing from your report.

Please also give your complete configure line, and the list of all commands
you've called after configure to get this result. Also make sure
the prefix directory is empty before configure so we're not
using some half-built tools.

As you've seen many people are building successfully Ada daily, so this is
something on your side, we need all details of what you did to be able to help.

-- 


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

[Bug ada/19337] [4.0 Regression] ada does not compile

[heitkamp at ameritech dot net]

--- Additional Comments From heitkamp at ameritech dot net  2005-01-09 
18:14 ---
Subject: Re:  [4.0 Regression] ada does not compile

On Sun, 9 Jan 2005, pinskia at gcc dot gnu dot org wrote:

I Checked out a clean version and got the same error.

+===GNAT BUG 
DETECTED==+
| 4.0.0 20050109 (experimental) (i686-pc-linux-gnu) GCC error: 
|
| in make_decl_rtl, at varasm.c:867 
|
| Error detected at ali.adb:2098:1 
|
| Please submit a bug report; see http://gcc.gnu.org/bugs.html. 
|
| Include the entire contents of this bug box in the report. 
|
| Include the exact gcc or gnatmake command that you entered. 
|
| Also include sources listed below in gnatchop format 
|
| (concatenated together with no headers between files). 
|
+==+

Please include these source files with error report
Note that list may not be accurate in some cases,
so please double check that the problem can still
be reproduced with the set of files listed.

../../gcc-cvs/gcc/gcc/ada/ali.adb
../../gcc-cvs/gcc/gcc/ada/ali.ads
../../gcc-cvs/gcc/gcc/ada/casing.ads
../../gcc-cvs/gcc/gcc/ada/types.ads
../../gcc-cvs/gcc/gcc/ada/gnatvsn.ads
../../gcc-cvs/gcc/gcc/ada/rident.ads
../../gcc-cvs/gcc/gcc/ada/table.ads
../../gcc-cvs/gcc/gcc/ada/butil.ads
../../gcc-cvs/gcc/gcc/ada/debug.ads
../../gcc-cvs/gcc/gcc/ada/fname.ads
../../gcc-cvs/gcc/gcc/ada/namet.ads
../../gcc-cvs/gcc/gcc/ada/alloc.ads
../../gcc-cvs/gcc/gcc/ada/opt.ads
../../gcc-cvs/gcc/gcc/ada/hostparm.ads
../../gcc-cvs/gcc/gcc/ada/osint.ads
../../gcc-cvs/gcc/gcc/ada/output.ads
../../gcc-cvs/gcc/gcc/ada/table.adb
../../gcc-cvs/gcc/gcc/ada/tree_io.ads


raised TYPES.UNRECOVERABLE_ERROR : comperr.adb:387


>
> --- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-09 
> 16:06 ---
> (In reply to comment #5)
>> Subject: Re:  [4.0 Regression] ada does not compile
>>
>> On Sat, 8 Jan 2005, pinskia at gcc dot gnu dot org wrote:
>>
>> Which file are you refering to? How do I check this?  I am a novice.
>> Thanks.
>
>
> I was asking a CVS question, check out CVS/TAGS but I would not know which 
> files have the tag set.
>
> I would check out a clean CVS version if this is a CVS, otherwise download a 
> snapshot.
>
> --
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19337
>
> --- You are receiving this mail because: ---
> You reported the bug, or are watching the reporter.
>


Fred

Error Loading Explorer.exe
You must reinstall Windows.


-- 


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

[Bug ada/19337] [4.0 Regression] ada does not compile

[aj at gcc dot gnu dot org]

--- Additional Comments From aj at gcc dot gnu dot org  2005-01-09 18:00 
---
Btw. this crashes in the same place as in PR 19241. 

-- 


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

[Bug rtl-optimization/19348] internal consistency error while compiling linux kernel

[aj at gcc dot gnu dot org]

--- Additional Comments From aj at gcc dot gnu dot org  2005-01-09 17:57 
---
This might be a duplicate of PR19084. 

-- 
   What|Removed |Added

 CC||aj at gcc dot gnu dot org,
   ||hubicka at gcc dot gnu dot
   ||org


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

[Bug rtl-optimization/19348] internal consistency error while compiling linux kernel

[ak at muc dot de]

--- Additional Comments From ak at muc dot de  2005-01-09 17:41 ---
Created an attachment (id=7913)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7913&action=view)
Preprocessed acct.c file from linux 2.6 kernel


-- 


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

[Bug rtl-optimization/19348] New: internal consistency error while compiling linux kernel

[ak at muc dot de]

(guessing at component) 

While compiling the attached file from the linux 2.6 kernel with
-march=i686  -fno-unit-at-a-time  -m32 -Os I get:
-a-time  -S -m32 -Os acct-full.i
/home/lsrc/v2.6/quilt/linux/kernel/acct.c: In function `encode_float':
/home/lsrc/v2.6/quilt/linux/kernel/acct.c:366: fatal error: internal consistency
failure
compilation terminated.

It needs these options, removing -fno-unit-at-a-time or -march=i686 makes it go 
away

The compiler was built without checking: 

Configured with: ../gcc/configure --disable-checking --enable-languages=c
--prefix=/pkg/gcc-4.0-050109
Thread model: posix
gcc version 4.0.0 20050108 (experimental)

-- 
   Summary: internal consistency error while compiling linux kernel
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ak at muc dot de
CC: gcc-bugs at gcc dot gnu dot org
  GCC host triplet: x86_64-linux
GCC target triplet: i386-linux (actually x86_64 -m32)


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

[Bug target/19334] ISHFT has the wrong type for constant values

[coudert at clipper dot ens dot fr]

--- Additional Comments From coudert at clipper dot ens dot fr  2005-01-09 
16:50 ---
Reduced case (from FP19335) still fails on powerpc-darwin with Tobias' patch.
The output from gfortran -fdump-tree-gimple (I hope this was the right thing to
do) is the same with and without -fmerge-constants, though the second fails at
link time. Here is the tree, with Tobias' modification to the pretty printer:

MAIN__ ()
{
  int1 k;

  k = 0_S8;
  _gfortran_filename = "reduced.f";
  _gfortran_line = 3_S32;
  _gfortran_ioparm.unit = 6_S32;
  _gfortran_ioparm.list_format = 1_S32;
  _gfortran_st_write ();
  {
int1 C.417 = 0_S8;

_gfortran_transfer_integer (&C.417, 1_S32);
  }
  _gfortran_st_write_done ();
}

-- 


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

[Bug c++/19343] [4.0 Regression] New warnings in libstdc++-v3 since 2004-01-05

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-09 
16:46 ---
But I do get it on my daily builds on i686-openbsd3.1 starting on the 7th.
I will try to reduce this later today once I finish some homework and get some 
food.

-- 


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

[Bug target/14436] [3.3/3.4 regression] ICE building libgcc.a

[joel at gcc dot gnu dot org]

--- Additional Comments From joel at gcc dot gnu dot org  2005-01-09 16:37 
---
(In reply to comment #9)
> Fixed on the mainline.

Could this fix be applied to the 3.4 branch? 

-- 
   What|Removed |Added

  Known to fail|3.3.3 3.4.0 |3.3.3 3.4.0 3.4.3


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

[Bug tree-optimization/18403] FAILs to vectorize testcases on ppc64-linux

[dorit at il dot ibm dot com]

--- Additional Comments From dorit at il dot ibm dot com  2005-01-09 16:35 
---
vect-[46,50,52,58,60] don't fail anymore, and vect-[77,78] xfail on vectorizing 
for lp62 targets, so I think we can classify this PR as missed-optimization 
only, or close it and open a new (missed-optimization) PR for vect-[77,78].c 
(for lp64 targets).

-- 


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

[Bug tree-optimization/19241] [4.0 Regression] ICE in make_decl_rtl with inliner

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-09 
16:20 ---
I think this was caused by:
2004-08-07  Jason Merrill  <[EMAIL PROTECTED]>

Make return in memory explicit.
* function.c (aggregate_value_p): Check DECL_BY_REFERENCE.
(assign_parm_find_data_types): Remove code for old front end
invisible reference handling.

which would confirm my theory about the return value not being mapped correctly.

-- 
   What|Removed |Added

 CC||jason at redhat dot com


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

[Bug ada/19337] [4.0 Regression] ada does not compile

[heitkamp at ameritech dot net]

--- Additional Comments From heitkamp at ameritech dot net  2005-01-09 
16:09 ---
Subject: Re:  [4.0 Regression] ada does not compile

On Sat, 8 Jan 2005, laurent at guerby dot net wrote:

I would be glad to provide any other information that you may need to 
reproduce the bug or give more insight into the problem.  Let me know.

I have an Athlon MP dual processor system running Linux 2.6.10 and glibc 
2.3.90.

Fred

>
> --- Additional Comments From laurent at guerby dot net  2005-01-08 22:11 
> ---
> I can't reproduce this on mainline x86 and x86_64 both work fine (in make 
> check
> right now).
>
> --
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19337
>
> --- You are receiving this mail because: ---
> You reported the bug, or are watching the reporter.
>


-- 


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

[Bug tree-optimization/19241] [4.0 Regression] ICE in make_decl_rtl with inliner

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-09 
16:08 ---
(In reply to comment #29)
> Subject: Re:  [4.0 Regression] ICE in make_decl_rtl with inliner
> I did already once, but it really seem to be template instanciation
> problem.  I will try harder...

In the small test case, there is no templates ...

I think the return value does not get mapped correctly but I could be totally 
wrong.

-- 


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

[Bug target/15491] ICE (Internal compiler error) while compiling glibc to vax-linux target

[danglin at gcc dot gnu dot org]

--- Additional Comments From danglin at gcc dot gnu dot org  2005-01-09 
16:08 ---
Could you test this change?  I've done a full bootstrap with an x86 cross
to vax-ultrix but this doesn't provide a full test.

The ICE was introduced in the 3.4 branch when the macro RTX_COSTS was
removed.  This macro contained a switch statement containing a list of
codes that vax_rtx_costs could handle.  This list appeared redundant
but it was in fact protecting vax_rtx_costs from being exposed to rts's
such EXPR_LIST that it wasn't designed to handle.  I've now reworked
vax_rtx_costs to eliminate an unnecessary calling layer and to return
false for rtx codes that it can't handle.

In doing this rework, it became clear that vax_rtx_costs was broken
in a number of ways:

1) Various rtx codes used in the machine definition were missing,
2) The POST_INC and PRE_DEC codes were not accessible in 3.3 and
   earlier,
3) The operands for NEG and NOT were not being included in the cost
   estimate.

I've tried to fix the ICE and the above problems.  The missing
codes are given a default cost of 3 which certainly isn't right.
However, as can be seen from the comments in the function, the
cost estimates are only approximate and variations occur from
cpu to cpu.

I will try to test the patch latter but my vax is currently
busy doing a 3.3 build.



-- 
   What|Removed |Added

 Status|NEW |WAITING


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

[Bug ada/19337] [4.0 Regression] ada does not compile

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-09 
16:06 ---
(In reply to comment #5)
> Subject: Re:  [4.0 Regression] ada does not compile
> 
> On Sat, 8 Jan 2005, pinskia at gcc dot gnu dot org wrote:
> 
> Which file are you refering to? How do I check this?  I am a novice. 
> Thanks.


I was asking a CVS question, check out CVS/TAGS but I would not know which 
files have the tag set.

I would check out a clean CVS version if this is a CVS, otherwise download a 
snapshot.

-- 


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

[Bug tree-optimization/19241] [4.0 Regression] ICE in make_decl_rtl with inliner

[hubicka at ucw dot cz]

--- Additional Comments From hubicka at ucw dot cz  2005-01-09 16:06 ---
Subject: Re:  [4.0 Regression] ICE in make_decl_rtl with inliner

> 
> --- Additional Comments From aj at gcc dot gnu dot org  2005-01-09 07:29 
> ---
> Honza, this is an inliner bug - could you look at it, please? 

I did already once, but it really seem to be template instanciation
problem.  I will try harder...
> 
> -- 
>What|Removed |Added
> 
>  CC||aj at gcc dot gnu dot org
>  AssignedTo|unassigned at gcc dot gnu   |hubicka at gcc dot gnu dot
>|dot org |org
>  Status|NEW |ASSIGNED
> 
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19241
> 
> --- You are receiving this mail because: ---
> You are the assignee for the bug, or are watching the assignee.


-- 


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

[Bug ada/19337] [4.0 Regression] ada does not compile

[heitkamp at ameritech dot net]

--- Additional Comments From heitkamp at ameritech dot net  2005-01-09 
16:04 ---
Subject: Re:  [4.0 Regression] ada does not compile

On Sat, 8 Jan 2005, pinskia at gcc dot gnu dot org wrote:

Which file are you refering to? How do I check this?  I am a novice. 
Thanks.

Fred

>
> --- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-08 
> 22:20 ---
> I cannot reproduce it either on ppc-darwin,  are you sure that you don't have 
> a file with a tag set (like a
> date tag).
>
> --
>   What|Removed |Added
> 
> Status|UNCONFIRMED |WAITING
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19337
>
> --- You are receiving this mail because: ---
> You reported the bug, or are watching the reporter.
>


-- 


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

[Bug middle-end/19327] [4.0 Regression] FAIL: gcc.c-torture/execute/921215-1.c compilation, -O3 -g

[ebotcazou at gcc dot gnu dot org]

--- Additional Comments From ebotcazou at gcc dot gnu dot org  2005-01-09 
16:00 ---
Reproducible on sparc32, sparc64, x86 and x86-64 with -gstabs:

RELOCATION RECORDS FOR [.stab]:
OFFSET   TYPE  VALUE
0014 R_386_32  .text
00e0 R_386_32  foo
0104 R_386_32  .text
0158 R_386_32  main
0194 R_386_32  r.1135
01b8 R_386_32  .text
01dc R_386_32  .text


-- 
   What|Removed |Added

 CC||ebotcazou at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
  GCC build triplet|hppa2.0w-hp-hpux11.11   |
   GCC host triplet|hppa2.0w-hp-hpux11.11   |
 GCC target triplet|hppa2.0w-hp-hpux11.11   |
   Last reconfirmed|-00-00 00:00:00 |2005-01-09 16:00:58
   date||


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

[Bug c++/19343] [4.0 Regression] New warnings in libstdc++-v3 since 2004-01-05

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-09 
15:58 ---
Hmm, is this at -O0 or -O2.  If the former then this is a dup of bug 16558.  If 
the later, then I don't 
know.

Please attach the preprocessed source (my last build did not have the warning).

-- 
   What|Removed |Added

   Keywords||diagnostic
Summary|New warnings in libstdc++-v3|[4.0 Regression] New
   |since 2004-01-05|warnings in libstdc++-v3
   ||since 2004-01-05
   Target Milestone|--- |4.0.0


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

[Bug target/15491] ICE (Internal compiler error) while compiling glibc to vax-linux target

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-01-09 15:58:53
   date||


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

[Bug tree-optimization/19224] [4.0 regression] Endless loop compiling simple file: Bug in tree-scalar-evolution.c (instantiate_parameters_1)?

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-09 
15:56 ---
Fixed.

-- 
   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug tree-optimization/19347] Invariant load not moved out of loop

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-09 
15:55 ---
Confirmed but add a full testcase here, thanks.

Actually I don't think it would require whole program analysis to do this in 
LIM (or LICM), we just need 
more information (which might be done on the structure-aliasing branch).

-- 
   What|Removed |Added

   Severity|normal  |enhancement
 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Keywords||missed-optimization
   Last reconfirmed|-00-00 00:00:00 |2005-01-09 15:55:15
   date||


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

[Bug c/19346] Wrong warnings about undefined aliases

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-09 
15:50 ---
Confirmed.

-- 
   What|Removed |Added

 CC||rth at gcc dot gnu dot org
 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Keywords||diagnostic
   Last reconfirmed|-00-00 00:00:00 |2005-01-09 15:50:05
   date||
   Target Milestone|--- |4.0.0


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

[Bug target/19334] ISHFT has the wrong type for constant values

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-09 
15:47 ---
Then this must be a target bug, I will look into it.

-- 
   What|Removed |Added

 AssignedTo|tobi at gcc dot gnu dot org |pinskia at gcc dot gnu dot
   ||org
  Component|fortran |target


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

[Bug debug/19345] [4.0 Regression] Segmentation fault

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-09 
15:46 ---
Confirmed.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-01-09 15:46:02
   date||


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

[Bug target/15491] ICE (Internal compiler error) while compiling glibc to vax-linux target

[danglin at gcc dot gnu dot org]

--- Additional Comments From danglin at gcc dot gnu dot org  2005-01-09 
15:45 ---
Created an attachment (id=7912)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7912&action=view)
Patch

For main.  Should also apply to 3.4.

-- 


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

[Bug fortran/19334] ISHFT has the wrong type for constant values

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

--- Additional Comments From Tobias dot Schlueter at physik dot 
uni-muenchen dot de  2005-01-09 15:36 ---
Subject: Re:  ISHFT has the wrong type for constant values

pinskia at gcc dot gnu dot org wrote:
> --- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-09 
> 15:29 ---
>   int1 C.454 = 0_S8;
> 
> The 8 is where the problem is, it is just plainly wrong, it should be 1.
> 
8 bits, unless I'm completely mistaken.


-- 


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

[Bug c/19342] [4.0 regression] ICE in common_type, at c-typeck.c:490

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-09 
15:35 ---
The only obvious change which caused this would be:
2005-01-07  Jakub Jelinek  <[EMAIL PROTECTED]>

* c-common.c (handle_mode_attribute): For ENUMERAL_TYPE, also copy
TYPE_MODE.

-- 
   What|Removed |Added

 CC||jakub at redhat dot com


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

[Bug fortran/19334] ISHFT has the wrong type for constant values

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-09 
15:29 ---
  int1 C.454 = 0_S8;

The 8 is where the problem is, it is just plainly wrong, it should be 1.

-- 


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

[Bug target/18329] [4.0 regression] mmix-knuth-mmixware testsuite failure: execute/920501-7.c

[hp at gcc dot gnu dot org]

--- Additional Comments From hp at gcc dot gnu dot org  2005-01-09 15:28 
---
*** Bug 18330 has been marked as a duplicate of this bug. ***

-- 


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

[Bug target/18330] [4.0 regression] mmix-knuth-mmixware testsuite failure: execute/comp-goto-2.c

[hp at gcc dot gnu dot org]

--- Additional Comments From hp at gcc dot gnu dot org  2005-01-09 15:28 
---


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

-- 
   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE


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

[Bug target/18329] [4.0 regression] mmix-knuth-mmixware testsuite failure: execute/920501-7.c

[hp at gcc dot gnu dot org]

--- Additional Comments From hp at gcc dot gnu dot org  2005-01-09 15:27 
---
http://gcc.gnu.org/ml/gcc-patches/2005-01/msg00478.html>

-- 
   What|Removed |Added

   Keywords||patch


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