[Bug fortran/31251] Non-integer character length leads to segfault

[jvdelisle at gcc dot gnu dot org]

--- Comment #10 from jvdelisle at gcc dot gnu dot org  2007-05-04 07:39 
---
Comment #9 is a red herring.  Using gdb and looking at this at line 2143:

 mpz_set (result->value.integer, e->ts.cl->length->value.integer);

(gdb) p *e->ts.cl->length
$9 = {expr_type = EXPR_CONSTANT, ts = {type = BT_REAL, kind = 4, 
derived = 0x0, cl = 0x0}, rank = 0, shape = 0x0, symtree = 0x0, ref = 0x0, 
  where = {nextc = 0xef3b0c "2.3) :: s", lb = 0xef3ae0}, from_H = 0, 
  inline_noncopying_intrinsic = 0, con_by_offset = 0x0, value = {logical = 24, 
integer = {{_mp_alloc = 24, _mp_size = 0, _mp_d = 0x1}}, real = {{
_mpfr_prec = 24, _mpfr_sign = 1, _mpfr_exp = 2, _mpfr_d = 0xf25d08}}, 
complex = {r = {{_mpfr_prec = 24, _mpfr_sign = 1, _mpfr_exp = 2, 
  _mpfr_d = 0xf25d08}}, i = {{_mpfr_prec = 0, _mpfr_sign = 0, 
  _mpfr_exp = 0, _mpfr_d = 0x0}}}, op = {operator = 24, uop = 0x1, 
  op1 = 0x2, op2 = 0xf25d08}, function = {actual = 0x18, 
  name = 0x1 , isym = 0x2, esym = 0xf25d08}, 
character = {length = 24, string = 0x1 }, 
constructor = 0x18}}

The type is real and we are trying to use the value.integer which is probably
meaningless.  Again, I am unable to really test this, but here is a suggestion:

Index: simplify.c
===
--- simplify.c  (revision 124405)
+++ simplify.c  (working copy)
@@ -2136,14 +2136,15 @@ gfc_simplify_len (gfc_expr *e)
 }

   if (e->ts.cl != NULL && e->ts.cl->length != NULL
-  && e->ts.cl->length->expr_type == EXPR_CONSTANT)
+  && e->ts.cl->length->expr_type == EXPR_CONSTANT
+  && e->ts.cl->length->ts.type == BT_INTEGER)
 {
   result = gfc_constant_result (BT_INTEGER, gfc_default_integer_kind,
&e->where);
   mpz_set (result->value.integer, e->ts.cl->length->value.integer);
   return range_check (result, "LEN");
 }
-  
+
   return NULL;
 }


-- 


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

[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should

[ian at airs dot com]

--- Comment #40 from ian at airs dot com  2007-05-04 07:37 ---
Created an attachment (id=13506)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13506&action=view)
Patch

Here is yet another patch, an improvement over the previous one.  It finally
dawned on me that we can use an asm to represent the exact memory operations we
care about, namely a use of the memory accessed via the old type and a def of
the memory accessed via the new type.  This way we don't mess with alias sets
at all per se, we just put down a barrier for exactly the memory addresses that
matter (of course the effect may be to VUSE and VDEF SMT tags, but the aliasing
machinery takes care of that for us).

This patch still needs some more testing--in particular I need to make sure it
does the right thing for templates--but it passes bootstrap and the g++
testsuite.

Richard, could you test it on your C++ test case(s)?  Thanks.


-- 

ian at airs dot com changed:

   What|Removed |Added

  Attachment #13504|0   |1
is obsolete||


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

[Bug fortran/31692] Wrong code when passing function name as result to procedures

[pault at gcc dot gnu dot org]

--- Comment #3 from pault at gcc dot gnu dot org  2007-05-04 07:29 ---
This fixes it but needs some cleaning up:

Index: gcc/fortran/trans-expr.c
===
*** gcc/fortran/trans-expr.c(revision 124354)
--- gcc/fortran/trans-expr.c(working copy)
*** conv_arglist_function (gfc_se *se, gfc_e
*** 1987,1992 
--- 1987,2068 
  }


+ /* Convert an array valued actual argument expression.  */
+ 
+ static void
+ gfc_conv_array_arg (gfc_se *se, gfc_se *parmse, gfc_ss *argss,
+   gfc_expr *e, gfc_symbol *sym, gfc_symbol *fsym)
+ {
+   /* If the procedure requires an explicit interface, the actual argument
+  is passed according to the corresponding formal argument.  If the
+  corresponding formal argument is a POINTER, ALLOCATABLE or assumed
+  shape, we do not use g77's calling convention, and pass the address
+  of the array descriptor instead. Otherwise we use g77's calling
+  convention.  */
+   tree tmp;
+   tree parent;
+   gfc_symbol *psym;
+   int f;
+ 
+   if (e->expr_type == EXPR_VARIABLE)
+ psym = e->symtree->n.sym;
+   else
+ psym = NULL;
+ 
+   parent = DECL_CONTEXT (current_function_decl);
+ 
+   f = (fsym != NULL)
+   && !(fsym->attr.pointer || fsym->attr.allocatable)
+   && fsym->as->type != AS_ASSUMED_SHAPE;
+   f = f || !sym->attr.always_explicit;
+ 
+   /* The actual argument is a component reference to an array of derived
+  types.  In this case, the argument is converted to a temporary,
+  which is passed and then written back after the procedure call.  */
+   if (e->expr_type == EXPR_VARIABLE && is_aliased_array (e))
+ gfc_conv_aliased_arg (parmse, e, f,
+ fsym ? fsym->attr.intent : INTENT_INOUT);
+ 
+   /* The actual argument is a reference to the procedure containing the
+  call, when it does not have an explicit result.  */
+   else if (psym && psym->attr.flavor == FL_PROCEDURE
+   && (psym->backend_decl == current_function_decl
+ || 
+   psym->backend_decl == parent))
+ {
+   int b = (parent == psym->backend_decl) ? 1 : 0;
+   parmse->expr = gfc_get_fake_result_decl (psym, b);
+ 
+   /* Pass a descriptor if required.  */
+   if (f == 0 && GFC_ARRAY_TYPE_P (TREE_TYPE (parmse->expr)))
+   {
+ tmp = gfc_conv_array_data (parmse->expr);
+ gfc_conv_expr_descriptor (parmse, e, argss);
+ parmse->expr = build_fold_addr_expr (parmse->expr);
+   }
+   else if (f == 1 && GFC_DESCRIPTOR_TYPE_P (TREE_TYPE (TREE_TYPE
(parmse->expr
+   parmse->expr = gfc_conv_array_data (build_fold_indirect_ref
(parmse->expr));
+ 
+   if (psym->ts.type == BT_CHARACTER)
+   parmse->string_length = psym->ts.cl->backend_decl;
+ }
+ 
+   /* The actual argument is an ordinary, honest-to-goodness array.  */
+   else
+ gfc_conv_array_parameter (parmse, e, argss, f);
+ 
+   /* If an ALLOCATABLE dummy argument has INTENT(OUT) and is allocated
+  on entry, it must be deallocated.  */
+   if (fsym && fsym->attr.allocatable
+ && fsym->attr.intent == INTENT_OUT)
+ {
+   tmp = build_fold_indirect_ref (parmse->expr);
+   tmp = gfc_trans_dealloc_allocated (tmp);
+   gfc_add_expr_to_block (&se->pre, tmp);
+ }
+ } 
+ 
+ 
  /* Generate code for a procedure call.  Note can return se->post != NULL.
 If se->direct_byref is set then se->expr contains the return parameter.
 Return nonzero, if the call has alternate specifiers.  */
*** gfc_conv_function_call (gfc_se * se, gfc
*** 2132,2172 
}
}
  else
!   {
!   /* If the procedure requires an explicit interface, the actual
!  argument is passed according to the corresponding formal
!  argument.  If the corresponding formal argument is a
POINTER,
!  ALLOCATABLE or assumed shape, we do not use g77's calling
!  convention, and pass the address of the array descriptor
!  instead. Otherwise we use g77's calling convention.  */
! int f;
! f = (fsym != NULL)
! && !(fsym->attr.pointer || fsym->attr.allocatable)
! && fsym->as->type != AS_ASSUMED_SHAPE;
! f = f || !sym->attr.always_explicit;
! 
! if (e->expr_type == EXPR_VARIABLE
!   && is_aliased_array (e))
!   /* The actual argument is a component reference to an
!  array of derived types.  In this case, the argument
!  is converted to a temporary, which is passed and then
!  written back after the procedure call.  */
!   gfc_conv_aliased_arg (&parmse, e, f,
!   fsym ? fsym->attr.intent : INTENT_INOUT);
! else
!   gfc_conv_array_parameter (&parmse, e,

[Bug fortran/31251] Non-integer character length leads to segfault

[jvdelisle at gcc dot gnu dot org]

--- Comment #9 from jvdelisle at gcc dot gnu dot org  2007-05-04 06:42 
---
I think the problem may be in arith.c (gfc_constant_result).  We are passing a
type real into this and so we do not mpz_init (result->value.integer);

Which we later try to set at simplify.c: 2143 
mpz_set (result->value.integer, e->ts.cl->length->value.integer);
And it breaks sometimes.

As I said, I can not reproduce the bug, but this is my look into it for what
its worth.  You might try this and see what it does:

Index: arith.c
===
--- arith.c (revision 124405)
+++ arith.c (working copy)
@@ -420,6 +420,7 @@ gfc_constant_result (bt type, int kind, 

 case BT_REAL:
   gfc_set_model_kind (kind);
+  mpz_init (result->value.integer);
   mpfr_init (result->value.real);
   break;


-- 


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

[Bug target/31797] gcc-4.2.0 racing

[ralf_corsepius at rtems dot org]

--- Comment #4 from ralf_corsepius at rtems dot org  2007-05-04 06:36 
---
Using GT64260eth.c from attachment 13505, I am able to reproduce the race with
gcc-4.2.0-20070430 for arm-rtems, bfin-rtems, powerpc-rtems, i386-rtems.

=> I assume this issue to be target independent and to affect all targets.


-- 

ralf_corsepius at rtems dot org changed:

   What|Removed |Added

   Severity|normal  |major
 GCC target triplet|powerpc-rtems*  |all
Summary|powerpc: race   |gcc-4.2.0 racing


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

[Bug target/31797] powerpc: race

[ralf_corsepius at rtems dot org]

--- Comment #3 from ralf_corsepius at rtems dot org  2007-05-04 06:29 
---
Created an attachment (id=13505)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13505&action=view)
Stripped down example to expose the issue on all targets


-- 


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

[Bug ada/31800] ACATS c46051a fails

[ebotcazou at gcc dot gnu dot org]

--- Comment #5 from ebotcazou at gcc dot gnu dot org  2007-05-04 06:26 
---
Spurious.


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||WORKSFORME


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

[Bug fortran/31251] Non-integer character length leads to segfault

[kargl at gcc dot gnu dot org]

--- Comment #8 from kargl at gcc dot gnu dot org  2007-05-04 06:16 ---
This appears to be an alignment issue.  On x86_64-*-FreeBSD, I do not
see the segfault.  On i386-*-FreeBSD, I see the segfault.  Here's is
the backtrace
Starting program:
/usr/home/kargl/work/4x/libexec/gcc/i386-unknown-freebsd7.0/4.3.0/f951 b.f90
b.f90:1.16:

  character(len=2.3) :: s
   1
Error: Expression at (1) must be of INTEGER type
b.f90:1.16:

  character(len=2.3) :: s
   1
Error: Expression at (1) must be of INTEGER type

Program received signal SIGSEGV, Segmentation fault.
0x287c4cf1 in __gmpn_copyi () from /usr/local/lib/libgmp.so.7


(gdb) bt
#0  0x287c4cf1 in __gmpn_copyi () from /usr/local/lib/libgmp.so.7
#1  0x287b5413 in __gmpz_set () from /usr/local/lib/libgmp.so.7
#2  0x0809495b in gfc_simplify_len (e=0x28932260) at
../../gcc4x/gcc/fortran/simplify.c:2143
#3  0x0806ba1d in do_simplify (specific=0x28941b70, e=0x28932200)
at ../../gcc4x/gcc/fortran/intrinsic.c:3134
#4  0x0806bde1 in gfc_intrinsic_func_interface (expr=0x28932200,
error_flag=680567168)
at ../../gcc4x/gcc/fortran/intrinsic.c:3395
#5  0x08089b91 in gfc_resolve_expr (e=0x28932200) at
../../gcc4x/gcc/fortran/resolve.c:1456
#6  0x0808bf4d in resolve_code (code=0x2892c9c0, ns=0x28938000)
at ../../gcc4x/gcc/fortran/resolve.c:5091
#7  0x0808d7ee in gfc_resolve_blocks (b=0x2892ca00, ns=0x28938000)
at ../../gcc4x/gcc/fortran/resolve.c:5024
#8  0x0808bf31 in resolve_code (code=0x2892ca80, ns=0x28938000)
at ../../gcc4x/gcc/fortran/resolve.c:5083
#9  0x0808ee65 in resolve_codes (ns=0x28938000) at
../../gcc4x/gcc/fortran/resolve.c:7386
#10 0x0808ee93 in gfc_resolve (ns=0x28938000) at
../../gcc4x/gcc/fortran/resolve.c:7405
#11 0x08084032 in gfc_parse_file () at ../../gcc4x/gcc/fortran/parse.c:3248
#12 0x080a0b10 in gfc_be_parse_file (set_yydebug=0) at
../../gcc4x/gcc/fortran/f95-lang.c:305
#13 0x082b4bcd in toplev_main (argc=2, argv=0xbfbfe8a3) at
../../gcc4x/gcc/toplev.c:1051
#14 0x080d795b in main (argc=2, argv=0xbfbfe734) at ../../gcc4x/gcc/main.c:35


-- 

kargl at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu dot org


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

[Bug c++/10179] alignment attributes are not inherited correctly with empty classes

[jadamcze at utas dot edu dot au]

--- Comment #4 from jadamcze at utas dot edu dot au  2007-05-04 05:58 
---
Also present in mainline as of 20070406.


-- 


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

[Bug c++/10179] alignment attributes are not inherited correctly with empty classes

[jadamcze at utas dot edu dot au]

--- Comment #3 from jadamcze at utas dot edu dot au  2007-05-04 05:10 
---
Bitten and confirmed.  gcc-4.1.1 (from cellsdk-2.0).


-- 

jadamcze at utas dot edu dot au changed:

   What|Removed |Added

 CC||jadamcze at utas dot edu dot
   ||au


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

[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should

[bangerth at dealii dot org]

--- Comment #39 from bangerth at dealii dot org  2007-05-04 04:54 ---
>From my perspective as a user, I wouldn't find a memory clobber
in front of every placement new all that terrible. People don't
do that in tight loops, and even if they did all that would happen
is that the clobber presents a barrier across which no memory
accesses can be moved and across which no dead stores etc can
be eliminated. Presumably with every placement new/delete, there
comes some housekeeping of available memory, so there will be
a significant amount of code before and after, and so a single
barrier isn't going to have the effect of slowing down a code by
any significant factor.

This appears to me to be a case where one could overengineer a solution.
I would just go with the memory clobber and see whether we get bug
reports of people complaining about missed optimizations :-)

W.


-- 

bangerth at dealii dot org changed:

   What|Removed |Added

 CC||bangerth at dealii dot org


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

[Bug c/31804] gcc segfaults on very long pointer chains

[bangerth at dealii dot org]

--- Comment #3 from bangerth at dealii dot org  2007-05-04 04:50 ---
(In reply to comment #0)
> $ perl -wle 'print "int", "*" x 99, "p;"' >try.c && gcc try.c
> gcc: Internal error: Segmentation fault (program cc1)

Yo, dude, that would take a seriously long program to even initialize
that pointer :-)

But seriously, while I do think that we should strive to compile even
programs that are "weird" or "unusual" in their requirements on the 
compiler, I think that this one goes a little overboard. I would,
however, be interested to hear how many levels of pointers gcc
actually *can* compile. I would imagine it's at least a few
hundred, maybe thousand. Maybe you could try to figure out?

Best
  Wolfgang


-- 

bangerth at dealii dot org changed:

   What|Removed |Added

 CC||bangerth at dealii dot org


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

[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should

[mark at codesourcery dot com]

--- Comment #38 from mark at codesourcery dot com  2007-05-04 03:47 ---
Subject: Re:  [4.0/4.1/4.2/4.3 Regression] placement
 new does not change the dynamic type as it should

rguenth at gcc dot gnu dot org wrote:
> --- Comment #36 from rguenth at gcc dot gnu dot org  2007-05-03 21:59 
> ---
> Well, the patch in comment #33 really does what I did with the patch to
> libstdc++.

I think that Ian's second patch (the heavy hammer of a memory clobber,
generated by the front end) is also reasonable.  It's more heavy-handed
than Ian's earlier solution, but certainly less intrusive and easier to
get right.

I think that either of these solutions will make user code work as
expected, which is the most important consideration.  I guess my
inclination would be to go with the heavy hammer, until/unless we start
finding real code that's seriously impacted.


-- 


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

[Bug c/31804] gcc segfaults on very long pointer chains

[fang at csl dot cornell dot edu]

--- Comment #2 from fang at csl dot cornell dot edu  2007-05-04 03:40 
---
adding to personal favorite list :)


-- 

fang at csl dot cornell dot edu changed:

   What|Removed |Added

 CC||fang at csl dot cornell dot
   ||edu


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

[Bug fortran/31251] Non-integer character length leads to segfault

[jvdelisle at gcc dot gnu dot org]

--- Comment #7 from jvdelisle at gcc dot gnu dot org  2007-05-04 03:27 
---
Very odd.  On rev 124344 on my old i686 FC5 box I did a bootstrap.  This is
unmodified source from the svn and I get no segfault and just the double error.
 This is what I see on x86-64 as reported above.


-- 


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

[Bug fortran/31218] ICE on valid code with gfortran

[jvdelisle at gcc dot gnu dot org]

--- Comment #4 from jvdelisle at gcc dot gnu dot org  2007-05-04 02:47 
---
The ice is happening here:

/* Create an array constructor from an initialization expression.
   We assume the frontend already did any expansions and conversions.  */

tree
gfc_conv_array_initializer (tree type, gfc_expr * expr)
{
  gfc_constructor *c;
  tree tmp;
  mpz_t maxval;
  gfc_se se;
  HOST_WIDE_INT hi;
  unsigned HOST_WIDE_INT lo;
  tree index, range;
  VEC(constructor_elt,gc) *v = NULL;
gfc_show_expr (expr);
  switch (expr->expr_type)
{
case EXPR_CONSTANT:
case EXPR_STRUCTURE:

The comment indicates that the initialization expression should already be
expanded.  For the test case given, expr->expr_type is FUNCTION for which there
is no case.  The function needs to be evaluated before getting here.


-- 


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

[Bug gcov-profile/31810] gcov returns wrong results

[echristo at apple dot com]

--- Comment #2 from echristo at apple dot com  2007-05-04 02:38 ---
Yeah, probably. Bah.


-- 


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

[Bug c++/12076] gcov misreports coverage of return statement [NRV]

[pinskia at gcc dot gnu dot org]

--- Comment #14 from pinskia at gcc dot gnu dot org  2007-05-04 02:34 
---
*** Bug 31810 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||echristo at apple dot com


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

[Bug gcov-profile/31810] gcov returns wrong results

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2007-05-04 02:34 ---
And this is why people should not confirm their own bugs :).

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


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE


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

[Bug gcov-profile/31810] gcov returns wrong results

[echristo at apple dot com]

-- 

echristo at apple dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-05-04 02:32:30
   date||


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

[Bug gcov-profile/31810] New: gcov returns wrong results

[echristo at apple dot com]

#include 

// this global string causes gcov to think there's executable lines
// beyond the end of the file, and that they have not been executed
std::string globalVar = "";

std::string
doSomething()
{
// instantiating this string and calling a method on it causes the
// 'return' line to be marked as having never been executed
std::string localVar;
localVar.size();
return localVar;
}

int
main(int, char **)
{
doSomething();
return 0;
}

produces the wrong results:

a) it says that the return is never called
b) it executes past the end of the file


-- 
   Summary: gcov returns wrong results
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: gcov-profile
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: echristo at apple dot com
 GCC build triplet: i386-apple-darwin
  GCC host triplet: i386-apple-darwin
GCC target triplet: i386-apple-darwin


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

[Bug c++/20912] C++ FE emitting assignments to read-only global symbols

[pinskia at gcc dot gnu dot org]

--- Comment #19 from pinskia at gcc dot gnu dot org  2007-05-04 01:30 
---
One more case where C++ front-end is doing this still is located in PR 31809.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

OtherBugsDependingO||31809
  nThis||


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

[Bug c++/31809] [4.1/4.2/4.3 Regression] sometimes TREE_READONLY is still set for non read only variables causing wrong code

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to fail||4.0.2 4.1.1 4.2.0 4.3.0
  Known to work||3.4.0
   Target Milestone|--- |4.1.3


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

[Bug c++/31809] New: [4.1/4.2/4.3 Regression] sometimes TREE_READONLY is still set for non read only variables causing wrong code

[pinskia at gcc dot gnu dot org]

Testcase which should not abort but does currently at -O1 and above because SRA
thinks the decl is constant so it using its DECL_INITIAL but that is NULL so we
get a zero instead of the corect value:
struct sc
{
 unsigned v;
 static inline sc f(unsigned a);
};
inline sc sc::f(unsigned a)
{
 static sc t = { a };
 return t;
}
const static sc RC = sc::f( 1 );
extern "C" void abort (void);
int main()
{
  sc RC1 = RC;
 if (! RC1.v ) abort ();
 return 0;
}


-- 
   Summary: [4.1/4.2/4.3 Regression] sometimes TREE_READONLY is
still set for non read only variables causing wrong code
   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: pinskia at gcc dot gnu dot org
GCC target triplet: powerpc-linux-gnu


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

[Bug ada/31808] New: cross-built gnattools installs vxaddr2line regardless of target triplet

[bje at gcc dot gnu dot org]

When building an ada-enabled compiler in a cross-environment, the gnattools
directory will install "vxaddr2line", even if the target is not *-*-vxworks*. 
It should only install vxaddr2line when the target matches *-*-vxworks*.


-- 
   Summary: cross-built gnattools installs vxaddr2line regardless of
target triplet
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bje at gcc dot gnu dot org


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

[Bug libstdc++/31807] bootstrap failure in 4.2.0 RC3. const_point_iterator.hpp not found

[daney at gcc dot gnu dot org]

--- Comment #4 from daney at gcc dot gnu dot org  2007-05-04 00:01 ---
Sorry for the noise.

After unpacking the tarball with gnu tar, the bootstrap proceeds past the
previous point of failure.


-- 

daney at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||FIXED


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

[Bug libstdc++/31807] bootstrap failure in 4.2.0 RC3. const_point_iterator.hpp not found

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2007-05-03 23:30 ---
The tar file which is created has the GNU tar extensions in it as file names
are long.  If you see anywhere @long_file (I think that is the name of the
file) file, then you know it did not exact it correctly.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING


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

[Bug ada/31800] ACATS c46051a fails

[anhvofrcaus at gmail dot com]

--- Comment #4 from anhvofrcaus at gmail dot com  2007-05-03 23:28 ---
On the second ACATS run, c46051a test passes. You are correct it exhibits a
spurious behavior. Therefore, this report is withdrawn (closed)


-- 


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

[Bug fortran/31781] fortran regressions on trunk if you --disable-checking

[fxcoudert at gcc dot gnu dot org]

--- Comment #4 from fxcoudert at gcc dot gnu dot org  2007-05-03 23:11 
---
Stupid mistake, trivial patch:

Index: simplify.c
===
--- simplify.c  (revision 124285)
+++ simplify.c  (working copy)
@@ -2919,7 +2919,10 @@ gfc_simplify_repeat (gfc_expr *e, gfc_ex
 return NULL;

   if (mpz_sgn (e->ts.cl->length->value.integer) != 0)
-gcc_assert (gfc_extract_int (n, &ncop) == NULL);
+{
+  const char *res = gfc_extract_int (n, &ncop);
+  gcc_assert (res == NULL);
+}
   else
 ncop = 0;


Many thanks to Kenneth for reporting the bug, to Daniel for reducing it and
posting tree dumps, and to Andrew for pointing the likely cause of the bug!


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |fxcoudert at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Keywords||patch, wrong-code
  Known to work||4.1.2 4.2.0
   Last reconfirmed|2007-05-03 22:46:39 |2007-05-03 23:11:53
   date||
   Target Milestone|--- |4.3.0


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

[Bug libstdc++/31807] bootstrap failure in 4.2.0 RC3. const_point_iterator.hpp not found

[daney at gcc dot gnu dot org]

--- Comment #2 from daney at gcc dot gnu dot org  2007-05-03 23:09 ---
Dang.

I am using busybox tar.  It seems to have failed while unpacking the tarfile.

I am building gnu tar now.  Perhaps that will solve this problem.


-- 


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

[Bug ada/31800] ACATS c46051a fails

[ebotcazou at gcc dot gnu dot org]

--- Comment #3 from ebotcazou at gcc dot gnu dot org  2007-05-03 23:04 
---
> Is there a spurious failure catatory in ACATS?

They are spurious failures on Linux, because of the harness.  Just look at the
log file and post the error message.


-- 


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

[Bug libstdc++/31807] bootstrap failure in 4.2.0 RC3. const_point_iterator.hpp not found

[daney at gcc dot gnu dot org]

--- Comment #1 from daney at gcc dot gnu dot org  2007-05-03 23:02 ---
I am investigating why

ext/pb_ds/detail/unordered_iterator/const_point_iterator.hpp

is missing from my source directory when it appears to be in the tarball.


-- 


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

[Bug fortran/31781] fortran regressions on trunk if you --disable-checking

[dfranke at gcc dot gnu dot org]

--- Comment #3 from dfranke at gcc dot gnu dot org  2007-05-03 22:57 ---
With "--enable-checking", the same dump as shown in comment #3 looks like:

$> cat repeat.f90.003t.original
MAIN__ ()
{
  _gfortran_set_std (68, 127, 0, 0, 0);
  {
struct __st_parameter_dt dt_parm.0;

dt_parm.0.common.filename = "repeat.f90";
dt_parm.0.common.line = 3;
dt_parm.0.common.unit = 6;
dt_parm.0.common.flags = 128;
_gfortran_st_write (&dt_parm.0);
_gfortran_transfer_character (&dt_parm.0, "aa: ", 4);
_gfortran_transfer_character (&dt_parm.0, "aa", 2);  # <---
_gfortran_st_write_done (&dt_parm.0);
  }


-- 


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

[Bug target/31801] [dataflow] undefined reference to `gen_blockage'

[dj at redhat dot com]

--- Comment #4 from dj at redhat dot com  2007-05-03 22:55 ---
Gak, the grep didn't show it earlier today, but does now.  Sigh.  Lesson: never
buy quantum computers!

We still have the problem that almost half the targets (on trunk) don't have
gen_blockage().  Will updating all the targets be part of the dataflow branch's
patchset when it merges?


-- 


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

[Bug libstdc++/31807] New: bootstrap failure in 4.2.0 RC3. const_point_iterator.hpp not found

[daney at gcc dot gnu dot org]

I was trying to bootstrap from the 4.2.0 RC3 tarball.

Configured as:
../gcc-4.2.0-20070501/configure --with-arch=mips32 --with-float=soft
--disable-java-awt --without-x --disable-tls --enable-__cxa_atexit
--disable-jvmpi --disable-static --disable-libmudflap
--enable-languages=c,c++,java

A similar bootstrap from SVN sources a couple of weeks ago was successful:
http://gcc.gnu.org/ml/gcc-testresults/2007-04/msg00666.html

The result is this failure in stage3 while building libstdc++:


/home/build/gcc-4.2-build/./gcc/xgcc -shared-libgcc
-B/home/build/gcc-4.2-build/./gcc -nostdinc++
-L/home/build/gcc-4.2-build/mipsel-unknown-linux-gnu/libstdc++-v3/src
-L/home/build/gcc-4.2-build/mipsel-unknown-linux-gnu/libstdc++-v3/src/.libs
-B/usr/local/mipsel-unknown-linux-gnu/bin/
-B/usr/local/mipsel-unknown-linux-gnu/lib/ -isystem
/usr/local/mipsel-unknown-linux-gnu/include -isystem
/usr/local/mipsel-unknown-linux-gnu/sys-include -Winvalid-pch -Wno-deprecated
-x c++-header -g -O2  -D_GNU_SOURCE
-I/home/build/gcc-4.2-build/mipsel-unknown-linux-gnu/libstdc++-v3/include/mipsel-unknown-linux-gnu
-I/home/build/gcc-4.2-build/mipsel-unknown-linux-gnu/libstdc++-v3/include
-I/home/build/gcc-4.2.0-20070501/libstdc++-v3/libsupc++ -O2 -g
/home/build/gcc-4.2.0-20070501/libstdc++-v3/include/precompiled/extc++.h -o
mipsel-unknown-linux-gnu/bits/extc++.h.gch/O2g.gch
In file included from
/home/build/gcc-4.2-build/mipsel-unknown-linux-gnu/libstdc++-v3/include/ext/pb_ds/detail/container_base_dispatch.hpp:53,
 from
/home/build/gcc-4.2-build/mipsel-unknown-linux-gnu/libstdc++-v3/include/ext/pb_ds/assoc_container.hpp:53,
 from
/home/build/gcc-4.2.0-20070501/libstdc++-v3/include/precompiled/extc++.h:59:
/home/build/gcc-4.2-build/mipsel-unknown-linux-gnu/libstdc++-v3/include/ext/pb_ds/detail/list_update_map_/lu_map_.hpp:142:72:
error: ext/pb_ds/detail/unordered_iterator/const_point_iterator.hpp: No such
file or directory
In file included from
/home/build/gcc-4.2-build/mipsel-unknown-linux-gnu/libstdc++-v3/include/ext/pb_ds/detail/priority_queue_base_dispatch.hpp:51,
 from
/home/build/gcc-4.2-build/mipsel-unknown-linux-gnu/libstdc++-v3/include/ext/pb_ds/priority_queue.hpp:51,
 from
/home/build/gcc-4.2.0-20070501/libstdc++-v3/include/precompiled/extc++.h:60:
/home/build/gcc-4.2-build/mipsel-unknown-linux-gnu/libstdc++-v3/include/ext/pb_ds/detail/binomial_heap_/binomial_heap_.hpp:56:72:
error: ext/pb_ds/detail/binomial_heap_base_/binomial_heap_base_.hpp: No such
file or directory
.
.
.


-- 
   Summary: bootstrap failure in 4.2.0 RC3. const_point_iterator.hpp
not found
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Keywords: build
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: daney at gcc dot gnu dot org
 GCC build triplet: mipsel-unknown-linux-gnu
  GCC host triplet: mipsel-unknown-linux-gnu
GCC target triplet: mipsel-unknown-linux-gnu


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

[Bug ada/31800] ACATS c46051a fails

[anhvofrcaus at gmail dot com]

--- Comment #2 from anhvofrcaus at gmail dot com  2007-05-03 22:48 ---
Is there a spurious failure catatory in ACATS? If true, how many are there? Are
they documented in the ACATS test procedure?


-- 


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

[Bug fortran/31781] fortran regressions on trunk if you --disable-checking

[dfranke at gcc dot gnu dot org]

--- Comment #2 from dfranke at gcc dot gnu dot org  2007-05-03 22:46 ---
Confirmed.

Testcase:
$> cat repeat.f90
  character(len=1), parameter :: s1 = "a"
  print *, "aa: ", repeat(s1, 2)
  end

$> gfortran-svn -g -Wall -fdump-tree-original repeat.f90
$> cat repeat.f90.003t.original
MAIN__ ()
{
  _gfortran_set_std (68, 127, 0, 0, 0);
  {
struct __st_parameter_dt dt_parm.0;

dt_parm.0.common.filename = "repeat.f90";
dt_parm.0.common.line = 3;
dt_parm.0.common.unit = 6;
dt_parm.0.common.flags = 128;
_gfortran_st_write (&dt_parm.0);
_gfortran_transfer_character (&dt_parm.0, "aa: ", 4);
_gfortran_transfer_character (&dt_parm.0, "", 0);
_gfortran_st_write_done (&dt_parm.0);
  }

If the PARAMETER statement of S1 is removed, REPEAT works as expected. 

Adding FX to CC as he worked on this a while ago.


-- 

dfranke at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||dfranke at gcc dot gnu dot
   ||org, fxcoudert at gcc dot
   ||gnu dot org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
  GCC build triplet|x86_64-unknown-linux-gnu|
   GCC host triplet|x86_64-unknown-linux-gnu|
 GCC target triplet|x86_64-unknown-linux-gnu|
  Known to fail||4.3.0
   Last reconfirmed|-00-00 00:00:00 |2007-05-03 22:46:39
   date||


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

[Bug ada/31669] GNAT blows up during compilation

[anhvofrcaus at gmail dot com]

--- Comment #2 from anhvofrcaus at gmail dot com  2007-05-03 22:42 ---
Just use a normal command as shown below:

gcc -c re_not_available.ads

It is true that gnatdist is part of GLADE. However, it should reject the codes
rather raising exception and terminated.


-- 


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

[Bug rtl-optimization/31806] New: miscompilation with -fschedule-insns2 -fthreadsafe-statics and static variables

[mueller at gcc dot gnu dot org]

Hi, 

the testcase below aborts with gcc 4.1.3 compiled with:
g++ -O2 -fno-threadsafe-statics

=== Cut ===
extern "C" void abort(void);

struct A
{
void *d;
};

static const A& staticA()
{
static A s_static;
return s_static;
}

void assert_failed()
{
abort();
}

A testMethod()
{
static const A& s = staticA( );
if (&s == 0)
assert_failed();
return s;
}

int main()
{
testMethod();
return 0;
}

// g++ -O2 -fno-inline -fno-threadsafe-statics -o kglobaltest kglobaltest.cpp
=== Cut ===

The testcase was extracted from a KDE miscompilation. -fno-schedule-insns2
seems to work around it. 

the bug is visible in assembler:

·   call·   _Z7staticAv·#
·   movl·   _ZZ10testMethodvE1s, %ebx·  # s, s.1
·   movb·   $1, _ZGVZ10testMethodvE1s·  #,
·   testl·  %ebx, %ebx· # s.1
·   movl·   %eax, _ZZ10testMethodvE1s·  # tmp61, s

the movl %eax,_ZZ10testMethodvE1s is moved below the movl·  
_ZZ10testMethodvE1s, %ebx, which causes the bug.


-- 
   Summary: miscompilation with -fschedule-insns2 -fthreadsafe-
statics and static variables
   Product: gcc
   Version: 4.1.3
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mueller at gcc dot gnu dot org
  GCC host triplet: i686-suse-linux


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

[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should

[pcarlini at suse dot de]

--- Comment #37 from pcarlini at suse dot de  2007-05-03 22:24 ---
By the way, would it be possible to have a look at the assembly of competitors?
I'm under the impression that a quick look would more than enough to understand
whether we are optimizing "enough"...


-- 


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

[Bug middle-end/31095] [4.3 Regression] ICE in expand_expr_real_1, at expr.c:8786

[pinskia at gcc dot gnu dot org]

--- Comment #7 from pinskia at gcc dot gnu dot org  2007-05-03 22:06 ---
*** Bug 31805 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||dfranke at gcc dot gnu dot
   ||org


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

[Bug fortran/31805] [4.3 only] regression of st_function.f90

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2007-05-03 22:06 ---


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


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug fortran/31805] New: [4.3 only] regression of st_function.f90

[dfranke at gcc dot gnu dot org]

Since May 1st, gfortran.fortran-torture/execute/st_function.f90 fails to
compile with optimization enabled.

$> gfortran-svn -g -O1 st_function.f90 && ./a.out
st_function.f90: In function 'MAIN__':
st_function.f90:63: internal compiler error: in expand_expr_real_1, at
expr.c:8833

(gdb) bt
#0  fancy_abort (file=0x86e2a6e "../../../gcc/gcc/expr.c", line=8833,
function=0x86e308e "expand_expr_real_1") at ../../../gcc/gcc/diagnostic.c:655
#1  0x0819a832 in expand_expr_real_1 (exp=0xb7d3c1f8, target=0x0,
tmode=VOIDmode, modifier=EXPAND_NORMAL, alt_rtl=0x0) at
../../../gcc/gcc/expr.c:8833
#2  0x081ab8df in expand_expr_real (exp=0xb7d3c1f8, target=0xb7c8e210,
tmode=VOIDmode, modifier=EXPAND_NORMAL, alt_rtl=0x0)
at ../../../gcc/gcc/expr.c:6795
#3  0x081abac4 in expand_expr (exp=0x1e, target=0xa, mode=3084108280,
modifier=EXPAND_NORMAL) at ../../../gcc/gcc/expr.h:504
#4  0x0819a9e0 in expand_expr_real_1 (exp=0xb7d3d180, target=, tmode=VOIDmode, modifier=EXPAND_NORMAL, alt_rtl=0x0)
at ../../../gcc/gcc/expr.c:6902
#5  0x081ab8df in expand_expr_real (exp=0xb7d3d180, target=0xb7c8e210,
tmode=VOIDmode, modifier=EXPAND_NORMAL, alt_rtl=0x0)
at ../../../gcc/gcc/expr.c:6795
#6  0x081116bc in expand_builtin_memmove_args (dest=,
src=, len=, type=0xb7c999b4,
target=0xb7c8e210, mode=VOIDmode, ignore=) at
../../../gcc/gcc/expr.h:504
#7  0x081118e2 in expand_builtin_memmove (exp=0xb7d127ec, target=0xb7c8e210,
mode=VOIDmode, ignore=1) at ../../../gcc/gcc/builtins.c:3453
#8  0x08127bef in expand_builtin (exp=0xb7d127ec, target=0xb7c8e210,
subtarget=0x0, mode=VOIDmode, ignore=1) at ../../../gcc/gcc/builtins.c:6313
#9  0x081a1393 in expand_expr_real_1 (exp=0xb7d127ec, target=0x0,
tmode=VOIDmode, modifier=EXPAND_NORMAL, alt_rtl=0x0) at
../../../gcc/gcc/expr.c:7787
#10 0x081aba4d in expand_expr_real (exp=0xb7d127ec, target=0xb7c8e210,
tmode=VOIDmode, modifier=EXPAND_NORMAL, alt_rtl=0x0)
at ../../../gcc/gcc/expr.c:6789
#11 0x082e818c in expand_expr_stmt (exp=0xb7d127ec) at
../../../gcc/gcc/expr.h:504
#12 0x085df12f in expand_gimple_basic_block (bb=0xb7d37474) at
../../../gcc/gcc/cfgexpand.c:1615
#13 0x085e0144 in tree_expand_cfg () at ../../../gcc/gcc/cfgexpand.c:1922
#14 0x0827cfd3 in execute_one_pass (pass=0x87aca60) at
../../../gcc/gcc/passes.c:1058
#15 0x0827d1af in execute_pass_list (pass=0x87aca60) at
../../../gcc/gcc/passes.c:1110
#16 0x0835a89c in tree_rest_of_compilation (fndecl=0xb7cf7c80) at
../../../gcc/gcc/tree-optimize.c:406
#17 0x084b1e50 in cgraph_expand_function (node=0xb7cff300) at
../../../gcc/gcc/cgraphunit.c:1016
#18 0x084b4360 in cgraph_optimize () at ../../../gcc/gcc/cgraphunit.c:1085
#19 0x080ad9fc in gfc_be_parse_file (set_yydebug=0) at
../../../gcc/gcc/fortran/f95-lang.c:309
#20 0x082fc738 in toplev_main (argc=4, argv=0xbfbf3674) at
../../../gcc/gcc/toplev.c:1051
#21 0x080f091f in main (argc=65588, argv=0x0) at ../../../gcc/gcc/main.c:35


The regression first shows up here (i686-pc-linux-gnu):
http://gcc.gnu.org/ml/gcc-testresults/2007-05/msg00052.html

The last message without regression (i686-pc-linux-gnu):
http://gcc.gnu.org/ml/gcc-testresults/2007-05/msg00042.html


-- 
   Summary: [4.3 only] regression of st_function.f90
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dfranke at gcc dot gnu dot org


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

[Bug c/31804] gcc segfaults on very long pointer chains

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2007-05-03 22:02 ---
you must be kidding.


-- 

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=31804

[Bug target/31801] [dataflow] undefined reference to `gen_blockage'

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2007-05-03 22:00 ---
(In reply to comment #2)
>  there's no mention of "blockage" in the trunk documentation.
HUH?

@cindex @code{blockage} instruction pattern
@item @samp{blockage}

This pattern defines a pseudo insn that prevents the instruction
scheduler from moving instructions across the boundary defined by the
blockage insn.  Normally an UNSPEC_VOLATILE pattern.


Which was added by:
http://gcc.gnu.org/ml/gcc-patches/2007-01/msg02304.html

See also: http://gcc.gnu.org/ml/gcc-patches/2007-02/msg00147.html
Which talks about this change.


-- 


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

[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should

[rguenth at gcc dot gnu dot org]

--- Comment #36 from rguenth at gcc dot gnu dot org  2007-05-03 21:59 
---
Well, the patch in comment #33 really does what I did with the patch to
libstdc++.
If we take the first patch (from comment #29) and change its effects on the
alias machinery so that for

  q = ALIAS_CONVERT_EXPR (p)

we have two VDEFs on qs and ps alias tags like

  # SMT.1_2 = VDEF 
  # SMT.2_2 = VDEF 
  q = ALIAS_CONVERT_EXPR (p)

(and optimize q = ALIAS_CONVERT_EXPR (p) to q = p if the types of q and p
are the same, as pinskia noted), then we are safe at the tree level (the
ALIAS_CONVERT_EXPR represents a load/store barrier for qs and pq type).

At expansion time we'd need to do the same, which would be emitting clobbers
for mem expressions representing dereferences of q/p.

I believe we cannot really do better here.


-- 


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

[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should

[pinskia at gcc dot gnu dot org]

--- Comment #35 from pinskia at gcc dot gnu dot org  2007-05-03 21:48 
---
(In reply to comment #34)
> "*intentionally* (emphasis mine) performs no other action".

There is no other action taken, it is just a barrior, not even really an action
in my mind.


-- 


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

[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should

[pcarlini at suse dot de]

--- Comment #34 from pcarlini at suse dot de  2007-05-03 21:45 ---
First blush, I'm not enthusiastic about this last proposal. Seems to me just a
concealed way to do what Richard suggested at the beginning of this thread. As
such, I'm still finding it, in spirit at least, against the letter of
18.4.1.3/1-3, according to which placement new returns the ptr, and
"*intentionally* (emphasis mine) performs no other action".


-- 


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

[Bug middle-end/31802] SSE2 performance is deteriorating when __m128 is placed in union

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2007-05-03 21:44 ---
This is because the union does not get the correct mode (it gets BLK or TImode)
so GCC stores the union to the stack all the time.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org
   Severity|normal  |enhancement
  Component|c++ |middle-end


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

[Bug c/31804] New: gcc segfaults on very long pointer chains

[rwxr-xr-x at gmx dot de]

$ perl -wle 'print "int", "*" x 99, "p;"' >try.c && gcc try.c
gcc: Internal error: Segmentation fault (program cc1)
...

$ gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-4.1.1-r3/work/gcc-4.1.1/configure --prefix=/usr
--bindir=/usr/i686-pc-linux-gnu/gcc-bin/4.1.1
--includedir=/usr/lib/gcc/i686-pc-linux-gnu/4.1.1/include
--datadir=/usr/share/gcc-data/i686-pc-linux-gnu/4.1.1
--mandir=/usr/share/gcc-data/i686-pc-linux-gnu/4.1.1/man
--infodir=/usr/share/gcc-data/i686-pc-linux-gnu/4.1.1/info
--with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/4.1.1/include/g++-v4
--host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --disable-altivec
--enable-nls --without-included-gettext --with-system-zlib --disable-checking
--disable-werror --enable-secureplt --disable-libunwind-exceptions
--disable-multilib --disable-libmudflap --disable-libssp --enable-java-awt=gtk
--enable-languages=c,c++,java,fortran --enable-shared --enable-threads=posix
--enable-__cxa_atexit --enable-clocale=gnu
Thread model: posix
gcc version 4.1.1 (Gentoo 4.1.1-r3)

gcc-4.3-20070427 seems to have the same problem.
3.4.6 works fine, but after increasing the number of *'s to  it says:
cc1: out of memory allocating 1677721600 bytes after a total of 845819904 bytes

So this problem seems to be new in gcc4.


-- 
   Summary: gcc segfaults on very long pointer chains
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rwxr-xr-x at gmx dot de


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

[Bug fortran/25071] dummy argument larger than actual argument

[patchapp at dberlin dot org]

--- Comment #3 from patchapp at dberlin dot org  2007-05-03 20:50 ---
Subject: Bug number PR25071

A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-05/msg00186.html


-- 


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

[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should

[ian at airs dot com]

--- Comment #33 from ian at airs dot com  2007-05-03 20:33 ---
Created an attachment (id=13504)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13504&action=view)
Patch

Here is a much simpler patch which also fixes the problem.  This simply inserts
a memory clobber before each placement new.  This is safe, but is not as
efficient as possible.  How much do we care about optimizing placement new? 
How often is placement new used in a way which we could in practice optimize
anyhow?

For the test case in this PR, the penalty is pretty severe: gcc can no longer
eliminate the loop.  But this code is obviously artificial in that the loop
serves no purpose.


-- 


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

[Bug c/31537] duplicate weakref emitted with IMA

[geoffk at gcc dot gnu dot org]

--- Comment #4 from geoffk at gcc dot gnu dot org  2007-05-03 20:14 ---
The following testcase should be equivalent to the original one but not involve
IMA:

void f1()
{ 
  static __gthrw_pthread_once __attribute__ ((__weakref__ ("pthread_once")));
}
void f2()
{ 
  static __gthrw_pthread_once __attribute__ ((__weakref__ ("pthread_once")));
}


-- 


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

[Bug ada/31800] ACATS c46051a fails

[ebotcazou at gcc dot gnu dot org]

--- Comment #1 from ebotcazou at gcc dot gnu dot org  2007-05-03 20:01 
---
Please try again, it may be spurious.


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug target/31801] [dataflow] undefined reference to `gen_blockage'

[dj at redhat dot com]

--- Comment #2 from dj at redhat dot com  2007-05-03 20:01 ---
Note that only 19 out of 33 target directories (trunk) even mention the word
"blockage" and there's no mention of "blockage" in the trunk documentation.


-- 


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

[Bug ada/31669] GNAT blows up during compilation

[ludovic at ludovic-brenta dot org]

--- Comment #1 from ludovic at ludovic-brenta dot org  2007-05-03 19:47 
---
Please specify how you invoked the compiler, and understand that you need
gnatdist for distributed programs.  gnatdist is part of GLADE which is separate
from GNAT.


-- 


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

[Bug ada/30618] [4.1 regression] Infinite loop in sem_ch8.end_use_clauses

[ludovic at ludovic-brenta dot org]

--- Comment #3 from ludovic at ludovic-brenta dot org  2007-05-03 19:45 
---
Since when are regressions priority P5? I understand Ada is never
release-critical (what a shame) but P2 would be appropriate.


-- 


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

[Bug fortran/31803] ICE when for character pointer => target(range)

[burnus at gcc dot gnu dot org]

--- Comment #1 from burnus at gcc dot gnu dot org  2007-05-03 19:43 ---
==11966== Invalid read of size 8
==11966==at 0x41BF0C: gfc_check_pointer_assign (expr.c:2555)
==11966==by 0x4519D0: resolve_code (resolve.c:5225)
==11966==by 0x452D3D: resolve_codes (resolve.c:7386)

Better test case:
---
  character (len = 7), target :: textt
  character (len = 7), pointer :: textp
  character (len = 5), pointer :: textp2
  textp => textt
  textp2 => textt(1:5)
  if(len(textp)  /= 7) call abort()
  if(len(textp2) /= 5) call abort()
  textp  = 'aaa'
  textp2 = 'bbb'
  if(textp  /= 'baa') call abort()
  if(textp2 /= 'b') call abort()
end


-- 


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

[Bug fortran/31803] New: ICE when for character pointer => target(range)

[burnus at gcc dot gnu dot org]

character (len = 70), target :: textt
  character (len = 70), pointer :: textp
  character (len = 50), pointer :: textp2

  a = 42
  textp => textt
  textp2 => textt(1:50)
end


-- 
   Summary: ICE when for character  pointer => target(range)
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org


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

[Bug target/31733] [4.3 Regression] ICE in rtl_verify_flow_info, at cfgrtl.c:2050: {return_internal} (nil)

[sje at cup dot hp dot com]

--- Comment #8 from sje at cup dot hp dot com  2007-05-03 19:36 ---
I went back to r124216 and added a print to see what the next instruction was,
since it wasn't a barrier.  What I found was a "NOTE_INSN_DELETED_LABEL",
followed by a barrier.  I am guessing we want to ignore that (and any other
deleted instructions?) before checking for a barrier.


-- 


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

[Bug c++/31802] New: SSE2 performance is deteriorating when __m128 is placed in union

[yuri at tsoft dot com]

When I compile the following testcase with '-O3 -msse3' options it runs in 
22.562sec, without 'union' clause it runs in 0.280sec. And should be the same
time.

-- begin testcase --
typedef float __v2df __attribute__ ((__vector_size__ (16)));
typedef __v2df __m128;

static __inline __m128 _mm_sub_pd (__m128 __A, __m128 __B) { return
(__m128)__builtin_ia32_subps ((__v2df)__A, (__v2df)__B); }
static __inline __m128 _mm_add_pd (__m128 __A, __m128 __B) { return
(__m128)__builtin_ia32_addps ((__v2df)__A, (__v2df)__B); }
static __inline __m128 _mm_setr_ps (float __Z, float __Y, float __X, float __W)
{ return __extension__ (__m128)(__v2df){ __Z, __Y, __X, __W }; }

struct FF {
  union {__m128 d; float f[4];}; // problem
  // __m128 d; // no problem

  __inline FF() { }
  __inline FF(__m128 new_d) : d(new_d) { }
  __inline FF(float f) : d(_mm_setr_ps(f, f, f, f)) { }

  __inline FF operator+(FF other) { return (FF(_mm_add_pd(d,other.d))); }
  __inline FF operator-(FF other) { return (FF(_mm_sub_pd(d,other.d))); }
};

float f[1024*1024];

int main() {
  int i;

  for (i = 0; i < 1024*1024; i++) { f[i] = 1.f/(1024*1024 + 10 - i); }

  FF total(0.f);

  for (int rpt = 0; rpt < 1000; rpt++) {
  FF p1(0.f), p2(0.), c;

  __m128 *pf = (__m128*)f;
  for (i = 0; i < 1024*1024/4; i++) {
FF c(*pf++);

total = total + c - p2 + p1;

p1 = p2;
p2 = c;
  }
  }
}
-- end testcase

This bug has similar testcase as 25500 (that's fixed now). Only 'union' clause
was added.

Yuri


-- 
   Summary: SSE2 performance is deteriorating when __m128 is placed
in union
   Product: gcc
   Version: 4.1.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: yuri at tsoft dot com


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

[Bug ada/16086] Legal program rejected, procedure of protected object should be visible

[ludovic at ludovic-brenta dot org]

--- Comment #5 from ludovic at ludovic-brenta dot org  2007-05-03 19:27 
---
I disagree.  Per RM 9.5.1(1), "a protected subprogram IS a subprogram..."
(emphasis mine).  Furthermore, the last sentence of 12.6(9) says: "The view is
a function or procedure, never an entry".  Both of these sentences consistently
imply that protected procedures and functions are allowed as actuals for
generic formal subprograms.

GNAT must accept the sample program if it is to comply with the ARM.  If you
still disagree, please quote chapter and verse.


-- 

ludovic at ludovic-brenta dot org changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |


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

[Bug target/31801] [dataflow] undefined reference to `gen_blockage'

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2007-05-03 19:24 ---
This is all target issues, they should be including a pattern for blockage.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Component|middle-end  |target
 Ever Confirmed|0   |1
 GCC target triplet||avr-*, cris-*, h8300-*,
   ||m32c-*, v850-*
   Last reconfirmed|-00-00 00:00:00 |2007-05-03 19:24:01
   date||


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

[Bug ada/15606] Legal program rejected, RM 8.2(22)

[ludovic at ludovic-brenta dot org]

--- Comment #3 from ludovic at ludovic-brenta dot org  2007-05-03 19:15 
---
I disagree.  As highlighted at the beginning of this PR, per 8.2(2), the
instance becomes visibleonly _after_ its declaration, i.e. at the semicolon. 
Before the semicolon, the two "Foo"s are NOT ambiguous because only the generic
is in scope, not the instance. Disambiguation is NOT necessary per the ARM, and
the error message does NOT comply with the ARM.


-- 

ludovic at ludovic-brenta dot org changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |


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

[Bug middle-end/31801] New: [dataflow] undefined reference to `gen_blockage'

[mstein at phenix dot rootshell dot be]

Hello,
the targets avr, cris, h8300, m32c and v850 show the same error when build
in the dataflow-branch:

gcc   -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition
-Wmissing-format-attribute -fno-common   -DHAVE_CONFIG_H  -o cc1-dummy c-lang.o
stub-objc.o attribs.o c-errors.o c-lex.o c-pragma.o c-decl.o c-typeck.o
c-convert.o c-aux-info.o c-common.o c-opts.o c-format.o c-semantics.o
c-incpath.o
cppdefault.o c-ppoutput.o c-cppbuiltin.o prefix.o c-objc-common.o c-dump.o
c-pch.o c-parser.o  c-gimplify.o tree-mudflap.o c-pretty-print.o c-omp.o
dummy-checksum.o \
  main.o tree-browser.o libbackend.a ../libcpp/libcpp.a
../libdecnumber/libdecnumber.a ../libcpp/libcpp.a   ../libiberty/libiberty.a
../libdecnumber/libdecnumber.a -lmpfr -lgmp
libbackend.a(builtins.o): In function `expand_builtin_setjmp_receiver':
/n/07/mstein/svn/dataflow-branch/gcc/builtins.c:759: undefined reference to
`gen_blockage'
/n/07/mstein/svn/dataflow-branch/gcc/builtins.c:759: undefined reference to
`gen_blockage'
libbackend.a(stmt.o): In function `expand_label':
/n/07/mstein/svn/dataflow-branch/gcc/stmt.c:1841: undefined reference to
`gen_blockage'
collect2: ld returned 1 exit status


The SVN revision was 124360.


-- 
   Summary: [dataflow] undefined reference to `gen_blockage'
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mstein at phenix dot rootshell dot be


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

[Bug fortran/31399] Wrong code for do loop with large interation count

[patchapp at dberlin dot org]

--- Comment #3 from patchapp at dberlin dot org  2007-05-03 18:37 ---
Subject: Bug number PR31399

A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-05/msg00121.html


-- 


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

[Bug fortran/31630] [4.3 regression] ICE on nasty derived types code

[patchapp at dberlin dot org]

--- Comment #5 from patchapp at dberlin dot org  2007-05-03 18:37 ---
Subject: Bug number PR31630

A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-05/msg00116.html


-- 


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

[Bug target/31768] Invalid code or ICE for %z constraint

[ubizjak at gmail dot com]

--- Comment #4 from ubizjak at gmail dot com  2007-05-03 17:38 ---
(In reply to comment #3)
> Is there any chance of this problem being fixed in 4.1 and 4.2 as well? If so,
> should I open new bugs for those?

The %z modifier is IMO not intended for general use, so I don't think the
backport will be done. However, you could just use

out (unsigned port, T val)
{
asm volatile ("out %0, %w1" : : "a" (val), "Nd" (port));
}

(i.e. "out" insn without any decorations), and correct code will be generated.
At least recent binutils will handle all cases, including unsigned long on
x86_64.


-- 


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

[Bug rtl-optimization/31799] Failed to optimize out test instruction

[ubizjak at gmail dot com]

--- Comment #2 from ubizjak at gmail dot com  2007-05-03 17:22 ---
Ah, for some reason insn 13 does not have the insn link pointing to insn 10.
Probably dataflow should/could fix this?


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 CC||ubizjak at gmail dot com


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

[Bug rtl-optimization/31799] Failed to optimize out test instruction

[ubizjak at gmail dot com]

--- Comment #1 from ubizjak at gmail dot com  2007-05-03 17:08 ---
(In reply to comment #0)

> foo:
> addl$1, %edi
> testl   %edi, %edi
> movl%edi, (%rdx)
> je  .L3
> movl$1, (%rsi)
> .L3:
> rep ; ret

This is just an unfortunate corner case. During combine phase we get:

(insn 10 6 11 2 (parallel [
(set (reg/v:SI 58 [ x.27 ])
(plus:SI (reg/v:SI 59 [ x ])
(const_int 1 [0x1])))
(clobber (reg:CC 17 flags))
]) 210 {*addsi_1} (insn_list:REG_DEP_TRUE 3 (nil))
(expr_list:REG_DEAD (reg/v:SI 59 [ x ])
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil

(insn 11 10 13 2 (set (mem:SI (reg/v/f:DI 61 [ z ]) [2 S4 A32])
(reg/v:SI 58 [ x.27 ])) 40 {*movsi_1} (insn_list:REG_DEP_TRUE 5
(insn_list:REG_DEP_TRUE 10 (nil)))
(expr_list:REG_DEAD (reg/v/f:DI 61 [ z ])
(nil)))

(insn 13 11 14 2 (set (reg:CCZ 17 flags)
(compare:CCZ (reg/v:SI 58 [ x.27 ])
(const_int -1 [0x]))) 5 {*cmpsi_1_insn} (nil)
(expr_list:REG_DEAD (reg/v:SI 58 [ x.27 ])
(nil)))


It looks that insn 10 and insn 13 don't combine into flags setting insn due to
insn 11 interfering in some way. If the code is changed to:

void
foo (int x, int *y, int *z)
{
  if (++x != 0)
*y = 1;
  *z = x;
}

then gcc generates expected asm without test insn.


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

   Severity|normal  |enhancement
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-05-03 17:08:39
   date||


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

[Bug target/30243] avr-gcc 4.1.1: signbit() causes an internal compiler error

[eweddington at cso dot atmel dot com]

--- Comment #1 from eweddington at cso dot atmel dot com  2007-05-03 17:06 
---
Confirmed. Also fails for 4.1.2.


-- 

eweddington at cso dot atmel dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
  Known to fail|4.1.1   |4.1.1 4.1.2
   Last reconfirmed|-00-00 00:00:00 |2007-05-03 17:06:24
   date||


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

[Bug target/31644] [avr] can't find a register in class 'BASE_POINTER_REGS' while reloading 'asm'

[eweddington at cso dot atmel dot com]

--- Comment #2 from eweddington at cso dot atmel dot com  2007-05-03 16:56 
---
Confirmed on GCC 4.1.2.


-- 

eweddington at cso dot atmel dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
  Known to fail||4.1.1 4.1.2
   Last reconfirmed|-00-00 00:00:00 |2007-05-03 16:56:59
   date||


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

[Bug c/18624] GCC does not detect local variable set but never used

[pinskia at gcc dot gnu dot org]

--- Comment #9 from pinskia at gcc dot gnu dot org  2007-05-03 16:52 ---
*** Bug 31795 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||ghazi at gcc dot gnu dot org


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

[Bug middle-end/31795] -Wunused should warn about variables set but never read

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2007-05-03 16:52 ---


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


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug target/31786] error: unable to find a register to spill in class 'BASE_POINTER_REGS'

[eweddington at cso dot atmel dot com]

--- Comment #8 from eweddington at cso dot atmel dot com  2007-05-03 16:40 
---
Confirmed. Code snippet fails for 4.1.2 when compiling for -O2 and -O3. Note
that compiling with -O[0,1,s] is successful.

Changing target to all avr.


-- 

eweddington at cso dot atmel dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
 GCC target triplet|avr-rtems*  |avr-*-*
   Last reconfirmed|-00-00 00:00:00 |2007-05-03 16:40:04
   date||


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

[Bug target/31768] Invalid code or ICE for %z constraint

[us15 at os dot inf dot tu-dresden dot de]

--- Comment #3 from us15 at os dot inf dot tu-dresden dot de  2007-05-03 
16:22 ---
Is there any chance of this problem being fixed in 4.1 and 4.2 as well? If so,
should I open new bugs for those?


-- 


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

[Bug fortran/31251] Non-integer character length leads to segfault

[fxcoudert at gcc dot gnu dot org]

--- Comment #6 from fxcoudert at gcc dot gnu dot org  2007-05-03 15:49 
---
(In reply to comment #5)
> I am not able to reproduce a segfault. However, this patch eliminates the
> double error message.  Could someone verify that they still get a segfault
> without this patch and then try with the patch to see what happens.

It's weird. I have applied your patch and rebuilt but I still get the double
error, and the segfault:

pr31251.f90:1.16:

  character(len=2.3) :: s
   1
Error: Expression at (1) must be of INTEGER type
pr31251.f90:1.16:

  character(len=2.3) :: s
   1
Error: Expression at (1) must be of INTEGER type
==3668== 
==3668== Invalid read of size 4
==3668==at 0x86ED6F1: __gmpn_copyi (in
/home/fxcoudert/svn/debug2/irun/libexec/gcc/i686-pc-linux-gnu/4.3.0/f951)
==3668==  Address 0x2 is not stack'd, malloc'd or (recently) free'd
pr31251.f90:0: internal compiler error: Segmentation fault


I don't know what the heck is happening here, but I'll try to understand it
better in the next few days.


-- 


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

[Bug ada/31800] New: ACATS c46051a fails

[anhvofrcaus at gmail dot com]

test -d testsuite/ada/acats || mkdir -p testsuite/ada/acats
testdir=`cd ../../gcc-4.2.0-20070501/gcc/testsuite/ada/acats; ${PWDCMD-pwd}`;\
export testdir; cd testsuite/ada/acats; /bin/sh ${testdir}/run_acats
=== acats configuration ===
target gcc is /home/voax/build-4.2.0/gcc/xgcc -B/home/voax/build-4.2.0/gcc/
Reading specs from /home/voax/build-4.2.0/gcc/specs Target:
i686-pc-linux-gnuConfigured with: ../gcc-4.2.0-20070501/configure
--enable-languages=ada,c++ Thread model: posix gcc version 4.2.0 20070501
(prerelease)
host=i386-redhat-linux
target=i686-pc-linux-gnu
gnatmake is /home/voax/build-4.2.0/gcc/gnatmake

=== acats support ===
Generating support files... done.
Compiling support files... done.

=== acats tests ===
Running chapter a ...
Running chapter c2 ...
Running chapter c3 ...
FAIL:   c380004
Running chapter c4 ...
FAIL:   c46051a
Running chapter c5 ...
Running chapter c6 ...
Running chapter c7 ...
Running chapter c8 ...
Running chapter c9 ...
Running chapter ca ...
Running chapter cb ...
Running chapter cc ...
Running chapter cd ...
Running chapter ce ...
Running chapter cxa ...
Running chapter cxb ...
Running chapter cxf ...
Running chapter cxg ...
Running chapter cxh ...
Running chapter cz ...
Running chapter d ...
Running chapter e ...
Running chapter gcc ...
Running chapter l ...
=== acats Summary ===
# of expected passes2313
# of unexpected failures2
*** FAILURES: c380004 c46051a


-- 
   Summary: ACATS c46051a fails
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: anhvofrcaus at gmail dot com
  GCC host triplet: Red Hat 10.0 Running on i386
GCC target triplet: Red Hat 10.0 Running on i386


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

[Bug target/31768] Invalid code or ICE for %z constraint

[ubizjak at gmail dot com]

--- Comment #2 from ubizjak at gmail dot com  2007-05-03 15:41 ---
(In reply to comment #0)

> unsigned long c;

Fixed in mainline. But don't use long types on "out" insn, as you will generate
"outll" on x86_64.


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Component|inline-asm  |target
  Known to fail||4.1.2 4.2.0
 Resolution||FIXED
   Target Milestone|--- |4.3.0


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

[Bug inline-asm/31768] Invalid code or ICE for %z constraint

[uros at gcc dot gnu dot org]

--- Comment #1 from uros at gcc dot gnu dot org  2007-05-03 15:32 ---
Subject: Bug 31768

Author: uros
Date: Thu May  3 14:32:25 2007
New Revision: 124379

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124379
Log:
PR target/31768
* config/i386/i386.c (print_operand) ['z']: Output 'w' for
operands of size 2 when operand is not MEM_P.


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


-- 


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

[Bug rtl-optimization/31799] New: Failed to optimize out test instruction

[hjl at lucon dot org]

For

void
foo (int x, int *y, int *z)
{
  *z = ++x;
  if (x != 0)
  *y = 1;
}

gcc 4.3 generates

foo:
.LFB2:
addl$1, %edi
testl   %edi, %edi
movl%edi, (%rdx)
je  .L3
movl$1, (%rsi)
.L3:
rep ; ret

But "testl   %edi, %edi" isn't needed since "addl$1, %edi" sets proper
FLAGS_REG.


-- 
   Summary: Failed to optimize out test instruction
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl at lucon dot org
GCC target triplet: x86_64-unknown-linux-gnu


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

[Bug target/31786] error: unable to find a register to spill in class 'BASE_POINTER_REGS'

[ralf_corsepius at rtems dot org]

--- Comment #7 from ralf_corsepius at rtems dot org  2007-05-03 15:20 
---
FYI: Vanilla gcc-4.1.2 without newlib also exposes this issue with the code
fragment from comment #6:

./avr-gcc -o tmp.o -c init.c -O2
init.c: In function 'init_array':
init.c:12: error: unable to find a register to spill in class
'BASE_POINTER_REGS'
init.c:12: error: this is the insn:
(insn 61 30 31 2 (set (mem/c:HI (plus:HI (reg/f:HI 28 r28)
(const_int 1 [0x1])) [4 S2 A8])
(reg:HI 24 r24)) 12 {*movhi} (nil)
(nil))
init.c:12: confused by earlier errors, bailing out


-- 

ralf_corsepius at rtems dot org changed:

   What|Removed |Added

  Known to fail|4.2.0   |4.1.2 4.2.0


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

[Bug tree-optimization/30565] ICE with -O1 -ftree-pre -ftree-loop-linear

[rakdver at gcc dot gnu dot org]

--- Comment #5 from rakdver at gcc dot gnu dot org  2007-05-03 14:27 ---
Subject: Bug 30565

Author: rakdver
Date: Thu May  3 13:27:26 2007
New Revision: 124378

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124378
Log:
PR tree-optimization/30565
* lambda-code.c (perfect_nestify): Fix updating of dominators.

* gcc.dg/tree-ssa/loop-27.c: New test.


Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/loop-27.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/lambda-code.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug middle-end/31699] [4.3 Regression] -march=opteron -ftree-vectorize generates wrong code

[burnus at gcc dot gnu dot org]

--- Comment #9 from burnus at gcc dot gnu dot org  2007-05-03 14:18 ---
As the fix has been checked in and it works (at least here ;-), mark as FIXED.


-- 

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=31699

[Bug middle-end/31699] [4.3 Regression] -march=opteron -ftree-vectorize generates wrong code

[burnus at gcc dot gnu dot org]

--- Comment #8 from burnus at gcc dot gnu dot org  2007-05-03 14:16 ---
*** Bug 31697 has been marked as a duplicate of this bug. ***


-- 


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

[Bug middle-end/31697] [4.3 Regression] Crash of gen. prog. when using -funroll-loops -march=opteron

[burnus at gcc dot gnu dot org]

--- Comment #7 from burnus at gcc dot gnu dot org  2007-05-03 14:16 ---
Mark as duplicate as the fix in PR 31699 fixes this bug.

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


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug target/31733] [4.3 Regression] ICE in rtl_verify_flow_info, at cfgrtl.c:2050: {return_internal} (nil)

[tbm at cyrius dot com]

--- Comment #7 from tbm at cyrius dot com  2007-05-03 14:12 ---
It's hard to say when this was introduced.  The problem is that starting with
r123363, gcc won't accept this preprocessed code.  I used preprocessed code
generated by 4.3 20070326 to test older revisions, but there the bug doesn't
show up.  With r123366, the first revision that accepts the preprocessed code
from 20070422, I can see the ICE.


-- 


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

[Bug target/31786] error: unable to find a register to spill in class 'BASE_POINTER_REGS'

[ralf_corsepius at rtems dot org]

--- Comment #6 from ralf_corsepius at rtems dot org  2007-05-03 14:07 
---
This is the minimised *.c having been extracted from newlib's file exposing the
bug:
-- snip --
extern void (*array_start []) (void);
extern void (*array_end []) (void);

void
init_array (void)
{
  int count;
  int i;
  count = array_end - array_start;
  for (i = 0; i < count; i++)
array_start[i] ();
}
-- snip --

Pretty trivial code, isn't it?


-- 


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

[Bug middle-end/31699] [4.3 Regression] -march=opteron -ftree-vectorize generates wrong code

[dorit at gcc dot gnu dot org]

--- Comment #7 from dorit at gcc dot gnu dot org  2007-05-03 13:55 ---
Subject: Bug 31699

Author: dorit
Date: Thu May  3 12:54:45 2007
New Revision: 124375

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124375
Log:
PR tree-optimization/31699
* tree-vect-analyze.c (vect_update_misalignment_for_peel): Remove wrong
code.
(vect_enhance_data_refs_alignment): Compute peel amount using
TYPE_VECTOR_SUBPARTS instead of vf.
* tree-vect-transform.c (vect_gen_niters_for_prolog_loop): Likewise.


Added:
trunk/gcc/testsuite/gcc.dg/vect/pr31699.c
trunk/gcc/testsuite/gcc.dg/vect/vect-multitypes-11.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/vect/vect-floatint-conversion-1.c
trunk/gcc/testsuite/gcc.dg/vect/vect-intfloat-conversion-1.c
trunk/gcc/testsuite/gcc.dg/vect/vect-iv-4.c
trunk/gcc/testsuite/gcc.dg/vect/vect-multitypes-1.c
trunk/gcc/testsuite/gcc.dg/vect/vect-multitypes-4.c
trunk/gcc/testsuite/lib/target-supports.exp
trunk/gcc/tree-vect-analyze.c
trunk/gcc/tree-vect-transform.c


-- 


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

[Bug target/31786] error: unable to find a register to spill in class 'BASE_POINTER_REGS'

[ralf dot corsepius at rtems dot org]

--- Comment #5 from ralf dot corsepius at rtems dot org  2007-05-03 13:12 
---
Subject: RE:  error: unable to find a register to spill
in class 'BASE_POINTER_REGS'

On Thu, 2007-05-03 at 06:05 -0600, Eric Weddington wrote:
>  
> > --- Comment #2 from ralf_corsepius at rtems dot org  
> > 2007-05-03 10:27 ---
> > I can also reproduce the bug with 4.2.0-20070501.
> > 
> > It also is related to optimization levels. Newlib is being 
> > compiled with -O2,
> > which triggers this breakdown. Using -O1 or -Os to build 
> > init.c lets the
> > breakdown vanish.
> > 
> > Eric, due to bugzilla's current brokenness, I am sending you 
> > the *.i on PM.
> 
> Hi Ralf,
> All public distros use avr-libc instead of newlib to build an AVR toolchain:
> 
> AFAIK, it is only RTEMS that attempts to use newlib. And because of this the
> only testing that is done is when you do it, so I'm not surprised that
> newlib is broken for the avr.
Though what you say is true, the file avr bombs out on is mere "c", i.e.
a bug in GCC.

Ralf


-- 


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

[Bug target/31786] error: unable to find a register to spill in class 'BASE_POINTER_REGS'

[eweddington at cso dot atmel dot com]

--- Comment #4 from eweddington at cso dot atmel dot com  2007-05-03 13:05 
---
Subject: RE:  error: unable to find a register to spill in
 class 'BASE_POINTER_REGS'



> --- Comment #2 from ralf_corsepius at rtems dot org  
> 2007-05-03 10:27 ---
> I can also reproduce the bug with 4.2.0-20070501.
> 
> It also is related to optimization levels. Newlib is being 
> compiled with -O2,
> which triggers this breakdown. Using -O1 or -Os to build 
> init.c lets the
> breakdown vanish.
> 
> Eric, due to bugzilla's current brokenness, I am sending you 
> the *.i on PM.

Hi Ralf,
All public distros use avr-libc instead of newlib to build an AVR toolchain:

AFAIK, it is only RTEMS that attempts to use newlib. And because of this the
only testing that is done is when you do it, so I'm not surprised that
newlib is broken for the avr.

Eric


-- 


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

[Bug c++/29365] Unnecessary anonymous namespace warnings

[aaronavay62 at aaronwl dot com]

--- Comment #20 from aaronavay62 at aaronwl dot com  2007-05-03 13:00 
---
It looks like this will not be backported to 4.2 as its not strictly a
regression.  See .  If you use
this sort of pimpl and anonymous namespaces or similar, and you want to use
-Werror, you'll need to patch your own sources for now.


-- 


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

[Bug ada/31744] Ada has way TOO MANY "may be used uninitialized" warnings.

[ebotcazou at gcc dot gnu dot org]

--- Comment #4 from ebotcazou at gcc dot gnu dot org  2007-05-03 12:44 
---
> I also did compile for my other platform (i686-pc-linux-gnu) and did not 
> notice
> if these warnings occurred when make was running.

They are only present on platforms that do not use DWARF-2 EH.


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu dot
   ||org


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

[Bug ada/31744] Ada has way TOO MANY "may be used uninitialized" warnings.

[charlet at gcc dot gnu dot org]

--- Comment #3 from charlet at gcc dot gnu dot org  2007-05-03 12:08 ---
Thanks for the feedback.

Closing this PR then.


-- 

charlet at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug middle-end/31795] -Wunused should warn about variables set but never read

[aldot at gcc dot gnu dot org]

--- Comment #1 from aldot at gcc dot gnu dot org  2007-05-03 11:16 ---
Maybe related to 30438, 18624

I started to do
Index: gcc/tree.h
===
--- gcc/tree.h  (revision 124373)
+++ gcc/tree.h  (working copy)
@@ -364,7 +364,7 @@ struct tree_common GTY(())
   unsigned asm_written_flag: 1;
   unsigned nowarning_flag : 1;

-  unsigned used_flag : 1;
+  unsigned used_flag : 2;
   unsigned nothrow_flag : 1;
   unsigned static_flag : 1;
   unsigned public_flag : 1;
@@ -1175,6 +1175,7 @@ extern void omp_clause_range_check_faile
Nonzero in an expr node means inhibit warning if value is unused.
In IDENTIFIER_NODEs, this means that some extern decl for this name
was used.
+   1 denotes set but never used, 2 is actually used.
In a BLOCK, this means that the block contains variables that are used.  */
 #define TREE_USED(NODE) ((NODE)->common.used_flag)


It's a bit tricky to get this right for -O0 (-O1 and above is much easier) i
think.


-- 

aldot at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||aldot at gcc dot gnu dot org


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

[Bug target/31787] bfin: Dreg expected for CLI. Input text was P0.

[ralf_corsepius at rtems dot org]

--- Comment #2 from ralf_corsepius at rtems dot org  2007-05-03 10:47 
---
Created an attachment (id=13503)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13503&action=view)
*.i of the breakdown above


-- 


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

[Bug target/31797] powerpc: race

[ralf_corsepius at rtems dot org]

--- Comment #2 from ralf_corsepius at rtems dot org  2007-05-03 10:45 
---
Created an attachment (id=13502)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13502&action=view)
*.i of the breakdown above


-- 


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

[Bug target/31786] error: unable to find a register to spill in class 'BASE_POINTER_REGS'

[ralf_corsepius at rtems dot org]

--- Comment #3 from ralf_corsepius at rtems dot org  2007-05-03 10:43 
---
Created an attachment (id=13501)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13501&action=view)
*.i of the breakdown above


-- 


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

[Bug target/31786] error: unable to find a register to spill in class 'BASE_POINTER_REGS'

[ralf_corsepius at rtems dot org]

--- Comment #2 from ralf_corsepius at rtems dot org  2007-05-03 10:27 
---
I can also reproduce the bug with 4.2.0-20070501.

It also is related to optimization levels. Newlib is being compiled with -O2,
which triggers this breakdown. Using -O1 or -Os to build init.c lets the
breakdown vanish.

Eric, due to bugzilla's current brokenness, I am sending you the *.i on PM.


-- 

ralf_corsepius at rtems dot org changed:

   What|Removed |Added

  Known to fail||4.2.0
  Known to work||4.0.3


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

[Bug ada/31744] Ada has way TOO MANY "may be used uninitialized" warnings.

[rob1weld at aol dot com]

--- Comment #2 from rob1weld at aol dot com  2007-05-03 10:09 ---
Confirmed. My Linux system has gcc 4.2.0 installed and I do NOT get that many
warnings, only a couple.

I _do_ have the _newest_ possible version of all programs for Cygwin. 

In any event, on _any_ platform, it is actually gcc/xgcc that is used to
compile that portion of Ada that has the enormous number of warnings and not
/usr/bin/gcc.

My test results for i686-pc-linux-gnu are here (nearly no Ada errors):
http://gcc.gnu.org/ml/gcc-testresults/2007-05/msg00135.html


Previous results on the Cygwin platform for Ada had results like this:

gcc version 4.2.0 20070202 (prerelease) =-=
stage3-gcc/testsuite/ada/acats/acats.log

=== acats Summary ===
# of expected passes1937
# of unexpected failures22
# of unsupported tests  356
*** FAILURES: c23003b c23003g c23003i c35507m cd2a23e cdd2a02 cxg2002 cxg2003
cxg2004 cxg2006 cxg2007 cxg2010 cxg2011 cxg2012 cxg2013 cxg2015 cxg2016 cxg2017
cxg2018 cxg2019 cxg2020 cxg2021 


gcc version 4.2.0 20070427 (prerelease) =-=
stage3-gcc/testsuite/ada/acats/acats.log

=== acats Summary ===
# of expected passes1940
# of unexpected failures19
# of unsupported tests  356
*** FAILURES: c23003b c23003g c23003i cxg2002 cxg2003 cxg2004 cxg2006 cxg2007
cxg2010 cxg2011 cxg2012 cxg2013 cxg2015 cxg2016 cxg2017 cxg2018 cxg2019 cxg2020
cxg2021 

Simply searching http://gcc.gnu.org/ml/gcc-testresults/ for "i686-pc-cygwin"
should show that there are not quite as good results for Ada on that target.

If you want Ada to run on WinXP it will need to either work on Cygwin or MinGW.


-- 


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