[Bug c++/19531] NRV is performed on volatile temporary

[chrbr at gcc dot gnu dot org]

--- Comment #8 from chrbr at gcc dot gnu dot org  2007-10-31 08:01 ---
fixed check_return_expr


-- 

chrbr at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug target/33948] Bootstrap broken on mips-sgi-irix6.5

[rsandifo at gcc dot gnu dot org]

--- Comment #3 from rsandifo at gcc dot gnu dot org  2007-10-31 08:23 
---
Subject: Bug 33948

Author: rsandifo
Date: Wed Oct 31 08:23:30 2007
New Revision: 129794

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129794
Log:
gcc/
PR target/33948
* config/mips/mips.c (mips_fpr_return_fields): Fix SCALAR_TYPE_P
check.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/mips/mips.c


-- 


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

[Bug target/33948] Bootstrap broken on mips-sgi-irix6.5

[rsandifo at gcc dot gnu dot org]

--- Comment #4 from rsandifo at gcc dot gnu dot org  2007-10-31 08:23 
---
Fixed on mainline.


-- 

rsandifo at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug c++/33952] -Wfatal-errors truncates multi-line error messages.

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2007-10-31 09:20 ---
Apart from the issue regarding that the last two errors should be notes this
is really impossible to "fix" if -Wfatal-errors should continue to work as
designed.  That is, the only way would be to annotate all _callers_ of
diagnostic
functions to eventually terminate compilation, which is a too large overhead
really.

Sorry.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WONTFIX


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

[Bug fortran/33596] ICE with simplified ISNAN

[fxcoudert at gcc dot gnu dot org]

--- Comment #2 from fxcoudert at gcc dot gnu dot org  2007-10-31 09:13 
---
Fixed on mainline.


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug tree-optimization/33953] [4.3 regression] internal compiler error: vector VEC(tree,base) index domain error, in vectorizable_operation at tree-vect-transform.c:4017

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2007-10-31 09:47 ---
Uh, the VEC_* stuff used there looks like a mess.  It's not clear who allocates
and what the size should be.  For example vect_get_vec_defs_for_stmt_copy
doesn't allocate the VECs which is exactly what causes the problem here.

Reducing.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||dorit at gcc dot gnu dot org


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

[Bug fortran/33897] Incorrect host association in module

[burnus at gcc dot gnu dot org]

--- Comment #15 from burnus at gcc dot gnu dot org  2007-10-31 09:59 ---
Subject: Bug 33897

Author: burnus
Date: Wed Oct 31 09:59:16 2007
New Revision: 129795

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129795
Log:
2007-10-31  Paul Thomas  <[EMAIL PROTECTED]>

PR fortran/33897
* decl.c (gfc_match_entry): Do not make ENTRY name
global for contained procedures.
* parse.c (gfc_fixup_sibling_symbols): Fix code for
determining whether a procedure is external.

2007-10-31  Paul Thomas  <[EMAIL PROTECTED]>

PR fortran/33897
* gfortran.dg/contained_3.f90: New.


Added:
trunk/gcc/testsuite/gfortran.dg/contained_3.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/decl.c
trunk/gcc/fortran/parse.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug fortran/33897] Incorrect host association in module

[burnus at gcc dot gnu dot org]

--- Comment #16 from burnus at gcc dot gnu dot org  2007-10-31 09:59 ---
FIXED on the trunk (= 4.3.0).


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug c++/33516] [4.1/4.2/4.3 Regression] Rejects typedef qualified name-lookup

[jakub at gcc dot gnu dot org]

--- Comment #6 from jakub at gcc dot gnu dot org  2007-10-31 10:25 ---
Testing a patch.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jakub at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-10-31 10:25:15
   date||


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

[Bug rtl-optimization/33673] [4.3 Regression] ICE in verify_flow_info, missing barrier, when multiple tree opts disabled

[jakub at gcc dot gnu dot org]

-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jakub at gcc dot gnu dot org
   |dot org |
URL||http://gcc.gnu.org/ml/gcc-
   ||patches/2007-
   ||10/msg01845.html
 Status|NEW |ASSIGNED
   Last reconfirmed|2007-10-11 12:53:19 |2007-10-31 10:29:42
   date||


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

[Bug tree-optimization/33953] [4.3 regression] internal compiler error: vector VEC(tree,base) index domain error, in vectorizable_operation at tree-vect-transform.c:4017

[ubizjak at gmail dot com]

--- Comment #3 from ubizjak at gmail dot com  2007-10-31 10:31 ---
Smaller testcase:

--cut here--
void
blockmove_NtoN_blend_noremap32 (const unsigned int *srcdata, int srcwidth,
int srcheight, int srcmodulo,
unsigned int *dstdata, int dstmodulo,
int srcshift)
{
  unsigned int *end;
  srcmodulo -= srcwidth;
  dstmodulo -= srcwidth;
  while (srcheight)
{
  end = dstdata + srcwidth;
  while (dstdata <= end - 8)
{
  dstdata[0] |= srcdata[0] << srcshift;
  dstdata[1] |= srcdata[1] << srcshift;
  dstdata[2] |= srcdata[2] << srcshift;
  dstdata[3] |= srcdata[3] << srcshift;
  dstdata[4] |= srcdata[4] << srcshift;
  dstdata[5] |= srcdata[5] << srcshift;
  dstdata[6] |= srcdata[6] << srcshift;
  dstdata[7] |= srcdata[7] << srcshift;
  dstdata += 8;
  srcdata += 8;
}
  while (dstdata < end)
*(dstdata++) |= *(srcdata++) << srcshift;
  srcdata += srcmodulo;
  dstdata += dstmodulo;
  srcheight--;
}
}
--cut here--

Confirmed on x86_64 and i686-sse2 with -O2 -ftree-vectorize.


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-10-31 10:31:46
   date||


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

[Bug tree-optimization/33953] [4.3 regression] internal compiler error: vector VEC(tree,base) index domain error, in vectorizable_operation at tree-vect-transform.c:4017

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2007-10-31 10:37 ---
typedef unsigned int UINT32;
void blockmove_NtoN_blend_noremap32 ( const UINT32 *srcdata,int srcwidth,int
srcheight,int srcmodulo, UINT32 *dstdata,int dstmodulo, int srcshift) {
 UINT32 *end;
 while (srcheight) {
  while (dstdata <= end - 8) {
  dstdata[0] |= srcdata[0] << srcshift;
  dstdata[1] |= srcdata[1] << srcshift;
  dstdata[2] |= srcdata[2] << srcshift;
  dstdata[3] |= srcdata[3] << srcshift;
  dstdata[4] |= srcdata[4] << srcshift;
  dstdata[5] |= srcdata[5] << srcshift;
  dstdata[6] |= srcdata[6] << srcshift;
  dstdata[7] |= srcdata[7] << srcshift;
  dstdata += 8;
  srcdata += 8;
  }
  }
}


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Last reconfirmed|2007-10-31 10:31:46 |2007-10-31 10:37:29
   date||


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

[Bug tree-optimization/33953] [4.3 regression] internal compiler error: vector VEC(tree,base) index domain error, in vectorizable_operation at tree-vect-transform.c:4017

[irar at il dot ibm dot com]

--- Comment #5 from irar at il dot ibm dot com  2007-10-31 10:57 ---
The problem here is that more than one vector stmts are used to vectorize (SLP)
this loop, while only one vector operand is created in case of vector shift
with scalar argument.

I am preparing a patch.

Thanks,
Ira


-- 


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

[Bug fortran/33941] [4.3 Regression] gfortran creates module files it can't read

[dominiq at lps dot ens dot fr]

--- Comment #19 from dominiq at lps dot ens dot fr  2007-10-31 11:11 ---
Minimal quick and dirty patch (including Tobias' one) that fixes the composite
relational operators:

--- /opt/gcc/_gcc-clean/gcc/fortran/module.c2007-10-28 21:01:20.0
+0100
+++ /opt/gcc/gcc-4.3-work/gcc/fortran/module.c  2007-10-31 11:27:08.0
+0100
@@ -1087,7 +1087,8 @@
   for (;;)
 {
   c = module_char ();
-  if (!ISALNUM (c) && c != '_' && c != '-')
+  /* Added '=' for intrinsic operators such as /= or >=.  */
+  if (!ISALNUM (c) && c != '_' && c != '-' && c != '=')
break;

   *p++ = c;
@@ -1195,6 +1196,11 @@
 case 'X':
 case 'Y':
 case 'Z':
+/* For intrinsic operators such as /= or >=.  */
+case '=':
+case '<':
+case '>':
+case '/':
   parse_name (c);
   return ATOM_NAME;

It assumes that parse_name is used to read a valid module. If this is not the
case, it leads to:

Fatal Error: Reading module foo at line 30 column 17: find_enum(): Enum not
found

(checked on a hacked module file, note that it would be more user friendly to
replace 'Enum' by the actual atom_name).

Final note for Toby: making FOX-3.0 fails at m_dom_dom.f90 with:

m_dom_dom.f90:10630.37:

character(len=getsystemId_len(np, associated(np))) :: c
1
Error: Inquiry function 'associated' at (1) is not permitted in an
initialization expression
...
m_dom_dom.f90:928.37:

character(len=getnodeName_len(np, associated(np))) :: c
1
Error: Inquiry function 'associated' at (1) is not permitted in an
initialization expression
m_dom_dom.f90:3838.21:

  if (str_vs(np%elExtras%namespaceNodes%nodes(i)%this%elExtras%namespac
1
Error: Procedure argument at (1) is local to a PURE procedure and has the
POINTER attribute
m_dom_dom.f90:3848.23:

if (str_vs(np%elExtras%ownerElement%elExtras%namespaceNodes%nodes(i
  1
Error: Procedure argument at (1) is local to a PURE procedure and has the
POINTER attribute
Fatal Error: Error count reached limit of 25.

If you think that these errors are buggy, please open a new PR.


-- 


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

[Bug tree-optimization/33953] [4.3 regression] internal compiler error: vector VEC(tree,base) index domain error, in vectorizable_operation at tree-vect-transform.c:4017

[irar at il dot ibm dot com]

--- Comment #6 from irar at il dot ibm dot com  2007-10-31 11:22 ---
(In reply to comment #2)
> Uh, the VEC_* stuff used there looks like a mess.  It's not clear who 
> allocates
> and what the size should be. 

I'll take a look and fix if necessary.

> For example vect_get_vec_defs_for_stmt_copy
> doesn't allocate the VECs which is exactly what causes the problem here.

vect_get_vec_defs_for_stmt_copy is not called here, it is used to create vector
copies in case of multiple types in the loop. It should reuse the VEC used for
the first copy. I think, there is indeed a problem here. We should overwrite
the  existing entries and not push the new ones. I'll look into this. 

> 
> Reducing.
> 

Thanks,
Ira


-- 


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

[Bug c++/33955] internal compiler error: in dependent_type_p, at cp/pt.c:15245 (vararg template problem)

[dgregor at gcc dot gnu dot org]

--- Comment #2 from dgregor at gcc dot gnu dot org  2007-10-31 12:09 ---
I can duplicate this locally. Here's a smaller test case:

template
struct uncvref
{
  typedef T type;
};

template
struct args
{
  static const int size = sizeof...(Args);
};

template
struct apply_args;

template
struct apply_args, args, S, V, N, N>
{
  typedef args<
typename G::template apply::type, S, V>::type...
> type;
};

struct or_
{
  template
  struct apply {
typedef typename E::type type;
  };
};

template
struct identity
{
  typedef T type;
};

apply_args, args>, float, double> a1;

I'm working on a fix now.


-- 

dgregor at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |dgregor at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-10-31 12:09:52
   date||


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

[Bug c++/33955] internal compiler error: in dependent_type_p, at cp/pt.c:15245 (vararg template problem)

[dgregor at gcc dot gnu dot org]

--- Comment #3 from dgregor at gcc dot gnu dot org  2007-10-31 12:23 ---
This tiny patch should fix the problem. We weren't digging into TYPENAME_TYPEs
deep enough to find all of the parameter packs. The patch fixes both the
original test case and the reduced one. However, I can't test it in isolation
at the moment.

Index: pt.c
===
--- pt.c(revision 129773)
+++ pt.c(working copy)
@@ -2505,6 +2505,12 @@ find_parameter_packs_r (tree *tp, int *w
   *walk_subtrees = 0;
   return NULL_TREE;

+case TYPENAME_TYPE:
+  cp_walk_tree (&TYPENAME_TYPE_FULLNAME (t), &find_parameter_packs_r,
+   ppd, ppd->visited);
+  *walk_subtrees = 0;
+  return NULL_TREE;
+
 case TYPE_PACK_EXPANSION:
 case EXPR_PACK_EXPANSION:
   *walk_subtrees = 0;


-- 


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

[Bug tree-optimization/31081] [4.3 Regression] Inliner messes up SSA for abnormals

[rguenth at gcc dot gnu dot org]

--- Comment #7 from rguenth at gcc dot gnu dot org  2007-10-31 12:24 ---
Another, similar testcase.  ICEs at -O and above with

Unable to coalesce ssa_names 23 and 15 which are marked as MUST COALESCE.
SR.8_23(ab) and  SR.8_15(ab)
t.ii: In function 'int main(int, char**)':
t.ii:36: internal compiler error: SSA corruption
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


class String;

class CString
{
public:
CString();
~CString() { operator delete(_rep); }
operator const char*() const { return _rep; }
private:
CString(char* cstr);
char* _rep;
};

class String
{
public:

String();
String(const char* str);
~String();
CString getCString() const;
};

int is_absolute_path(const char *path);

inline void getAbsolutePath(
const char* path,
const String& filename)
{
(!is_absolute_path(filename.getCString()) && path);
return;
}

int foo(int &value);

int main(int argc, char** argv)
{
int repeatTestCount = 0;
if (foo(repeatTestCount))
{
repeatTestCount = 1;
}
for (int numTests = 1; numTests <= repeatTestCount; numTests++)
{
getAbsolutePath("blah", "blah");
}
return 0;
}


-- 


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

[Bug fortran/33957] New: gfortran rejects valid initialization expression

[tow21 at cam dot ac dot uk]

gfortran rejects the following:

function bug(i) result(c)
  integer, pointer :: i
  character(len=merge(1,2, associated(p)) :: c
end function bug

Error: Inquiry function 'associated' at (1) is not permitted in an
initialization expression

However according to 7.1.6.2 of ISO/IEC1539-1 there is no such prohibition:

R734: specification-expr is scalar-int-expr
Constraint: scalar-int-expr shall be a restricted expression:

A restricted expression is [composed of]

(2) a variable that is a dummy argument that has neither then OPTIONAL nor the
INTENT(OUT) attribut [...]

[ie referencing a POINTER argument is ok]

[...]

(8) a reference to any other intrinsic function defined in this standard where
each argument is a restricted expression.

[...]

(and indeed no other compiler I have access to has complained about this.)


-- 
   Summary: gfortran rejects valid initialization expression
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tow21 at cam dot ac dot uk


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

[Bug c++/32384] [4.1/4.2/4.3 regression] Pseudo-dtor in template class rejected

[jakub at gcc dot gnu dot org]

--- Comment #1 from jakub at gcc dot gnu dot org  2007-10-31 12:31 ---
Testing a patch.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jakub at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-10-31 12:31:17
   date||


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

[Bug middle-end/33779] [4.3 Regression] folds unsigned multiplication == 0 to true

[rguenth at gcc dot gnu dot org]

--- Comment #8 from rguenth at gcc dot gnu dot org  2007-10-31 12:33 ---
Subject: Bug 33779

Author: rguenth
Date: Wed Oct 31 12:33:05 2007
New Revision: 129796

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129796
Log:
2007-10-31  Richard Guenther  <[EMAIL PROTECTED]>

PR middle-end/33779
* fold-const.c (extract_muldiv_1): Make sure to not introduce
new undefined integer overflow.
(fold_binary): Avoid useless conversion.

* gcc.c-torture/execute/pr33779-1.c: New testcase.
* gcc.c-torture/execute/pr33779-2.c: Likewise.

Added:
trunk/gcc/testsuite/gcc.c-torture/execute/pr33779-1.c
trunk/gcc/testsuite/gcc.c-torture/execute/pr33779-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/fold-const.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug middle-end/33779] [4.3 Regression] folds unsigned multiplication == 0 to true

[rguenth at gcc dot gnu dot org]

--- Comment #9 from rguenth at gcc dot gnu dot org  2007-10-31 12:34 ---
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=33779

[Bug tree-optimization/33953] [4.3 regression] internal compiler error: vector VEC(tree,base) index domain error, in vectorizable_operation at tree-vect-transform.c:4017

[irar at il dot ibm dot com]

--- Comment #7 from irar at il dot ibm dot com  2007-10-31 12:57 ---
I am testing the following patch:

Index: tree-vect-transform.c
===
--- tree-vect-transform.c   (revision 129627)
+++ tree-vect-transform.c   (working copy)
@@ -3915,10 +3915,14 @@ vectorizable_operation (tree stmt, block
   /* Handle def.  */
   vec_dest = vect_create_destination_var (scalar_dest, vectype);

-  if (!slp_node)
-vec_oprnds0 = VEC_alloc (tree, heap, 1);
-  if (op_type == binary_op)
-vec_oprnds1 = VEC_alloc (tree, heap, 1);
+  if (slp_node && op_type == binary_op)
+vec_oprnds1 = VEC_alloc (tree, heap, slp_node->vec_stmts_size);
+  else
+{
+  vec_oprnds0 = VEC_alloc (tree, heap, 1);
+  if (op_type == binary_op)
+vec_oprnds1 = VEC_alloc (tree, heap, 1);
+}

   /* In case the vectorization factor (VF) is bigger than the number
  of elements that we can fit in a vectype (nunits), we have to generate
@@ -3993,6 +3997,11 @@ vectorizable_operation (tree stmt, block
fprintf (vect_dump, "operand 1 using scalar mode.");
  vec_oprnd1 = op1;
  VEC_quick_push (tree, vec_oprnds1, vec_oprnd1);
+  if (slp_node)
+{
+   for (i = 0; i < slp_node->vec_stmts_size - 1; i++)
+  VEC_quick_push (tree, vec_oprnds1, vec_oprnd1);
+}
}
}


-- 


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

[Bug fortran/33957] gfortran rejects valid initialization expression

[anlauf at gmx dot de]

--- Comment #1 from anlauf at gmx dot de  2007-10-31 12:59 ---
(In reply to comment #0)

> [...]
> 
> (and indeed no other compiler I have access to has complained about this.)

As a side note: xlf 9.1 says this is a F2003 feature and not a F95 feature.


-- 


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

[Bug tree-optimization/32723] [4.2 Regression] memory hog in solve_graph

[rguenth at gcc dot gnu dot org]

--- Comment #15 from rguenth at gcc dot gnu dot org  2007-10-31 13:07 
---
The memory is temporarily needed now by solve_graph(), because the graph has
48902 nodes.  On the mainline we have only 3 constraints while for 4.2 we have
thousands:

ANYTHING = &ANYTHING
READONLY = &ANYTHING
INTEGER = &ANYTHING
ESCAPED_VARS = *ESCAPED_VARS
NONLOCAL.6 = ESCAPED_VARS
ESCAPED_VARS = &NONLOCAL.6
ESCAPED_VARS = &NONLOCAL.6
infos = ESCAPED_VARS
c_20089 = ESCAPED_VARS
ESCAPED_VARS = &c_20089
c_20089 = &ANYTHING
c_20089 = &ANYTHING
ESCAPED_VARS = &c_20089.val
c_20089.val = ESCAPED_VARS
infos = &c_20089
infos = &c_20089.val
c_200A2 = ESCAPED_VARS
ESCAPED_VARS = &c_200A2
...

the mainline looks like:

ANYTHING = { ANYTHING }
READONLY = { ANYTHING }
INTEGER = { ANYTHING }
D.28988 = same as infos
D.28988.c = same as infos
D.28988.b = same as infos
infos = { ANYTHING }


The shared bitmap stuff was not dominant for this testcase.  Still I doubt
we can backport all of the solver changes.  Also quite possibly 4.3 benefits
from early optimizations simplifying the problem to solve.


-- 

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|REOPENED|NEW


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

[Bug target/31507] [4.3 Regression] libffi regression, many.c, closure_fn2/fn3.c with -Os

[jakub at gcc dot gnu dot org]

--- Comment #7 from jakub at gcc dot gnu dot org  2007-10-31 13:09 ---
The c#4 testcase fails even on x86_64-linux, with
-m64 -Os -fno-omit-frame-pointer.


-- 


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

[Bug fortran/33957] gfortran rejects valid initialization expression

[dominiq at lps dot ens dot fr]

--- Comment #2 from dominiq at lps dot ens dot fr  2007-10-31 13:17 ---
The test case is bogus (missing closing parenthesis and p is not a pointer). I
hope the following is valid:

! { dg-do compile }
function bug(i) result(c)
  integer, pointer :: i
  character(len=merge(1,2, associated(i))) :: c
  c = ""
end function bug

it is accepted by xlf and g95 (with or without -std=f95).

If my understanding of the proc 'check_inquiry' in expr.c is correct,
'associated' is not in the set inquiry_func_f2003.


-- 


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

[Bug rtl-optimization/33796] valgrind error with -O2 for linux kernel code

[bonzini at gnu dot org]

--- Comment #8 from bonzini at gnu dot org  2007-10-31 13:21 ---
Reopening and marking as enhancement.

A patch like this should work:

Index: sparseset.c
===
--- sparseset.c (revision 129768)
+++ sparseset.c (working copy)
@@ -21,6 +21,18 @@ along with GCC; see the file COPYING3.  
 #include "libiberty.h"
 #include "sparseset.h"

+#ifdef ENABLE_VALGRIND_CHECKING
+# ifdef HAVE_VALGRIND_MEMCHECK_H
+#  include 
+# elif defined HAVE_MEMCHECK_H
+#  include 
+# else
+#  include 
+# endif
+#else
+/* Avoid #ifdef:s when we can help it.  */
+#define VALGRIND_MAKE_MEM_DEFINED_IF_ADDRESSABLE(x, y)
+#endif

 /* Allocate and clear a n_elms SparseSet.  */

@@ -33,6 +45,8 @@ sparseset_alloc (SPARSESET_ELT_TYPE n_el
   sparseset set = (sparseset) xmalloc (n_bytes);
   set->dense = &(set->elms[0]);
   set->sparse = &(set->elms[n_elms]);
+  VALGRIND_MAKE_MEM_DEFINED_IF_ADDRESSABLE
+(set->sparse, n_elms * sizeof (SPARSESET_ELT_TYPE));
   set->size = n_elms;
   sparseset_clear (set);
   return set;

but only if the compiler is compiled with --enable-checking=valgrind or
--enable-checking=yes,valgrind.  There are data structures that *rely* on safe
uninitialized data reads for speed, this is one of them.


-- 

bonzini at gnu dot org changed:

   What|Removed |Added

   Severity|normal  |enhancement
 Status|RESOLVED|REOPENED
 GCC target triplet|x86_64-linux-gnu|{i86,x86_64}-linux-gnu
 Resolution|INVALID |


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

[Bug fortran/33957] gfortran rejects valid initialization expression

[dominiq at lps dot ens dot fr]

--- Comment #3 from dominiq at lps dot ens dot fr  2007-10-31 13:33 ---
(7) A specification inquiry where each designator or function argument is
 (a) a restricted expression or
 (b) a variable whose properties inquired about are not
  (i) dependent on the upper bound of the last dimension of an assumed-size
array,
  (ii) deferred, or
  (iii) defined by an expression that is not a restricted expression,
 (8) A reference to any other standard intrinsic function where each argument
is a restricted expression,

A specification inquiry is a reference to
(1) an array inquiry function (13.5.7),
(2) the bit inquiry function BIT_SIZE,
(3) the character inquiry function LEN,
(4) the kind inquiry function KIND,
(5) the character inquiry function NEW_LINE,
(6) a numeric inquiry function (13.5.6),
(7) a type parameter inquiry (6.1.3), or
(8) an IEEE inquiry function (14.9.1),

ASSOCIATED appears in 13.5.8, but is not listed above, so it is probably not a
valid "specification inquiry" however this restriction seems lifted by (8) (it
is probably the appropriate time to have a "simplified" F2003 draft!-).

13.5.8 Other inquiry functions

ALLOCATED (ARRAY) or ALLOCATED (SCALAR) Allocation status
ASSOCIATED (POINTER [, TARGET]) Association status inquiry or comparison
BIT_SIZE (I) Number of bits of the model
EXTENDS TYPE OF (A, MOLD) Same dynamic type or an extension
LEN (STRING [, KIND]) Length of a character entity
NEW_LINE (A) Newline character
PRESENT (A) Argument presence
SAME_TYPE_AS (A, B) Same dynamic type


-- 


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

[Bug fortran/33941] [4.3 Regression] gfortran creates module files it can't read

[burnus at gcc dot gnu dot org]

--- Comment #20 from burnus at gcc dot gnu dot org  2007-10-31 13:35 ---
Alternative patch (bootstraps/regtests).

I'm not sure how soon I can submit it.

Index: gcc/fortran/module.c
===
--- gcc/fortran/module.c(Revision 129791)
+++ gcc/fortran/module.c(Arbeitskopie)
@@ -2627,17 +2627,17 @@
 minit ("OR", INTRINSIC_OR),
 minit ("EQV", INTRINSIC_EQV),
 minit ("NEQV", INTRINSIC_NEQV),
-minit ("==", INTRINSIC_EQ),
+minit ("EQ_SIGN", INTRINSIC_EQ),
 minit ("EQ", INTRINSIC_EQ_OS),
-minit ("/=", INTRINSIC_NE),
+minit ("NE_SIGN", INTRINSIC_NE),
 minit ("NE", INTRINSIC_NE_OS),
-minit (">", INTRINSIC_GT),
+minit ("GT_SIGN", INTRINSIC_GT),
 minit ("GT", INTRINSIC_GT_OS),
-minit (">=", INTRINSIC_GE),
+minit ("GE_SIGN", INTRINSIC_GE),
 minit ("GE", INTRINSIC_GE_OS),
-minit ("<", INTRINSIC_LT),
+minit ("LT_SIGN", INTRINSIC_LT),
 minit ("LT", INTRINSIC_LT_OS),
-minit ("<=", INTRINSIC_LE),
+minit ("LE_SIGN", INTRINSIC_LE),
 minit ("LE", INTRINSIC_LE_OS),
 minit ("NOT", INTRINSIC_NOT),
 minit ("PARENTHESES", INTRINSIC_PARENTHESES),


-- 


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

[Bug target/31507] [4.3 Regression] libffi regression, many.c, closure_fn2/fn3.c with -Os

[jakub at gcc dot gnu dot org]

--- Comment #8 from jakub at gcc dot gnu dot org  2007-10-31 13:41 ---
Testing a fix.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jakub at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2007-09-01 20:32:10 |2007-10-31 13:41:46
   date||


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

[Bug tree-optimization/32377] can't determine dependence (source/destination overlap without more than size)

[spop at gcc dot gnu dot org]

--- Comment #18 from spop at gcc dot gnu dot org  2007-10-31 13:53 ---
Subject: Bug 32377

Author: spop
Date: Wed Oct 31 13:53:03 2007
New Revision: 129797

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129797
Log:
2007-10-31  Sebastian Pop  <[EMAIL PROTECTED]>

PR tree-optimization/32377
* tree-data-ref.c (compute_overlap_steps_for_affine_univar): Make it
work also for unknown number of iterations.
(analyze_subscript_affine_affine): Clean up.  Don't fail when the 
number of iterations is not known.

* gfortran.dg/vect/pr32377.f90: New.



Added:
trunk/gcc/testsuite/gfortran.dg/vect/pr32377.f90
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-data-ref.c


-- 


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

[Bug tree-optimization/32377] can't determine dependence (source/destination overlap without more than size)

[spop at gcc dot gnu dot org]

--- Comment #19 from spop at gcc dot gnu dot org  2007-10-31 13:53 ---
Fixed.


-- 

spop at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug fortran/33957] gfortran rejects valid initialization expression

[tow21 at cam dot ac dot uk]

--- Comment #4 from tow21 at cam dot ac dot uk  2007-10-31 13:58 ---
(Sorry for mis-typed example, I can't cut & paste from the VM I'm working in
into my web-browser. Your corrected version is what I meant to type)

Well I'm going from the F95 standard (which is the only one I have to hand; and
in any case I am trying to write F95-compliant code here, so I'm not overly
concerned about F2003 personally). F95 has no concept of a "specification
inquiry" (that I can see). Section (7) of the definition of a "restricted
expression" seems to cover mostly the same ground, and reads in full:

(7) A reference to an intrinsic function that is
  (a) an array inquiry function (13.11.15) other than ALLOCATED,
  (b) the bit inquiry function BIT_SIZE
  (c) the character enquiry function LEN
  (d) the kind inquire function KIND, or
  (e) a numeric inquiry function (13.11.8)
and where each argument of the function is
  (a) a restricted expression
  (b) a variable whose properties inquired about are not 
(i) dependent on the upper bound of the last dimension of an assumed-size
array,
(ii) defined by an expression that is not a restricted expression, or
(iii) definable by an ALLOCATE or pointer assignment expression

That is - the expression is not allowed under (7) - but it is under (8).


-- 


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

[Bug fortran/33941] [4.3 Regression] gfortran creates module files it can't read

[fxcoudert at gcc dot gnu dot org]

--- Comment #21 from fxcoudert at gcc dot gnu dot org  2007-10-31 14:04 
---
(In reply to comment #20)
> Alternative patch (bootstraps/regtests).

I think it's better to go that way: apparently, care has been taken until now
to keep module files alphanumeric, let's keep it that way.

If your patch regetests fine, it's pre-approved.


-- 


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

[Bug tree-optimization/32723] [4.2 Regression] memory hog in solve_graph

[dberlin at dberlin dot org]

--- Comment #16 from dberlin at gcc dot gnu dot org  2007-10-31 14:22 
---
Subject: Re:  [4.2 Regression] memory hog in solve_graph

On 31 Oct 2007 13:07:57 -, rguenth at gcc dot gnu dot org
<[EMAIL PROTECTED]> wrote:
>
>
> --- Comment #15 from rguenth at gcc dot gnu dot org  2007-10-31 13:07 
> ---
> The memory is temporarily needed now by solve_graph(), because the graph has
> 48902 nodes.

48902 nodes is not a lot for the solver, to be honest.

>  On the mainline we have only 3 constraints while for 4.2 we have
> thousands:
>
> ANYTHING = &ANYTHING
> READONLY = &ANYTHING
> INTEGER = &ANYTHING
> ESCAPED_VARS = *ESCAPED_VARS
> NONLOCAL.6 = ESCAPED_VARS
> ESCAPED_VARS = &NONLOCAL.6
> ESCAPED_VARS = &NONLOCAL.6
> infos = ESCAPED_VARS
> c_20089 = ESCAPED_VARS
> ESCAPED_VARS = &c_20089
> c_20089 = &ANYTHING
> c_20089 = &ANYTHING
> ESCAPED_VARS = &c_20089.val
> c_20089.val = ESCAPED_VARS
> infos = &c_20089
> infos = &c_20089.val
> c_200A2 = ESCAPED_VARS
> ESCAPED_VARS = &c_200A2
> ...
>
> the mainline looks like:
>
> ANYTHING = { ANYTHING }
> READONLY = { ANYTHING }
> INTEGER = { ANYTHING }
> D.28988 = same as infos
> D.28988.c = same as infos
> D.28988.b = same as infos
> infos = { ANYTHING }

This is because we compute call clobbering differently for mainline now.
The thing you'd want to add to 4.2 would be location equivalence
optimization, which i never finished for either 4.2 or 4.3 (4.3 has
code to compute it, but we don't substitute the variables).

Location equivalence would turn the escaped_vars set into 1 variable
during propagation, and then expand it back out at the end.


-- 


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

[Bug fortran/33162] INTRINSIC functions as ACTUAL argument

[jvdelisle at gcc dot gnu dot org]

--- Comment #14 from jvdelisle at gcc dot gnu dot org  2007-10-31 14:27 
---
Subject: Bug 33162

Author: jvdelisle
Date: Wed Oct 31 14:26:57 2007
New Revision: 129798

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129798
Log:
2007-10-31  Jerry DeLisle  <[EMAIL PROTECTED]>

PR fortran/33162
* interface.c (compare_intr_interfaces): New function to check
intrinsic
function arguments against formal arguments. (compare_interfaces): Fix
logic in comparison of function and subroutine attributes.
(compare_parameter): Use new function for intrinsic as argument.
* resolve.c (resolve_actual_arglist): Allow an intrinsic without
function attribute to be checked further.  Set function attribute if
intrinsic symbol is found, return FAILURE if not.

Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/interface.c
trunk/gcc/fortran/resolve.c


-- 


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

[Bug preprocessor/30786] [4.1/4.2/4.3 Regression] ICE on _Pragma at end of file

[tromey at gcc dot gnu dot org]

--- Comment #8 from tromey at gcc dot gnu dot org  2007-10-31 14:50 ---
Subject: Bug 30786

Author: tromey
Date: Wed Oct 31 14:50:13 2007
New Revision: 129800

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129800
Log:
gcc/testsuite
PR preprocessor/30786:
* gcc.dg/cpp/pr30786.c: New file.
libcpp
PR preprocessor/30786:
* macro.c (builtin_macro): Return result of _cpp_do__Pragma.
* directives.c (_cpp_do__Pragma): Return error status.
* internal.h (_cpp_do__Pragma): Update.
* directives.c (get__Pragma_string): Back up if EOF seen.

Added:
trunk/gcc/testsuite/gcc.dg/cpp/pr30786.c
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/libcpp/ChangeLog
trunk/libcpp/directives.c
trunk/libcpp/internal.h
trunk/libcpp/macro.c


-- 


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

[Bug c++/33960] New: [4.3 Regression] r129030 breaks -fopenmp -static compile of tramp3d-v4

[rguenth at gcc dot gnu dot org]

Starting with r129030 tramp3d-v4 segfaults on startup if compiled statically
with -fopenmp.  This can be reproduced with the preprocessed testcase from
http://www.suse.de/~rguenther/tramp3d/tramp3d-v4.ii.gz (x86_64) and compiling
with -fopenmp -static (optimization does not change the effect).

Author: jason
Date: Fri Oct  5 05:35:46 2007
New Revision: 129030

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129030
Log:
2007-09-13  Doug Kwan  <[EMAIL PROTECTED]>

* gcc/gthr-posix.h (__gthread_cond_broadcast, __gthread_cond_wait,
__gthread_cond_wait_recursive): Add to extend interface for POSIX
conditional variables. (__GTHREAD_HAS_COND): Macro defined to signify
support of conditional variables.
* gcc/gthr-posix95.h (__gthread_cond_broadcast, __gthread_cond_wait,
__gthread_cond_wait_recursive): Add to extend interface for POSIX
conditional variables. (__GTHREAD_HAS_COND): Macro defined to signify
support of conditional variables.
* gcc/gthr-single.h (__gthread_cond_broadcast, __gthread_cond_wait,
__gthread_cond_wait_recursive): Add to extend interface for POSIX
conditional variables.
* gcc/gthr.h: Update comments to document new interface.
* libstdc++-v3/include/ext/concurrent.h (class __mutex,
class __recursive_mutex): Add new method gthread_mutex to access
inner gthread mutex.
[__GTHREAD_HAS_COND] (class __concurrence_broadcast_error,
class __concurrence_wait_error, class __cond): Add.
* guard.cc (recursive_push, recursive_pop): Delete.
(init_in_progress_flag, set_init_in_progress_flag): Add to
replace recursive_push and recursive_pop.
(throw_recursive_init_exception): Add.
(acquire, __cxa_guard_acquire, __cxa_guard_abort and
__cxa_guard_release): [__GTHREAD_HAS_COND] Use a conditional
for synchronization of static variable initialization.
The global mutex is only held briefly when guards are
accessed. [!__GTHREAD_HAS_COND] Fall back to the old code,
which deadlocks.
* testsuite/thread/guard.cc: Add new test. It deadlocks with the
old locking code in libstdc++-v3/libsup++/guard.cc.


-- 
   Summary: [4.3 Regression] r129030 breaks -fopenmp -static compile
of tramp3d-v4
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org


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

[Bug target/31507] [4.3 Regression] libffi regression, many.c, closure_fn2/fn3.c with -Os

[jakub at gcc dot gnu dot org]

--- Comment #11 from jakub at gcc dot gnu dot org  2007-10-31 14:47 ---
Created an attachment (id=14449)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14449&action=view)
gcc43-pr31507.patch

That's IMHO wrong, you are changing the meaning of < constraint.
This patch is what I'll bootstrap/regtest tonight which fixes it the same way
as push{qi,hi}* are handled on i?86 -m32/-m64 and pushsi for -m64.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|rask at gcc dot gnu dot org |jakub at gcc dot gnu dot org


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

[Bug target/31507] [4.3 Regression] libffi regression, many.c, closure_fn2/fn3.c with -Os

[rask at gcc dot gnu dot org]

--- Comment #10 from rask at gcc dot gnu dot org  2007-10-31 14:44 ---
Oops, I'm sorry about stealing your bug, Jakub. I didn't see you had taken it.


-- 


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

[Bug c++/33960] [4.3 Regression] r129030 breaks -fopenmp -static compile of tramp3d-v4

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2007-10-31 14:53 ---
gdb doesn't like static code too much but the following is a backtrace of the
crash:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x88d8a0 (LWP 8358)]
0x in ?? ()
(gdb) bt
#0  0x in ?? ()
warning: (Internal error: pc 0x55290b in read in psymtab, but not in symtab.)

#1  0x0055290c in __cxa_guard_release (g=warning: (Internal error: pc
0x5528d0 in read in psymtab, but not in symtab.)

warning: (Internal error: pc 0x55290b in read in psymtab, but not in symtab.)

0x874a70)
at
/space/rguenther/tramp3d/obj/x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu/bits/gthr-default.h:749
#2  0x004fc9ac in get_locale_mutex ()
at ../../../../trunk/libstdc++-v3/src/locale_init.cc:42
#3  0x004fe99a in locale (this=0x872dd8)
at ../../../../trunk/libstdc++-v3/src/locale_init.cc:215
#4  0x004fa325 in Init (this=)
at
/space/rguenther/tramp3d/obj/x86_64-unknown-linux-gnu/libstdc++-v3/include/streambuf:462
#5  0x00402a79 in __static_initialization_and_destruction_0 (
__initialize_p=1, __priority=65535)
at
/space/rguenther/tramp3d/install/lib/gcc/x86_64-unknown-linux-gnu/4.3.0/../../../../include/c++/4.3.0/iostream:77
#6  0x00402fc9 in global constructors keyed to _ZN5Pooma5pinfoE ()
at tramp3d-v4.cpp:56094
#7  0x005cb046 in __do_global_ctors_aux ()
#8  0x004001a3 in _init ()
#9  0x0001 in ?? ()
#10 0x00569736 in __libc_csu_init ()
#11 0x005691e2 in __libc_start_main ()
#12 0x004001d9 in _start ()


-- 


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

[Bug target/31507] [4.3 Regression] libffi regression, many.c, closure_fn2/fn3.c with -Os

[rask at gcc dot gnu dot org]

--- Comment #9 from rask at gcc dot gnu dot org  2007-10-31 14:37 ---
Created an attachment (id=14448)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14448&action=view)
patch for testing

This seems to be a simple mismatch between what push_operand() accepts and what
matches the '<' constraint, so reload thinks the destination doesn't match any
of the alternatives and doesn't know how to fix this sort of operand. Please
test this patch on x86_64-apple-darwin8.


-- 

rask at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|jakub at gcc dot gnu dot org|rask at gcc dot gnu dot org


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

[Bug c++/33958] New: Using "-ftree-vectorize" , creates an illegal movaps instruction

[eran dot nissenhaus at mobileye dot com]

g++ -v output:
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.2.0/configure --prefix=/opt/gcc4.2.0
Thread model: posix
gcc version 4.2.0

using the following compilation flags:
g++ -Wall -Werror -ansi -pedantic -Wno-long-long -pipe -fmessage-length=0
-funit-at-a-time -maccumulate-outgoing-args -fvisibility-inlines-hidden
-fno-strict-aliasing -O3 -fsee -momit-leaf-frame-pointer -fmodulo-sched
-fgcse-sm -fgcse-las -fgcse-after-reload -ftree-loop-im -ftree-loop-ivcanon
-ftree-vectorize -fbranch-target-load-optimize2 -march=i686 -mfpmath=sse -msse
./bug.cpp

creates illegal code.
I think movapps recieves a misaligned memory address.  Omitting
"ftree-vectorize" from the compiler flags solves the problem.

thanks.


-- 
   Summary: Using "-ftree-vectorize" , creates an illegal movaps
instruction
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: eran dot nissenhaus at mobileye dot com
  GCC host triplet: i686-pc-linux-gnu


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

[Bug fortran/33162] INTRINSIC functions as ACTUAL argument

[jvdelisle at gcc dot gnu dot org]

--- Comment #15 from jvdelisle at gcc dot gnu dot org  2007-10-31 14:31 
---
Subject: Bug 33162

Author: jvdelisle
Date: Wed Oct 31 14:30:48 2007
New Revision: 129799

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129799
Log:
2007-10-31  Jerry DeLisle  <[EMAIL PROTECTED]>

PR fortran/33162
* gfortran.dg/interface_19.f90: New.
* gfortran.dg/interface_20.f90: New.
* gfortran.dg/interface_21.f90: New.

Added:
trunk/gcc/testsuite/gfortran.dg/interface_19.f90
trunk/gcc/testsuite/gfortran.dg/interface_20.f90
trunk/gcc/testsuite/gfortran.dg/interface_21.f90
Modified:
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug c++/33958] Using "-ftree-vectorize" , creates an illegal movaps instruction

[eran dot nissenhaus at mobileye dot com]

--- Comment #1 from eran dot nissenhaus at mobileye dot com  2007-10-31 
14:34 ---
Created an attachment (id=14447)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14447&action=view)
test-case


-- 


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

[Bug c++/33959] New: ice in cp/pt.c instantiate_class_template

[cppljevans at suddenlink dot net]

Error also occurs in g++4.3 in 20071026 snapshot.  In that snapshot,
the ice occurred on line 6651 which is a gcc_assert preceded by comment:

  /* We should never instantiate a nested class before its enclosing
 class; we need to look up the nested class by name before we can
 instantiate it, and that lookup should instantiate the enclosing
 class.  */

I will attach the output from make showing the error and the
.ii file (once I figure how to do that).


-- 
   Summary: ice in cp/pt.c instantiate_class_template
   Product: gcc
   Version: 4.1.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: cppljevans at suddenlink dot net


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

[Bug c++/33960] [4.3 Regression] r129030 breaks -fopenmp -static compile of tramp3d-v4

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2007-10-31 14:59 ---
Which is

static inline int
__gthread_cond_broadcast (__gthread_cond_t *cond)
{
  return __gthrw_(pthread_cond_broadcast) (cond);
}

It looks like pthread_cond_broadcast is not correctly bound, as the disassembly
shows:

 <__cxa_guard_release+52>:  mov%rax,%rdi
 <__cxa_guard_release+55>:  callq  0x0

though it _does_ work for pthread_mutex_lock:

 <__cxa_guard_release+28>:  mov%rax,%rdi
 <__cxa_guard_release+31>:  callq  0x566dc0 


-- 


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

[Bug target/31507] [4.3 Regression] libffi regression, many.c, closure_fn2/fn3.c with -Os

[rask at gcc dot gnu dot org]

--- Comment #12 from rask at gcc dot gnu dot org  2007-10-31 15:00 ---
> That's IMHO wrong, you are changing the meaning of < constraint.

Yes, I see what you mean, they ('<' and '>') are defined independently of stack
direction. They should however accept PRE_MODIFY and POST_MODIFY.


-- 


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

[Bug fortran/33941] [4.3 Regression] gfortran creates module files it can't read

[burnus at gcc dot gnu dot org]

--- Comment #22 from burnus at gcc dot gnu dot org  2007-10-31 15:10 ---
Subject: Bug 33941

Author: burnus
Date: Wed Oct 31 15:10:12 2007
New Revision: 129801

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129801
Log:
2007-10-31  Tobias Burnus  <[EMAIL PROTECTED]>

PR fortran/33941
* modules.c (intrinsics): Use only alphabetic names for
intrinsic operators.


2007-10-31  Dominique d'Humieres  <[EMAIL PROTECTED]>
Tobias Burnus  <[EMAIL PROTECTED]>

PR fortran/33941
* gfortran.dg/module_read_1.f90: New.


Added:
trunk/gcc/testsuite/gfortran.dg/module_read_1.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/module.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug fortran/33941] [4.3 Regression] gfortran creates module files it can't read

[burnus at gcc dot gnu dot org]

--- Comment #23 from burnus at gcc dot gnu dot org  2007-10-31 15:11 ---
> > Alternative patch (bootstraps/regtests).
> I think it's better to go that way: apparently, care has been taken until now
> to keep module files alphanumeric, let's keep it that way.
> If your patch regetests fine, it's pre-approved.

I checked in now in.

FIXED for the trunk (4.3.0).


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug c++/33960] [4.3 Regression] r129030 breaks -fopenmp -static compile of tramp3d-v4

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2007-10-31 15:23 ---
The complete statically linked __cxa_guard_release looks like:

005528d0 <__cxa_guard_release>:
  5528d0:   53  push   %rbx
  5528d1:   48 89 fbmov%rdi,%rbx
  5528d4:   48 83 ec 10 sub$0x10,%rsp
  5528d8:   48 83 3d 90 e6 31 00cmpq   $0x0,0x31e690(%rip)#
870f70 
  5528df:   00 
  5528e0:   74 4b   je 55292d
<__cxa_guard_release+0x5d>
  5528e2:   c6 44 24 0f 01  movb   $0x1,0xf(%rsp)
  5528e7:   e8 c4 fd ff ff  callq  5526b0
<_ZN12_GLOBAL__N_116get_static_mutexEv>
  5528ec:   48 89 c7mov%rax,%rdi
  5528ef:   e8 cc 44 01 00  callq  566dc0 <__pthread_mutex_lock>
  5528f4:   85 c0   test   %eax,%eax
  5528f6:   75 3e   jne552936
<__cxa_guard_release+0x66>
  5528f8:   c6 43 01 00 movb   $0x0,0x1(%rbx)
  5528fc:   c6 03 01movb   $0x1,(%rbx)
  5528ff:   e8 5c fe ff ff  callq  552760
<_ZN12_GLOBAL__N_115get_static_condEv>
  552904:   48 89 c7mov%rax,%rdi
  552907:   e8 f4 d6 aa ff  callq  0 <_nl_current_LC_CTYPE>
  55290c:   85 c0   test   %eax,%eax
  55290e:   75 54   jne552964
<__cxa_guard_release+0x94>
  552910:   80 7c 24 0f 00  cmpb   $0x0,0xf(%rsp)
  552915:   74 10   je 552927
<__cxa_guard_release+0x57>
  552917:   48 8b 3d aa 23 33 00mov0x3323aa(%rip),%rdi#
884cc8 <_ZN12_GLOBAL__N_1L12static_mutexE>
  55291e:   e8 0d 4f 01 00  callq  567830 <__pthread_mutex_unlock>
  552923:   85 c0   test   %eax,%eax
  552925:   75 6b   jne552992
<__cxa_guard_release+0xc2>
  552927:   48 83 c4 10 add$0x10,%rsp
  55292b:   5b  pop%rbx
  55292c:   c3  retq   
  55292d:   c6 47 01 00 movb   $0x0,0x1(%rdi)
  552931:   c6 07 01movb   $0x1,(%rdi)
  552934:   eb f1   jmp552927
<__cxa_guard_release+0x57>
  552936:   bf 08 00 00 00  mov$0x8,%edi
  55293b:   e8 40 ec ff ff  callq  551580
<__cxa_allocate_exception>
  552940:   48 89 c7mov%rax,%rdi
  552943:   48 8b 05 3e e6 31 00mov0x31e63e(%rip),%rax#
870f88 
  55294a:   48 8b 15 e7 e5 31 00mov0x31e5e7(%rip),%rdx#
870f38 
  552951:   48 8b 35 40 e6 31 00mov0x31e640(%rip),%rsi#
870f98 
  552958:   48 83 c0 10 add$0x10,%rax
  55295c:   48 89 07mov%rax,(%rdi)
  55295f:   e8 0c fc ff ff  callq  552570 <__cxa_throw>
  552964:   bf 08 00 00 00  mov$0x8,%edi
  552969:   e8 12 ec ff ff  callq  551580
<__cxa_allocate_exception>
  55296e:   48 89 c7mov%rax,%rdi
  552971:   48 8b 05 08 e6 31 00mov0x31e608(%rip),%rax#
870f80 
  552978:   48 8b 15 41 e6 31 00mov0x31e641(%rip),%rdx#
870fc0 
  55297f:   48 8b 35 6a e5 31 00mov0x31e56a(%rip),%rsi#
870ef0 
  552986:   48 83 c0 10 add$0x10,%rax
  55298a:   48 89 07mov%rax,(%rdi)
  55298d:   e8 de fb ff ff  callq  552570 <__cxa_throw>
  552992:   bf 08 00 00 00  mov$0x8,%edi
  552997:   e8 e4 eb ff ff  callq  551580
<__cxa_allocate_exception>
  55299c:   48 89 c7mov%rax,%rdi
  55299f:   48 8b 05 72 e5 31 00mov0x31e572(%rip),%rax#
870f18 
  5529a6:   48 8b 15 1b e6 31 00mov0x31e61b(%rip),%rdx#
870fc8 
  5529ad:   48 8b 35 2c e5 31 00mov0x31e52c(%rip),%rsi#
870ee0 
  5529b4:   48 83 c0 10 add$0x10,%rax
  5529b8:   48 89 07mov%rax,(%rdi)
  5529bb:   e8 b0 fb ff ff  callq  552570 <__cxa_throw>
  5529c0:   48 8d 7c 24 0f  lea0xf(%rsp),%rdi
  5529c5:   48 89 c3mov%rax,%rbx
  5529c8:   e8 c3 fd ff ff  callq  552790
<_ZN10__cxxabiv113mutex_wrapperD1Ev>
  5529cd:   48 89 dfmov%rbx,%rdi
  5529d0:   e8 5b 07 01 00  callq  563130 <_Unwind_Resume>

showing the obvious error.  The shared libstdc++v3 has a relocation to
pthread_cond_broadcast instead:

   c4aff:   e8 5c fe ff ff  callq  c4960
<_ZN12_GLOBAL__N_115get_static_condEv>
   c4b04:   48 89 c7mov%rax,%rdi
   c4b07:   e8 24 0d f9 ff  callq  55830
<[EMAIL PROTECTED]>
   c4b0c:   85 c0   test   %eax,%eax


-- 


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

[Bug c++/33959] ice in cp/pt.c instantiate_class_template

[cppljevans at suddenlink dot net]

--- Comment #1 from cppljevans at suddenlink dot net  2007-10-31 15:09 
---
I was unable to create attachment; so, here's the source (no #includes).
<-- cut here --
//Purpose:
//  Reproduce, with simplified code, the error:
/*
main.cpp:1675:   instantiated from here
main.cpp:1277: internal compiler error: in instantiate_class_template, at
cp/pt.c:6651
 */
//reported in main.cpp.log on line 767 which occured during
//compile of main.cpp with gcc-4.3-20071026 on:
//  Tue Oct 30 08:45:37
//The same error occurred with gcc-4.1, but not gcc-3.4.
//
template
  < typename Variables
  >
  struct
gram_tree
{
typedef
  Variables
vars
;
  struct
defn_variable
{
 public:
typedef
  defn_variable
my_type
;
defn_variable(void)
{}

defn_variable(my_type const& a_copy)
;

template
  < typename Rhs
  >
defn_variable(Rhs const& a_rhs)
;
  my_type const&
operator=(my_type const& a_var)
;
template
  < typename Rhs
  >
  my_type const&
operator=(Rhs const& a_rhs)
;

};//end defn_variable struct

  struct
productions
{
productions(void)
;
  defn_variable&
operator[](typename vars::symb_enum)
;
};//end productions struct

//begin: Composite expressions

  struct
expr_sequence
{
template
  < typename Left
  , typename Right
  >
  struct
node
{
node(Left const& a_left, Right const& a_right)
;
};
};

template
  < typename Left
  , typename Right
  >
friend
  expr_sequence::node
operator>>(Left const& a_left, Right const& a_right)
;

//end: Composite expressions

};//end gram_tree struct

  struct
vars
{
  enum 
symb_enum
  { e
  };

};//exit vars struct

  int
main(void)
{
typedef gram_tree gt;
gt::productions prods;

prods[vars::e]=prods[vars::e] >> prods[vars::e] ;

return 0;
}

>-- cut here --
and here's the make output
<-- cut here --
cd
/home/evansl/prog_dev/boost-svn/ro/trunk/sandbox/lje/libs/grammar_pipeline/test/spirit_proto/
make -f Makefile.imk bugrept
/usr/bin/g++-4.1 -c -Wall -ftemplate-depth-100 -O0 -fno-inline -v -save-temps
main-pt-c-ice.cpp -o bugrept
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu
--enable-libstdcxx-debug --enable-mpfr --with-tune=i686
--enable-checking=release i486-linux-gnu
Thread model: posix
gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)
 /usr/lib/gcc/i486-linux-gnu/4.1.2/cc1plus -E -quiet -v -D_GNU_SOURCE
main-pt-c-ice.cpp -mtune=i686 -Wall -ftemplate-depth-100 -fno-inline -O0
-fpch-preprocess -o main-pt-c-ice.ii
ignoring nonexistent directory "/usr/local/include/i486-linux-gnu"
ignoring nonexistent directory
"/usr/lib/gcc/i486-linux-gnu/4.1.2/../../../../i486-linux-gnu/include"
ignoring nonexistent directory "/usr/include/i486-linux-gnu"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/i486-linux-gnu/4.1.2/../../../../include/c++/4.1.2
 /usr/lib/gcc/i486-linux-gnu/4.1.2/../../../../include/c++/4.1.2/i486-linux-gnu
 /usr/lib/gcc/i486-linux-gnu/4.1.2/../../../../include/c++/4.1.2/backward
 /usr/local/include
 /usr/lib/gcc/i486-linux-gnu/4.1.2/include
 /usr/include
End of search list.
 /usr/lib/gcc/i486-linux-gnu/4.1.2/cc1plus -fpreprocessed main-pt-c-ice.ii
-quiet -dumpbase main-pt-c-ice.cpp -mtune=i686 -auxbase-strip bugrept -O0 -Wall
-version -ftemplate-depth-100 -fno-inline -o main-pt-c-ice.s
GNU C++ version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21) (i486-linux-gnu)
compiled by GNU C version 4.1.2 20061115 (prerelease) (Debian
4.1.1-21).
GGC heuristics: --param ggc-min-expand=55 --param ggc-min-heapsize=48218
Compiler executable checksum: 183d42a838ed2b7313bffcb8f2f2fda7
main-pt-c-ice.cpp: In instantiation of
'gram_tree::expr_sequence::node::defn_variable,
gram_tree::defn_variable>':
main-pt-c-ice.cpp:109:   instantiated from here
main-pt-c-ice.cpp:74: internal compiler error: in instantiate_class_template,
at cp/pt.c:5652
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
For Debian GNU/Linux specific bug reporting instructions,
see .
Preprocessed source stored into /tmp/ccITi2V4.out file, please attach this to
your bugreport.
make: *** [bugrept] Error 1

Compilation exited abnormally with code 2 at Wed Oct 31 09:20:49

>-- cut here --


-- 


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

[Bug target/31507] [4.3 Regression] libffi regression, many.c, closure_fn2/fn3.c with -Os

[jakub at gcc dot gnu dot org]

--- Comment #13 from jakub at gcc dot gnu dot org  2007-10-31 15:08 ---
See md.texi:
@cindex @samp{<} in constraint
@item @samp{<}
A memory operand with autodecrement addressing (either predecrement or
postdecrement) is allowed.

And that's for a reason, post_modify here adjusts it by different size than
the size of the mode, so it shouldn't be valid < operand.


-- 


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

[Bug c++/33959] [4.1/4.2/4.3 Regression] ICE in instantiate_class_template, at cp/pt.c:6649

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2007-10-31 15:41 ---
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.2.2 4.3.0
  Known to work||3.4.6
   Last reconfirmed|-00-00 00:00:00 |2007-10-31 15:41:24
   date||
Summary|ice in cp/pt.c  |[4.1/4.2/4.3 Regression] ICE
   |instantiate_class_template  |in
   ||instantiate_class_template,
   ||at cp/pt.c:6649
   Target Milestone|--- |4.2.3


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

[Bug c++/33958] Using "-ftree-vectorize" , creates an illegal movaps instruction

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2007-10-31 15:46 ---
Works for me.  Try a newer 4.2.x release.


-- 


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

[Bug c++/33960] [4.3 Regression] r129030 breaks -fopenmp -static compile of tramp3d-v4

[pinskia at gcc dot gnu dot org]

--- Comment #4 from pinskia at gcc dot gnu dot org  2007-10-31 15:48 ---
What happens if you force libpthreads to be all linked in?


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING


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

[Bug target/31507] [4.3 Regression] libffi regression, many.c, closure_fn2/fn3.c with -Os

[andreast at gcc dot gnu dot org]

--- Comment #14 from andreast at gcc dot gnu dot org  2007-10-31 15:58 
---
Started a test build.


-- 


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

[Bug debug/33537] [4.1/4.2/4.3 regression] C++ arguments passed by invisible reference have wrong type

[jakub at gcc dot gnu dot org]

--- Comment #5 from jakub at gcc dot gnu dot org  2007-10-31 15:58 ---
dwarf2out.c needs to handle DECL_BY_REFERENCE PARM_DECLs (and perhaps also
RESULT_DECLs).


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jakub at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2007-09-23 17:07:02 |2007-10-31 15:58:54
   date||


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

[Bug c++/32053] Anonymous union members' names should be distinct within enclosing scope

[andrew dot stubbs at st dot com]

--- Comment #1 from andrew dot stubbs at st dot com  2007-10-31 16:15 
---
This bug appears to be no longer present in GCC 4.2.1.


-- 

andrew dot stubbs at st dot com changed:

   What|Removed |Added

  Known to fail||4.1.1
  Known to work||3.4.3 4.2.1


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

[Bug tree-optimization/33680] [4.3 Regression] ICE when compilling elbg.c from ffmpeg (vectorizer)

[jakub at gcc dot gnu dot org]

--- Comment #20 from jakub at gcc dot gnu dot org  2007-10-31 16:31 ---
What I'd try instead is something like:
--- tree-data-ref.c.jj112007-10-28 19:34:10.0 +0100
+++ tree-data-ref.c 2007-10-31 16:22:21.0 +0100
@@ -629,7 +629,7 @@ dr_analyze_innermost (struct data_refere
   enum machine_mode pmode;
   int punsignedp, pvolatilep;
   affine_iv base_iv, offset_iv;
-  tree init, dinit, step;
+  tree init, dinit, step, type;

   if (dump_file && (dump_flags & TDF_DETAILS))
 fprintf (dump_file, "analyze_innermost: ");
@@ -666,9 +666,21 @@ dr_analyze_innermost (struct data_refere

   init = ssize_int (pbitpos / BITS_PER_UNIT);
   split_constant_offset (base_iv.base, &base_iv.base, &dinit);
-  init =  size_binop (PLUS_EXPR, init, dinit);
+  init = size_binop (PLUS_EXPR, init, dinit);
   split_constant_offset (offset_iv.base, &offset_iv.base, &dinit);
-  init =  size_binop (PLUS_EXPR, init, dinit);
+  init = size_binop (PLUS_EXPR, init, dinit);
+
+  /* See if base address involves a variable length type somewhere.
+ Bases with such types shouldn't be gimplified again.  */
+  type = TREE_TYPE (base_iv.base);
+  while (POINTER_TYPE_P (type))
+type = TREE_TYPE (type);
+  if (int_size_in_bytes (type) < 0)
+{
+  if (dump_file && (dump_flags & TDF_DETAILS))
+fprintf (dump_file, "failed: base involves a variable length
type.\n");
+  return;
+}

   step = size_binop (PLUS_EXPR,
 fold_convert (ssizetype, base_iv.step),

or similar check in the vectorizer instead.  This exact patch breaks
gfortran.dg/vect/vect-3.f90 and gfortran.dg/vect/pr19049.f90 (they are no
longer vectorized as expected), would need to see whether it tries to unsafely
gimplify the VLA type sizes in the vectorizer or not.


-- 


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

[Bug rtl-optimization/33961] New: [4.3 regression] gcc 4.3 causes crash valid code to crash

[bero at arklinux dot org]

The attached simple sample application crashes if it is with g++ 4.3 at -O1 or
higher.

To make things even odder, it works as expected when built with g++ 4.3 at -O1
or higher with -DDONTCRASH, even though the #ifdef DONTCRASH codepath is never
actually run.

The problem is reproducable on both x86_32 and x86_64.


This bug affects KHTML.


-- 
   Summary: [4.3 regression] gcc 4.3 causes crash valid code to
crash
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: blocker
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bero at arklinux dot org
 GCC build triplet: i586-pc-linux-gnu
  GCC host triplet: i586-pc-linux-gnu
GCC target triplet: i586-pc-linux-gnu


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

[Bug c++/33495] [4.1/4.2/4.3 regression] Broken diagnostic: Trouble pretty-printing statement expressions

[jakub at gcc dot gnu dot org]

--- Comment #2 from jakub at gcc dot gnu dot org  2007-10-31 16:52 ---
But should we really print it?  What if this while_stmt contains
say megabyte of source?  Wouldn't be better to just print
could not convert expression at [locus] to bool?


-- 


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

[Bug tree-optimization/33961] [4.3 regression] gcc 4.3 causes crash valid code to crash

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2007-10-31 16:53 ---
This is the new pass by Matz which is causing the issue.  So we have a
conditional write which writes to a read only memory.

Though the warning:
vt.cc: In function 'int main(int, char**)':
t.cc:21: warning: deprecated conversion from string constant to 'char*'

Should tell you that the code could be invalid anyways.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|blocker |normal
  Component|rtl-optimization|tree-optimization


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

[Bug rtl-optimization/33961] [4.3 regression] gcc 4.3 causes crash valid code to crash

[bero at arklinux dot org]

--- Comment #1 from bero at arklinux dot org  2007-10-31 16:44 ---
Created an attachment (id=14450)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14450&action=view)
Test case


-- 


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

[Bug tree-optimization/33961] [4.3 regression] gcc 4.3 causes crash valid code to crash

[bero at arklinux dot org]

--- Comment #3 from bero at arklinux dot org  2007-10-31 17:00 ---
That conversion warning is only in the simplified test case, the original code
it's extracted from (khtml) doesn't pass a string constant (it passes html code
retrieved from a web server) and crashes the same way.

There is a const_cast conversion from a const char * in the code though,
this probably triggers the same (mis)optimization pass?


-- 


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

[Bug rtl-optimization/33961] [4.3 regression] gcc 4.3 causes crash valid code to crash

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2007-10-31 17:03 ---
Reduced testcase:

void decode(char *d, int len);

void decode(char *d, int len) {
int i = len - 1;
while(i >= 0) {
d[i];
if(d[i] == 0)
d[i]=' ';
i--;
}
}

int main(int argc, char **argv)
{
decode("this bug is really weird", 24);
}

the store is turned into an unconditional store by the cselim pass, but
this store traps as the 'd' argument is in read-only memory.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||matz at gcc dot gnu dot org
   Severity|normal  |blocker
 Status|UNCONFIRMED |NEW
  Component|tree-optimization   |rtl-optimization
 Ever Confirmed|0   |1
   Keywords||wrong-code
   Last reconfirmed|-00-00 00:00:00 |2007-10-31 17:03:11
   date||


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

[Bug tree-optimization/33961] [4.3 regression] gcc 4.3 causes crash valid code to crash

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|blocker |normal
  Component|rtl-optimization|tree-optimization
   Target Milestone|--- |4.3.0


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

[Bug tree-optimization/33961] [4.3 regression] gcc 4.3 causes crash valid code to crash

[pinskia at gcc dot gnu dot org]

--- Comment #5 from pinskia at gcc dot gnu dot org  2007-10-31 17:07 ---
So what we have is a conditional store but a non conditional read.  So the
store can trap but the read does not.  Really using a const_cast does nothing
to change the fact you are passing a readonly memory to something which might
be written to.


-- 


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

[Bug preprocessor/30805] [4.1/4.2/4.3 Regression] Internal compiler error when using "x##,##__VA_ARGS__" in macro

[tromey at gcc dot gnu dot org]

--- Comment #6 from tromey at gcc dot gnu dot org  2007-10-31 17:37 ---
This patch makes gcc enter an infinite loop rather than ICEing.


-- 

tromey at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||tromey at gcc dot gnu dot
   ||org


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

[Bug tree-optimization/33961] [4.3 regression] gcc 4.3 causes crash valid code to crash

[maksim at kde dot org]

--- Comment #6 from maksim at kde dot org  2007-10-31 17:45 ---
The usage scenario of the method pretty much precludes it from being used in a
way where read-only memory would have to be written, except if someone does
something silly with the API. Essentially it is called either with outside data
which may need the '\0' -> ' ' sort of cleanup, or a few literals inside our
own code where it will not be needed. 


-- 


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

[Bug target/33958] Using "-ftree-vectorize" , creates an illegal movaps instruction

[dorit at gcc dot gnu dot org]

--- Comment #3 from dorit at gcc dot gnu dot org  2007-10-31 17:46 ---
(In reply to comment #2)
> Works for me.  Try a newer 4.2.x release.

I wonder if the fix for PR25413 fixed this problem - it went into 4.2 on July
25th, just shortly after 4.2.1 was released :-( but should be in 4.2.2


-- 


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

[Bug tree-optimization/33915] iv folding fails with pointer iterations

[rakdver at gcc dot gnu dot org]

--- Comment #3 from rakdver at gcc dot gnu dot org  2007-10-31 17:39 ---
It does not reproduce for me on i686-linux, either.  Do you pass any special
flags to configure?


-- 


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

[Bug tree-optimization/33915] iv folding fails with pointer iterations

[dj at redhat dot com]

--- Comment #4 from dj at redhat dot com  2007-10-31 18:03 ---
Subject: Re:  iv folding fails with pointer iterations


Oops, sorry, I have a local patch.  Apparently I'm trying to support
pointer math the same size as pointers (pointers are 24 bits) as an
option for the future, which lowers the priority for this bug, but I'd
appreciate it if it worked anyway - I'm getting requests for this
functionality.  By default, pointers are 24 bits but size_t is only
16, which causes wrong-code in some cases.

Index: config/m32c/m32c.h
===
--- config/m32c/m32c.h  (revision 129762)
+++ config/m32c/m32c.h  (working copy)
@@ -170,12 +170,15 @@ machine_function;

 #define DEFAULT_SIGNED_CHAR 1

 #undef PTRDIFF_TYPE
 #define PTRDIFF_TYPE (TARGET_A16 ? "int" : "long int")

+#undef SIZE_TYPE
+#define SIZE_TYPE (TARGET_A16 ? "unsigned int" : "long unsigned int")
+
 /* REGISTER USAGE */

 /* Register Basics */

 /* Register layout:



-- 


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

[Bug regression/33637] "checking for nm: test: too many arguments" causes "Undefined symbol: __gxx_personality_v0"

[dje at gcc dot gnu dot org]

--- Comment #4 from dje at gcc dot gnu dot org  2007-10-31 18:20 ---
If the "nm found only is a wrapper passing through the arguments, the -B
-X32_64, should not cause an error.


-- 

dje at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||dje at gcc dot gnu dot org


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

[Bug tree-optimization/33915] iv folding fails with pointer iterations

[rguenth at gcc dot gnu dot org]

--- Comment #5 from rguenth at gcc dot gnu dot org  2007-10-31 18:20 ---
I think the middle-end internal sizetype needs to be at least the same size
as pointer types, otherwise you _will_ definitely see wrong-code in some
circumstances.


-- 


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

[Bug tree-optimization/33961] [4.3 regression] gcc 4.3 causes crash valid code to crash

[bero at arklinux dot org]

--- Comment #7 from bero at arklinux dot org  2007-10-31 17:54 ---
To clarify, the problem in this usage scenario occurs because the test case
crashes even though the code path that writes to the read-only memory is never
actually run (there is no \0 in the string).

if(d[i] == 0) {
crashing_if_d_points_to_readonly();
}

would work just fine.


-- 


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

[Bug c++/33960] [4.3 Regression] r129030 breaks -fopenmp -static compile of tramp3d-v4

[dougkwan at google dot com]

--- Comment #5 from dougkwan at google dot com  2007-10-31 18:00 ---
Subject: Re:  New: [4.3 Regression] r129030 breaks -fopenmp -static compile of
tramp3d-v4

I'm looking at that.

-Doug

31 Oct 2007 14:52:04 -, rguenth at gcc dot gnu dot org
<[EMAIL PROTECTED]>:
> Starting with r129030 tramp3d-v4 segfaults on startup if compiled statically
> with -fopenmp.  This can be reproduced with the preprocessed testcase from
> http://www.suse.de/~rguenther/tramp3d/tramp3d-v4.ii.gz (x86_64) and compiling
> with -fopenmp -static (optimization does not change the effect).
>
> Author: jason
> Date: Fri Oct  5 05:35:46 2007
> New Revision: 129030
>
> URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129030
> Log:
> 2007-09-13  Doug Kwan  <[EMAIL PROTECTED]>
>
> * gcc/gthr-posix.h (__gthread_cond_broadcast, __gthread_cond_wait,
> __gthread_cond_wait_recursive): Add to extend interface for POSIX
> conditional variables. (__GTHREAD_HAS_COND): Macro defined to signify
> support of conditional variables.
> * gcc/gthr-posix95.h (__gthread_cond_broadcast, __gthread_cond_wait,
> __gthread_cond_wait_recursive): Add to extend interface for POSIX
> conditional variables. (__GTHREAD_HAS_COND): Macro defined to signify
> support of conditional variables.
> * gcc/gthr-single.h (__gthread_cond_broadcast, __gthread_cond_wait,
> __gthread_cond_wait_recursive): Add to extend interface for POSIX
> conditional variables.
> * gcc/gthr.h: Update comments to document new interface.
> * libstdc++-v3/include/ext/concurrent.h (class __mutex,
> class __recursive_mutex): Add new method gthread_mutex to access
> inner gthread mutex.
> [__GTHREAD_HAS_COND] (class __concurrence_broadcast_error,
> class __concurrence_wait_error, class __cond): Add.
> * guard.cc (recursive_push, recursive_pop): Delete.
> (init_in_progress_flag, set_init_in_progress_flag): Add to
> replace recursive_push and recursive_pop.
> (throw_recursive_init_exception): Add.
> (acquire, __cxa_guard_acquire, __cxa_guard_abort and
> __cxa_guard_release): [__GTHREAD_HAS_COND] Use a conditional
> for synchronization of static variable initialization.
> The global mutex is only held briefly when guards are
> accessed. [!__GTHREAD_HAS_COND] Fall back to the old code,
> which deadlocks.
> * testsuite/thread/guard.cc: Add new test. It deadlocks with the
> old locking code in libstdc++-v3/libsup++/guard.cc.
>
>
> --
>Summary: [4.3 Regression] r129030 breaks -fopenmp -static compile
> of tramp3d-v4
>Product: gcc
>Version: 4.3.0
> Status: UNCONFIRMED
>   Keywords: wrong-code
>   Severity: normal
>   Priority: P3
>  Component: c++
> AssignedTo: unassigned at gcc dot gnu dot org
> ReportedBy: rguenth at gcc dot gnu dot org
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33960
>
> --- You are receiving this mail because: ---
> You are on the CC list for the bug, or are watching someone who is.
>


-- 


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

[Bug java/33765] [4.3 regression] gcj internal compiler error when reading an empty file

[bero at arklinux dot org]

--- Comment #4 from bero at arklinux dot org  2007-10-31 18:36 ---
Unfortunately I don't remember what I was trying to compile, but I was trying
to compile some open source code I had downloaded. It was running javac on a
huge list of files, one of which was empty (probably to be implemented later).

So apparently some broken code using this javac "feature" exists.


-- 


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

[Bug tree-optimization/33915] iv folding fails with pointer iterations

[dj at redhat dot com]

--- Comment #6 from dj at redhat dot com  2007-10-31 18:36 ---
Subject: Re:  iv folding fails with pointer iterations


Hmmm... pointers are PSImode (24 bits) with --mcpu=m32c.  How do you
make sizetype that size?  The chip doesn't have enough 24 bit math
opcodes to do all the things gcc wants.


-- 


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

[Bug java/33765] [4.3 regression] gcj internal compiler error when reading an empty file

[tromey at gcc dot gnu dot org]

--- Comment #3 from tromey at gcc dot gnu dot org  2007-10-31 18:26 ---
Confirmed.

I would not mind giving an error for this.  We don't necessarily have
to be compatible with javac here.

I wonder, though, whether this is used in a configure script or something
like this.  How did the reporter happen across this case?


-- 

tromey at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-10-31 18:26:32
   date||


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

[Bug c++/33959] [4.1/4.2/4.3 Regression] ICE in instantiate_class_template, at cp/pt.c:6649

[cppljevans at suddenlink dot net]

--- Comment #3 from cppljevans at suddenlink dot net  2007-10-31 18:49 
---
When that following main is used instead of the one posted earlier,
the error no longer occurs.

<-- cut here --
  int
main(void)
{
typedef gram_tree gt;
gt::productions prods;
  #define INST_SEQ
  #ifdef INST_SEQ
gt::expr_sequence inst_seq;
  #endif
prods[vars::e]=prods[vars::e] >>
#ifdef INST_SEQ
  inst_seq
#else
  prods[vars::e] 
#endif
  ;

return 0;
}

>-- cut here --

IOW, the pt.c insource comment mentioned in my first post
really means what it says, i.e. the above code instantiates 
the outer class, expr_sequence, and the ice no longer occurs.  

Maybe the gcc_assert that's in pt.c on line 6651
and that was mentioned in my first post should be removed?


-- 


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

[Bug middle-end/32429] [PPC, missing optimization] stack space not optimized when stack not used

[pthaugen at gcc dot gnu dot org]

--- Comment #1 from pthaugen at gcc dot gnu dot org  2007-10-31 19:05 
---
Looks like the -fpic/PIC/pie/PIE issue was fixed on mainline with the following
patch.

2007-09-04  Daniel Jacobowitz  <[EMAIL PROTECTED]>

* config/rs6000/rs6000.c (rs6000_stack_info): Allocate space for the
GOT pointer only if there is a constant pool.  Use the allocated space
for SPE also.


See bug 28966 for the -maltivec fix.


-- 

pthaugen at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||pthaugen at gcc dot gnu dot
   ||org, drow at gcc dot gnu dot
   ||org


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

[Bug preprocessor/30805] [4.1/4.2/4.3 Regression] Internal compiler error when using "x##,##__VA_ARGS__" in macro

[tromey at gcc dot gnu dot org]

--- Comment #7 from tromey at gcc dot gnu dot org  2007-10-31 19:12 ---
I'm testing a revised patch.


-- 

tromey at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |tromey at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2007-08-06 15:06:47 |2007-10-31 19:12:33
   date||


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

[Bug fortran/33957] gfortran rejects valid initialization expression

[jv244 at cam dot ac dot uk]

-- 

jv244 at cam dot ac dot uk changed:

   What|Removed |Added

OtherBugsDependingO||32834
  nThis||
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-10-31 19:20:31
   date||


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

[Bug c++/33962] New: ICE at call to overloaded template function with variable-length function argument list

[rjpeters at klab dot caltech dot edu]

I ran across this ICE while compiling some old code that used to compile
cleanly with at least gcc 3.3.x and maybe 3.4.x. Looks like this ICE occurs in
a number of 4.x versions including 4.0.1 (Darwin), 4.1.1 (Mandriva Cooker
2007), 4.1.2 (Fedora Core 7), as well as current 4.3.0 mainline from svn.

$ /home/tmp/u/rjpeters/gcc-svn-install/bin/g++ -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: /home/tmp/u/rjpeters/gcc-svn/configure
--prefix=/home/tmp/u/rjpeters/gcc-svn-install --enable-shared
--enable-threads=posix --with-system-zlib --enable-__cxa_atexit
--enable-languages=c,c++ --enable-long-long --enable-checking
--with-gmp=/home/tmp/u/rjpeters/gmp-4.2.1-install
--with-mpfr=/home/tmp/u/rjpeters/mpfr-2.2.1-install
Thread model: posix
gcc version 4.3.0 20071031 (experimental) [trunk revision 129804] (GCC)


$ cat bug.C
template  struct A;

template  void foo(const U& x, ...);
template  void foo(const A& x, ...);

void bar(const A& x, const char* y)
{
  foo(x, y); // <--- ICE occurs here
}

$ /home/tmp/u/rjpeters/gcc-svn-install/bin/g++ -c bug.C
bug.C: In function ‘void bar(const A&, const char*)’:
bug.C:8: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

The code compiles cleanly when either the '...' is replaced with 'const char*',
or when one of the function overloads is removed.


Other compiler versions that give the same ICE:

$ g++ -v
Using built-in specs.
Target: i386-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk
--disable-dssi --enable-plugin
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile --enable-java-maintainer-mode
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --with-cpu=generic
--host=i386-redhat-linux
Thread model: posix
gcc version 4.1.2 20070502 (Red Hat 4.1.2-12)


$ g++ -v
Using built-in specs.
Target: x86_64-mandriva-linux-gnu
Configured with: ../configure --prefix=/usr --libexecdir=/usr/lib
--with-slibdir=/lib64 --mandir=/usr/share/man --infodir=/usr/share/info
--enable-shared --enable-threads=posix --enable-checking=release
--enable-languages=c,c++,ada,fortran,objc,obj-c++,java
--host=x86_64-mandriva-linux-gnu --with-cpu=generic --with-system-zlib
--enable-long-long --enable-__cxa_atexit --enable-clocale=gnu
--disable-libunwind-exceptions --enable-java-awt=gtk
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --enable-gtk-cairo
--enable-ssp --disable-libssp
Thread model: posix
gcc version 4.1.1 20060724 (prerelease) (4.1.1-3mdk)


$ g++ -v
Using built-in specs.
Target: i686-apple-darwin8
Configured with: /private/var/tmp/gcc/gcc-5363.obj~28/src/configure
--disable-checking -enable-werror --prefix=/usr --mandir=/share/man
--enable-languages=c,objc,c++,obj-c++
--program-transform-name=/^[cg][^.-]*$/s/$/-4.0/
--with-gxx-include-dir=/include/c++/4.0.0 --with-slibdir=/usr/lib
--build=powerpc-apple-darwin8 --with-arch=nocona --with-tune=generic
--program-prefix= --host=i686-apple-darwin8 --target=i686-apple-darwin8
Thread model: posix
gcc version 4.0.1 (Apple Computer, Inc. build 5363)


Thanks,
Rob Peters


-- 
   Summary: ICE at call to overloaded template function with
variable-length function argument list
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rjpeters at klab dot caltech dot edu
 GCC build triplet: x86_64-unknown-linux-gnu
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu


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

[Bug c++/33495] [4.1/4.2/4.3 regression] Broken diagnostic: Trouble pretty-printing statement expressions

[pcarlini at suse dot de]

--- Comment #3 from pcarlini at suse dot de  2007-10-31 19:23 ---
Good point, Jakub. If you have a patch ready to post, please go ahead, don't be
afraid to reassing. Otherwise, will work along the lines you are suggesting.


-- 


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

[Bug tree-optimization/33961] [4.3 regression] gcc 4.3 causes crash valid code to crash

[jakub at gcc dot gnu dot org]

--- Comment #8 from jakub at gcc dot gnu dot org  2007-10-31 19:25 ---
This is valid code and cselim really has to be changed not to introduce writes
to possibly shared or read-only variables that are otherwise never written
into.


-- 


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

[Bug target/28966] -maltivec -m32 causes the stack to be saved and restored even though there is no need for it

[pthaugen at gcc dot gnu dot org]

--- Comment #4 from pthaugen at gcc dot gnu dot org  2007-10-31 19:48 
---
Subject: Bug 28966

Author: pthaugen
Date: Wed Oct 31 19:48:19 2007
New Revision: 129806

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129806
Log:
2007-10-01  Pat Haugen  <[EMAIL PROTECTED]>

Backport the following patches:

2007-09-04  Daniel Jacobowitz  <[EMAIL PROTECTED]>

* config/rs6000/rs6000.c (rs6000_stack_info): Allocate space for the
GOT pointer only if there is a constant pool.  Use the allocated space
for SPE also.

2006-12-21  Nathan Sidwell  <[EMAIL PROTECTED]>

PR target/28966
PR target/29248
* reload1.c (reload): Realign stack after it changes size.


Modified:
branches/ibm/gcc-4_1-branch/gcc/ChangeLog
branches/ibm/gcc-4_1-branch/gcc/config/rs6000/rs6000.c
branches/ibm/gcc-4_1-branch/gcc/reload1.c


-- 


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

[Bug target/29248] Stack pointer is modified in functions that don't use the stack

[pthaugen at gcc dot gnu dot org]

--- Comment #7 from pthaugen at gcc dot gnu dot org  2007-10-31 19:48 
---
Subject: Bug 29248

Author: pthaugen
Date: Wed Oct 31 19:48:19 2007
New Revision: 129806

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129806
Log:
2007-10-01  Pat Haugen  <[EMAIL PROTECTED]>

Backport the following patches:

2007-09-04  Daniel Jacobowitz  <[EMAIL PROTECTED]>

* config/rs6000/rs6000.c (rs6000_stack_info): Allocate space for the
GOT pointer only if there is a constant pool.  Use the allocated space
for SPE also.

2006-12-21  Nathan Sidwell  <[EMAIL PROTECTED]>

PR target/28966
PR target/29248
* reload1.c (reload): Realign stack after it changes size.


Modified:
branches/ibm/gcc-4_1-branch/gcc/ChangeLog
branches/ibm/gcc-4_1-branch/gcc/config/rs6000/rs6000.c
branches/ibm/gcc-4_1-branch/gcc/reload1.c


-- 


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

[Bug c++/33916] Default constructor fails to initialize array members

[crowl at google dot com]

--- Comment #1 from crowl at google dot com  2007-10-31 20:08 ---
The wording in the C++ standard working paper is as follows:

8.5 Initializers [dcl.init]

-8- An object whose initializer is an empty set of parentheses, i.e.,
   (), shall be value-initialized.

Therefore, in <<< Stats my_stats = Stats(); >>>, the temporary object
is value-initialized and then my_stats is copy-constructed.

-5- To value-initialize an object of type T means:
   -- if T is a non-union class type without a user-provided
  constructor, then every non-static data member and base-class
  component of T is value-initialized;93)

   93) Value-initialization for such a class object may be
   implemented by zero-initializing the object and then calling
   the default constructor.

   -- if T is an array type, then each element is value-initialized;

   -- otherwise, the object is zero-initialized

Therefore, the temporary should be zero-initialized and the resulting
copy should copy zeros.  So, I conclude that gcc 4.2.1 is in error.
(I suspect the compiler already eliminates the copy.)

I suspect the problem arose in someone thinking that the zero
initialization in front of a call to a default constructor was
redundant.  Alas, it is not.  It is redundant only if the constructor
initializes all fields, which is generally unknowable, though the
compiler could determine so for many types and constructors.


-- 

crowl at google dot com changed:

   What|Removed |Added

 CC||crowl at google dot com


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

[Bug target/33963] New: Dllimport attribute wrongly accepted on typedefs

[dannysmith at users dot sourceforge dot net]

Testcase gcc.dg/attr-invalid.c started failing on mingw32 with

http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125975

In particular, this delta
* tree.c (handle_dll_attribute): Set DECL_VISIBILITY on the
imported or exported declaration, including type declarations.

made these TYPE_DECL's valid:

# 88 "attr-invalid.c"
typedef int dllimport_type __attribute__((dllimport));

typedef int (*dllimport_fntype)(void) __attribute__((dllimport));

Prior to that revision the attribute was valid only on FUNCTION_DECLS's
and VAR_DECL's 

However, although there is no warning, the attribute is ignored 

typedef int dllimport_type __attribute__((dllimport));
extern dllimport_type foo;
int bar () { return foo; }

gives

_bar:
pushl   %ebp
movl%esp, %ebp
movl_foo, %eax
popl%ebp
ret


-- 
   Summary: Dllimport attribute wrongly accepted on typedefs
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dannysmith at users dot sourceforge dot net
GCC target triplet: i686-pc-mingw32


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

[Bug c++/33964] New: internal compiler error: in dependent_type_p, at cp/pt.c:15319 (vararg templates)

[eric dot niebler at gmail dot com]

I'm not sure if the following should compile or not, but it certainly should
ICE the compiler. Latest gcc from SVN with vararg template patches from Doug
Gregor. Build with -std=c++0x.

Doug, no rush on this one. Just logging it for posterity.

template
struct foo
{
static bool const value = true;
};

template
struct foo< typename Args::is_applied... >
{
static bool const value = false;
};

struct not_applied { typedef void is_applied; };
struct applied { typedef applied is_applied; };

int main()
{
foo i;
}


-- 
   Summary: internal compiler error: in dependent_type_p, at
cp/pt.c:15319 (vararg templates)
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: eric dot niebler at gmail dot com


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

[Bug target/31507] [4.3 Regression] libffi regression, many.c, closure_fn2/fn3.c with -Os

[andreast at gcc dot gnu dot org]

--- Comment #15 from andreast at gcc dot gnu dot org  2007-10-31 21:06 
---
=== libffi Summary for unix/-m64 ===

# of expected passes1108
# of unsupported tests  8

=== libffi Summary for unix ===

# of expected passes1105
# of unexpected failures3
# of unsupported tests  8

=== libffi Summary ===

# of expected passes2213
# of unexpected failures3
# of unsupported tests  16

The three failures are in the area of 32843. Not yet fixed.

Thanks Jakub!


-- 


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

[Bug libstdc++/33831] [4.3 Regression] Revision 129442 breaks libstc++ API

[bkoz at gcc dot gnu dot org]

-- 

bkoz at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |bkoz at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2007-10-28 00:53:44 |2007-10-31 21:35:12
   date||


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

[Bug libstdc++/33832] Can't tell gcc 4.3 libstdc++ API from gcc 4.2 libstdc++ API

[bkoz at gcc dot gnu dot org]

-- 

bkoz at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |bkoz at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-10-31 21:35:26
   date||


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

[Bug c++/33965] New: internal compiler error: tree check: expected class 'type', have 'constant' (integer_cst) in cp_type_quals, at cp/typeck.c:6955 (vararg templates)

[eric dot niebler at gmail dot com]

In the following SFINAE scenario involving vararg templates an non-type
template parameters, the compiler ICEs instead of ignoring the specialization.

Latest SVN g++ with patches from Doug Gregor for vararg templates.

template
struct foo
{
static bool const value = false;
};

template class T, typename... Args>
struct foo >
{
static bool const value = false;
};

template
struct int_
{};

int main()
{
foo > f; // ICE
}


-- 
   Summary: internal compiler error: tree check: expected class
'type', have 'constant' (integer_cst) in cp_type_quals,
at cp/typeck.c:6955 (vararg templates)
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: eric dot niebler at gmail dot com


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

[Bug target/30572] [4.3 Regression] target libraries links against /libgcc_s.1.dylib instead of $(prefix)/lib/libgcc_s.1.dylib

[pinskia at gcc dot gnu dot org]

--- Comment #8 from pinskia at gcc dot gnu dot org  2007-10-31 22:00 ---
Couldn't we use install_name_tool before installing the binary to fix up the
install name?


-- 


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

[Bug tree-optimization/33915] iv folding fails with pointer iterations

[dj at redhat dot com]

--- Comment #8 from dj at redhat dot com  2007-10-31 22:27 ---
Subject: Re:  iv folding fails with pointer iterations


Right, that's why I was trying to use 32 bit math instead, which led
to the original iv bug.


-- 


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

[Bug tree-optimization/33961] [4.3 regression] gcc 4.3 causes crash valid code to crash

[matz at gcc dot gnu dot org]

--- Comment #9 from matz at gcc dot gnu dot org  2007-10-31 21:52 ---
Working on it.


-- 

matz at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |matz at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2007-10-31 17:03:11 |2007-10-31 21:52:02
   date||


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