[Bug libgcj/38872] [4.4 Regression] libgcj.so dropped _Jv_CreateJavaVM and _Jv_GetStringChars symbols

[jakub at gcc dot gnu dot org]

--- Comment #3 from jakub at gcc dot gnu dot org  2009-01-27 10:09 ---
Subject: Bug 38872

Author: jakub
Date: Tue Jan 27 10:09:23 2009
New Revision: 143698

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143698
Log:
PR libgcj/38872
* gcj/javaprims.h (_Jv_CreateJavaVM): Change to extern "C" symbol.
* libjgc_bc.c (_Jv_GetStringChars): Remove.

Modified:
trunk/libjava/ChangeLog
trunk/libjava/gcj/javaprims.h
trunk/libjava/libgcj_bc.c


-- 


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

[Bug libgcj/38872] [4.4 Regression] libgcj.so dropped _Jv_CreateJavaVM and _Jv_GetStringChars symbols

[jakub at gcc dot gnu dot org]

--- Comment #4 from jakub at gcc dot gnu dot org  2009-01-27 10:18 ---
Fixed.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug rtl-optimization/38969] [4.3/4.4 Regression] -foptimize-sibling-calls generates wrong code on alpha

[uros at gcc dot gnu dot org]

--- Comment #5 from uros at gcc dot gnu dot org  2009-01-27 10:19 ---
Subject: Bug 38969

Author: uros
Date: Tue Jan 27 10:18:54 2009
New Revision: 143699

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143699
Log:
PR middle-end/38969
* calls.c (initialize_argument_information): Do not wrap complex
arguments in SAVE_EXPR.

testsuite/ChangeLog:

PR middle-end/38969
* gcc.c-torture/execute/pr38969.c: New test.


Added:
trunk/gcc/testsuite/gcc.c-torture/execute/pr38969.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/calls.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug middle-end/38934] [4.3/4.4 Regression] ICE in set_value_range, at tree-vrp.c:398

[jakub at gcc dot gnu dot org]

--- Comment #9 from jakub at gcc dot gnu dot org  2009-01-27 10:25 ---
So, what should we do for 4.4 then?
--- tree-vrp.c.jj2009-01-02 09:32:55.0 +0100
+++ tree-vrp.c2009-01-27 11:16:57.0 +0100
@@ -1620,7 +1620,8 @@ extract_range_from_assert (value_range_t
  all should be optimized away above us.  */
   if ((cond_code == LT_EXPR
&& compare_values (max, min) == 0)
-  || is_overflow_infinity (max))
+  || is_overflow_infinity (max)
+  || TREE_OVERFLOW (max))
 set_value_range_to_varying (vr_p);
   else
 {
@@ -1655,7 +1656,8 @@ extract_range_from_assert (value_range_t
  all should be optimized away above us.  */
   if ((cond_code == GT_EXPR
&& compare_values (min, max) == 0)
-  || is_overflow_infinity (min))
+  || is_overflow_infinity (min)
+  || TREE_OVERFLOW (min))
 set_value_range_to_varying (vr_p);
   else
 {

fixes this for me (and, is_overflow_infinity check could be actually dropped).
There is a problem with the testcase also - while the
integer constant is so large that it is unsigned
warning is emitted always,
integer overflow in expression
is emitted only for 32-bit HWI gcc, for x86_64 -m32 as well as -m64 only the
first warning is emitted.


-- 


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

[Bug middle-end/38969] [4.3 Regression] -foptimize-sibling-calls generates wrong code on alpha

[ubizjak at gmail dot com]

--- Comment #6 from ubizjak at gmail dot com  2009-01-27 10:27 ---
Fixed in the trunk.


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

URL||http://gcc.gnu.org/ml/gcc-
   ||patches/2009-
   ||01/msg01292.html
  Component|rtl-optimization|middle-end
Summary|[4.3/4.4 Regression] -  |[4.3 Regression] -foptimize-
   |foptimize-sibling-calls |sibling-calls generates
   |generates wrong code on |wrong code on alpha
   |alpha   |


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

[Bug middle-end/38934] [4.3/4.4 Regression] ICE in set_value_range, at tree-vrp.c:398

[rguenther at suse dot de]

--- Comment #10 from rguenther at suse dot de  2009-01-27 10:29 ---
Subject: Re:  [4.3/4.4 Regression] ICE in set_value_range,
 at tree-vrp.c:398

On Tue, 27 Jan 2009, jakub at gcc dot gnu dot org wrote:

> --- Comment #9 from jakub at gcc dot gnu dot org  2009-01-27 10:25 ---
> So, what should we do for 4.4 then?
> --- tree-vrp.c.jj2009-01-02 09:32:55.0 +0100
> +++ tree-vrp.c2009-01-27 11:16:57.0 +0100
> @@ -1620,7 +1620,8 @@ extract_range_from_assert (value_range_t
>   all should be optimized away above us.  */
>if ((cond_code == LT_EXPR
> && compare_values (max, min) == 0)
> -  || is_overflow_infinity (max))
> +  || is_overflow_infinity (max)
> +  || TREE_OVERFLOW (max))
>  set_value_range_to_varying (vr_p);
>else
>  {
> @@ -1655,7 +1656,8 @@ extract_range_from_assert (value_range_t
>   all should be optimized away above us.  */
>if ((cond_code == GT_EXPR
> && compare_values (min, max) == 0)
> -  || is_overflow_infinity (min))
> +  || is_overflow_infinity (min)
> +  || TREE_OVERFLOW (min))
>  set_value_range_to_varying (vr_p);
>else
>  {

That looks reasonable to me.

Richard.


-- 


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

[Bug middle-end/38503] [4.4 regression] warnings from -isystem headers strikes back.

[rguenth at gcc dot gnu dot org]

--- Comment #16 from rguenth at gcc dot gnu dot org  2009-01-27 10:43 
---
Subject: Bug 38503

Author: rguenth
Date: Tue Jan 27 10:42:59 2009
New Revision: 143700

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143700
Log:
2009-01-27  Richard Guenther  

PR tree-optimization/38503
* cfgexpand.c (expand_gimple_basic_block): Ignore
GIMPLE_CHANGE_DYNAMIC_TYPE during expansion.
* tree-ssa-structalias.c (set_uids_in_ptset): Do not prune
variables that cannot have TBAA applied.
(compute_points_to_sets): Do not remove GIMPLE_CHANGE_DYNAMIC_TYPE
statements.

* g++.dg/warn/Wstrict-aliasing-bogus-placement-new.C: New testcase.

Added:
trunk/gcc/testsuite/g++.dg/warn/Wstrict-aliasing-bogus-placement-new.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cfgexpand.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-structalias.c


-- 


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

[Bug middle-end/38503] [4.4 regression] warnings from -isystem headers strikes back.

[rguenth at gcc dot gnu dot org]

--- Comment #17 from rguenth at gcc dot gnu dot org  2009-01-27 10:43 
---
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug middle-end/38934] [4.3/4.4 Regression] ICE in set_value_range, at tree-vrp.c:398

[bonzini at gnu dot org]

--- Comment #11 from bonzini at gnu dot org  2009-01-27 10:33 ---
> integer overflow in expression
> is emitted only for 32-bit HWI gcc, for x86_64 -m32 as well as -m64 only the
> first warning is emitted.

If the warning should be there in 64-bit HWI gcc too, that's a separate bug. 
But if (as I think it should be) it should not be there, the front-end bug is
the root cause of this PR and fixing it will remove the need for the VRP fix.


-- 


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

[Bug tree-optimization/38984] New: [4.2/4.3/4.4 Regression] NULL pointers always considered distinct by PTA, even with -fno-delete-null-pointer-checks

[bonzini at gnu dot org]

This testcase fails:

/* { dg-do compile } */
/* { dg-options "-O2 -fno-delete-null-pointer-checks -fdump-tree-optimized" }
*/

int f(int *p)
{
  int a = *p;
  int *null = 0;
  *null = 5;
  return *p == a;
}

/* { dg-final { scan-tree-dump-times " = \\\*p" 2 "optimized" } } */
/* { dg-final { scan-tree-dump-not "return 1" "optimized" } } */
/* { dg-final { cleanup-tree-dump "optimized" } } */

This testcase is important because targets that are always MMU-less (like AVR)
will always have -fdelete-null-pointer-checks disabled, so the wrong code bug
will happen with -O2.  IMO it is a P2.


-- 
   Summary: [4.2/4.3/4.4 Regression] NULL pointers always considered
distinct by PTA, even with -fno-delete-null-pointer-
checks
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bonzini at gnu dot org


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

[Bug tree-optimization/38984] [4.2/4.3/4.4 Regression] NULL pointers always considered distinct by PTA, even with -fno-delete-null-pointer-checks

[bonzini at gnu dot org]

--- Comment #1 from bonzini at gnu dot org  2009-01-27 11:02 ---
This simple patch is not enough:

Index: tree-ssa-structalias.c
===
--- tree-ssa-structalias.c  (revision 142960)
+++ tree-ssa-structalias.c  (working copy)
@@ -3030,8 +3030,14 @@ get_constraint_for_1 (tree t, VEC (ce_s,
  happens below, since it will fall into the default case. The only
  case we know something about an integer treated like a pointer is
  when it is the NULL pointer, and then we just say it points to
- NULL.  */
-  if (TREE_CODE (t) == INTEGER_CST
+ NULL.
+
+ Do not do that if -fno-delete-null-pointer-checks though, because
+ in that case *NULL does not fail, so it _should_ alias *anything.
+ It is not worth adding a new option or renaming the existing one,
+ since this case is relatively obscure.  */
+  if (flag_delete_null_pointer_checks
+  && TREE_CODE (t) == INTEGER_CST
   && integer_zerop (t))
 {
   temp.var = nothing_id;

We get:

ANYTHING = &ANYTHING
ESCAPED = *ESCAPED
NONLOCAL = &ESCAPED
INTEGER = &ANYTHING
derefaddrtmp.8 = &NONLOCAL
*ESCAPED = derefaddrtmp.8
p = &NONLOCAL

...

NULL = { }
ANYTHING = { ANYTHING }
READONLY = { READONLY }
ESCAPED = { }
NONLOCAL = { ESCAPED }
CALLUSED = { }
INTEGER = { ANYTHING }
derefaddrtmp.7 = { ESCAPED }
derefaddrtmp.8 = { NONLOCAL }
p = same as derefaddrtmp.8

...

Updating SSA information for statement a_2 = *p_1(D);

Updating SSA information for statement D.1236_4 = *p_1(D);

...

VUSE operands 2  8b
VDEF operands 0  0b

...

  # VUSE  { SMT.9D.1248 }
  aD.1233_2 = *pD.1230_1(D);
  *0B ={v} 5;
  # VUSE  { SMT.9D.1248 }
  D.1236_4 = *pD.1230_1(D);
  D.1235_5 = D.1236_4 == aD.1233_2;
  return D.1235_5;

Note there is no vdef, so FRE comes and removes the second load.


-- 

bonzini at gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-01-27 11:02:25
   date||


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

[Bug tree-optimization/38984] [4.2/4.3/4.4 Regression] NULL pointers always considered distinct by PTA, even with -fno-delete-null-pointer-checks

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2009-01-27 11:06 ---
Can you fill in a known-to-work version?

ANYTHING = &ANYTHING
ESCAPED = *ESCAPED
NONLOCAL = &ESCAPED
INTEGER = &ANYTHING
derefaddrtmp.8 = &NONLOCAL
*ESCAPED = derefaddrtmp.8
p = &NONLOCAL

misses a constraint for null.  It should say

null = &ANYTHING


-- 


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

[Bug tree-optimization/38984] [4.2/4.3/4.4 Regression] NULL pointers always considered distinct by PTA, even with -fno-delete-null-pointer-checks

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2009-01-27 11:06 ---
hm, or rather, we CCP into null ... which makes this an operand scanner issue.


-- 


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

[Bug tree-optimization/38926] [4.4 Regression] ice in find_or_generate_expression, at tree-ssa-pre.c:2769

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2009-01-27 11:07 ---
Smaller testcase:

unsigned foo (int _si1, unsigned _si2)
{
  return _si1 > 0 && _si1 > 2147483647 - _si2;
}

unsigned bar (unsigned _left, int _right)
{
  return (unsigned) _right >= 8 ? 1 : _left >> _right;
}

unsigned g_2;
unsigned g_67;
unsigned g_111;
volatile unsigned g_162;

int func_62 (unsigned p_63)
{
  p_63 = g_2 & g_67;
  if (g_2)
;
  else if (p_63)
return 1;
  g_67 = bar (p_63, g_2);
  return 0;
}

void func_1 (void)
{
  if (g_2)
for (; g_2 <= -16; g_2 = foo (g_2, 1))
  {
for (; g_162; g_162)
  func_62 (func_62 (0));
if (g_111)
  return;
  }
}

void crc32 (int);

void baz (void)
{
  func_1 ();
  crc32 (g_2);
}


-- 


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

Re: [Bug tree-optimization/38984] [4.2/4.3/4.4 Regression] NULL pointers always considered distinct by PTA, even with -fno-delete-null-pointer-checks

[Andrew Thomas Pinski]

Sent from my iPhone

On Jan 27, 2009, at 3:02 AM, "bonzini at gnu dot org" > wrote:





--- Comment #1 from bonzini at gnu dot org  2009-01-27 11:02  
---

This simple patch is not enough:

Index: tree-ssa-structalias.c
===
--- tree-ssa-structalias.c  (revision 142960)
+++ tree-ssa-structalias.c  (working copy)
@@ -3030,8 +3030,14 @@ get_constraint_for_1 (tree t, VEC (ce_s,
 happens below, since it will fall into the default case. The only
 case we know something about an integer treated like a pointer is
 when it is the NULL pointer, and then we just say it points to
- NULL.  */
-  if (TREE_CODE (t) == INTEGER_CST
+ NULL.
+
+ Do not do that if -fno-delete-null-pointer-checks though,  
because
+ in that case *NULL does not fail, so it _should_ alias  
*anything.
+ It is not worth adding a new option or renaming the existing  
one,

+ since this case is relatively obscure.  */
+  if (flag_delete_null_pointer_checks
+  && TREE_CODE (t) == INTEGER_CST
  && integer_zerop (t))
{
  temp.var = nothing_id;

We get:

ANYTHING = &ANYTHING
ESCAPED = *ESCAPED
NONLOCAL = &ESCAPED
INTEGER = &ANYTHING
derefaddrtmp.8 = &NONLOCAL
*ESCAPED = derefaddrtmp.8
p = &NONLOCAL

...

NULL = { }
ANYTHING = { ANYTHING }
READONLY = { READONLY }
ESCAPED = { }
NONLOCAL = { ESCAPED }
CALLUSED = { }
INTEGER = { ANYTHING }
derefaddrtmp.7 = { ESCAPED }
derefaddrtmp.8 = { NONLOCAL }
p = same as derefaddrtmp.8

...

Updating SSA information for statement a_2 = *p_1(D);

Updating SSA information for statement D.1236_4 = *p_1(D);

...

VUSE operands 2  8b
VDEF operands 0  0b

...

 # VUSE  { SMT.9D.1248 }
 aD.1233_2 = *pD.1230_1(D);
 *0B ={v} 5;
 # VUSE  { SMT.9D.1248 }
 D.1236_4 = *pD.1230_1(D);
 D.1235_5 = D.1236_4 == aD.1233_2;
 return D.1235_5;

Note there is no vdef, so FRE comes and removes the second load.


If that patch is not enough and the above is happening we are going to  
have issues wit volatiles also.







--

bonzini at gnu dot org changed:

  What|Removed |Added
--- 
--- 
--

Status|UNCONFIRMED |NEW
Ever Confirmed|0   |1
  Last reconfirmed|-00-00 00:00:00 |2009-01-27 11:02:25
  date||


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

[Bug tree-optimization/38984] [4.2/4.3/4.4 Regression] NULL pointers always considered distinct by PTA, even with -fno-delete-null-pointer-checks

[pinskia at gmail dot com]

--- Comment #4 from pinskia at gmail dot com  2009-01-27 11:08 ---
Subject: Re:  [4.2/4.3/4.4 Regression] NULL pointers always considered distinct
by PTA, even with -fno-delete-null-pointer-checks



Sent from my iPhone

On Jan 27, 2009, at 3:02 AM, "bonzini at gnu dot org"  wrote:

>
>
> --- Comment #1 from bonzini at gnu dot org  2009-01-27 11:02  
> ---
> This simple patch is not enough:
>
> Index: tree-ssa-structalias.c
> ===
> --- tree-ssa-structalias.c  (revision 142960)
> +++ tree-ssa-structalias.c  (working copy)
> @@ -3030,8 +3030,14 @@ get_constraint_for_1 (tree t, VEC (ce_s,
>  happens below, since it will fall into the default case. The only
>  case we know something about an integer treated like a pointer is
>  when it is the NULL pointer, and then we just say it points to
> - NULL.  */
> -  if (TREE_CODE (t) == INTEGER_CST
> + NULL.
> +
> + Do not do that if -fno-delete-null-pointer-checks though,  
> because
> + in that case *NULL does not fail, so it _should_ alias  
> *anything.
> + It is not worth adding a new option or renaming the existing  
> one,
> + since this case is relatively obscure.  */
> +  if (flag_delete_null_pointer_checks
> +  && TREE_CODE (t) == INTEGER_CST
>   && integer_zerop (t))
> {
>   temp.var = nothing_id;
>
> We get:
>
> ANYTHING = &ANYTHING
> ESCAPED = *ESCAPED
> NONLOCAL = &ESCAPED
> INTEGER = &ANYTHING
> derefaddrtmp.8 = &NONLOCAL
> *ESCAPED = derefaddrtmp.8
> p = &NONLOCAL
>
> ...
>
> NULL = { }
> ANYTHING = { ANYTHING }
> READONLY = { READONLY }
> ESCAPED = { }
> NONLOCAL = { ESCAPED }
> CALLUSED = { }
> INTEGER = { ANYTHING }
> derefaddrtmp.7 = { ESCAPED }
> derefaddrtmp.8 = { NONLOCAL }
> p = same as derefaddrtmp.8
>
> ...
>
> Updating SSA information for statement a_2 = *p_1(D);
>
> Updating SSA information for statement D.1236_4 = *p_1(D);
>
> ...
>
> VUSE operands 2  8b
> VDEF operands 0  0b
>
> ...
>
>  # VUSE  { SMT.9D.1248 }
>  aD.1233_2 = *pD.1230_1(D);
>  *0B ={v} 5;
>  # VUSE  { SMT.9D.1248 }
>  D.1236_4 = *pD.1230_1(D);
>  D.1235_5 = D.1236_4 == aD.1233_2;
>  return D.1235_5;
>
> Note there is no vdef, so FRE comes and removes the second load.

If that patch is not enough and the above is happening we are going to  
have issues wit volatiles also.


>
>
>
> -- 
>
> bonzini at gnu dot org changed:
>
>   What|Removed |Added
> --- 
> --- 
> --
> Status|UNCONFIRMED |NEW
> Ever Confirmed|0   |1
>   Last reconfirmed|-00-00 00:00:00 |2009-01-27 11:02:25
>   date||
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38984
>


-- 


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

[Bug tree-optimization/38984] [4.2/4.3/4.4 Regression] NULL pointers always considered distinct by PTA, even with -fno-delete-null-pointer-checks

[bonzini at gnu dot org]

--- Comment #5 from bonzini at gnu dot org  2009-01-27 11:09 ---
I don't think CCPing of the "null" variable is a problem.  Writing it as "*(int
*)0 = 5" would not make the testcase invalid.


-- 


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

[Bug tree-optimization/38985] New: [4.2/4.3/4.4 Regression] missing constraints for pointers accessed directly via their address

[bonzini at gnu dot org]

This testcase fails:

/* { dg-do compile } */
/* { dg-options "-O2 -fdump-tree-optimized" } */

int f(int *p)
{
  int a = *p;
  int *q = (int *)0xDEADBEE0;
  *q = 5;
  return *p == a;
}

/* { dg-final { scan-tree-dump-times " = \\\*p" 2 "optimized" } } */
/* { dg-final { scan-tree-dump-not "return 1" "optimized" } } */
/* { dg-final { cleanup-tree-dump "optimized" } } */


Unlike PR38984 it does not require -fno-delete-null-pointer-checks.


-- 
   Summary: [4.2/4.3/4.4 Regression] missing constraints for
pointers accessed directly via their address
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bonzini at gnu dot org
OtherBugsDependingO 38984
 nThis:


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

[Bug tree-optimization/38984] [4.2/4.3/4.4 Regression] NULL pointers always considered distinct by PTA, even with -fno-delete-null-pointer-checks

[bonzini at gnu dot org]

--- Comment #6 from bonzini at gnu dot org  2009-01-27 11:15 ---
The issue with the operand scanner is now PR38985


-- 


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

Re: [Bug tree-optimization/38985] New: [4.2/4.3/4.4 Regression] missing constraints for pointers accessed directly via their address

[Andrew Thomas Pinski]

Sent from my iPhone

On Jan 27, 2009, at 3:15 AM, "bonzini at gnu dot org" > wrote:



This testcase fails:

/* { dg-do compile } */
/* { dg-options "-O2 -fdump-tree-optimized" } */

int f(int *p)
{
 int a = *p;
 int *q = (int *)0xDEADBEE0;
 *q = 5;
 return *p == a;
}

/* { dg-final { scan-tree-dump-times " = \\\*p" 2 "optimized" } } */
/* { dg-final { scan-tree-dump-not "return 1" "optimized" } } */
/* { dg-final { cleanup-tree-dump "optimized" } } */


Unlike PR38984 it does not require -fno-delete-null-pointer-checks.


Volatile addresses also don't have vops on them.  As I mentioned in  
the other bug.  So this is also a bug for volatiles.






--
  Summary: [4.2/4.3/4.4 Regression] missing constraints for
   pointers accessed directly via their address
  Product: gcc
  Version: 4.4.0
   Status: UNCONFIRMED
 Keywords: wrong-code
 Severity: normal
 Priority: P3
Component: tree-optimization
   AssignedTo: unassigned at gcc dot gnu dot org
   ReportedBy: bonzini at gnu dot org
OtherBugsDependingO 38984
nThis:


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

[Bug tree-optimization/38985] [4.2/4.3/4.4 Regression] missing constraints for pointers accessed directly via their address

[pinskia at gmail dot com]

--- Comment #1 from pinskia at gmail dot com  2009-01-27 11:27 ---
Subject: Re:   New: [4.2/4.3/4.4 Regression] missing constraints for pointers
accessed directly via their address



Sent from my iPhone

On Jan 27, 2009, at 3:15 AM, "bonzini at gnu dot org"  wrote:

> This testcase fails:
>
> /* { dg-do compile } */
> /* { dg-options "-O2 -fdump-tree-optimized" } */
>
> int f(int *p)
> {
>  int a = *p;
>  int *q = (int *)0xDEADBEE0;
>  *q = 5;
>  return *p == a;
> }
>
> /* { dg-final { scan-tree-dump-times " = \\\*p" 2 "optimized" } } */
> /* { dg-final { scan-tree-dump-not "return 1" "optimized" } } */
> /* { dg-final { cleanup-tree-dump "optimized" } } */
>
>
> Unlike PR38984 it does not require -fno-delete-null-pointer-checks.

Volatile addresses also don't have vops on them.  As I mentioned in  
the other bug.  So this is also a bug for volatiles.

>
>
>
> -- 
>   Summary: [4.2/4.3/4.4 Regression] missing constraints for
>pointers accessed directly via their address
>   Product: gcc
>   Version: 4.4.0
>Status: UNCONFIRMED
>  Keywords: wrong-code
>  Severity: normal
>  Priority: P3
> Component: tree-optimization
>AssignedTo: unassigned at gcc dot gnu dot org
>ReportedBy: bonzini at gnu dot org
> OtherBugsDependingO 38984
> nThis:
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38985
>


-- 


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

[Bug middle-end/38934] [4.3/4.4 Regression] ICE in set_value_range, at tree-vrp.c:398

[jakub at gcc dot gnu dot org]

--- Comment #12 from jakub at gcc dot gnu dot org  2009-01-27 11:29 ---
The difference is in interpret_integer:
579  if (itk == itk_none)
580/* cpplib has already issued a warning for overflow.  */
581type = ((flags & CPP_N_UNSIGNED)
582? widest_unsigned_literal_type_node
583: widest_integer_literal_type_node);
584  else
585type = integer_types[itk];
in both cases the overflow warning has been issued, but
widest_integer_literal_type_node differs between 32-bit HWI and 64-bit HWI -
in the former case it is signed DImode, in the latter case signed TImode.
Negating TImode 0x8000 doesn't overflow, but negating
DImode 0x8000 does and thus the warning in 32-bit HWI case.


-- 


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

[Bug target/38706] [4.4 Regression] ../../../../src/libstdc++-v3/src/strstream.cc:419: internal compiler error: Segmentation fault

[uros at gcc dot gnu dot org]

--- Comment #13 from uros at gcc dot gnu dot org  2009-01-27 11:39 ---
Subject: Bug 38706

Author: uros
Date: Tue Jan 27 11:39:42 2009
New Revision: 143701

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143701
Log:
gcc/ChangeLog:

Backport from mainline:
2009-01-13  Uros Bizjak  

* config/alpha/alpha.c (alpha_legitimate_address_p): Explicit
relocations of local symbols wider than UNITS_PER_WORD are not valid.
(alpha_legitimize_address): Do not split local symbols wider than
UNITS_PER_WORD into HIGH/LO_SUM parts.

2009-01-07  Uros Bizjak  

PR target/38706
* config/alpha/alpha.c (alpha_end_function): For TARGET_ABI_OSF, call
free_after_compilation when outputting a thunk.
(alpha_output_mi_thunk_osf): Assert that we are processing a thunk.
Do not call free_after_compilation here.

2008-12-22  Uros Bizjak  

* config/alpha/elf.h (ASM_OUTPUT_EXTERNAL): New macro.

2008-12-21  Uros Bizjak  

* config/alpha/alpha.c (alpha_pad_noreturn): New static function.
(alpha_reorg): Call alpha_pad_noreturn.

2008-12-08  Uros Bizjak  

* config/alpha/alpha.c (alpha_set_memflags): Process memory
references in full insn sequence.

2008-12-05  Uros Bizjak  

* config/alpha/alpha.c (alpha_fold_vector_minmax): Create
VIEW_CONVERT_EXPR to convert output to long_integer_type_node.

(alpha_emit_conditional_branch): Do not generate direct branch
for UNORDERED comparisons.

gcc/testsuite/ChangeLog:

Backport from mainline:
2009-01-07  Uros Bizjak  

PR target/38706
* g++.dg/other/pr38706.C: New test.

libstdc++/ChangeLog:

Backport from mainline:
2009-01-13  Uros Bizjak  

* scripts/extract_symvers: Add sed script to remove ' [: xx] '
field from readelf output.


Added:
branches/gcc-4_3-branch/gcc/testsuite/g++.dg/other/pr38706.C
  - copied unchanged from r143167,
trunk/gcc/testsuite/g++.dg/other/pr38706.C
Modified:
branches/gcc-4_3-branch/gcc/ChangeLog
branches/gcc-4_3-branch/gcc/config/alpha/alpha.c
branches/gcc-4_3-branch/gcc/config/alpha/elf.h
branches/gcc-4_3-branch/gcc/testsuite/ChangeLog
branches/gcc-4_3-branch/libstdc++-v3/ChangeLog
branches/gcc-4_3-branch/libstdc++-v3/scripts/extract_symvers


-- 


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

[Bug middle-end/38934] [4.3/4.4 Regression] ICE in set_value_range, at tree-vrp.c:398

[jakub at gcc dot gnu dot org]

--- Comment #13 from jakub at gcc dot gnu dot org  2009-01-27 11:59 ---
I wonder if the libcpp warning is correct in this case for -std=c99/-std=gnu99,
saying that the constant is too large that it is unsigned doesn't match the C99
wording, which says that the constant may have a signed extended type, not
unsigned.  For 32-bit HWI, unfortunately I don't see how we could have a larger
type than 2 * HOST_BITS_PER_WIDE_INT, as there would be no way to represet
TYPE_MIN_VALUE and TYPE_MAX_VALUE.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||jsm28 at gcc dot gnu dot org


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

[Bug tree-optimization/38985] [4.2/4.3/4.4 Regression] missing constraints for pointers accessed directly via their address

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2009-01-27 12:04 ---
Works on the alias-improvements branch.  Confirmed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
  Known to fail|4.1.3 4.4.0 |4.0.4 4.1.3 4.4.0
   Last reconfirmed|-00-00 00:00:00 |2009-01-27 12:04:37
   date||
   Target Milestone|--- |4.2.5


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

[Bug tree-optimization/38985] [4.2/4.3/4.4 Regression] missing constraints for pointers accessed directly via their address

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2009-01-27 12:06 ---
In the operand scanner we try to be clever ...

  else if (TREE_CODE (ptr) == INTEGER_CST)
{
  /* If a constant is used as a pointer, we can't generate a real
 operand for it but we mark the statement volatile to prevent
 optimizations from messing things up.  */
  gimple_set_has_volatile_ops (stmt, true);
  return;

but that of course misses the fact that we miss all necessary conflicts.


-- 


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

[Bug c++/38986] New: comparing lengths of 2 strings reads through both strings completely

[esigra at gmail dot com]

Suppose that someone wants to see if a string is shorter than another and
writes:
   #include 
   bool f(char const * const a, char const * const b) {return strlen(a) <=
strlen(b);}

Then g++ generates this:
pushl   %ebp
movl%esp, %ebp
pushl   %ebx
subl$4, %esp
movl8(%ebp), %eax
movl%eax, (%esp)
callstrlen
movl%eax, %ebx
movl12(%ebp), %eax
movl%eax, (%esp)
callstrlen
cmpl%eax, %ebx
setbe   %al
addl$4, %esp
popl%ebx
popl%ebp
ret

But it looks like this code reads through both strings completely! This is
obviously very efficient if one of the strings is much longer than the other.
It should of course only read as far into each string as the shortest of them
is long. The generated code should be similar to what this would give:
bool g(char const * a, char const * b) {
   for (;; ++a, ++b)
  if  (not *a)
 return true;
  else if (not *b)
 return false;
}


-- 
   Summary: comparing lengths of 2 strings reads through both
strings completely
   Product: gcc
   Version: 4.3.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: esigra at gmail dot com


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

[Bug tree-optimization/38985] [4.2/4.3/4.4 Regression] missing constraints for pointers accessed directly via their address

[rguenth at gcc dot gnu dot org]

--- Comment #5 from rguenth at gcc dot gnu dot org  2009-01-27 12:09 ---
The bad thing is that this is really bad.  We would need to add the SMT for
the type here, but we have no way of looking that up.  So the only way to fix
this in a reasonable way is to simply not CCP constant addresses into
dereferences.


-- 


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

[Bug tree-optimization/38984] [4.2/4.3/4.4 Regression] NULL pointers always considered distinct by PTA, even with -fno-delete-null-pointer-checks

[rguenth at gcc dot gnu dot org]

--- Comment #7 from rguenth at gcc dot gnu dot org  2009-01-27 12:13 ---
Note that for *(int *)0 = 5 the gimplifier inserts a temporary.


-- 


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

[Bug fortran/38852] [Fix pending] UBOUND fails for negative stride triplets

[pault at gcc dot gnu dot org]

--- Comment #8 from pault at gcc dot gnu dot org  2009-01-27 12:16 ---
I have done most of the work on the corner cases and the fix below looks good. 
I am marking it as pending for temporary book-keeping purposes.

Paul


-- 

pault at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|UBOUND fails for negative   |[Fix pending] UBOUND fails
   |stride triplets |for negative stride triplets


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

[Bug tree-optimization/38985] [4.2/4.3/4.4 Regression] missing constraints for pointers accessed directly via their address

[bonzini at gnu dot org]

--- Comment #6 from bonzini at gnu dot org  2009-01-27 12:21 ---
These passes are able to propagate the address to the load: CCP, VRP, DOM.  If
we decide that it's an invalid transformation, fixing them would fix this bug.


-- 


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

[Bug tree-optimization/38985] [4.2/4.3/4.4 Regression] missing constraints for pointers accessed directly via their address

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2009-01-27 12:04 ---
Mine.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rguenth at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2009-01-27 12:04:37 |2009-01-27 12:04:54
   date||


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

[Bug tree-optimization/38984] [4.2/4.3/4.4 Regression] NULL pointers always considered distinct by PTA, even with -fno-delete-null-pointer-checks

[bonzini at gnu dot org]

--- Comment #8 from bonzini at gnu dot org  2009-01-27 12:27 ---
>From PR38985:

> These passes are able to propagate the address to the load: CCP, VRP, DOM.  
> If 
> we decide that it's an invalid transformation, fixing them would fix this bug.

The interesting part is that after you disable them... you find out PTA is not
actually able to use the NULL special variable because *NULL and *ANYTHING
conflict!  The pointed-to sets are okay though:

  pD.1230_1(D), is dereferenced, its value escapes, points-to anything
  nullD.1234_3, is dereferenced, points-to anything, points-to NULL

The patch in comment #1 however works (tested with -fno-tree-ccp -fno-tree-vrp
-fno-tree-dominator-opts, and looking at the constraints for null).  So my plan
would be:

1) apply the patch after regtesting, XFAILing the testcase;

2) when PR38985 is fixed, the testcase will pass and the XFAIL will be removed.

Sounds okay?


-- 


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

[Bug tree-optimization/38985] [4.2/4.3/4.4 Regression] missing constraints for pointers accessed directly via their address

[bonzini at gnu dot org]

--- Comment #7 from bonzini at gnu dot org  2009-01-27 12:29 ---
> simply not CCP constant addresses into dereferences.

Apart from the fact that it's not only CCP, it seems mostly sensible.


-- 


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

[Bug tree-optimization/38984] [4.2/4.3/4.4 Regression] NULL pointers always considered distinct by PTA, even with -fno-delete-null-pointer-checks

[rguenther at suse dot de]

--- Comment #9 from rguenther at suse dot de  2009-01-27 12:29 ---
Subject: Re:  [4.2/4.3/4.4 Regression] NULL
 pointers always considered distinct by PTA, even with
 -fno-delete-null-pointer-checks

On Tue, 27 Jan 2009, bonzini at gnu dot org wrote:

> --- Comment #8 from bonzini at gnu dot org  2009-01-27 12:27 ---
> From PR38985:
> 
> > These passes are able to propagate the address to the load: CCP, VRP, DOM.  
> > If 
> > we decide that it's an invalid transformation, fixing them would fix this 
> > bug.
> 
> The interesting part is that after you disable them... you find out PTA is not
> actually able to use the NULL special variable because *NULL and *ANYTHING
> conflict!  The pointed-to sets are okay though:
> 
>   pD.1230_1(D), is dereferenced, its value escapes, points-to anything
>   nullD.1234_3, is dereferenced, points-to anything, points-to NULL
> 
> The patch in comment #1 however works (tested with -fno-tree-ccp -fno-tree-vrp
> -fno-tree-dominator-opts, and looking at the constraints for null).  So my 
> plan
> would be:
> 
> 1) apply the patch after regtesting, XFAILing the testcase;
> 
> 2) when PR38985 is fixed, the testcase will pass and the XFAIL will be 
> removed.
> 
> Sounds okay?

Sounds good.

Richard.


-- 


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

[Bug tree-optimization/38985] [4.2/4.3/4.4 Regression] missing constraints for pointers accessed directly via their address

[rguenth at gcc dot gnu dot org]

--- Comment #8 from rguenth at gcc dot gnu dot org  2009-01-27 12:31 ---
Created an attachment (id=17190)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17190&action=view)
incomplete patch

I tried this quick hack to add proper operands for the dereference, but it
shows
that (of course) we do not bother to create SMTs for dereferences of constants.


-- 


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

[Bug middle-end/38934] [4.3/4.4 Regression] ICE in set_value_range, at tree-vrp.c:398

[bonzini at gnu dot org]

--- Comment #14 from bonzini at gnu dot org  2009-01-27 12:32 ---
Yes, for the record those were my thoughts too when I prepared the --std=c99
testcase.


-- 


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

[Bug tree-optimization/38985] [4.2/4.3/4.4 Regression] missing constraints for pointers accessed directly via their address

[rguenth at gcc dot gnu dot org]

--- Comment #9 from rguenth at gcc dot gnu dot org  2009-01-27 12:33 ---
As this bug exists basically forever (since tree-ssa merge) I am inclined to
only fix it for 4.5 with the alias-improvements branch merge.


-- 


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

[Bug tree-optimization/37021] Fortran Complex reduction / multiplication not vectorized

[dorit at gcc dot gnu dot org]

--- Comment #9 from dorit at gcc dot gnu dot org  2009-01-27 12:40 ---
(In reply to comment #4)
> The testcase should be
> subroutine to_product_of(self,a,b,a1,a2)
>   complex(kind=8) :: self (:)
>   complex(kind=8), intent(in) :: a(:,:)
>   complex(kind=8), intent(in) :: b(:)
>   integer a1,a2
>   do i = 1,a1
> do j = 1,a2
>   self(i) = self(i) + a(j,i)*b(j)
> end do
>   end do
> end subroutine
> to be meaningful - otherwise we are accessing a in non-continuous ways in the
> inner loop which would prevent vectorization.

this change from a(i,j) to a(j,i) is not required if we try to vectorize the
outer-loop, where the stride is 1. It's also a better way to vectorize the
reduction. A few limitations on the way though are:

1) somehow don't let gcc create guard code around the innermost loop to check
that it executes more than zero iterations. This creates a complicated control
flow structure within the outer-loop. For now you have to have  constant number
of iterations for the inner-loop because of that, or insert a statement like
"if (a2<=0) return;" before the loop...

2) use -fno-tree-sink cause otherwise it moves the loop iv increment to the
latch block and the vectorizer likes to have the latch block empty...

(see also PR33113 for related reference).


> With the versioning for stride == 1 I get then
> .L13:
> movupd  16(%rax), %xmm1
> movupd  (%rax), %xmm3
> incl%ecx
> movupd  (%rdx), %xmm4
> addq$32, %rax
> movapd  %xmm3, %xmm0
> unpckhpd%xmm1, %xmm3
> unpcklpd%xmm1, %xmm0
> movupd  16(%rdx), %xmm1
> movapd  %xmm4, %xmm2
> addq$32, %rdx
> movapd  %xmm3, %xmm9
> cmpl%ecx, %r8d
> unpcklpd%xmm1, %xmm2
> unpckhpd%xmm1, %xmm4
> movapd  %xmm4, %xmm1
> movapd  %xmm2, %xmm4
> mulpd   %xmm1, %xmm9
> mulpd   %xmm0, %xmm4
> mulpd   %xmm3, %xmm2
> mulpd   %xmm1, %xmm0
> subpd   %xmm9, %xmm4
> addpd   %xmm2, %xmm0
> addpd   %xmm4, %xmm6
> addpd   %xmm0, %xmm5
> ja  .L13
> haddpd  %xmm5, %xmm5
> cmpl%r15d, %edi
> movl-4(%rsp), %ecx
> haddpd  %xmm6, %xmm6
> addsd   %xmm5, %xmm8
> addsd   %xmm6, %xmm7
> jne .L12
> jmp .L14
> for the innermost loop, followed by a tail loop (peel for niters).  This is
> about 15% faster on AMD K10 than the non-vectorized loop (if you disable
> the cost-model and make sure to have enough iterations in the inner loop
> to pay back for the extra guarding conditions).


-- 


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

[Bug tree-optimization/33113] Failing to represent the stride (with array) of a dataref when it is not a constant

[dorit at gcc dot gnu dot org]

--- Comment #7 from dorit at gcc dot gnu dot org  2009-01-27 12:46 ---
related testcase/PR: PR37021 
and related discussion: http://gcc.gnu.org/ml/gcc-patches/2009-01/msg01322.html


-- 


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

[Bug target/34790] [avr] no sibling call optimisation

[eric dot weddington at atmel dot com]

--- Comment #4 from eric dot weddington at atmel dot com  2009-01-27 12:52 
---
Closing bug. No feedback from the OP for almost a year.


-- 

eric dot weddington at atmel dot com changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||WORKSFORME


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

[Bug tree-optimization/38985] [4.2/4.3/4.4 Regression] missing constraints for pointers accessed directly via their address

[bonzini at gnu dot org]

--- Comment #10 from bonzini at gnu dot org  2009-01-27 12:58 ---
Created an attachment (id=17191)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17191&action=view)
tentative patch

Do you want to pursue something as in the attached patch instead?  You can then
revert it in the alias-improvements branch if you wish.


-- 


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

[Bug tree-optimization/38985] [4.2/4.3/4.4 Regression] missing constraints for pointers accessed directly via their address

[rguenth at gcc dot gnu dot org]

--- Comment #11 from rguenth at gcc dot gnu dot org  2009-01-27 13:05 
---
The patch is not enough.  Consider replacements in loads and in loads of
call arguments to const/pure calls.


-- 


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

[Bug tree-optimization/38985] [4.2/4.3/4.4 Regression] missing constraints for pointers accessed directly via their address

[bonzini at gnu dot org]

--- Comment #12 from bonzini at gnu dot org  2009-01-27 13:18 ---
Ok, I'm not working on it anyway.  I'll just leave the patch in case someone
else would pick it up.


-- 


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

[Bug middle-end/38934] [4.3/4.4 Regression] ICE in set_value_range, at tree-vrp.c:398

[joseph at codesourcery dot com]

--- Comment #15 from joseph at codesourcery dot com  2009-01-27 13:33 
---
Subject: Re:  [4.3/4.4 Regression] ICE in set_value_range,
 at tree-vrp.c:398

On Tue, 27 Jan 2009, jakub at gcc dot gnu dot org wrote:

> I wonder if the libcpp warning is correct in this case for 
> -std=c99/-std=gnu99,
> saying that the constant is too large that it is unsigned doesn't match the 
> C99
> wording, which says that the constant may have a signed extended type, not

I'm not clear what the issue here is supposed to be.

Anything that involves a type wider than intmax_t in a program should 
yield a pedwarn, not just a warning, for C99.  That was part of the 
intended effect of my patch 
.  The part for 
"mode" attributes was lost with 
 - since the 
relevant code is now in c-common.c again, it could be restored.  I don't 
know offhand when the check for integer constants was lost, although I 
don't see it in c-lex.c.  Unfortunately my original patch didn't have 
testcases for these diagnostics, probably because making them 
target-independent is hard and we didn't have the effective-target 
infrastructure back then.

> unsigned.  For 32-bit HWI, unfortunately I don't see how we could have a 
> larger
> type than 2 * HOST_BITS_PER_WIDE_INT, as there would be no way to represet
> TYPE_MIN_VALUE and TYPE_MAX_VALUE.

It's very clear to me by now that HOST_WIDE_INT should only depend on the 
target (probably only on the target architecture), not the host; that's 
the only way to ensure consistency between hosts for the same target.  
And so all the cases that really mean something related to the target 
should use some other name.  (There may be cases where the host not the 
target really is relevant, though there may also be better host types such 
as size_t to use in some of those cases.  Unfortunately there are nearly 
5000 uses of HOST_WIDE_INT in the compiler, so a huge task for anyone 
cleaning this up.)


-- 


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

[Bug tree-optimization/38926] [4.4 Regression] ice in find_or_generate_expression, at tree-ssa-pre.c:2769

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2009-01-27 13:36 ---
static inline int foo (unsigned _si1)
{
  if (_si1 != 0)
if (_si1 > 2147483647)
  return 1;
  return 0;
}

static inline unsigned bar (unsigned _left, int _right)
{
  return (unsigned) _right >= 8 ? 1 : _left >> _right;
}

unsigned g_2;
unsigned g_67;
volatile unsigned g_162;

static inline int func_62 (unsigned p_63)
{
  p_63 = g_2 & g_67;
  if (g_2)
;
  else if (p_63)
return 1;
  g_67 = bar (p_63, g_2);
  return 0;
}

unsigned baz (void)
{
  if (g_2)
for (; g_2 <= -16; g_2 = foo (g_2))
  {
for (; g_162; g_162)
  func_62 (func_62 (0));
if (g_67)
  break;
  }
  return g_2;
}


The only difference between -O2 and -O3 is that PPRE is enabled which is
what somehow triggers the ICE.


-- 


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

[Bug libstdc++/25956] Memory error when dynamic linking STL specializations

[jkp at kirkconsulting dot co dot uk]

--- Comment #4 from jkp at kirkconsulting dot co dot uk  2009-01-27 13:44 
---
Hi there

I reported this bug too long ago to even remember the details.  All I can say
is that now PPC OS X is probably completely irrelevant to most people.  I
certainly won't be wasting any more time on it.  That said: perhaps if this
issue is a PPC thing it still warrants investigation.

Thanks

Jamie


-- 


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

[Bug middle-end/38934] [4.3/4.4 Regression] ICE in set_value_range, at tree-vrp.c:398

[bonzini at gnu dot org]

--- Comment #16 from bonzini at gnu dot org  2009-01-27 13:44 ---
> It's very clear to me by now that HOST_WIDE_INT should only depend on the 
> target (probably only on the target architecture), not the host; that's 
> the only way to ensure consistency between hosts for the same target.  

It wouldn't actually be very hard to do that.  I'm almost sure that it would
"just work".

But the (sub)problem here is that the same target architecture (32-bit i386)
has different HOST_WIDE_INT size depending on whether GCC is a 32-bit
single-arch or a 32-/64-bit bi-arch compiler.


-- 


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

[Bug bootstrap/38981] internal compiler error

[kamaraju at gmail dot com]

--- Comment #8 from kamaraju at gmail dot com  2009-01-27 13:51 ---
I would like to confirm that, even after recompiling gcc with bison, I am still
getting the internal compiler error. There is no yacc, no /usr/ccs/bin in $PATH
when gcc was compiled.


-- 


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

[Bug tree-optimization/38926] [4.4 Regression] ice in find_or_generate_expression, at tree-ssa-pre.c:2769

[rguenth at gcc dot gnu dot org]

--- Comment #5 from rguenth at gcc dot gnu dot org  2009-01-27 14:34 ---
We try to insert {nop_expr,g_2.7_58} in bb 41

:
  # g_67_22 = PHI 
  # g_2.7_58 = PHI 
  # g_2_59 = PHI 
  # VUSE 
  g_162.9_61 ={v} g_162;
  if (g_162.9_61 != 0)
goto ;
  else
goto ;

:
  goto ;

:
  goto ;

The original avail_out computation says

exp_gen[41] := {  }
tmp_gen[41] := {  }
avail_out[41] := { g_2.7_1 (0002), g_2.7_58 (0030), g_162.9_61 (0032) }

(correct)

but at the point of insertion we instead have

debug[0] := { g_2.7_1 (0002), g_162.9_61 (0032), pretmp.23_38 (0046),
prephitmp.24_23 (0044), prephitmp.29_66 (0037) }

so we replaced some value here, but with a different value-number.

This happens in

  /* Note that we need to value_replace both NEW_SETS, and
 AVAIL_OUT. For both the case of NEW_SETS, the value may be
 represented by some non-simple expression here that we want
 to replace it with.  */
  FOR_EACH_EXPR_ID_IN_SET (newset, i, bi)
{
  pre_expr expr = expression_for_id (i);
  bitmap_value_replace_in_set (NEW_SETS (block), expr);
  bitmap_value_replace_in_set (AVAIL_OUT (block), expr);
}

where I see us replacing in

debug[0] := { g_2.7_1 (0002), g_2.7_58 (0030), g_162.9_61 (0032), pretmp.23_38
(0046), prephitmp.24_23 (0044), prephitmp.29_66 (0037) }

with expr prephitmp.29_66 (0037)

with the above result.  The expression set for 0037 at that point is

debug[0] := { g_2.7_58 (0030), {g_2} (0037), pretmp.23_2 (0037),
prephitmp.29_66 (0037) }

where for some weird reason g_2.7_58 (0030) is in it (!?).


-- 


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

[Bug tree-optimization/38926] [4.4 Regression] ice in find_or_generate_expression, at tree-ssa-pre.c:2769

[rguenth at gcc dot gnu dot org]

--- Comment #6 from rguenth at gcc dot gnu dot org  2009-01-27 14:38 ---
Happens here:

  /* If the PHI node is already available, use it.  */
  if ((res = vn_phi_lookup (phi)) != NULL_TREE)
{
  gimple_stmt_iterator gsi = gsi_for_stmt (phi);
  remove_phi_node (&gsi, true);
  release_defs (phi);
  add_to_value (val, get_or_alloc_expr_for_name (res));

we add g_2.7_58 to 0037 here even though get_expr_value_id returns 0030.  I
vaguely remember adding that code ...


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rguenth at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2009-01-21 10:13:21 |2009-01-27 14:38:26
   date||


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

[Bug middle-end/38934] [4.3/4.4 Regression] ICE in set_value_range, at tree-vrp.c:398

[joseph at codesourcery dot com]

--- Comment #17 from joseph at codesourcery dot com  2009-01-27 14:55 
---
Subject: Re:  [4.3/4.4 Regression] ICE in set_value_range,
 at tree-vrp.c:398

On Tue, 27 Jan 2009, bonzini at gnu dot org wrote:

> > It's very clear to me by now that HOST_WIDE_INT should only depend on the 
> > target (probably only on the target architecture), not the host; that's 
> > the only way to ensure consistency between hosts for the same target.  
> 
> It wouldn't actually be very hard to do that.  I'm almost sure that it would
> "just work".
> 
> But the (sub)problem here is that the same target architecture (32-bit i386)
> has different HOST_WIDE_INT size depending on whether GCC is a 32-bit
> single-arch or a 32-/64-bit bi-arch compiler.

My claim is that we should stop doing this: it should always be 64-bit for 
x86 and ARM, rather than depending on whether the target is biarch (x86) 
or whether it is EABI (ARM), just as it is for other targets that may or 
may not be biarch (MIPS, Power, SPARC).


-- 


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

[Bug tree-optimization/38926] [4.4 Regression] ice in find_or_generate_expression, at tree-ssa-pre.c:2769

[rguenth at gcc dot gnu dot org]

--- Comment #7 from rguenth at gcc dot gnu dot org  2009-01-27 15:08 ---
So we are about to insert a duplicate PHI node but for a different value
number.

I can trivially avoid the ICE, but I wonder if that (missed optimization?) is
bad or not ...

Patch in testing.


-- 


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

[Bug bootstrap/38892] gcc 4.4.0 20090104 - natVMVirtualMachine.cc:903: error: request for member 'frame_type' in ...

[rob1weld at aol dot com]

--- Comment #2 from rob1weld at aol dot com  2009-01-27 15:13 ---
Same issue on Fedora 10

# ../gcc_build/gcc/xgcc -v
Using built-in specs.
Target: i386-redhat-linux
Configured with: ../gcc_trunk/configure
--enable-languages=c,c++,fortran,java,objc,obj-c++ --enable-shared
--disable-static --enable-decimal-float --with-long-double-128 --enable-nls
--with-included-gettext --disable-gather-detailed-mem-stats --with-stabs
--enable-debug --enable-symvers --enable-version-specific-runtime-libs
--without-system-zlib --enable-gtk-cairo --enable-gconf-peer --enable-xmlj
--enable-gtk-peer --enable-plugin --enable-tool-wrappers
--enable-portable-native-sync --enable-hash-synchronization
--enable-interpreter --enable-local-sockets --enable-gjdoc
--enable-java-awt=gtk,xlib,x --enable-gc-debug --enable-libgcj-debug
--enable-objc-gc --disable-concept-checks --enable-libstdcxx-debug
--disable-stage1-checking --enable-checking=release --with-tune=k8
--with-cpu=k8 --with-arch=k8 --enable-__cxa_atexit
--disable-libunwind-exceptions --disable-dssi --enable-libgcj-multifile
--build=i386-redhat-linux --prefix=/mnt/drive2/gcc_test --with-cloog=/usr/local
Thread model: posix
gcc version 4.4.0 20090126 (experimental) [trunk revision 143680] (GCC) 


After applying the same fix as used for OpenSolaris the build continued.

Rob


-- 


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

[Bug middle-end/38934] [4.3/4.4 Regression] ICE in set_value_range, at tree-vrp.c:398

[jakub at gcc dot gnu dot org]

--- Comment #18 from jakub at gcc dot gnu dot org  2009-01-27 15:14 ---
The problem on ix86 is I believe that on such a register starved host, using
long long in many places will mean very noticeable performance degradation.

In any case, I'd prefer to change tree-vrp.c at this point (am going to
bootstrap/regtest it), with the testcase with -w in dg-options, and handle the
rest separately, as P2.  The rest is certainly not a recent regression (3.4.0
behaves the same way between i386 cc1 and x86_64 cc1 -m32).


-- 


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

[Bug boehm-gc/38967] gcc 4.4.0 20090125 [trunk revision 143660] - Boehm Testsuite failure is not unreported

[rob1weld at aol dot com]

--- Comment #1 from rob1weld at aol dot com  2009-01-27 15:18 ---
Running trunk revision 143680 on Fedora 10 I get:

# ../gcc_build/gcc/xgcc -v
Using built-in specs.
Target: i386-redhat-linux
Configured with: ../gcc_trunk/configure
--enable-languages=c,c++,fortran,java,objc,obj-c++ --enable-shared
--disable-static --enable-decimal-float --with-long-double-128 --enable-nls
--with-included-gettext --disable-gather-detailed-mem-stats --with-stabs
--enable-debug --enable-symvers --enable-version-specific-runtime-libs
--without-system-zlib --enable-gtk-cairo --enable-gconf-peer --enable-xmlj
--enable-gtk-peer --enable-plugin --enable-tool-wrappers
--enable-portable-native-sync --enable-hash-synchronization
--enable-interpreter --enable-local-sockets --enable-gjdoc
--enable-java-awt=gtk,xlib,x --enable-gc-debug --enable-libgcj-debug
--enable-objc-gc --disable-concept-checks --enable-libstdcxx-debug
--disable-stage1-checking --enable-checking=release --with-tune=k8
--with-cpu=k8 --with-arch=k8 --enable-__cxa_atexit
--disable-libunwind-exceptions --disable-dssi --enable-libgcj-multifile
--build=i386-redhat-linux --prefix=/mnt/drive2/gcc_test --with-cloog=/usr/local
Thread model: posix
gcc version 4.4.0 20090126 (experimental) [trunk revision 143680] (GCC) 


make[4]: Entering directory `/mnt/drive2/gcc_build/i386-redhat-linux/boehm-gc'
Switched to incremental mode
Emulating dirty bits with mprotect/signals
Completed 3 tests
Allocated 5635726 collectable objects
Allocated 306 uncollectable objects
Allocated 375 atomic objects
Allocated 34440 stubborn objects
Finalized 6608/6608 objects - finalization is probably ok
Total number of bytes allocated is 185927964
Final heap size is 9179136 bytes
Collector appears to work
Completed 148 collections
PASS: gctest
==
All 1 tests passed
==
make[4]: Leaving directory `/mnt/drive2/gcc_build/i386-redhat-linux/boehm-gc'

Rob


-- 


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

[Bug middle-end/38934] [4.3/4.4 Regression] ICE in set_value_range, at tree-vrp.c:398

[bonzini at gnu dot org]

--- Comment #19 from bonzini at gnu dot org  2009-01-27 15:21 ---
> The problem on ix86 is I believe that on such a register starved host, using
> long long in many places will mean very noticeable performance degradation.

Probably noticeable; however, Debian and Apple are already distributing bi-arch
compilers, and something has been done to improve the situation
(HOST_WIDEST_FAST_INT, the -fsplit-wide-types pass, ...).


-- 


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

[Bug testsuite/38820] During "make -i check" we set GCC_EXEC_PREFIX="/usr/local/lib/gcc/"

[rob1weld at aol dot com]

--- Comment #3 from rob1weld at aol dot com  2009-01-27 15:38 ---
(In reply to comment #2)
> It's not a bug that GCC EXEC_PREFIX is defined when the testsuite is run, as
> explained in these patches:
> 
>   http://gcc.gnu.org/ml/gcc-patches/2006-10/msg00708.html
>   http://gcc.gnu.org/ml/gcc-patches/2006-12/msg01493.html
> 
> When testing in the build tree the compiler is invoked with -B, which takes
> precendence over GCC_EXEC_PREFIX.  That allows getting start files from
> GCC_EXEC_PREFIX while the GCC support itself comes from the build tree.  It
> doesn't matter if $GCC_EXEC_PREFIX contains an old installation.
> 
OK for "RESOLVED INVALID" but I do not see that it was tested cross-target.

One example is host i386-unknown-linux-gnu target x86_64-unknown-linux-gnu
in the case where you want to upgrade from 32 bit based Operating System
to a 64 bit based system.

Another untested situations is where host and target are i386-unknown-linux-gnu
but the build is configured using "--with-tune=k8 --with-cpu=k8
--with-arch=k8".

Yet another is where you want to change your start files over from elf to
dwarf.

etc ...

I will test some of those sometime this year and re-open this if needed.

Thanks,
Rob


-- 


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

[Bug testsuite/38820] During "make -i check" we set GCC_EXEC_PREFIX="/usr/local/lib/gcc/"

[hjl dot tools at gmail dot com]

--- Comment #4 from hjl dot tools at gmail dot com  2009-01-27 15:47 ---
Reopen ...


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |


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

[Bug testsuite/38820] During "make -i check" we set GCC_EXEC_PREFIX="/usr/local/lib/gcc/"

[hjl dot tools at gmail dot com]

--- Comment #5 from hjl dot tools at gmail dot com  2009-01-27 15:48 ---


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


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug testsuite/36443] [4.3/4.4 Regression]: HOSTCC doesn't work with installed gcc

[hjl dot tools at gmail dot com]

--- Comment #32 from hjl dot tools at gmail dot com  2009-01-27 15:48 
---
*** Bug 38820 has been marked as a duplicate of this bug. ***


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 CC||rob1weld at aol dot com


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

[Bug testsuite/38946] [trunk regression]�gcc trunk 143562 - Testsuite - gfortran failing tests that worked previously

[rob1weld at aol dot com]

--- Comment #6 from rob1weld at aol dot com  2009-01-27 15:50 ---
Here is a newer result on Fedora 10:

=== gfortran tests ===

Running target unix

=== gfortran Summary ===

# of expected passes29107
# of expected failures  14
# of unsupported tests  113
/mnt/drive2/gcc_build/gcc/testsuite/gfortran/../../gfortran  version 4.4.0
20090126 (experimental) [trunk revision 143680] (GCC) 

# grep FAIL /mnt/drive2/gcc_build/gcc/testsuite/gfortran/gfortran.log | grep -v
XFAIL
# grep FAIL /mnt/drive2/gcc_build/gcc/testsuite/gfortran/gfortran.log | wc -l
14


It works OK (now) on i386-redhat-linux-* .

Rob


-- 


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

[Bug testsuite/36443] [4.3/4.4 Regression]: HOSTCC doesn't work with installed gcc

[hjl dot tools at gmail dot com]

--- Comment #33 from hjl dot tools at gmail dot com  2009-01-27 15:54 
---
I think it is a very bad idea to set GCC_EXEC_PREFIX for "make check".
If some people want binary tools, which aren't the part of installed gcc,
in the GCC_EXEC_PREFIX directory when running "make check", they
should use a branch or local change for this purpose. They shouldn't
impose their desires on all gcc developers.


-- 


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

[Bug testsuite/38946] [trunk regression]�gcc trunk 143562 - Testsuite - gfortran failing tests that worked previously

[rob1weld at aol dot com]

--- Comment #7 from rob1weld at aol dot com  2009-01-27 16:00 ---
(In reply to comment #5)
> ! Test XFAILed on these platforms because the system's printf() lacks
> ! proper support for denormalized long doubles. See PR24685
> 
> Looks like this testcase should be xfailed on solaris also.
> 

Eric says PR24685 works on "Solaris" (which is not the same OS as mine):
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24685#c27

Should libiberty test if the printf() fails and replace it we a better one?

Rob


-- 


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

[Bug c++/38908] [4.4 regression] Unexplained "'' is used uninitialized in this function" warning in cc1plus -m64

[bangerth at gmail dot com]

--- Comment #5 from bangerth at gmail dot com  2009-01-27 16:00 ---
Richard,
this isn't a duplicate of PR 38851: while the testcase there indeed now
passes, the one in the current PR still fails.

Best
 Wolfgang


-- 

bangerth at gmail dot com changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|DUPLICATE   |


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

[Bug c++/38908] [4.4 regression] Unexplained "'' is used uninitialized in this function" warning in cc1plus -m64

[bangerth at gmail dot com]

-- 

bangerth at gmail dot com changed:

   What|Removed |Added

   Priority|P3  |P2


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

[Bug testsuite/36443] [4.3/4.4 Regression]: HOSTCC doesn't work with installed gcc

[hjl dot tools at gmail dot com]

--- Comment #34 from hjl dot tools at gmail dot com  2009-01-27 16:06 
---
If I have an old gcc 4.4 installed on my machine, will setting
GCC_EXEC_PREFIX use the old installed gcc 4.4 for "make check"?


-- 


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

[Bug c++/38908] [4.4 regression] Unexplained "'' is used uninitialized in this function" warning in cc1plus -m64

[rguenth at gcc dot gnu dot org]

--- Comment #6 from rguenth at gcc dot gnu dot org  2009-01-27 16:11 ---
Well, it is a duplicate really, just this testcase involves one more case:

  # VUSE 
  # _3 = VDEF <_2(D)>
  __comp_ctor  (&, D.2044);

where the uninitialized aggregate use appears as a function argument.  While
I would like to have registers for these, simply disabling the warning for
calls looks easier.

I am testing a patch.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rguenth at gcc dot gnu dot
   |dot org |org
 Status|REOPENED|ASSIGNED
   Last reconfirmed|2009-01-21 22:24:03 |2009-01-27 16:11:53
   date||


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

[Bug testsuite/38946] [trunk regression]�gcc trunk 143562 - Testsuite - gfortran failing tests that worked previously

[rob1weld at aol dot com]

--- Comment #8 from rob1weld at aol dot com  2009-01-27 16:18 ---
(In reply to comment #4)
> (In reply to comment #3)
> > This is not so much an error in Fortran than it is an error in the
> > scripting and it's ability to add it's own LD_LIBRARY_PATH components.
> No. The current linking scheme links to the just-built libgfortran, not to
> the system libgfortran. This is fine, because it is the newly built library
> that we want to test. 

No. It is the same library since I type "make install" before I type "make
-i check".


> > They worked last week.
> Sure, this is a regression. 

I installed cloog in /usr/local on F10 and needed to use LD_LIBRARY_PATH
on this platform also. On i386-redhat-linux we don't have any trouble.


> > Here is my most recent test. Above you ask "Could you try before/after this"
> > do you mean compile and run the Testuite on both "r143461" and "r143463"?
> Yes. But to save time you can update only fortran or libgfortran and narrow
> the testsuite run to the failing tests using the RUNTESTFLAGS variable as
> explained here http://gcc.gnu.org/wiki/TestCaseWriting

OK, I'll be back on my OpenSolaris platform tomorrow.


> Furthermore, as your tests show that the failure is in the libgfortran, there
> is only one commit in that area in the window you gave (r143454-r143562): 
> 
> 
> r143541 | domob | 2009-01-21 14:34:55 +0100 (mer. 21 janv. 2009) | 29 lines
> 
> I don't know though how this could cause system-dependent failures :-(. 
> Daniel?

No reply.


> > Thanks for fixing this,
> Thanks for helping to fix this. 

One piece at a time ...

Rob


-- 


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

[Bug tree-optimization/38984] [4.2/4.3/4.4 Regression] NULL pointers always considered distinct by PTA, even with -fno-delete-null-pointer-checks

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.4.0


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

[Bug tree-optimization/38977] [4.4 Regression] bash no longer builds with profile-feedback

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2009-01-27 16:25 ---
Mine.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rguenth at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-01-27 16:25:02
   date||


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

[Bug target/38924] gcc 4.4.0 20090117 - init_priority incorrect for GNU ld in "gcc/config/sol2.h"

[rob1weld at aol dot com]

--- Comment #2 from rob1weld at aol dot com  2009-01-27 16:26 ---
(In reply to comment #1)
> With that dropped in gcc seems to build and test correctly. It _might_ be 
> that gcc builds Faster and uses Less memory during the two peaks in libjava
> after this patch, more testing required.
> Rob

It does build a bit faster and uses a lot less memory. It may be required
to use this patch in future just to get libjava to link on OpenSolaris
Platforms with less than 2GB of memory. This cuts the peaks in half.

The only downfall to this patch would be that "make install" is very much
slower and there is multiple re-linking of files which is annoying.

Rob


-- 


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

[Bug c++/38987] New: Including a precompiled header from another header causes invalid assembly to be generated

[frank dot richter at gmail dot com]

When a header(A) is precompiled and included from another header(B), compiling
a source file using B results in invalid assembly. The message from the
assembler is "file number X already allocated".


-- 
   Summary: Including a precompiled header from another header
causes invalid assembly to be generated
   Product: gcc
   Version: 4.2.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: frank dot richter at gmail dot com
  GCC host triplet: x86_64-pc-linux-gnu
GCC target triplet: x86_64-pc-linux-gnu


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

[Bug c++/38987] Including a precompiled header from another header causes invalid assembly to be generated

[frank dot richter at gmail dot com]

--- Comment #1 from frank dot richter at gmail dot com  2009-01-27 16:28 
---
Created an attachment (id=17192)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17192&action=view)
Test case for precompiled header inclusion

This test case is a simple scenario where a precompiled header is included by
another header. Run 'cause-bug.sh' to precompile a header and then attempt to
build a source indirectly using that header-


-- 


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

[Bug testsuite/38910] gcc 4.4.0 - Testsuite charset.exp not checking my locale

[rob1weld at aol dot com]

--- Comment #1 from rob1weld at aol dot com  2009-01-27 16:30 ---
On Fedora 10 (i386-redhat-linux) trunk revision 143680 using:

# iconv --version
iconv (GNU libc) 2.9

# iconv -l | grep IBM1047
IBM1047//

Rob


-- 


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

[Bug c++/38880] [4.4 Regression] g++.dg/init/const7.C XFAILed

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2009-01-27 16:33 ---
Created an attachment (id=17193)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17193&action=view)
example patch

I just found this, I tried to fix this in fold but in the end agreed with
Andrew
that the C++ FE should do what the C FE does here.


-- 


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

[Bug rtl-optimization/38583] huge test case makes register allocator run out of memory while constructing the conflict graph

[hjl dot tools at gmail dot com]

--- Comment #4 from hjl dot tools at gmail dot com  2009-01-27 16:50 ---
(In reply to comment #0)
> This is split off from PR38474 for clarity. Compiling the testcase of that PR 
> 
> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16873)
> 
> as
> 
> gfortran -ffree-line-length-512 -g -ffree-form -ftime-report -c -O3
> -march=native -funroll-loops -fno-rename-registers testcase.f90
> 
> requires ~9.3Gb of RAM with mainline, while 4.3 only requires ~2.5Gb.
> 

This testcase failed to compile with gcc 4.3.4 143496:

/usr/gcc-4.3/bin/gcc -S -march=native -funroll-loops -fno-rename-registers
-ffree-line-length-512 -g -ffree-form -ftime-report -c -O3 testcase.f90
-fmem-report
f951: out of memory allocating 6998974688 bytes after a total of 674205696
bytes

on Linux/Intel64 with 4GB RAM and 2GB swap. Gcc 4.4.0 revision 143680
compiles it on the same machine.


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug bootstrap/38867] [Regression] gcc 4.4.0 20090114 - libjava/configure sets "NONE/share/python", need "${prefix}/share/python"

[rob1weld at aol dot com]

--- Comment #1 from rob1weld at aol dot com  2009-01-27 17:00 ---
Trunk revision 143680 works on Fedora 10:

# gcc/xgcc -v
Using built-in specs.
Target: i386-redhat-linux
Configured with: ../gcc_trunk/configure
--enable-languages=c,c++,fortran,java,objc,obj-c++ --enable-shared
--disable-static --enable-decimal-float --with-long-double-128 --enable-nls
--with-included-gettext --disable-gather-detailed-mem-stats --with-stabs
--enable-debug --enable-symvers --enable-version-specific-runtime-libs
--without-system-zlib --enable-gtk-cairo --enable-gconf-peer --enable-xmlj
--enable-gtk-peer --enable-plugin --enable-tool-wrappers
--enable-portable-native-sync --enable-hash-synchronization
--enable-interpreter --enable-local-sockets --enable-gjdoc
--enable-java-awt=gtk,xlib,x --enable-gc-debug --enable-libgcj-debug
--enable-objc-gc --disable-concept-checks --enable-libstdcxx-debug
--disable-stage1-checking --enable-checking=release --with-tune=k8
--with-cpu=k8 --with-arch=k8 --enable-__cxa_atexit
--disable-libunwind-exceptions --disable-dssi --enable-libgcj-multifile
--build=i386-redhat-linux --prefix=/mnt/drive2/gcc_test --with-cloog=/usr/local
Thread model: posix
gcc version 4.4.0 20090126 (experimental) [trunk revision 143680] (GCC) 


# grep --colour Python\ modules made_1*
made_1a_log.txt:Python modules dir: /mnt/drive2/gcc_test/share/python


# ls -l /mnt/drive2/gcc_test/share/python/
total 24
-rw-r--r-- 1 root root 14342 2009-01-26 18:40 aotcompile.py
-rw-r--r-- 1 root root  7400 2009-01-26 18:40 classfile.py


Rob


-- 


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

[Bug tree-optimization/38977] [4.4 Regression] bash no longer builds with profile-feedback

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2009-01-27 17:01 ---
Hm, unfortunately simply disabling that error doesn't fix my bash build.
Instead we now error on

jobs.c:4121: error: corrupted profile info: number of executions for edge 10-11
thought to be -1726
jobs.c:4121: error: corrupted profile info: number of executions for edge 10-12
thought to be 1745
jobs.c:4121: error: corrupted profile info: number of iterations for basic
block 11 thought to be -120

which is an error that is present also in 4.3.  So I guess there is some real
bug wrt profiling in gcc 4.4.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug c++/38987] Including a precompiled header from another header causes invalid assembly to be generated

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2009-01-27 17:14 ---
CXX=g++-4.3 ./cause-error.sh 
In file included from :0:
:0: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

This looks related to https://bugzilla.novell.com/show_bug.cgi?id=432433
and https://bugzilla.novell.com/show_bug.cgi?id=444153

-> PCH is broken wrt location information.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
  Known to fail||4.1.2 4.2.4 4.3.3 4.4.0


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

[Bug target/38988] New: Cannot build crtstuff.c with -mcmodel=large -fPIC -O2

[sje at cup dot hp dot com]

If you compile the following code (cut down from crtstuff.c) with
-mcmodel=large -fPIC -O2 on a 64 bit x86 target GCC will ICE.  There are at
least two problems, one in cselib_hash_rtx, and if that is fixed then I get a
shared rtx abort.

The test case is 

typedef long unsigned int size_t;
typedef void (*func_ptr) (void);
static func_ptr __DTOR_LIST__[1] = { (func_ptr) (-1) };
static void __attribute__((used)) __do_global_dtors_aux (void)
{
  extern func_ptr __DTOR_END__[];
  size_t dtor_idx = 0;
  const size_t max_idx = __DTOR_END__ - __DTOR_LIST__ - 1;
  func_ptr f;
  while (dtor_idx < max_idx)
  {
f = __DTOR_LIST__[++dtor_idx];
f ();
  }
}


-- 
   Summary: Cannot build crtstuff.c with -mcmodel=large -fPIC -O2
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sje at cup dot hp dot com
GCC target triplet: x86_64-*-*


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

[Bug c++/38987] Including a precompiled header from another header causes invalid assembly to be generated

[frank dot richter at gmail dot com]

--- Comment #3 from frank dot richter at gmail dot com  2009-01-27 17:18 
---
No ICE here (gcc version 4.2.4 (Gentoo 4.2.4 p1.0)), but the underlying cause
might be the same.


-- 


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

[Bug c++/28017] lack of guard variables for explicitly instantiated template static data

[bkoz at gcc dot gnu dot org]

--- Comment #13 from bkoz at gcc dot gnu dot org  2009-01-27 17:26 ---
*** Bug 25956 has been marked as a duplicate of this bug. ***


-- 

bkoz at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||jkp at kirkconsulting dot co
   ||dot uk


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

[Bug libstdc++/25956] Memory error when dynamic linking STL specializations

[bkoz at gcc dot gnu dot org]

--- Comment #5 from bkoz at gcc dot gnu dot org  2009-01-27 17:26 ---

Duplicate

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


-- 

bkoz at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug target/38988] Cannot build crtstuff.c with -mcmodel=large -fPIC -O2

[hjl dot tools at gmail dot com]

--- Comment #1 from hjl dot tools at gmail dot com  2009-01-27 17:46 ---
Do you have a testcase to show that -mcmodel=large doesn't work for
you?


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 CC||hjl dot tools at gmail dot
   ||com


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

[Bug target/38988] Cannot build crtstuff.c with -mcmodel=large -fPIC -O2

[hjl dot tools at gmail dot com]

--- Comment #2 from hjl dot tools at gmail dot com  2009-01-27 17:48 ---
By testcase, I meant a user application, not crtstuff.c, like

# gcc -mcmodel=large foo.c
# ./a.out


-- 


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

[Bug target/38988] Cannot build crtstuff.c with -mcmodel=large -fPIC -O2

[sje at cup dot hp dot com]

--- Comment #3 from sje at cup dot hp dot com  2009-01-27 17:54 ---
No, I don't have a user application.  I believe the problem was that the user
was compiling a program with something like
-Wl,--section-start,.text=0x11000 and because the crt files weren't
compiled with -mcmodel=large they couldn't reach the text section.  If I
compile a simple hello world program with this linker option I get a number of
errors about relocations being truncated.


-- 


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

[Bug c++/37554] [4.3/4.4 regression] ICE with invalid cast

[paolo dot carlini at oracle dot com]

--- Comment #4 from paolo dot carlini at oracle dot com  2009-01-27 17:56 
---
On it.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |paolo dot carlini at oracle
   |dot org |dot com
 Status|NEW |ASSIGNED


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

[Bug target/38988] Cannot build crtstuff.c with -mcmodel=large -fPIC -O2

[hjl dot tools at gmail dot com]

--- Comment #4 from hjl dot tools at gmail dot com  2009-01-27 18:07 ---
Assuming you have solved crtstuff.c issue, will /usr/lib64/crt1.o
work with -Wl,--section-start,.text=0x11000? Can you try
the latest binutils from CVS with

[...@gnu-6 pr38988]$ cat f.c
#include 

int
main ()
{
  printf ("hello\n");
  return 0;
}
[...@gnu-6 pr38988]$ gcc f.c -Wl,-Ttext-segment,0x11000 -fpie -pie -g
[...@gnu-6 pr38988]$ gdb a.out 
GNU gdb (GDB) 6.8.50.20081208-cvs (AVX revision 4683)
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu".
For bug reporting instructions, please see:
...
(gdb) b main
Breakpoint 1 at 0x11708: file f.c, line 6.
(gdb) r
Starting program: /export/home/hjl/bugs/gcc/pr38988/a.out 

Breakpoint 1, main () at f.c:6
6 printf ("hello\n");
(gdb) p $rip
$1 = (void (*)()) 0x11708 
(gdb) c
Continuing.
hello

Program exited normally.
(gdb) 

I added a new linker switch:

-Ttext-segment ADDRESS  Set address of text segment

It may work for you.


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING


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

[Bug fortran/38883] [4.4 Regression] ICE for MVBITS with derived type argument that has run-time subscripts

[domob at gcc dot gnu dot org]

--- Comment #7 from domob at gcc dot gnu dot org  2009-01-27 18:08 ---
Subject: Bug 38883

Author: domob
Date: Tue Jan 27 18:07:54 2009
New Revision: 143707

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143707
Log:
2009-01-27  Daniel Kraft  

PR fortran/38883
* trans-stmt.c (gfc_conv_elemental_dependencies):  Create temporary
for the real type needed to make it work for subcomponent-references.

2009-01-27  Daniel Kraft  

PR fortran/38883
* gfortran.dg/mvbits_6.f90:  New test.
* gfortran.dg/mvbits_7.f90:  New test.
* gfortran.dg/mvbits_8.f90:  New test.

Added:
trunk/gcc/testsuite/gfortran.dg/mvbits_6.f90
trunk/gcc/testsuite/gfortran.dg/mvbits_7.f90
trunk/gcc/testsuite/gfortran.dg/mvbits_8.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-stmt.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug fortran/38883] [4.4 Regression] ICE for MVBITS with derived type argument that has run-time subscripts

[domob at gcc dot gnu dot org]

--- Comment #8 from domob at gcc dot gnu dot org  2009-01-27 18:10 ---
Fixed on trunk.


-- 

domob at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug c++/37737] [c++0x] ICE in get_innermost_template_args at cp/pt.c:516 during variadic function overload deduction

[ethouris at gmail dot com]

--- Comment #7 from ethouris at gmail dot com  2009-01-27 18:33 ---
Created an attachment (id=17194)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17194&action=view)
Preprocessed source that caused the problem

The problem is reported for line 40 in msigslot.h, where a 'friend' declaration
is provided (with a variadic-templated function).


-- 


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

[Bug c++/37737] [c++0x] ICE in get_innermost_template_args at cp/pt.c:516 during variadic function overload deduction

[ethouris at gmail dot com]

--- Comment #8 from ethouris at gmail dot com  2009-01-27 18:35 ---
I added as attachment the code that causes the same error message.

Please note that this code was compiling and working correctly with the old
Doug Gregor's patch, which was the first version of 'variadic template'
feature.
I'd suggest you check why it was working there.


-- 


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

[Bug ada/37430] [4.4 Regression] C974013 gives exception

[hjl dot tools at gmail dot com]

--- Comment #3 from hjl dot tools at gmail dot com  2009-01-27 18:39 ---
Fixed as of revision 139039.


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug testsuite/36443] [4.3/4.4 Regression]: HOSTCC doesn't work with installed gcc

[janis at gcc dot gnu dot org]

--- Comment #35 from janis at gcc dot gnu dot org  2009-01-27 18:45 ---
In response to comment #34, the -B option overrides GCC_EXEC_PREFIX and the
compiler being tested in the build directory is invoked with -B. 
GCC_EXEC_PREFIX will only be used to find files that are not in the build
directory.


-- 


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

[Bug middle-end/38615] [4.2/4.3 Regression] invalid promotion to static from auto

[sje at gcc dot gnu dot org]

--- Comment #4 from sje at gcc dot gnu dot org  2009-01-27 18:46 ---
Subject: Bug 38615

Author: sje
Date: Tue Jan 27 18:45:49 2009
New Revision: 143708

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143708
Log:
PR middle-end/38615
* gimplify.c (gimplify_init_constructor): Fix promotion of const
variables to static.
* doc/invoke.texi (-fmerge-all-constants): Update description.
* testsuite/gcc.dg/pr38615.c: New test.

Added:
branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/pr38615.c
Modified:
branches/gcc-4_3-branch/gcc/ChangeLog
branches/gcc-4_3-branch/gcc/doc/invoke.texi
branches/gcc-4_3-branch/gcc/gimplify.c
branches/gcc-4_3-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug middle-end/38615] [4.2/4.3 Regression] invalid promotion to static from auto

[sje at cup dot hp dot com]

--- Comment #5 from sje at cup dot hp dot com  2009-01-27 18:48 ---
Fixed on trunk for 4.4.0 and on 4.3 branch for 4.3.4.


-- 

sje at cup dot hp dot com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
  Known to fail|4.0.1 4.4.0 4.3.0 4.1.1 |4.0.1 4.3.0 4.1.1 4.2.0
   |4.2.0 4.3.3 |4.3.3
  Known to work|3.3.3 4.4.0 |3.3.3 4.3.4 4.4.0
 Resolution||FIXED


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

[Bug other/38983] GPL version 3 transition incomplete

[bkoz at gcc dot gnu dot org]

--- Comment #1 from bkoz at gcc dot gnu dot org  2009-01-27 18:55 ---
http://gcc.gnu.org/ml/gcc/2009-01/msg00417.html


-- 


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

[Bug ada/37430] [4.4 Regression] C974013 gives exception

[joel at gcc dot gnu dot org]

--- Comment #4 from joel at gcc dot gnu dot org  2009-01-27 19:04 ---
(In reply to comment #3)
> Fixed as of revision 139039.
> 

Disagree.  http://gcc.gnu.org/ml/gcc-testresults/2009-01/msg02352.html is ACATS
for powerpc-rtems on psim. Test C974013 fails with exactly the same backtrace
as originally reported.

powerpc-rtems4.10-gcc (GCC) 4.4.0 20090122 (experimental) [trunk revision
143574]


-- 

joel at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|FIXED   |


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

[Bug ada/38989] New: How much stack space should c380004 take?

[joel at gcc dot gnu dot org]

RTEMS has fixed size task stacks.  This test is blowing a stack that is ~100K
large.  How large does it need to be?  Is is a bug to use this much stack?

,.,. C380004 ACATS 2.5 88-01-01 00:00:00
 C380004 Check evaluation of discriminant expressions when the
constraint depends on a discriminant, and the
discriminants have defaults -
discriminant-dependententry families and protected
components.
   - C380004 Discriminant-dependent entry families for task types.
   - C380004 Discriminant-dependent entry families for protected types.
BLOWN STACK!!! Offending task(0x6EE614): id=0x0B010002; name=0x
  stack covers range 0x6FAE38 - 0x713E47 (102416 bytes)


-- 
   Summary: How much stack space should c380004 take?
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: joel at gcc dot gnu dot org
GCC target triplet: powerpc-rtems4.10


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