[Bug rtl-optimization/33222] New: failing rtl iv analysis (maybe due to df)

[dorit at gcc dot gnu dot org]

In the testcase below, after the inner-loop gets completely unrolled, the
enclosing i-loop does not get unrolled because of failure to analyze the loop
iv, possibly due to a bug in df:

#define N 40
#define M 10
float in[N+M], coeff[M], out[N];
void fir (){
  int i,j,k;
  float diff;
  for (i = 0; i < N; i++) {
diff = 0;
for (j = 0; j < M; j++) {
  diff += in[j+i]*coeff[j];
}
out[i] = diff;
  }
}

Compiler options used:
/Develop/mainline-dn1/bin/gcc -O3 -maltivec -funroll-loops
vect-outer-fir2-kernel.c -S --param max-completely-peeled-insns=5000 --param
max-completely-peel-times=40 -fdump-tree-all -da -ftree-vectorize

(without -ftree-vectorize the i-loop does get unrolled).

Detailed description and discussion here: 
http://gcc.gnu.org/ml/gcc/2007-08/msg00482.html

Here are the relevant pieces from the RTL dump (at loop3_unroll):

bb2:
(insn 40 39 41 2 vect-outer-fir2-kernel.c:38 (set (reg:DI 187 [ ivtmp.59 ])
(mem/u/c:DI (plus:DI (reg:DI 2 2)
(const:DI (minus:DI (symbol_ref/u:DI ("*.LC4") [flags 0x2])
(symbol_ref:DI ("*.LCTOC1") [7 S8 A8])) 344
{*movdi_internal64} (expr_list:REG_EQUAL (symbol_ref:DI ("fir_out") [flags
0x80] )
(nil)))

...
(insn 289 288 68 2 (set (reg/f:DI 319)
(plus:DI (reg:DI 187 [ ivtmp.59 ])
(const_int 160 [0xa0]))) 80 {*adddi3_internal1} (expr_list:REG_DEAD
(reg:DI 2 2)
(expr_list:REG_EQUAL (const:DI (plus:DI (symbol_ref:DI ("fir_out")
[flags 0x80] )
(const_int 160 [0xa0])))
(nil
...

loop:
bb3 (loop-header):
...
(insn 255 254 256 3 vect-outer-fir2-kernel.c:47 (set (reg:DI 187 [ ivtmp.59 ])
(plus:DI (reg:DI 187 [ ivtmp.59 ])
(const_int 16 [0x10]))) 80 {*adddi3_internal1} (nil))
...
(insn 265 263 266 3 vect-outer-fir2-kernel.c:47 (set (reg:CC 316)
(compare:CC (reg:DI 187 [ ivtmp.59 ])
(reg/f:DI 319))) 459 {*cmpdi_internal1} (expr_list:REG_EQUAL
(compare:CC (reg:DI 187 [ ivtmp.59 ])
(const:DI (plus:DI (symbol_ref:DI ("fir_out") [flags 0x80]
)
(const_int 160 [0xa0]
(nil)))


Below is the output of df_ref_debug for adef in each iteration of the loop in
latch_dominating_def:

d40 reg 187 bb 3 insn 255 flag 0x0 type 0x0 loc 0xf7da4608(0xf7d9a4e0) chain {
}
d93 reg 187 bb 2 insn 40 flag 0x0 type 0x0 loc 0xf7d89cc8(0xf7d9a4e0) chain { }

For both the bitmap is set.


-- 
   Summary: failing rtl iv analysis (maybe due to df)
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dorit at gcc dot gnu dot org
 GCC build triplet: powerpc64-linux
  GCC host triplet: powerpc64-linux
GCC target triplet: powerpc64-linux


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

[Bug c/33219] Error in compiling when there is a function with a char parameter called before its declaration with inline parameters.

[andreagrassi at sogeasoft dot com]

-- 

andreagrassi at sogeasoft dot com changed:

   What|Removed |Added

   Severity|enhancement |major


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

[Bug middle-end/32758] [4.3 Regression] ecj1 hangs

[jakub at gcc dot gnu dot org]

--- Comment #19 from jakub at gcc dot gnu dot org  2007-08-29 08:07 ---
Binary search among the routines in java_raw_api.c with -fno-inline shows
the noclass testcase fails if either ffi_java_raw_call or
ffi_java_translate_args
is compiled with -O2 -fdce, if both are compiled with -O2 -fno-dce the testcase
succeeds.
The assembly diff for ffi_java_raw_call is fairly small:
--- /tmp/j4.s1  2007-08-29 10:05:43.0 +0200
+++ /tmp/j4.s2  2007-08-29 10:05:49.0 +0200
@@ -51,12 +51,6 @@ ffi_java_raw_call:
 # /tmp/j4.i:1008
.loc 1 1008 0
lwz 0,0(1)
-# /tmp/j4.i:1007
-   .loc 1 1007 0
-   mr 31,1
-.LCFI9:
-# /tmp/j4.i:1008
-   .loc 1 1008 0
lwz 9,4(3)
slwi 9,9,2
addi 9,9,30
@@ -150,10 +144,6 @@ ffi_java_raw_call:
.uleb128 0x2
.byte   0x9d # DW_CFA_offset, column 0x1d
.uleb128 0x3
-   .byte   0x4  # DW_CFA_advance_loc4
-   .4byte  .LCFI9-.LCFI8
-   .byte   0xd  # DW_CFA_def_cfa_register
-   .uleb128 0x1f
.align 2
 .LEFDE0:
 #NO_APP
@@ -207,10 +197,6 @@ ffi_java_raw_call:
.uleb128 0x2
.byte   0x9d # DW_CFA_offset, column 0x1d
.uleb128 0x3
-   .byte   0x4  # DW_CFA_advance_loc4
-   .4byte  .LCFI9-.LCFI8
-   .byte   0xd  # DW_CFA_def_cfa_register
-   .uleb128 0x1f
.align 2
 .LEFDE1:
 #NO_APP
@@ -224,14 +210,9 @@ ffi_java_raw_call:
.2byte  0x1  # Location expression size
.byte   0x51 # DW_OP_reg1
.4byte  .LCFI0-.Ltext0   # Location list begin address (*.LLST0)
-   .4byte  .LCFI9-.Ltext0   # Location list end address (*.LLST0)
-   .2byte  0x2  # Location expression size
-   .byte   0x71 # DW_OP_breg1
-   .sleb128 32
-   .4byte  .LCFI9-.Ltext0   # Location list begin address (*.LLST0)
.4byte  .LFE28-.Ltext0   # Location list end address (*.LLST0)
.2byte  0x2  # Location expression size
-   .byte   0x8f # DW_OP_breg31
+   .byte   0x71 # DW_OP_breg1
.sleb128 32
.4byte  0x0  # Location list terminator begin (*.LLST0)
.4byte  0x0  # Location list terminator end (*.LLST0)

Investigating (though my guess is this is caused by dataflow).


-- 


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

[Bug libfortran/33223] New: libfortran / floating point output broken?

[jpr at csc dot fi]

program t
  print*,huge(1.0d0),tiny(1.0d0)
end program t

gives the output

  1.797693134862316E+30^@  2.225073858507201E-30^@

with latest gfortran binary:

Target: i386-pc-linux-gnu
Configured with: /home/fx/gfortran_nightbuild/trunk/configure
--prefix=/home/fx/gfortran_nightbuild/irun-20070828
--enable-languages=c,fortran --build=i386-pc-linux-gnu
--enable-checking=release --with-gmp=/home/fx/gfortran_nightbuild/software
Thread model: posix
gcc version 4.3.0 20070828 (experimental) [trunk revision 127846] (GCC)

Maybe related to this thread:

http://gcc.gnu.org/ml/fortran/2007-08/msg00476.html

?

Regards, Juha


-- 
   Summary: libfortran / floating point output broken?
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libfortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jpr at csc dot fi


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

[Bug c/33219] Error in compiling when there is a function with a char parameter called before its declaration with inline parameters.

[pcarlini at suse dot de]

-- 

pcarlini at suse dot de changed:

   What|Removed |Added

   Severity|major   |normal


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

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

[Andrew Pinski]

On 29 Aug 2007 03:15:04 -, bangerth at dealii dot org
<[EMAIL PROTECTED]> wrote:
> It is a good question in itself whether pimpl_ has a type at all -- it's a
> pointer to an incomplete type in any case :-)

All types in C++ are exported (well except for anonymous namespace
types) including incomplete types.

So the following two TUs are invalid when combined together.
TU1:
extern struct a *b;
TU2:
extern struct c *b;

It does not matter in C++ if it is an incomplete type because the type
is based on the name rather than compatibility rules (like what is
done for C).

So again this warning is correct based on the One definition rule.

Thanks,
Andrew Pinski

[Bug middle-end/32758] [4.3 Regression] ecj1 hangs

[jakub at gcc dot gnu dot org]

--- Comment #20 from jakub at gcc dot gnu dot org  2007-08-29 08:52 ---
typedef struct {
  int abi;
  unsigned nargs;
  void **arg_types;
  void *rtype;
  unsigned bytes;
  unsigned flags;
} ffi_cif;

void ffi_java_raw_to_ptrarray (ffi_cif *cif, void *raw, void **args);
void ffi_java_rvalue_to_raw (ffi_cif *cif, void *rvalue);
void ffi_call(ffi_cif *cif, void (*fn)(), void *rvalue, void **avalue);

void ffi_java_raw_call (ffi_cif *cif, void (*fn)(), void *rvalue, void *raw)
{
  void **avalue = (void**) __builtin_alloca (cif->nargs * sizeof (void*));
  ffi_java_raw_to_ptrarray (cif, raw, avalue);
  ffi_call (cif, fn, rvalue, avalue);
  ffi_java_rvalue_to_raw (cif, rvalue);
}

-m32 -O2 -fexceptions -fno-dce vs. -m32 -O2 -fexceptions -fdce
shows the same difference.
The assignment of stack pointer to hard frame pointer is removed during
*.peephole2.  Although the hard frame pointer is never referenced directly
in the function, it is really necessary for proper unwind info, given
that the function uses alloca and stack pointer is decreased by some
non-constant
value.

Here is an executable testcase for inclusion in the testsuite.  Fails with both
ppc -m32 and -m64 at -O2 -fexceptions, doesn't fail with -O2 -fno-dce
-fexceptions.

/* HP-UX libunwind.so doesn't provide _UA_END_OF_STACK */
/* { dg-do run } */
/* { dg-options "-O2 -fexceptions" } */
/* { dg-skip-if "" { "ia64-*-hpux11.*" }  { "*" } { "" } } */
/* Verify unwind info in presence of alloca.  */

#include 
#include 
#include 

static _Unwind_Reason_Code
force_unwind_stop (int version, _Unwind_Action actions,
   _Unwind_Exception_Class exc_class,
   struct _Unwind_Exception *exc_obj,
   struct _Unwind_Context *context,
   void *stop_parameter)
{
  if (actions & _UA_END_OF_STACK)
abort ();
  return _URC_NO_REASON;
}

static void force_unwind (void)
{
  struct _Unwind_Exception *exc = malloc (sizeof (*exc));
  memset (&exc->exception_class, 0, sizeof (exc->exception_class));
  exc->exception_cleanup = 0;

#ifndef __USING_SJLJ_EXCEPTIONS__
  _Unwind_ForcedUnwind (exc, force_unwind_stop, 0);
#else
  _Unwind_SjLj_ForcedUnwind (exc, force_unwind_stop, 0);
#endif

  abort ();
}

__attribute__((noinline))
void foo (void *x __attribute__((unused)))
{
  force_unwind ();
}

__attribute__((noinline))
int bar (unsigned int x)
{
  void *y = __builtin_alloca (x);
  foo (y);
  return 1;
}

static void handler (void *p __attribute__((unused)))
{
  exit (0);
}

__attribute__((noinline))
static void doit ()
{
  char dummy __attribute__((cleanup (handler)));
  bar (1024);
}

int main ()
{
  doit ();
  abort ();
}


-- 


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

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

[pinskia at gmail dot com]

--- Comment #39 from pinskia at gmail dot com  2007-08-29 08:52 ---
Subject: Re:  Unnecessary anonymous namespace warnings

On 29 Aug 2007 03:15:04 -, bangerth at dealii dot org
<[EMAIL PROTECTED]> wrote:
> It is a good question in itself whether pimpl_ has a type at all -- it's a
> pointer to an incomplete type in any case :-)

All types in C++ are exported (well except for anonymous namespace
types) including incomplete types.

So the following two TUs are invalid when combined together.
TU1:
extern struct a *b;
TU2:
extern struct c *b;

It does not matter in C++ if it is an incomplete type because the type
is based on the name rather than compatibility rules (like what is
done for C).

So again this warning is correct based on the One definition rule.

Thanks,
Andrew Pinski


-- 


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

[Bug rtl-optimization/33224] New: failing rtl iv analysis (maybe due to df)

[dorit at gcc dot gnu dot org]

In the testcase below, after the inner-loop gets completely unrolled, the
enclosing i-loop does not get unrolled because of failure to analyze the loop
iv, possibly due to a bug in df:

#define N 40
#define M 10
float in[N+M], coeff[M], out[N];
void fir (){
  int i,j,k;
  float diff;
  for (i = 0; i < N; i++) {
diff = 0;
for (j = 0; j < M; j++) {
  diff += in[j+i]*coeff[j];
}
out[i] = diff;
  }
}

Compiler options used:
/Develop/mainline-dn1/bin/gcc -O3 -maltivec -funroll-loops
vect-outer-fir2-kernel.c -S --param max-completely-peeled-insns=5000 --param
max-completely-peel-times=40 -fdump-tree-all -da -ftree-vectorize

(without -ftree-vectorize the i-loop does get unrolled).

Detailed description and discussion here: 
http://gcc.gnu.org/ml/gcc/2007-08/msg00482.html

Here are the relevant pieces from the RTL dump (at loop3_unroll):

bb2:
(insn 40 39 41 2 vect-outer-fir2-kernel.c:38 (set (reg:DI 187 [ ivtmp.59 ])
(mem/u/c:DI (plus:DI (reg:DI 2 2)
(const:DI (minus:DI (symbol_ref/u:DI ("*.LC4") [flags 0x2])
(symbol_ref:DI ("*.LCTOC1") [7 S8 A8])) 344
{*movdi_internal64} (expr_list:REG_EQUAL (symbol_ref:DI ("fir_out") [flags
0x80] )
(nil)))

...
(insn 289 288 68 2 (set (reg/f:DI 319)
(plus:DI (reg:DI 187 [ ivtmp.59 ])
(const_int 160 [0xa0]))) 80 {*adddi3_internal1} (expr_list:REG_DEAD
(reg:DI 2 2)
(expr_list:REG_EQUAL (const:DI (plus:DI (symbol_ref:DI ("fir_out")
[flags 0x80] )
(const_int 160 [0xa0])))
(nil
...

loop:
bb3 (loop-header):
...
(insn 255 254 256 3 vect-outer-fir2-kernel.c:47 (set (reg:DI 187 [ ivtmp.59 ])
(plus:DI (reg:DI 187 [ ivtmp.59 ])
(const_int 16 [0x10]))) 80 {*adddi3_internal1} (nil))
...
(insn 265 263 266 3 vect-outer-fir2-kernel.c:47 (set (reg:CC 316)
(compare:CC (reg:DI 187 [ ivtmp.59 ])
(reg/f:DI 319))) 459 {*cmpdi_internal1} (expr_list:REG_EQUAL
(compare:CC (reg:DI 187 [ ivtmp.59 ])
(const:DI (plus:DI (symbol_ref:DI ("fir_out") [flags 0x80]
)
(const_int 160 [0xa0]
(nil)))


Below is the output of df_ref_debug for adef in each iteration of the loop in
latch_dominating_def:

d40 reg 187 bb 3 insn 255 flag 0x0 type 0x0 loc 0xf7da4608(0xf7d9a4e0) chain {
}
d93 reg 187 bb 2 insn 40 flag 0x0 type 0x0 loc 0xf7d89cc8(0xf7d9a4e0) chain { }

For both the bitmap is set.


-- 
   Summary: failing rtl iv analysis (maybe due to df)
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dorit at gcc dot gnu dot org
 GCC build triplet: powerpc64-linux
  GCC host triplet: powerpc64-linux
GCC target triplet: powerpc64-linux


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

[Bug rtl-optimization/33224] failing rtl iv analysis (maybe due to df)

[dorit at gcc dot gnu dot org]

--- Comment #1 from dorit at gcc dot gnu dot org  2007-08-29 09:04 ---
> In the testcase below, after the inner-loop gets completely unrolled, the
> enclosing i-loop does not get unrolled because of failure to analyze the loop
> iv, possibly due to a bug in df:
...
> Compiler options used:
> /Develop/mainline-dn1/bin/gcc -O3 -maltivec -funroll-loops
> vect-outer-fir2-kernel.c -S --param max-completely-peeled-insns=5000 --param
> max-completely-peel-times=40 -fdump-tree-all -da -ftree-vectorize
> (without -ftree-vectorize the i-loop does get unrolled).

(it could be ofcourse a result of something the vectorizer does. like, maybe
the vectorizer is not updating the dominance information correctly or
something. but I'd think most such information would be recomputed and verified
between vectorization and rtl unrolling? anyhow, verify_dominance seem to
pass).


-- 


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

[Bug rtl-optimization/33222] failing rtl iv analysis (maybe due to df)

[dorit at gcc dot gnu dot org]

--- Comment #1 from dorit at gcc dot gnu dot org  2007-08-29 09:08 ---
I accidentally entered this bug twice. I'm closing this one, and will use
PR33224 instead.


-- 

dorit at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug rtl-optimization/33224] failing rtl iv analysis (maybe due to df)

[dorit at gcc dot gnu dot org]

-- 

dorit at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |dorit at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-08-29 09:13:05
   date||


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

[Bug libfortran/33223] libfortran / floating point output broken?

[fxcoudert at gcc dot gnu dot org]

--- Comment #1 from fxcoudert at gcc dot gnu dot org  2007-08-29 09:42 
---
The patch was reversed, this should be fixed in next binaries.


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu dot
   ||org, fxcoudert at gcc dot
   ||gnu dot org


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

[Bug libfortran/33225] New: [4.3 regression] Missing last digit is some formatted output

[dominiq at lps dot ens dot fr]

With the patch in http://gcc.gnu.org/ml/fortran/2007-08/msg00476.html (revision
127846), some formatted output are missing the last digit on Darwin (see
http://gcc.gnu.org/ml/fortran/2007-08/msg00586.html):

! { dg-do run }
! PR32554 Bug in P formatting
! Test case from the bug reporter
program gfcbug66
  real(8) :: x = 1.0e-100_8
  character(50) :: outstr
  write (outstr,'(1X,2E12.3)')x, 2 * x
  print *, outstr
  if (outstr.ne."0.100E-99   0.200E-99") call abort
  ! Before patch 2 * x was put out wrong
  write (outstr,'(1X,1P,2E12.3)') x, 2 * x
  print *, outstr
  if (outstr.ne."1.000-100   2.000-100") call abort
end program gfcbug66

output

 0.100E-99   0.200E-99 
 1.000-10   2.000-10 
Abort

instead of

 0.100E-99   0.200E-99 
 1.000-100   2.000-100 

and

! { dg-do run }
! { dg-require-effective-target fortran_large_real }
! PR 24174 and PR 24305
program large_real_kind_form_io_1
  ! This should be 10 on systems that support kind=10
  integer, parameter :: k = selected_real_kind (precision (0.0_8) + 1)
  real(kind=k) :: a,b(2), c, eps
  complex(kind=k) :: d, e, f(2), g
  character(len=180) :: tmp
  ! Test real(k) scalar and array formatted IO
  eps = 10 * spacing (2.0_k) ! 10 ulp precision is enough.
  d = cmplx ( 1.0_k, 2.0_k, k)
  write (tmp, '(2(e12.4e5, 2x))') d
  print *, tmp
  read (tmp, '(2(e12.4e5, 2x))') e
  if (abs (e - d) > eps) call abort()
end program large_real_kind_form_io_1

outputs

 .1000E+  .2000E+   
At line 15 of file large_real_kind_form_io_1_red.f90
Fortran runtime error: Bad value during floating point read

instead of

 .1000E+1  .2000E+1 

Also the code

print *,  huge(1.0), -huge(1.0), huge(1.0d0), -huge(1.0d0)
print *,  nearest(huge(1.0),-1.0), nearest(-huge(1.0),1.0),
nearest(huge(1.0d0),-1.0d0), nearest(-huge(1.0d0),1.0d0)
print *,  nearest(huge(1.0),1.0), nearest(-huge(1.0),-1.0),
nearest(huge(1.0d0),1.0d0), nearest(-huge(1.0d0),-1.0d0)
end

gives

edit_real_1_red_3.f90:3.18:

print *,  nearest(huge(1.0),1.0), nearest(-huge(1.0),-1.0), nearest(huge(1.0d0)
 1
Error: Result of NEAREST overflows its kind at (1)
edit_real_1_red_3.f90:3.42:

print *,  nearest(huge(1.0),1.0), nearest(-huge(1.0),-1.0), nearest(huge(1.0d0)
 1
Error: Result of NEAREST overflows its kind at (1)
edit_real_1_red_3.f90:3.68:

print *,  nearest(huge(1.0),1.0), nearest(-huge(1.0),-1.0), nearest(huge(1.0d0)
   1
Error: Result of NEAREST overflows its kind at (1)
edit_real_1_red_3.f90:3.96:

e(1.0),1.0), nearest(-huge(1.0),-1.0), nearest(huge(1.0d0),1.0d0), nearest(-hug
  1 
Error: Result of NEAREST overflows its kind at (1)

I was expecting no errors and 

 3.4028235E+38 -3.4028235E+38 1.7976931348623157E+308 -1.7976931348623157E+308
 3.4028233E+38 -3.4028233E+38 1.7976931348623155E+308 -1.7976931348623155E+308
 +Inf -Inf +Inf -Inf

If I remove the offending line, the output is:

  3.4028235E+38 -3.4028235E+38  1.797693134862316E+30 -1.797693134862316E+30
  3.4028233E+38 -3.4028233E+38  1.797693134862316E+30 -1.797693134862316E+30

Due to this regression, the tests gfortran.dg/fmt_p_1.f90,
gfortran.dg/output_exponents_1.f90, and
gfortran.dg/large_real_kind_form_io_1.f90 fail on PPC Darwin.


-- 
   Summary: [4.3 regression] Missing last digit is some formatted
output
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libfortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dominiq at lps dot ens dot fr
GCC target triplet: powerpc-apple-darwin8


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

[Bug target/18251] unable to find a register to spill in class `POINTER_REGS'

[sdepagnier at avidyne dot com]

--- Comment #39 from sdepagnier at avidyne dot com  2007-08-29 10:00 ---
Created an attachment (id=14131)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14131&action=view)
another test case

This test case only has problems when gcc is invoked with the -ftree-pre flag
which is part of -O2 by default.


-- 


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

[Bug java/33218] Process.waiFor() Process.destroy() misbehave for childs which are not reacting to Ctrl+C SIGQUIT

[cyberflex at mail dot ru]

--- Comment #6 from cyberflex at mail dot ru  2007-08-29 10:16 ---
(In reply to comment #4)
> Created an attachment (id=14129)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14129&action=view) [edit]
> Test case that works.
> 
> With the new "Test case that works" and attached test.sh and the original
> test.sh I get no failures on x86_64-pc-linux  (FC6)  with: gcj (GCC) 4.3.0
> 20070728 (experimental) 
> 
> I am inclined to mark the bug as Works-for-me in a few days if it cannot be
> reproduced on the trunk.
> 
Ok, that's need more investigation.
I'll be working on my project again (choosing workaround) in a few days,
I'll investigate in more detail the situation when I see the issue at both
architectures.

I no mean to reproduce is found (till the middle of the next week) then the bug
may be reopened as a good testcase would be produced.

Thank you for looking through current code.
In GCJ 3.x.x we had a couple of troubles with zombie childs may be some
nonetrivial case is not swept pou yet.


-- 


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

[Bug c++/32113] [4.1/4.2/4.3 regression] ICE with invalid template parameter

[pcarlini at suse dot de]

-- 

pcarlini at suse dot de changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |pcarlini at suse dot de
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-08-29 10:19:41
   date||


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

[Bug middle-end/33199] [4.3 Regression] tr1/2_general_utilities/shared_ptr/assign/auto_ptr.cc

[rguenth at gcc dot gnu dot org]

--- Comment #19 from rguenth at gcc dot gnu dot org  2007-08-29 10:32 
---
MTAG_ALIASES of the SMTs are different:

SMT.469 no aliases
SMT.470 no aliases
SMT.464{ ctor_count ctor_count dtor_count SMT.465 SMT.470 }
SMT.465{ ctor_count ctor_count dtor_count SMT.470 }
SMT.466{ ctor_count ctor_count dtor_count SMT.469 }
SMT.468{ ctor_count ctor_count dtor_count SMT.469 SMT.470 }
SMT.467{ ctor_count ctor_count dtor_count }

SMT.464D.9338, UID D.9338, _Atomic_wordD.5734, is addressable, is global, is
volatile, direct reads: 0, direct writes: 9, indirect reads: 0, indirect
writes: 26, read frequency: 0, write frequency: 0, call clobbered (passed to
call, is global var), may aliases: { ctor_countD.7347 ctor_countD.7372
dtor_countD.7373 SMT.465D.9339 SMT.470D.9344 }
SMT.465D.9339, UID D.9339, struct _Sp_counted_baseD.6722, is addressable, is
global, direct reads: 34, direct writes: 3, indirect reads: 0, indirect writes:
35, read frequency: 0, write frequency: 401, call clobbered (stored in global,
passed to call, is global var), may aliases: { ctor_countD.7347
ctor_countD.7372 dtor_countD.7373 SMT.470D.9344 }
SMT.469D.9343, UID D.9343, struct AD.7343, is addressable, is global, direct
reads: 0, direct writes: 0, indirect reads: 2, indirect writes: 27, read
frequency: 7108, write frequency: 1, call clobbered (stored in global,
passed to call, is global var)
SMT.470D.9344, UID D.9344, struct _Sp_counted_base_implD.8267, is addressable,
is global, direct reads: 2, direct writes: 3, indirect reads: 34, indirect
writes: 38, read frequency: 47544, write frequency: 30401, call clobbered
(stored in global, passed to call, is global var)
SMT.466D.9340, UID D.9340, struct BD.7365, is addressable, is global, direct
reads: 2, direct writes: 1, indirect reads: 0, indirect writes: 26, read
frequency: 0, write frequency: 0, call clobbered (stored in global, passed to
call, is global var), may aliases: { ctor_countD.7347 ctor_countD.7372
dtor_countD.7373 SMT.469D.9343 }, belongs to partition: MPT.471D.9345
SMT.468D.9342, UID D.9342, , is addressable, is global, direct reads: 0, direct
writes: 0, indirect reads: 0, indirect writes: 26, read frequency: 0, write
frequency: 0, call clobbered (passed to call, is global var), may aliases: {
ctor_countD.7347 ctor_countD.7372 dtor_countD.7373 SMT.469D.9343 SMT.470D.9344
}, belongs to partition: MPT.471D.9345
SMT.467D.9341, UID D.9341, intD.2 (*__vtbl_ptr_typeD.1557) (void), is
addressable, is global, direct reads: 10, direct writes: 0, indirect reads: 0,
indirect writes: 26, read frequency: 0, write frequency: 0, call clobbered (is
global var), may aliases: { ctor_countD.7347 ctor_countD.7372 dtor_countD.7373
}, belongs to partition: MPT.471D.9345

vs.

SMT.464{ ctor_count ctor_count dtor_count SMT.465 SMT.466 }
SMT.465{ ctor_count ctor_count dtor_count SMT.466 }
SMT.466{ ctor_count ctor_count dtor_count }
SMT.467{ ctor_count ctor_count dtor_count }
SMT.468{ ctor_count ctor_count dtor_count SMT.469 SMT.470 }
SMT.469{ SMT.470 }
SMT.470 no aliases

SMT.464D.9522, UID D.9522, struct _Sp_counted_base_implD.8268, is addressable,
is global, direct reads: 2, direct writes: 3, indirect reads: 0, indirect
writes: 26, read frequency: 0, write frequency: 0, call clobbered (is global
var), may aliases: { ctor_countD.7348 ctor_countD.7373 dtor_countD.7374
SMT.465D.9523 SMT.466D.9524 }, belongs to partition: MPT.471D.9529
SMT.465D.9523, UID D.9523, struct _Sp_counted_baseD.6723, is addressable, is
global, direct reads: 34, direct writes: 3, indirect reads: 2, indirect writes:
29, read frequency: 2, write frequency: 3, call clobbered (stored in
global, passed to call, is global var), may aliases: { ctor_countD.7348
ctor_countD.7373 dtor_countD.7374 SMT.466D.9524 }
SMT.466D.9524, UID D.9524, _Atomic_wordD.5735, is addressable, is global, is
volatile, direct reads: 0, direct writes: 9, indirect reads: 36, indirect
writes: 32, read frequency: 67544, write frequency: 6, call clobbered
(stored in global, passed to call, is global var), may aliases: {
ctor_countD.7348 ctor_countD.7373 dtor_countD.7374 }
SMT.467D.9525, UID D.9525, intD.2 (*__vtbl_ptr_typeD.1558) (void), is
addressable, is global, direct reads: 10, direct writes: 0, indirect reads: 0,
indirect writes: 26, read frequency: 0, write frequency: 0, call clobbered (is
global var), may aliases: { ctor_countD.7348 ctor_countD.7373 dtor_countD.7374
}
SMT.468D.9526, UID D.9526, , is addressable, is global, direct reads: 0, direct
writes: 0, indirect reads: 0, indirect writes: 26, read frequency: 0, write
frequency: 0, call clobbered (passed to call, is global var), may aliases: {
ctor_countD.7348 ctor_countD.7373 dtor_countD.7374 SMT.470D.9528 MPT.471D.9529
}, belongs to partition: MPT.471D.9529
SMT.469D.9527, UID D.9527, struct BD.7366, is addressable, is global, direct
reads: 2, direct writes: 1, indirect reads: 0, indirect writes: 26, read
frequency: 0, write frequency: 0, call clobbered (stored in global, passed to
call, is 

[Bug c/33219] Error in compiling when there is a function with a char parameter called before its declaration with inline parameters.

[raeburn at raeburn dot org]

--- Comment #6 from raeburn at raeburn dot org  2007-08-29 11:12 ---
(In reply to comment #5)
> I don't understand the error !! It's all so simple and I don't understand
> why the compile works if I write in the second form (not inline parameter
> declaration) !!!

(This would be more suitable for the gcc-help list, btw...)

The bit about a type with default promotions refers to the fact that if there
isn't a prototype declaration (or a prototype style function definition) in
scope for the function, then integral arguments narrower than "int" get
"promoted" to "int" in the function signature, and that's how the argument gets
passed.  (And "float" would become "double" as well.)  Your second ("not
inline") version uses a non-prototype style definition, so the passed argument
type is in fact an "int".

In the first version of your code, the function is called with no declaration
in scope, so it's assumed that all argument types are the result of the default
promotions, and then you declare it as taking a "char" not promoted to "int",
which conflicts with the previous assumption.

(The use of a function without a prototype in scope also causes the compiler to
assume that it takes a fixed number of arguments, not a variable number of
arguments like printf; gcc knows that printf takes a variable number of
arguments, but warns you about it because according to the semantics of the C
language, your source file is still requiring that printf be a
non-variable-argument function.  While on many platforms that won't cause you
problems, on some it will; sometimes variable argument lists get passed
differently from fixed argument lists.)

I know it seems a bit odd; I think it's come to be this way mostly because of a
combination of factors in the standardization process, mainly trying to allow
really old C code (from before there was a language standard in 1989) to work
as it was, and to allow compilers to get good performance out of modern code
(using prototypes and such introduced with the 1989 standard).

In short, if you want to use non-promoted types in your argument lists, you
should make sure you've got prototypes in scope before the function gets
referenced.  Stick "int a(char);" at the top of the first version and it should
work fine.


-- 


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

[Bug middle-end/32758] [4.3 Regression] ecj1 hangs

[jakub at gcc dot gnu dot org]

--- Comment #21 from jakub at gcc dot gnu dot org  2007-08-29 11:18 ---
The major difference between say i?86 or x86_64 and ppc here is that
on the former two the hard frame pointer is actually visibly, not just
artificially, used when restoring the stack pointer.  ppc restores the
stack pointer from the memory value stwux instruction creates and so it
doesn't visibly use hard frame pointer.
While rest_of_handle_ud_dce calls mark_artificial_uses and that way marks
all the instructions that define the artificial registers.  On the other
side, dce_process_block from fast_dce will not mark the instructions that
define the artificial uses, instead or all the artificial register bits into
local_live bitmap.
31 (ppc hard frame pointer) is an artificial use, so dce_process_block
sets bit 31 in local_live during initialization (i.e. at the end of the basic
block).  But then goes through insns backwards and finds
(insn 50 49 51 2 l2.c:9 (set (reg/f:DI 31 31)
(mem/c:DI (plus:DI (reg/f:DI 1 1)
(const_int -8 [0xfff8])) [5 S8 A8])) -1 (nil))
which restores the saved hard frame pointer in the epilogue.  This definition
clears bit 31 from the local_live bitmap and as everything is one basic block,
there is nothing else which will prevent removing the hard frame pointer
initialization.

df_simulate_one_insn_forwards and df_simulate_one_insn_backwards
(why we have the former when nothing ever uses it?) both call
df_simulate_fixup_sets to fix this up, shouldn't dce_process_block call that
too?


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||dberlin at gcc dot gnu dot
   ||org, bonzini at gnu dot org
   Priority|P3  |P1


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

[Bug middle-end/32758] [4.3 Regression] ecj1 hangs

[jakub at gcc dot gnu dot org]

--- Comment #22 from jakub at gcc dot gnu dot org  2007-08-29 11:41 ---
Created an attachment (id=14132)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14132&action=view)
gcc43-pr32758.patch

Here is what I will try to regtest (already verified it fixes the testcase).
Alternatively, artificial_live could be a pointer bitmap which would just
point to one of the &df->*_block_artificial_uses bitmap, though not sure
if that ever could or in some register that wasn't originally set in
local_live.
Certainly calling df_has_eh_preds just once per bb rather than per insn is IMHO
worthwhile.


-- 

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


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

[Bug middle-end/29478] [4.2 Regression] optimization generates warning for casts

[tbm at cyrius dot com]

--- Comment #18 from tbm at cyrius dot com  2007-08-29 11:47 ---
(In reply to comment #17)
> Unassigning.

So you don't intend to fix this for 4.2?  I guess the patch you commited to
trunk
is too big for 4.2 but do you think there's some kind of workaround that could
be applied to 4.2?  This bug is quite annoying.


-- 


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

[Bug middle-end/32758] [4.3 Regression] ecj1 hangs

[paolo dot bonzini at lu dot unisi dot ch]

--- Comment #23 from paolo dot bonzini at lu dot unisi dot ch  2007-08-29 
11:47 ---
Subject: Re:  [4.3 Regression] ecj1 hangs


> df_simulate_one_insn_forwards and df_simulate_one_insn_backwards
> (why we have the former when nothing ever uses it?) both call
> df_simulate_fixup_sets to fix this up, shouldn't dce_process_block call that
> too?

Yes, it was probably an oversight of this patch:

2007-05-21  Kenneth Zadeck <[EMAIL PROTECTED]>

 * dbgcnt.def: Fixed comment.
 * df-scan.c (df_get_regular_block_artificial_uses): Added frame
 pointer after reload if frame_pointer_needed.
 * df.h (df_simulate_defs, df_simulate_uses): Made public.
 * df-problems.c (df_simulate_defs, df_simulate_uses): Made
public.
 * dce.c (deletable_insn_p): Only allow frame-related insns to be
 deleted if there is a REG_MAYBE_DEAD note.
 (dce_process_block): Now uses df_simulate_defs and
 df_simulate_uses.

It should be placed outside the if, i.e. you should always execute it. 
You can CC me when you send the patch to the mailing list (but I'll be 
out of office from tomorrow to sunday).


-- 


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

[Bug middle-end/33199] [4.3 Regression] tr1/2_general_utilities/shared_ptr/assign/auto_ptr.cc

[rguenth at gcc dot gnu dot org]

--- Comment #20 from rguenth at gcc dot gnu dot org  2007-08-29 11:58 
---
Due to the alias differences with -g compared to without -g we have the
following
difference after tree-level optimization:

--- -   2007-08-29 13:52:02.567822000 +0200
+++ b/auto_ptr.min.ii.116t.optimized2007-08-29 13:51:05.0 +0200
@@ -505,6 +505,7 @@ int test01() ()
   D.8890 = (struct _Sp_counted_base_impl *) D.8889;
   __d = __d.79;
   D.8891 = &D.8890->D.8307;
+  D.8890->D.8307._vptr._Sp_counted_base =
&_ZTVNSt3tr116_Sp_counted_baseILN9__gnu_cxx12_Lock_policyE1EEE[2];
   D.8890->D.8307._M_use_count = 1;
   D.8890->D.8307._M_weak_count = 1;
   D.8890->D.8307._vptr._Sp_counted_base =
&_ZTVNSt3tr121_Sp_counted_base_implIP1BNS_11_Sp_deleterIS1_EELN9__gnu_cxx12_Lock_policyE1EEE[2];
@@ -529,9 +530,9 @@ Invalid sum of incoming frequencies 8500
   goto ;

 :
-  D.8898 = D.8890->D.8307._M_use_count + 1;
-  *D.8895 ={v} D.8898;
   __result = D.8890->D.8307._M_use_count;
+  D.8898 = __result + 1;
+  *D.8895 ={v} D.8898;
   D.9413 = __result + -1;
   *D.8895 ={v} D.9413;
   goto ;

that is, we have one dead store removed by DSE and PRE removes one load of
_M_use_count:

 int test01() ()
 {
+  _Atomic_word prephitmp.476;
+  _Atomic_word pretmp.475;
   int storetmp.473;
   volatile _Atomic_word * __mem.22;
   _Atomic_word __result;
@@ -3806,9 +3836,11 @@ Invalid sum of incoming frequencies 8415
   goto ;

 :
+  pretmp.475_164 = D.8890_24->D.8307._M_use_count;

 :
-  __result_86 = D.8890_24->D.8307._M_use_count;
+  # prephitmp.476_144 = PHI 
+  __result_86 = prephitmp.476_144;
   D.9413_88 = __result_86 + -1;
   *D.8895_29 ={v} D.9413_88;

before PRE this looks like

:
Invalid sum of incoming frequencies 8500, should be 7225
  D.8895_29 = &D.8890_24->D.8307._M_use_count;
...

:
  # VUSE 
  D.8897_31 = D.8890_24->D.8307._M_use_count;
  D.8898_32 = D.8897_31 + 1;
  # ctor_count_373 = VDEF 
  # ctor_count_374 = VDEF 
  # dtor_count_375 = VDEF 
  *D.8895_29 ={v} D.8898_32;
  goto ;

...

:

:
  # MPT.471_203 = PHI 
  # SMT.470_61 = PHI 
  # SMT.467_59 = PHI 
  # SMT.466_58 = PHI 
  # SMT.465_54 = PHI 
  # dtor_count_53 = PHI 
  # ctor_count_52 = PHI 
  # ctor_count_48 = PHI 
  # VUSE 
  __result_86 = D.8890_24->D.8307._M_use_count;
  D.9413_88 = __result_86 + -1;
  # ctor_count_449 = VDEF 
  # ctor_count_450 = VDEF 
  # dtor_count_451 = VDEF 
  *D.8895_29 ={v} D.9413_88;


forwprop doesn't propagate the address expr &D.8890_24->D.8307._M_use_count
to the dereference because the dereference site has volatile ops.  But
you can see from  that we have wrong alias info there - the load
does not use the ctor_count and dtor_count syms and the store does not
def the two SMTs.


-- 


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

[Bug c++/33226] New: class name permitted in enum

[asteinarson at gmail dot com]

If an identifier given inside an enum is the same as an existing class
the compiler still accepts it:

<<< code <<<
class MyClass { };
MyClass g_my_class;  // An instance

enum { Mode1, MyClass };  // We could have error already here

MyClass g_my_class2;  // Compiler gives error here
<<< endcode <<<


For functions the desired behaviour is there:
<<< code <<<
int MyFunc() { return 0; }

enum { Mode1, MyFunc };  // Compiler objects here
<<< endcode <<<

Inside an enum it is very seldom the purpose to overwrite a class or template
in the global namespace. It is accidental, so an early error from the compiler
would be good.

Also template names can be overwritten inside enums.

Regards
Arne Steinarson


-- 
   Summary: class name permitted in enum
   Product: gcc
   Version: 4.1.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: asteinarson at gmail dot com
 GCC build triplet: Linux, Ubuntu 7.04
  GCC host triplet: Linux, Ubuntu 7.04
GCC target triplet: Linux, Ubuntu 7.04


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

[Bug middle-end/32758] [4.3 Regression] ecj1 hangs

[paolo dot bonzini at lu dot unisi dot ch]

--- Comment #24 from paolo dot bonzini at lu dot unisi dot ch  2007-08-29 
12:15 ---
Subject: Re:  [4.3 Regression] ecj1 hangs

> Here is what I will try to regtest (already verified it fixes the testcase).

This is wrong, because local_live changes during execution of 
dce_process_block.  The {eh,regular}_block_artificial_uses must always 
be set (they are live throughout, not just at the bottom of the basic 
block).

> Alternatively, artificial_live could be a pointer bitmap which would just
> point to one of the &df->*_block_artificial_uses bitmap, though not sure
> if that ever could or in some register that wasn't originally set in
> local_live.

Much better, and would have the same effect as dce_simulate_fixup_sets.

> Certainly calling df_has_eh_preds just once per bb rather than per insn is 
> IMHO
> worthwhile.

A patch to do so if preapproved if you add a comment saying

/* Calling df_simulate_fixup_sets has the disadvantage of calling
df_has_eh_preds once per insn, so we cache the information here.  */

before the place where you set artificial_live.

Thanks!


-- 


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

[Bug middle-end/33211] [4.3 Regression] FAIL: gcc.target/spu/fixed-range.c scan-assembler lqd.*21

[sandra at codesourcery dot com]

--- Comment #2 from sandra at codesourcery dot com  2007-08-29 12:19 ---
See patch and discussion here:

http://gcc.gnu.org/ml/gcc-patches/2007-08/msg02027.html


-- 


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

[Bug c++/33194] [4.3 Regression] ICE: canonical types differ for identical types void ()(const char*, ...) and void ()(const char*, ...)

[dgregor at gcc dot gnu dot org]

--- Comment #2 from dgregor at gcc dot gnu dot org  2007-08-29 12:25 ---
Subject: Bug 33194

Author: dgregor
Date: Wed Aug 29 12:25:01 2007
New Revision: 127896

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127896
Log:
2007-08-29  Douglas Gregor  <[EMAIL PROTECTED]>

PR c++/33194
* tree.c (build_type_attribute_qual_variant): Set canonical types
on the final, unqualified attribute variant before building the
qualified version.

2007-08-29  Douglas Gregor  <[EMAIL PROTECTED]>

PR c++/33194
* g++.dg/other/canon-33194.C: New.

Added:
trunk/gcc/testsuite/g++.dg/other/canon-33194.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree.c


-- 


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

[Bug c++/33194] [4.3 Regression] ICE: canonical types differ for identical types void ()(const char*, ...) and void ()(const char*, ...)

[dgregor at gcc dot gnu dot org]

--- Comment #3 from dgregor at gcc dot gnu dot org  2007-08-29 12:28 ---
Fixed on mailine


-- 

dgregor 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=33194

[Bug middle-end/29478] [4.2 Regression] optimization generates warning for casts

[rguenth at gcc dot gnu dot org]

--- Comment #19 from rguenth at gcc dot gnu dot org  2007-08-29 12:55 
---
Fixing of the trunk was a side-effect of some major re-structuring.  This won't
go on the branch for sure, no easy way to fix this another way either.


-- 


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

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

[Gabriel Dos Reis]

"Andrew Pinski" <[EMAIL PROTECTED]> writes:

| On 29 Aug 2007 03:15:04 -, bangerth at dealii dot org
| <[EMAIL PROTECTED]> wrote:
| > It is a good question in itself whether pimpl_ has a type at all -- it's a
| > pointer to an incomplete type in any case :-)
| 
| All types in C++ are exported (well except for anonymous namespace
| types) including incomplete types.

What does not could mean in C++?

-- Gaby

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

[gdr at cs dot tamu dot edu]

--- Comment #40 from gdr at cs dot tamu dot edu  2007-08-29 13:19 ---
Subject: Re:  Unnecessary anonymous namespace warnings

"Andrew Pinski" <[EMAIL PROTECTED]> writes:

| On 29 Aug 2007 03:15:04 -, bangerth at dealii dot org
| <[EMAIL PROTECTED]> wrote:
| > It is a good question in itself whether pimpl_ has a type at all -- it's a
| > pointer to an incomplete type in any case :-)
| 
| All types in C++ are exported (well except for anonymous namespace
| types) including incomplete types.

What does not could mean in C++?

-- Gaby


-- 


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

[Bug middle-end/32758] [4.3 Regression] ecj1 hangs

[jakub at gcc dot gnu dot org]

--- Comment #25 from jakub at gcc dot gnu dot org  2007-08-29 13:26 ---
Unfortunately it breaks e.g. memcpy-chk.c, simplified testcase here:
extern void abort (void);
typedef __SIZE_TYPE__ size_t;
extern void *memcpy (void *, const void *, size_t);
extern volatile int chk_fail_allowed;
extern void *chk_fail_buf[];
char *s2 = "defg";
char *s3 = "FGH";
size_t l1 = 1;
void
__attribute__((noinline))
test4 (void)
{
  struct A { char buf1[10]; char buf2[10]; } a;
  char buf3[20];

  chk_fail_allowed = 1;

  if (__builtin_setjmp (chk_fail_buf) == 0)
{
  __builtin___memcpy_chk (&a.buf2[9], s2, l1 + 1, __builtin_object_size
(&a.buf2[9], 0));
  abort ();
}
  if (__builtin_setjmp (chk_fail_buf) == 0)
{
  __builtin___memcpy_chk (&a.buf2[7], s3, strlen (s3) + 1,
__builtin_object_size (&a.buf2[7], 0));
  abort ();
}

  if (__builtin_setjmp (chk_fail_buf) == 0)
{
  __builtin___memcpy_chk (&buf3[19], "ab", 2, __builtin_object_size
(&buf3[19], 0));
  abort ();
}
  chk_fail_allowed = 0;
}

Not all basic blocks have all 4 x86_64 regular_block_artificial_regs registers
set in DF_LR_IN and so oring this in causes infinite loop, as process_dce_block
always returns something changed.


-- 


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

[Bug middle-end/19912] GCC does not disclose parentheses

[l_belev at yahoo dot com]

--- Comment #5 from l_belev at yahoo dot com  2007-08-29 13:35 ---
Tested this in 4.2.1 and int seems to be fixed (i.e. the compiler now does not
make difference between the 2 variants ot the code)
Thank you!


-- 

l_belev at yahoo dot com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED
Version|4.0.0   |4.2.1


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

[Bug fortran/33215] Bind(C): Bugs with empty "name=": Creates wrong result and accepts invalid

[burnus at gcc dot gnu dot org]

--- Comment #4 from burnus at gcc dot gnu dot org  2007-08-29 13:36 ---
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=33215

[Bug middle-end/32758] [4.3 Regression] ecj1 hangs

[jakub at gcc dot gnu dot org]

--- Comment #26 from jakub at gcc dot gnu dot org  2007-08-29 13:56 ---
Apparently dce is the only user of df_simulate_* which at the start of the
basic block compares the resulting bitmap with DF_LR_IN.  All other users
of these interfaces don't do that (ifcvt, rtl-factoring, peephole2).
And df-problems.c which computes DF_LR_IN doesn't or in the regular or eh
artificial uses bitmap in every step.
So, if fast dce is to keep comparing the local_live bitmap with DF_LR_IN
(and it probably needs to, since if some insns are marked to be deleted,
it needs to update it), local_live has to be computed the same way as it is
now.

So either we just check either local_live or au bitmaps:

--- dce.c.jj2007-08-13 15:11:18.0 +0200
+++ dce.c   2007-08-29 15:37:57.0 +0200
@@ -527,6 +527,7 @@ static bool
 dce_process_block (basic_block bb, bool redo_out)
 {
   bitmap local_live = BITMAP_ALLOC (&dce_tmp_bitmap_obstack);
+  bitmap au;
   rtx insn;
   bool block_changed;
   struct df_ref **def_rec, **use_rec;
@@ -569,6 +570,15 @@ dce_process_block (basic_block bb, bool 
bitmap_set_bit (local_live, DF_REF_REGNO (use));
 }

+  /* These regs are considered always live so if they end up dying
+ because of some def, we need to bring the back again.
+ Calling df_simulate_fixup_sets has the disadvantage of calling
+ df_has_eh_preds once per insn, so we cache the information here.  */
+  if (df_has_eh_preds (bb))
+au = df->eh_block_artificial_uses;
+  else
+au = df->regular_block_artificial_uses;
+
   FOR_BB_INSNS_REVERSE (bb, insn)
 if (INSN_P (insn))
   {
@@ -580,7 +590,8 @@ dce_process_block (basic_block bb, bool 

/* The insn is needed if there is someone who uses the output.  */
for (def_rec = DF_INSN_DEFS (insn); *def_rec; def_rec++)
- if (bitmap_bit_p (local_live, DF_REF_REGNO (*def_rec)))
+ if (bitmap_bit_p (local_live, DF_REF_REGNO (*def_rec))
+ || bitmap_bit_p (au, DF_REG_REGNO (*def_rec)))
{
  needed = true;
  break;

or add another bitmap:

--- dce.c.jj2007-08-13 15:11:18.0 +0200
+++ dce.c   2007-08-29 15:41:48.0 +0200
@@ -527,6 +527,8 @@ static bool
 dce_process_block (basic_block bb, bool redo_out)
 {
   bitmap local_live = BITMAP_ALLOC (&dce_tmp_bitmap_obstack);
+  bitmap local_live_or_au = BITMAP_ALLOC (&dce_tmp_bitmap_obstack);
+  bitmap au;
   rtx insn;
   bool block_changed;
   struct df_ref **def_rec, **use_rec;
@@ -569,6 +571,16 @@ dce_process_block (basic_block bb, bool 
bitmap_set_bit (local_live, DF_REF_REGNO (use));
 }

+  /* These regs are considered always live so if they end up dying
+ because of some def, we need to bring the back again.
+ Calling df_simulate_fixup_sets has the disadvantage of calling
+ df_has_eh_preds once per insn, so we cache the information here.  */
+  if (df_has_eh_preds (bb))
+au = df->eh_block_artificial_uses;
+  else
+au = df->regular_block_artificial_uses;
+  bitmap_ior (local_live_or_au, local_live, au);
+
   FOR_BB_INSNS_REVERSE (bb, insn)
 if (INSN_P (insn))
   {
@@ -580,7 +592,7 @@ dce_process_block (basic_block bb, bool 

/* The insn is needed if there is someone who uses the output.  */
for (def_rec = DF_INSN_DEFS (insn); *def_rec; def_rec++)
- if (bitmap_bit_p (local_live, DF_REF_REGNO (*def_rec)))
+ if (bitmap_bit_p (local_live_or_au, DF_REF_REGNO (*def_rec)))
{
  needed = true;
  break;
@@ -600,6 +612,7 @@ dce_process_block (basic_block bb, bool 
if (dump_file)
  fprintf (dump_file, "needed libcall %d\n", INSN_UID
(insn));
mark_libcall (insn, true);
+   BITMAP_FREE (local_live_or_au);
BITMAP_FREE (local_live);
return dce_process_block (bb, false);
  }
@@ -616,6 +629,8 @@ dce_process_block (basic_block bb, bool 
   anything in local_live.  */
if (marked_insn_p (insn))
  df_simulate_uses (insn, local_live);
+
+   bitmap_ior (local_live_or_au, local_live, au);
   }

   for (def_rec = df_get_artificial_defs (bb_index); *def_rec; def_rec++)
@@ -640,6 +655,7 @@ dce_process_block (basic_block bb, bool 
   if (block_changed)
 bitmap_copy (DF_LR_IN (bb), local_live);

+  BITMAP_FREE (local_live_or_au);
   BITMAP_FREE (local_live);
   return block_changed;
 }

The latter might be faster, but I'm not 100% sure about that.


-- 


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

[Bug c/33219] Error in compiling when there is a function with a char parameter called before its declaration with inline parameters.

[andreagrassi at sogeasoft dot com]

--- Comment #7 from andreagrassi at sogeasoft dot com  2007-08-29 13:56 
---
Subject: R:  Error in compiling when there is a function with a char parameter
called before its declaration with inline parameters.

Thank you so much for the speed, the kindness and the precision with which
you answered me
but I continue to think this is a gcc programmers mistake or , at least, it
shouldn't work so.

1. First, you spoke about an internal difference between the "inline" and
"not inline" definition, but
in my opinion this should be only a syntax difference and not a semanthics
one.
In other words my two codes should be only formally different but with the
same meaning.

2. Then, I understand that the compiler at the compile-time must understand
the type of a value
and so it promotes this value to the larger type it can include this value
but then it should be
able to re-cast the type to the new type in the definition if there is
compatibility
between the two types. (In this case between "int" and "char" there is full
compatibility !!)
I know that re-casting an "int" to "char" I could have loss or alteration of
data because it pass from a larger to a smaller one but usually the C
permits this.

 -You can think to the assignemt. The following code is allowed:

char c;
int i=0;

c=i;   // <--- implicit conversion from larger to smaller!!!
Syntactically good code

 -The pointer are accepted even if they belong to different type pointers.
 This following code is syntactically permited even if it's full of type
errors that probably
 will make my code fail !!

 main()
  {
   double a;
   ffa(&a);  // < *double
  } //  |
//  |
  ffa(int *par) // < *int
  {
  char c;
  printf("%c\n",*par);  // char <--> int
  return(0);
  }

 - ecc...
So a warning is correct (more, needed ) but not an error !!!

3. In the prevoius version (3.x) of gcc this was OK.!!

4. Consider the error message:

"an argument type that has a default promotion can't match an empty
parameter name list declaration"

empty parameter ? Where it saw this ? The message is wrong ...
This make me suspect that the compiler goes in an not managed case of
failure !!
In fact if I read your "c-decl.c" code in the function
"diagnose_mismatched_decls()",
the message "conflicting types for..." is the LAST branch of the
"if/then/elsif/../elsif/else" case !!
And the following line with "diagnose_arglist_conflict()" find a wrong
message/note because
probably this failure was not desired and considered.

Sorry if I bored with this long mail, but I try to explain to you the reason
for which I think this should be considered a bug. I know the problem is
by-passable
but I have a lot of sources with this new errors and this would make me to
adjust all these codes.

Please let me know if this can be considered a bug and if / when you think
to solve and fix it.
Thank you so much anyway.
Best regards.

Andrea

> -Messaggio originale-
> Da: raeburn at raeburn dot org [mailto:[EMAIL PROTECTED]
> Inviato: mercoledì 29 agosto 2007 13.13
> A: [EMAIL PROTECTED]
> Oggetto: [Bug c/33219] Error in compiling when there is a
> function with
> a char parameter called before its declaration with inline parameters.
>
>
>
>
> --- Comment #6 from raeburn at raeburn dot org
> 2007-08-29 11:12 ---
> (In reply to comment #5)
> > I don't understand the error !! It's all so simple and I
> don't understand
> > why the compile works if I write in the second form (not
> inline parameter
> > declaration) !!!
>
> (This would be more suitable for the gcc-help list, btw...)
>
> The bit about a type with default promotions refers to the
> fact that if there
> isn't a prototype declaration (or a prototype style function
> definition) in
> scope for the function, then integral arguments narrower than
> "int" get
> "promoted" to "int" in the function signature, and that's how
> the argument gets
> passed.  (And "float" would become "double" as well.)  Your
> second ("not
> inline") version uses a non-prototype style definition, so
> the passed argument
> type is in fact an "int".
>
> In the first version of your code, the function is called
> with no declaration
> in scope, so it's assumed that all argument types are the
> result of the default
> promotions, and then you declare it as taking a "char" not
> promoted to "int",
> which conflicts with the previous assumption.
>
> (The use of a function without a prototype in scope also
> causes the compiler to
> assume that it takes a fixed number of arguments, not a
> variable number of
> arguments like printf; gcc knows that printf takes a variable
> number of
> arguments, but warns you about it because according to the
> semantics of the C
> language, your source file is still requiring that printf be a
> non-variable-argument function.  While on many platforms that
> won't cause you
>

[Bug c/33227] New: 4.1.1 / 3.2

[tony dot radca at macys dot com]

I have ran into a situation where code compiled on RedHat 8.0 with gcc 3.2 runs
well.  We have upgraded our systems to Fedora Core 6 with gcc 4.1.1 and now
multiple programs are dropping core files left and right.  When we turn the
optimization off (create a debugable version) the programs act normal and do
not core dump. 

RedHat 8.0 with gcc 3.2
$ gcc -v
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.2/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/u
sr/share/info --enable-shared --enable-threads=posix --disable-checking
--host=i
386-redhat-linux --with-system-zlib --enable-__cxa_atexit
Thread model: posix
gcc version 3.2 20020903 (Red Hat Linux 8.0 3.2-7)

Fedora Core 6 with gcc 4.1.1
$ gcc -v
Using built-in specs.
Target: i386-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/u
sr/share/info --enable-shared --enable-threads=posix --enable-checking=release
-
-with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-
libgcj-multifile --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.4.2-gcj-1.4.2.0/jre --with-cpu=generic --host=i386-redhat-linux
Thread model: posix
gcc version 4.1.1 20061011 (Red Hat 4.1.1-30)

Thank You


-- 
   Summary: 4.1.1 / 3.2
   Product: gcc
   Version: 4.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tony dot radca at macys dot com


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

[Bug fortran/33215] Bind(C): Bugs with empty "name=": Creates wrong result and accepts invalid

[burnus at gcc dot gnu dot org]

--- Comment #3 from burnus at gcc dot gnu dot org  2007-08-29 13:09 ---
Subject: Bug 33215

Author: burnus
Date: Wed Aug 29 13:08:55 2007
New Revision: 127898

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127898
Log:
2007-08-29  Christopher D. Rickett  <[EMAIL PROTECTED]>

PR fortran/33215
* decl.c (build_sym): Pass number of identifiers on line to
set_binding_label.
(set_binding_label): Verify that only one identifier given if
NAME= specified, even if the given binding label has zero length.
(gfc_match_bind_c): Remove declaration for has_name_equals because
it hides the static global one that is needed.

2007-08-29  Christopher D. Rickett  <[EMAIL PROTECTED]>

PR fortran/33215
* gfortran.dg/binding_label_tests_15.f03: New test case.
* gfortran.dg/binding_label_tests_16.f03: Ditto.


Added:
trunk/gcc/testsuite/gfortran.dg/binding_label_tests_15.f03
trunk/gcc/testsuite/gfortran.dg/binding_label_tests_16.f03
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/decl.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug c/33227] 4.1.1 / 3.2

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2007-08-29 14:11 ---
Of course this is completely useless information for a bugreport.  Please read
http://gcc.gnu.org/bugs.html and try again.  You may also want to report to
your distributor, that is, RedHat in this case.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug middle-end/32758] [4.3 Regression] ecj1 hangs

[bonzini at gnu dot org]

--- Comment #27 from bonzini at gnu dot org  2007-08-29 14:11 ---

> Not all basic blocks have all 4 x86_64 regular_block_artificial_regs registers
> set in DF_LR_IN and so oring this in causes infinite loop, as 
> process_dce_block
> always returns something changed.

If so, your previous patch would be correct.  But in that case I wonder:

1) what is the purpose df_simulate_fixup_sets in df_simulate_one_insn_backwards
(and df_simulate_one_insn_forwards, FWIW).  Doing the OR for every insn is
clearly wrong, if it doesn't result in the IN set equal to DF_LR_IN.

2) why is the code marked as 

  /* Process the artificial defs and uses at the bottom of the block.  */

in dce_process_block slightly different from df_simulate_artificial_refs_at_end
and df_simulate_artificial_refs_at_top.

3) whether the code you added in dce_process_block should go in
df_simulate_artificial_refs_at_end actually.

Post your first patch, I will try to sort out this mess next week and may ask
you to regtest a patch on at least x86_64 and ia64.  In the meanwhile I CCed
Zadeck so that he can answer these questions...


-- 

bonzini at gnu dot org changed:

   What|Removed |Added

 CC||zadeck at gcc dot gnu dot
   ||org


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

[Bug middle-end/32758] [4.3 Regression] ecj1 hangs

[bonzini at gnu dot org]

--- Comment #28 from bonzini at gnu dot org  2007-08-29 14:14 ---
> Apparently dce is the only user of df_simulate_* which at the start of the
> basic block compares the resulting bitmap with DF_LR_IN. 

Yes.  The other two don't get infinite loops from their doing the wrong thing;
they just think some register is live and may miss some optimization.


-- 


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

[Bug fortran/33228] New: Accepts use-associated functions in MODULE PROCEDURE

[burnus at gcc dot gnu dot org]

module m
USE MOD, only: foo1
interface generic_intrf
  module procedure foo1
end interface

is accepted although "bar" is not a host-associated procedure, but a
use-associated procedure.

(Using "PROCEDURE foo1" instead of "MODULE PROCEDURE foo1" allows
use-associated procedures.)

NAG f95 correctly diagnoses:

Error: a.f90, line 13: FOO1 is not a module procedure

Full example, from:
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/4d51d6ca89f7d4f8/

MODULE a
  USE iso_c_binding
  INTERFACE
SUBROUTINE foo1(a) BIND(C,name="a_c_routine")
  IMPORT C_INT
  INTEGER(C_INT) ::a
END SUBROUTINE
  END INTERFACE
END MODULE
MODULE b
  USE a,ONLY : foo1
  INTERFACE foo
MODULE procedure foo1,foo2,foo3
  END INTERFACE
  CONTAINS
  SUBROUTINE foo2(a)
DOUBLE PRECISION ::a
  END SUBROUTINE
  SUBROUTINE foo3(a)
CHARACTER ::a
  END SUBROUTINE
END MODULE


-- 
   Summary: Accepts use-associated functions in MODULE PROCEDURE
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Keywords: accepts-invalid
  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=33228

[Bug middle-end/32758] [4.3 Regression] ecj1 hangs

[bonzini at gnu dot org]

--- Comment #29 from bonzini at gnu dot org  2007-08-29 14:16 ---
(When I said "post your first patch", I meant the first one from comment #26;
if my "fixing the mess" works, it'll not be necessary anymore).


-- 


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

[Bug fortran/33229] New: ICE with "intrinsic" plus calling a subroutine as function

[burnus at gcc dot gnu dot org]

The following invalid program gives a memory access error. Note, without
INTRINSIC or with IMPLICIT NONE, everything works as expected.

intrinsic cpu_time
real :: time
print *, CPU_TIME(TIME)
end


-- 
   Summary: ICE with "intrinsic" plus calling a subroutine as
function
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-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=33229

[Bug fortran/33105] F2003: Support is_iostat_end & is_iostat_eor intrinsics

[fxcoudert at gcc dot gnu dot org]

--- Comment #4 from fxcoudert at gcc dot gnu dot org  2007-08-29 15:16 
---
Subject: Bug 33105

Author: fxcoudert
Date: Wed Aug 29 15:16:00 2007
New Revision: 127903

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127903
Log:
PR fortran/33105

* intrinsic.c (add_functions): Add IS_IOSTAT_END and
IS_IOSTAT_EOR intrinsics.
* gfortran.h (gfc_isym_id): Add GFC_ISYM_IS_IOSTAT_END and
GFC_ISYM_IS_IOSTAT_EOR.
* trans-intrinsic.c (gfc_conv_has_intvalue): New function.
(gfc_conv_intrinsic_function): Call gfc_conv_has_intvalue for
GFC_ISYM_IS_IOSTAT_END and GFC_ISYM_IS_IOSTAT_EOR.
* intrinsic.texi: Add IS_IOSTAT_END and IS_IOSTAT_EOR.

* gfortran.dg/is_iostat_end_eor_1.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/is_iostat_end_eor_1.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/gfortran.h
trunk/gcc/fortran/intrinsic.c
trunk/gcc/fortran/intrinsic.texi
trunk/gcc/fortran/trans-intrinsic.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug fortran/33105] F2003: Support is_iostat_end & is_iostat_eor intrinsics

[fxcoudert at gcc dot gnu dot org]

--- Comment #5 from fxcoudert at gcc dot gnu dot org  2007-08-29 15:16 
---
Fixed.


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug middle-end/33199] [4.3 Regression] tr1/2_general_utilities/shared_ptr/assign/auto_ptr.cc

[rguenth at gcc dot gnu dot org]

--- Comment #21 from rguenth at gcc dot gnu dot org  2007-08-29 15:19 
---
I wonder why D.9380_64, defined as

  D.9380_64 = &D.8894_34->_M_use_count;

points to anything and NULL:

  D.9380_64, is dereferenced, points-to anything, points-to NULL

where the single dereference site looks like

  # ctor_count_403 = VDEF 
  # ctor_count_404 = VDEF 
  # dtor_count_405 = VDEF 
  *D.9380_64 ={v} D.9383_69;

of course because of the constraints:

  D.9380_64 = { NULL }

possibly because

  # VUSE 
  D.8894_34 = D.8885._M_refcount._M_pi;

which also

  D.8894_34, is dereferenced, its value escapes, points-to anything, points-to
NULL

which is because

  D.8885._M_pi = &NULL

but (!?) we have

...
  D.7990_3 ={v} operator new (4);

:
  D.7950_4 = (struct B *) D.7990_3;
...
  # SMT.470_328 = VDEF 
  D.7950_4->_vptr.B = &_ZTV1B[2];
...
  # SFT.432_331 = VDEF 
  __ref.80._M_ptr = D.7950_4;
  # VUSE 
  __ref$_M_ptr_14 = __ref.80._M_ptr;
  # SFT.425_333 = VDEF 
  b._M_ptr = __ref$_M_ptr_14;
  # VUSE 
  D.8873_20 = b._M_ptr;
  D.8884_21 = (struct A *) D.8873_20;
  # SFT.434_335 = VDEF 
  D.8885._M_ptr = D.8884_21;

so it is at most non-null, because we dereference the pointer.

Note we miss(?) a constraint for D.7990_3 but only have

D.7950_4 = D.7990_3
__ref.80 = D.7950_4
__ref$_M_ptr_14 = __ref.80
b = __ref$_M_ptr_14
D.8873_20 = b
D.8884_21 = D.8873_20
D.8885 = D.8884_21
(and then directly)
D.8885._M_pi = &NULL

shouldn't we have

D.7990_3 = &ANYTHING

?

In find_func_aliases we don't create a constraint for the lhs of a call
at all:

  else if (((TREE_CODE (t) == GIMPLE_MODIFY_STMT
 && TREE_CODE (GIMPLE_STMT_OPERAND (t, 1)) == CALL_EXPR
 && !(call_expr_flags (GIMPLE_STMT_OPERAND (t, 1))
  & (ECF_MALLOC | ECF_MAY_BE_ALLOCA)))
|| (TREE_CODE (t) == CALL_EXPR
&& !(call_expr_flags (t)
 & (ECF_MALLOC | ECF_MAY_BE_ALLOCA)
{
  if (!in_ipa_mode)
{
  if (TREE_CODE (t) == GIMPLE_MODIFY_STMT)
handle_rhs_call (GIMPLE_STMT_OPERAND (t, 1));
  else
handle_rhs_call (t);
}

So the following adds this constraint:

Index: tree-ssa-structalias.c
===
--- tree-ssa-structalias.c  (revision 127848)
+++ tree-ssa-structalias.c  (working copy)
@@ -3726,7 +3726,23 @@ find_func_aliases (tree origt)
   if (!in_ipa_mode)
{
  if (TREE_CODE (t) == GIMPLE_MODIFY_STMT)
-   handle_rhs_call (GIMPLE_STMT_OPERAND (t, 1));
+   {
+ handle_rhs_call (GIMPLE_STMT_OPERAND (t, 1));
+ if (POINTER_TYPE_P (TREE_TYPE (GIMPLE_STMT_OPERAND (t, 1
+   {
+ VEC(ce_s, heap) *lhsc = NULL;
+ struct constraint_expr rhsc;
+ unsigned int j;
+ struct constraint_expr *lhsp;
+ rhsc.var = anything_id;
+ rhsc.offset = 0;
+ rhsc.type = ADDRESSOF;
+ get_constraint_for (GIMPLE_STMT_OPERAND (t, 0), &lhsc);
+  for (j = 0; VEC_iterate (ce_s, lhsc, j, lhsp); j++)
+process_constraint_1 (new_constraint (*lhsp, rhsc), true);
+ VEC_free (ce_s, heap, lhsc);
+   }
+   }
  else
handle_rhs_call (t);
}

but still we end up with

D.8885 = D.8884_21
D.8885._M_pi = &NULL

!?

hm, we have

  # SFT.433_314 = VDEF 
  D.8885._M_refcount._M_pi = 0B;

so that might be ok.  The above patch fixes the failure for me, but
this might be pure luck given the fragile aliasing machinery.  So, does
the patch look anywhere sane?


-- 


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

[Bug libfortran/32989] GETARG intrinsic

[fxcoudert at gcc dot gnu dot org]

--- Comment #4 from fxcoudert at gcc dot gnu dot org  2007-08-29 15:25 
---
Fixed.


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug rtl-optimization/33224] failing rtl iv analysis (maybe due to df)

[spark at gcc dot gnu dot org]

--- Comment #2 from spark at gcc dot gnu dot org  2007-08-29 15:23 ---
I suspect this might be due to not updating the rd information after unrolling.
Can you check if 
analyze_insns_in_loop() (which calls df_analyze()) is being called just before
the problematic unrolling ?


-- 


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

[Bug libfortran/32989] GETARG intrinsic

[fxcoudert at gcc dot gnu dot org]

--- Comment #5 from fxcoudert at gcc dot gnu dot org  2007-08-29 15:27 
---
Subject: Bug 32989

Author: fxcoudert
Date: Wed Aug 29 15:22:55 2007
New Revision: 127905

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127905
Log:
PR fortran/32989

* iresolve.c (gfc_resolve_getarg): Handle non-default integer
kinds.
* check.c (gfc_check_getarg): New function
* intrinsic.h: Add prototype for gfc_check_getarg.
* intrinsic.c (add_subroutines): Add reference to gfc_check_getarg.
* intrinsic.texi (GETARG): Adjust documentation.

* gfortran.fortran-torture/execute/getarg_1.f90: Add check for
non-default integer kind arguments.

Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/check.c
trunk/gcc/fortran/intrinsic.c
trunk/gcc/fortran/intrinsic.h
trunk/gcc/fortran/intrinsic.texi
trunk/gcc/fortran/iresolve.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.fortran-torture/execute/getarg_1.f90


-- 


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

[Bug middle-end/32758] [4.3 Regression] ecj1 hangs

[zadeck at naturalbridge dot com]

--- Comment #30 from zadeck at naturalbridge dot com  2007-08-29 15:34 
---
Subject: Re:  [4.3 Regression] ecj1 hangs

bonzini at gnu dot org wrote:
> --- Comment #29 from bonzini at gnu dot org  2007-08-29 14:16 ---
> (When I said "post your first patch", I meant the first one from comment #26;
> if my "fixing the mess" works, it'll not be necessary anymore).
>
>
>   
For some reason, I was not copied on any of the postings for this patch
until this morning.

First, thankyou Jakub and Andreas for going this.

I think that it is obvious that you have spotted the exact problem: in
some way shape form of fashion, the artificial uses at the end of the
block need to be re added into the live set after the processing of each
insn in the block.

There are two ways of doing this (assume that you have a local variable
called artificial_uses_fixup which is a pointer to either
df->eh_block_artificial_uses or
df->regular_block_artificial_uses depending on if the block has eh preds) :

1) you can explicitly or artificial_uses_fixup into local_live after
processing each insn.
2) you can test artificial_uses_fixup along with local_live when setting
needed.

As noted, (1) has the problem that may cause an infinite loop.  This
infinite loop could be fixed by changing the equation for block_changed
to be

!bitmap_equal (local_live, DF_LR_IN (BB) || artificial_uses_fixup)

i.e. the infinite loop is because DF_LR_IN may be deficient in some of
the bits in artificial_uses_fixup for basically the same reason that
caused the bug in the first place.

I personally think that solution (1) is preferable to (2) because it is
fewer bitmap operations even though it will require a extra temp bitmap
to hold the or.

But either patch is a reasonable approach. 

As far as why there are all of the df_simulate functions that do things
in different ways, the answer is that the code has evolved and sometimes
things get missed.

The addition of the df->eh_block_artificial_uses and
df->regular_block_artificial_uses sets is fairly recent and it would
most likely be useful to replace walks  of artificial_uses with them. 

Kenny


-- 


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

[Bug fortran/33230] New: Missing check: specification function must be pure

[burnus at gcc dot gnu dot org]

gfortran -std=f95 -pedantic -Wall -fall-intrinsics
gfortran.dg/char_result_7.f90

Compiles, but as g95 remarks:
  Error: Specification function 'fn' at (1) must be PURE
which NAG f95 confirms:
  Error: Reference to non-specification function FN in specification
and ifort joins in as well:
  An explicit interface is required for a specification function.   [FN]

Excerpt of that file (see testsuite for the full program):

  function f2 (fn, i)
integer :: i, fn
character (len = fn (i)) :: f2

Called as "f2 (double, 70)" where DOUBLE is pure.


-- 
   Summary: Missing check: specification function must be pure
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Keywords: accepts-invalid
  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=33230

[Bug fortran/33231] New: Reject for -std=f* calls to elementar functions where array and scalar are mixed

[burnus at gcc dot gnu dot org]

gfortran -fall-intrinsics -std=f95 -Wall -pedantic
gfortran.dg/elemental_subroutine_1.f90

gives no error, but ifort:

In a reference to an elemental subroutine, either all act-args shall be scalar,
or all act-args associated with INTENT(OUT) and INTENT(INOUT) dum-args shall be
conforming arrays.   [V]
  call foobar (x, v)

and g95:

Error: Scalar argument at (1) to an ELEMENTAL procedure must be a conforming
array

NAG f95:
Scalar actual for INTENT(OUT) dummy B of elemental FOOBAR, but another argument
is an array


  elemental subroutine foobar (a, b)
real, intent(IN) :: a
real, intent(out) :: b

And the call has:
  real, dimension (2)  :: x, y
  real :: u, v

  call foobar (x, v)


-- 
   Summary: Reject for -std=f* calls to elementar functions where
array and scalar are mixed
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Keywords: accepts-invalid
  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=33231

[Bug fortran/33232] New: Diagnose comma in "read()," and "write(),"

[burnus at gcc dot gnu dot org]

The following is a common vendor extension but to my knowledge not allowed up
to Fortran 2003 (and probably also Fortran 2008):

write(*,*), 'Hello'
read(*,*), a
end

gfortran -pedantic -std=f95 -Wall accepts simply accepts it.

ifort -stand f03  reports correctly:

fortcom: Warning: a.f90, line 1: Use of comma to separate io-access spec and
io_list is non_standard.
write(*,*), 'Hello'
--^
fortcom: Warning: a.f90, line 2: Use of comma to separate io-access spec and
io_list is non_standard.
read(*,*), a
-^


-- 
   Summary: Diagnose comma in "read()," and "write(),"
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Keywords: diagnostic
  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=33232

[Bug fortran/33233] New: Parent and contained procedure: Wrongly treated as generic procedures

[burnus at gcc dot gnu dot org]

This is a follow up to PR30746.

While I believe the test case in PR30746 is correct, I think the
gfortran.dg/host_assoc_function_1.f90 test case is wrong.

(Simplified, see testsuite for the full file)

MODULE m
  REAL :: x(3) = (/ 1.5, 2.5, 3.5 /)
CONTAINS
  SUBROUTINE s
if (x(2) .ne. 2.5) call abort ()
  CONTAINS
FUNCTION x(n, m)
  x = REAL(n)**m
END FUNCTION
  END SUBROUTINE s
END MODULE m

I am very much in favour of the other compilers which think the "x" in "s"
refers to only the contained function "x" and not to the variable. gfortran
somehow seems to treat the symbol "x" as generic symbol which means with one
argument the variable and with two the function.
I would argue that the function name makes the variable inaccessible.

Using NAG's f95:
Error: host_assoc_function_1.f90, line 22: Too few arguments in reference to X
Error: host_assoc_function_1.f90, line 23: Too few arguments in reference to Z

ifort:
fortcom: Error: host_assoc_function_1.f90, line 22: A non-optional actual
argument must be present when invoking a procedure with an explicit interface. 
 [M] [...]


-- 
   Summary: Parent and contained procedure: Wrongly treated as
generic procedures
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Keywords: accepts-invalid
  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=33233

[Bug fortran/33234] New: -stf=f* and passing intrinsic function as actual argument without INTRINSIC

[burnus at gcc dot gnu dot org]

The following is invalid Fortran 95/2003:
  call sub (len, "abcdef")
unless one has used before "intrinsic len".

gfortran happily accepts this, "ifort -stand f03" diagnoses:

fortcom: Warning: intrinsic_actual_4.f90, line 17: Allowing an intrinsic
procedure name to appear as an actual argument when the intrinsic procedure is
not explicitly declared as INTRINSIC is not standard F2003.   [LEN]

As does NAG f95:
Actual INTRINSIC procedure argument LEN not declared INTRINSIC

Longer excerpt from gfortran.dg/intrinsic_actual_4.f90:

  implicit none
  integer i
  i = len ("123")
  call sub (len, "abcdef")

where sub takes as argument an integer function with implicit interface.


-- 
   Summary: -stf=f* and passing intrinsic function as actual
argument without INTRINSIC
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Keywords: diagnostic
  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=33234

[Bug c/33219] Error in compiling when there is a function with a char parameter called before its declaration with inline parameters.

[pinskia at gcc dot gnu dot org]

--- Comment #8 from pinskia at gcc dot gnu dot org  2007-08-29 16:15 ---
No C is defined this way.  Look at the error message, we mention why this code
is invalid.  
> a.c:7: note: an argument type that has a default promotion can't match an 
> empty
> parameter name list declaration

What more do you want from GCC, except from accepting this invalid code?


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug c++/33235] New: C++0x overloading problem with move constructor and trivial copy constructor

[dgregor at gcc dot gnu dot org]

Overload resolution is picking the wrong candidate for the construction of b3,
below:

  base2 b3(static_cast(b));

Instead of choosing the move constructor, it is picking the trivial copy
constructor. However, adding a normal copy constructor fixes the problem.

Naturally, this only occurs in C++0x mode.


-- 
   Summary: C++0x overloading problem with move constructor and
trivial copy constructor
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dgregor at gcc dot gnu dot org


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

[Bug c++/33235] C++0x overloading problem with move constructor and trivial copy constructor

[dgregor at gcc dot gnu dot org]

--- Comment #1 from dgregor at gcc dot gnu dot org  2007-08-29 16:16 ---
Created an attachment (id=14133)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14133&action=view)
Failing test-case


-- 


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

[Bug c/33219] Error in compiling when there is a function with a char parameter called before its declaration with inline parameters.

[manu at gcc dot gnu dot org]

--- Comment #9 from manu at gcc dot gnu dot org  2007-08-29 16:30 ---
Since "a" is called before being defined/declared is assumed:

extern int a();

See also: http://c-faq.com/decl/implfdecl.html

The error message could be a bit clearer by pointing out this explicitly:

a.c:7: error: conflicting types for 'a'
a.c:7: note: an argument type that has a default promotion can't match an empty
parameter name list declaration
a.c:3: error: previous implicit declaration 'extern int a()' of 'a' was here

But I doubt anyone would be interested to work on a patch for that. Would you?


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||manu at gcc dot gnu dot org


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

[Bug c/33219] Error in compiling when there is a function with a char parameter called before its declaration with inline parameters.

[andreagrassi at sogeasoft dot com]

--- Comment #10 from andreagrassi at sogeasoft dot com  2007-08-29 17:01 
---
Subject: R:  Error in compiling when there is a function with a char parameter
called before its declaration with inline parameters.


Read again your "brilliant" error message where you mention why my code is
invalid (even was invalid) !!
My parameter name list declaration is not empty !!
Maybe don't match the promoted type but not is empty.
At least fix the message ...

Le informazioni contenute in questo messaggio di posta elettronica sono di
natura confidenziale; qualsiasi pubblicazione, utilizzo o diffusione anche
parziale dello stesso non può essere effettuata senza autorizzazione e
potrebbe costituire un illecito penale ai sensi del Decreto Legs.vo N°
196/2003 sulla Protezione dei Dati Personali e del Codice Penale, Art.
617-621-635 bis oltre che della legge 547/93. Qualora non siate tra i
legittimi destinatari di questa e-mail Vi preghiamo cortesemente di
cancellarla dal Vostro sistema dopo aver notificato al mittente, rispondendo
alla comunicazione, l'errore da questi commesso.



> -Messaggio originale-
> Da: pinskia at gcc dot gnu dot org [mailto:[EMAIL PROTECTED]
> Inviato: mercoledì 29 agosto 2007 18.16
> A: [EMAIL PROTECTED]
> Oggetto: [Bug c/33219] Error in compiling when there is a
> function with
> a char parameter called before its declaration with inline parameters.
>
>
>
>
> --- Comment #8 from pinskia at gcc dot gnu dot org
> 2007-08-29 16:15 ---
> No C is defined this way.  Look at the error message, we
> mention why this code
> is invalid.
> > a.c:7: note: an argument type that has a default promotion
> can't match an empty
> > parameter name list declaration
>
> What more do you want from GCC, except from accepting this
> invalid code?
>
>
> --
>
> pinskia at gcc dot gnu dot org changed:
>
>What|Removed |Added
> --
> --
>  Status|UNCONFIRMED |RESOLVED
>  Resolution||INVALID
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33219
>
> --- You are receiving this mail because: ---
> You reported the bug, or are watching the reporter.
>
>
>
>


-- 


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

[Bug target/33168] [4.3 Regression] GCC Boot failure, building libstc++

[dje at gcc dot gnu dot org]

--- Comment #7 from dje at gcc dot gnu dot org  2007-08-29 17:01 ---
Subject: Bug 33168

Author: dje
Date: Wed Aug 29 17:01:35 2007
New Revision: 127910

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127910
Log:
2007-08-29  Paolo Bonzini  <[EMAIL PROTECTED]>

PR target/33168
* config/rs6000/rs6000.c (compare_section_name): New function.
(rs6000_elf_in_small_data_p): Compare section prefixes instead
of full name.

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


-- 


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

[Bug c++/33226] class name permitted in enum

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2007-08-29 17:09 ---
I have to look this up but I think this code is valid.


-- 


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

[Bug c/33219] Error in compiling when there is a function with a char parameter called before its declaration with inline parameters.

[andreagrassi at sogeasoft dot com]

--- Comment #11 from andreagrassi at sogeasoft dot com  2007-08-29 17:39 
---
Subject: R:  Error in compiling when there is a function with a char parameter
called before its declaration with inline parameters.

I accept the answer to gave me but then also the definition of

a(a)
   char a;
{
...

should be invalid. I don't understand why if I define

a(char a)
{
...

the compiler take a as "char" and don't match with promoted type giving me
an error whereas the other way the compiler promotes the "char a" to "int"
ALSO IN THE DEFINITION of the function !!
Why in summary

a(a)
   char a;// => promoted to int
{
...

whereas

a(char a)// =>remains char
{
...

The two manner defines the SAME THING (even if in 2 different forms) and
MUST be treated identically
(like for example "(*a).b" and "a->b" ).
You can tell me that your gcc works so, that your gcc treat differently the
2 cases,
I accept and I correct my code in order to success, but officially it isn't
correct.

Then, finishing, I don't understand because you must promote a parameter
EXPLICITLY rapresented by a char-constant as 'A' or by a variable previously
declared as char, or why, once promoted, you cannot re-correct the signature
!! The definition should override the implicitly signature .
I know it's from always so, but this is a twist of the logic of the
language.

However thanks to "raeburn at raeburn dot org" for his kindness, whereas I
cannot say so about you and Andrew Pinski, to whom I say to be kinder and to
try to develop a product and answer people using more his brain.




Le informazioni contenute in questo messaggio di posta elettronica sono di
natura confidenziale; qualsiasi pubblicazione, utilizzo o diffusione anche
parziale dello stesso non può essere effettuata senza autorizzazione e
potrebbe costituire un illecito penale ai sensi del Decreto Legs.vo N°
196/2003 sulla Protezione dei Dati Personali e del Codice Penale, Art.
617-621-635 bis oltre che della legge 547/93. Qualora non siate tra i
legittimi destinatari di questa e-mail Vi preghiamo cortesemente di
cancellarla dal Vostro sistema dopo aver notificato al mittente, rispondendo
alla comunicazione, l'errore da questi commesso.



> -Messaggio originale-
> Da: manu at gcc dot gnu dot org [mailto:[EMAIL PROTECTED]
> Inviato: mercoledì 29 agosto 2007 18.31
> A: [EMAIL PROTECTED]
> Oggetto: [Bug c/33219] Error in compiling when there is a
> function with
> a char parameter called before its declaration with inline parameters.
>
>
>
>
> --- Comment #9 from manu at gcc dot gnu dot org
> 2007-08-29 16:30 ---
> Since "a" is called before being defined/declared is assumed:
>
> extern int a();
>
> See also: http://c-faq.com/decl/implfdecl.html
>
> The error message could be a bit clearer by pointing out this
> explicitly:
>
> a.c:7: error: conflicting types for 'a'
> a.c:7: note: an argument type that has a default promotion
> can't match an empty
> parameter name list declaration
> a.c:3: error: previous implicit declaration 'extern int a()'
> of 'a' was here
>
> But I doubt anyone would be interested to work on a patch for
> that. Would you?
>
>
> --
>
> manu at gcc dot gnu dot org changed:
>
>What|Removed |Added
> --
> --
>  CC||manu at gcc
> dot gnu dot org
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33219
>
> --- You are receiving this mail because: ---
> You reported the bug, or are watching the reporter.
>
>
>
>


-- 


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

[Bug fortran/31879] ICE with function having array of character variables argument

[patchapp at dberlin dot org]

--- Comment #5 from patchapp at dberlin dot org  2007-08-29 18:05 ---
Subject: Bug number PR31879

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-08/msg02114.html


-- 


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

[Bug target/18251] unable to find a register to spill in class `POINTER_REGS'

[eweddington at cso dot atmel dot com]

--- Comment #40 from eweddington at cso dot atmel dot com  2007-08-29 18:06 
---
(In reply to comment #39)
> Created an attachment (id=14131)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14131&action=view) [edit]
> another test case
> 
> This test case only has problems when gcc is invoked with the -ftree-pre flag
> which is part of -O2 by default.
> 

This is not a good test case as "float *a" is being used uninitialized. Please
provide a better test case. FWIW, this test case works for me on:
4.2.1 -O[0123s]
4.3.0 20070824 snapshot -O[0123s]
4.1.2 (WinAVR 20070525) -O[0123s]

Please provide which version of GCC, and which target that you are using to
make it fail, including how GCC is configured. I would also suggest opening up
a new bug report for this until it is determined that this is the same bug.


-- 


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

[Bug fortran/33040] [ISO_C_BINDING] ICE in gfc_trans_structure_assign

[burnus at gcc dot gnu dot org]

--- Comment #2 from burnus at gcc dot gnu dot org  2007-08-29 18:15 ---
At least for it currently crashes already for the following reduced example;
the problem seems to be the default initializer. (Another hint that this is
indeed the problem: After commenting out the "if (f->sym && f->sym->attr.intent
== INTENT_OUT" etc. in gfc_trans_deferred_vars, gfortran does not crash
anymore.)

module m
  use, intrinsic :: iso_c_binding
  implicit none
  type t
type(c_ptr) :: matrix  = c_null_ptr
  end type t
contains
  subroutine func(a)
type(t), intent(out) :: a
  end subroutine func
end module m


-- 


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

[Bug middle-end/33199] [4.3 Regression] tr1/2_general_utilities/shared_ptr/assign/auto_ptr.cc

[dberlin at dberlin dot org]

--- Comment #22 from dberlin at gcc dot gnu dot org  2007-08-29 18:30 
---
Subject: Re:  [4.3 Regression]
tr1/2_general_utilities/shared_ptr/assign/auto_ptr.cc

On 29 Aug 2007 15:19:10 -, rguenth at gcc dot gnu dot org
<[EMAIL PROTECTED]> wrote:
>
>
> --- Comment #21 from rguenth at gcc dot gnu dot org  2007-08-29 15:19 
> ---
> I wonder why D.9380_64, defined as
>
>   D.9380_64 = &D.8894_34->_M_use_count;
>
> points to anything and NULL:
>
>   D.9380_64, is dereferenced, points-to anything, points-to NULL
>
> where the single dereference site looks like
>
>   # ctor_count_403 = VDEF 
>   # ctor_count_404 = VDEF 
>   # dtor_count_405 = VDEF 
>   *D.9380_64 ={v} D.9383_69;
>
> of course because of the constraints:
>
>   D.9380_64 = { NULL }
>
> possibly because
>
>   # VUSE 
>   D.8894_34 = D.8885._M_refcount._M_pi;
>
> which also
>
>   D.8894_34, is dereferenced, its value escapes, points-to anything, points-to
> NULL
>
> which is because
>
>   D.8885._M_pi = &NULL
>
> but (!?) we have
>
> ...
>   D.7990_3 ={v} operator new (4);
>
> :
>   D.7950_4 = (struct B *) D.7990_3;
> ...
>   # SMT.470_328 = VDEF 
>   D.7950_4->_vptr.B = &_ZTV1B[2];
> ...
>   # SFT.432_331 = VDEF 
>   __ref.80._M_ptr = D.7950_4;
>   # VUSE 
>   __ref$_M_ptr_14 = __ref.80._M_ptr;
>   # SFT.425_333 = VDEF 
>   b._M_ptr = __ref$_M_ptr_14;
>   # VUSE 
>   D.8873_20 = b._M_ptr;
>   D.8884_21 = (struct A *) D.8873_20;
>   # SFT.434_335 = VDEF 
>   D.8885._M_ptr = D.8884_21;
>
> so it is at most non-null, because we dereference the pointer.
>
> Note we miss(?) a constraint for D.7990_3 but only have
>
> D.7950_4 = D.7990_3
> __ref.80 = D.7950_4
> __ref$_M_ptr_14 = __ref.80
> b = __ref$_M_ptr_14
> D.8873_20 = b
> D.8884_21 = D.8873_20
> D.8885 = D.8884_21
> (and then directly)
> D.8885._M_pi = &NULL
>
> shouldn't we have
>
> D.7990_3 = &ANYTHING
>
> ?
>
> In find_func_aliases we don't create a constraint for the lhs of a call
> at all:
>
>   else if (((TREE_CODE (t) == GIMPLE_MODIFY_STMT
>  && TREE_CODE (GIMPLE_STMT_OPERAND (t, 1)) == CALL_EXPR
>  && !(call_expr_flags (GIMPLE_STMT_OPERAND (t, 1))
>   & (ECF_MALLOC | ECF_MAY_BE_ALLOCA)))
> || (TREE_CODE (t) == CALL_EXPR
> && !(call_expr_flags (t)
>  & (ECF_MALLOC | ECF_MAY_BE_ALLOCA)
> {
>   if (!in_ipa_mode)
> {
>   if (TREE_CODE (t) == GIMPLE_MODIFY_STMT)
> handle_rhs_call (GIMPLE_STMT_OPERAND (t, 1));
>   else
> handle_rhs_call (t);
> }
>
> So the following adds this constraint:
>
> Index: tree-ssa-structalias.c
> ===
> --- tree-ssa-structalias.c  (revision 127848)
> +++ tree-ssa-structalias.c  (working copy)
> @@ -3726,7 +3726,23 @@ find_func_aliases (tree origt)
>if (!in_ipa_mode)
> {
>   if (TREE_CODE (t) == GIMPLE_MODIFY_STMT)
> -   handle_rhs_call (GIMPLE_STMT_OPERAND (t, 1));
> +   {
> + handle_rhs_call (GIMPLE_STMT_OPERAND (t, 1));
> + if (POINTER_TYPE_P (TREE_TYPE (GIMPLE_STMT_OPERAND (t, 1
> +   {
> + VEC(ce_s, heap) *lhsc = NULL;
> + struct constraint_expr rhsc;
> + unsigned int j;
> + struct constraint_expr *lhsp;
> + rhsc.var = anything_id;
> + rhsc.offset = 0;
> + rhsc.type = ADDRESSOF;
> + get_constraint_for (GIMPLE_STMT_OPERAND (t, 0), &lhsc);
> +  for (j = 0; VEC_iterate (ce_s, lhsc, j, lhsp); j++)
> +process_constraint_1 (new_constraint (*lhsp, rhsc), 
> true);
> + VEC_free (ce_s, heap, lhsc);
> +   }
> +   }


This is right for !in_ipa_mode.  You may want to encapsulate it into a
new "handle_lhs_of_call" though :)


-- 


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

[Bug target/33236] New: -minimal-toc register should be psedu-register

[pinskia at gcc dot gnu dot org]

If -minimal-toc is used with a leaf function (that uses global memory), the
register r31 is saved/restored which causes a LHS store on the Cell's PowerPC
side.
Simple example:
int i;
int f(void)
{
  return i;
}
asm:
std 30,-16(1)
ld 30,[EMAIL PROTECTED](2)
ld 9,.LC0-.LCTOC1(30)
lwz 3,0(9)
ld 30,-16(1)  <--- LHS because this is most likely within 50 cycles
blr


-- 
   Summary: -minimal-toc register should be psedu-register
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: enhancement
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
GCC target triplet: powerpc64-linux-gnu


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

[Bug target/33236] -minimal-toc register should be psedu-register

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2007-08-29 18:38 ---
s/r31/r30 in comment #0, r31 is the frame pointer :).


-- 


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

[Bug target/33147] ICE: SEGV compiling for -mcpu=ep9312 -mfpu-maverick -mhard-float -O

[martinwguy at yahoo dot it]

--- Comment #3 from martinwguy at yahoo dot it  2007-08-29 18:45 ---
The patches contained in http://files.futaris.org/gcc/crunch.tar.bz2 not only
fix this issue but also make MaverickCrunch support work reliably in gcc-4.1.2
and gcc-4.2.0 (presumably they can also apply to TRUNK).

There are more patches in the gcc/gcc-{4.1.2,4.2.0} dirs than are necessary
(old versions) - applying the ones listed in the .bb files makes for a working
system.


-- 


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

[Bug tree-optimization/33237] New: Tree memory partitioning is spending 430 seconds of a 490 second compile.

[bergner at gcc dot gnu dot org]

The tree memory partitioning phase is spending 430 seconds of a 490 second
compile which seems a little excessive. The test case is a slightly modified
version of another test case within bugzilla (I forget which one) but with some
syntax warning cleaned up. I'm using GCC mainline revision 127398. I'll attach
the test case in the next post. The relevant parts of the -ftime-report output
looks like:

gcc -O1 -S -ftime-report syntax-case.i

Execution times (seconds)
[snip]
 tree memory partitioning: 433.26 (88%) usr   0.03 ( 1%) sys 433.29 (87%) wall 
 0 kB ( 0%) ggc
[snip]
 TOTAL : 491.34 4.19   495.53
199506 kB


-- 
   Summary: Tree memory partitioning is spending 430 seconds of a
490 second compile.
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bergner at gcc dot gnu dot org
 GCC build triplet: powerpc64-linux
  GCC host triplet: powerpc64-linux
GCC target triplet: powerpc64-linux


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

[Bug tree-optimization/33237] Tree memory partitioning is spending 430 seconds of a 490 second compile.

[bergner at gcc dot gnu dot org]

--- Comment #1 from bergner at gcc dot gnu dot org  2007-08-29 18:54 ---
Created an attachment (id=14134)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14134&action=view)
Test case mentioned above.

To recreate: gcc -O1 -S -ftime-report syntax-case.i


-- 


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

[Bug libfortran/33055] Runtime error in INQUIRE unit existance with -fdefault-integer-8

[tkoenig at gcc dot gnu dot org]

--- Comment #8 from tkoenig at gcc dot gnu dot org  2007-08-29 19:02 ---
Hi Jerry,

what was the problem?


-- 


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

[Bug fortran/32928] DATA statement with array element as initializer is rejected

[pault at gcc dot gnu dot org]

--- Comment #4 from pault at gcc dot gnu dot org  2007-08-29 19:19 ---
(In reply to comment #3)
> I am going to try this one.
> 
Jerry,

This fixes it but I do not understand why it is necessary; nor have I
regtested.  It's yours - I am going to tackle "spanned" pointers next, in the
hope of getting it into 4.3.0

Paul


-- 


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

[Bug libfortran/33225] [4.3 regression] Missing last digit is some formatted output

[dominiq at lps dot ens dot fr]

--- Comment #1 from dominiq at lps dot ens dot fr  2007-08-29 19:29 ---
Note that the problem disappears on Darwin with -m64 (excepted the problem
Error: Result of NEAREST overflows its kind at (1)).


-- 


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

[Bug c/33238] New: [4.1.2 regression] ICE on statement expression using variable-sized structure in tree_low_cst, at tree.c:4502

[radford at blackbean dot org]

The following code gives an internal compiler error using gcc 4.1.2, but
compiles using 3.4.  Remove the ()s around the {}s and it compiles just fine. 

void reverse(void *_p, int nmemb, int size)
{
struct { char _[size]; } *p = _p, tmp;
for (int i=nmemb-1, j=0; jhttp://gcc.gnu.org/bugzilla/show_bug.cgi?id=33238

[Bug middle-end/32758] [4.3 Regression] ecj1 hangs

[andreast at gcc dot gnu dot org]

--- Comment #31 from andreast at gcc dot gnu dot org  2007-08-29 20:17 
---
Thanks Jakub!

With this patch: http://gcc.gnu.org/ml/gcc-patches/2007-08/msg02111.html
you not only brought back the testsuite passes, you also made the bytecode
compilation work again on ppc-linux and ppc-darwin (32-bit at least).
Before it was not possible, since the dataflow merge revision, to compile a
hello.java into a class file and execute via gij.

Your speed on how to solve this issue really impressed me!
Thanks again!!!


-- 


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

[Bug tree-optimization/33140] [4.3 Regression] ICE in build2_stat, at tree.c:3115

[pinskia at gcc dot gnu dot org]

--- Comment #6 from pinskia at gcc dot gnu dot org  2007-08-29 20:41 ---
Mine, working on it.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |pinskia at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-08-29 20:41:06
   date||


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

[Bug fortran/33174] Testsuite: unexpected failures

[pinskia at gcc dot gnu dot org]

--- Comment #8 from pinskia at gcc dot gnu dot org  2007-08-29 20:42 ---
That ICE is most likely PR 33140.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

Version|4.2.0   |4.3.0


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

[Bug tree-optimization/33237] [4.3 Regression]Tree memory partitioning is spending 430 seconds of a 490 second compile.

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords||compile-time-hog
Summary|Tree memory partitioning is |[4.3 Regression]Tree memory
   |spending 430 seconds of a   |partitioning is spending 430
   |490 second compile. |seconds of a 490 second
   ||compile.
   Target Milestone|--- |4.3.0


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

[Bug tree-optimization/33237] [4.3 Regression]Tree memory partitioning is spending 430 seconds of a 490 second compile.

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2007-08-29 20:52 ---
I think this comes down to the referenced decls is huge because of the static
"const" variable but I don't know for sure (I had looked into one of those
issues before).


-- 


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

[Bug c/33238] [4.1.2 regression] ICE on statement expression using variable-sized structure in tree_low_cst, at tree.c:4502

[radford at blackbean dot org]

--- Comment #1 from radford at blackbean dot org  2007-08-29 21:19 ---
Bug is present in 4.2.1 as well.


-- 

radford at blackbean dot org changed:

   What|Removed |Added

Summary|[4.1.2 regression] ICE on   |[4.1.2 regression] ICE on
   |statement expression using  |statement expression using
   |variable-sized structure in |variable-sized structure in
   |tree_low_cst, at tree.c:4502|tree_low_cst, at tree.c:4502


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

[Bug c/33219] Error in compiling when there is a function with a char parameter called before its declaration with inline parameters.

[raeburn at raeburn dot org]

--- Comment #12 from raeburn at raeburn dot org  2007-08-29 21:51 ---
Subject: Re:  Error in compiling when there is a function with a char parameter
called before its declaration with inline parameters.

On Aug 29, 2007, at 13:39, andreagrassi at sogeasoft dot com wrote:
> I accept the answer to gave me but then also the definition of
>
> a(a)
>char a;
> {
> ...
>
> should be invalid. I don't understand why if I define
>
> a(char a)
> {
> ...
>
> the compiler take a as "char" and don't match with promoted type  
> giving me
> an error whereas the other way the compiler promotes the "char a"  
> to "int"
> ALSO IN THE DEFINITION of the function !!

It would seem to make sense, wouldn't it?  But that's not how the C  
standard was defined.  It does cause confusion, but I guess the  
benefit of letting "new-style" code be optimized better (e.g., you  
can read a byte from memory and stuff it in the argument list,  
without having to do the signed or unsigned widening to full "int",  
or pass a "float" using 4 bytes on the stack instead of widening it  
to an 8-byte "double") while leaving the meaning of "old-style" code  
unchanged (old 1970s and 1980s compilers would always do the "default  
promotions", even if it slowed down the code a little) was deemed to  
be worth it.  I wasn't there, and can't read the minds of the people  
on the committee, but it's a fait accompli at this point.

Note too that in the 1999 version of the standard, the ability to  
write the "old-style" code is described an "obsolescent feature", and  
the general direction the standards are moving in seems to suggest  
that you should (1) always include a prototype declaration before  
calling a function (or include the relevant header for standard C  
functions), and (2) always use the prototype-style function  
definitions instead of the older style.  Having a prototype  
declaration in scope before using a function is good practice,  
anyways, because it lets the compiler do better type-checking of your  
function call, even if the function definition isn't in the same file.

> Why in summary
>
> a(a)
>char a;// => promoted to int
> {
> ...
>
> whereas
>
> a(char a)// =>remains char
> {
> ...
>
> The two manner defines the SAME THING (even if in 2 different  
> forms) and
> MUST be treated identically

The C language specification says no, they're actually not the same.   
It causes some confusion when converting old C code to use prototype  
declarations and definitions, because you might think you could just  
move the argument declaration up without changing the semantics, but  
it does change them subtly.

> Then, finishing, I don't understand because you must promote a  
> parameter
> EXPLICITLY rapresented by a char-constant as 'A' or by a variable  
> previously
> declared as char, or why, once promoted, you cannot re-correct the  
> signature
> !! The definition should override the implicitly signature .
> I know it's from always so, but this is a twist of the logic of the
> language.

Actually, that's another funny point of C... and in fact it's an area  
where C and C++ are different.  Character constants like 'A' are  
actually considered to have type "int" in C, not type "char"!  I have  
no idea what the logic was behind that (probably it's what 1970s-80s  
compilers did), but once again, it was decided years ago and that's  
the way it is.

Go ahead and try something like

   printf("%d\n", sizeof('a'));

... the size isn't 1 in C, it's the size of an int.

C++, on the other hand, treats 'A' as a "char" constant.  It's  
probably a lot more important to distinguish "char" from "int" in C++  
where you might be doing function overloading or template  
instantiation based on the type.

Ken


-- 


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

[Bug c++/33239] New: internal compiler error in instantiate_class_template, at cp/pt.c:5666

[masse_nicolas at yahoo dot fr]

All is in the title. Here is the complete output I have (my system is in
french):
g++ -DHAVE_CONFIG_H -I. -I.. -I ../src-g -O2 -MT sample1.o -MD -MP -MF
.deps/sample1.Tpo -c -o sample1.o sample1.cpp
../src/tuple.hpp: In instantiation of 'yactl::tuple_impl, std::allocator >
>::append, std::allocator > >':
../src/tuple.hpp:105:   instantiated from 'yactl::tuple, std::allocator >,
yactl::null_type, yactl::null_type, yactl::null_type, yactl::null_type,
yactl::null_type, yactl::null_type, yactl::null_type, yactl::null_type,
yactl::null_type, yactl::null_type, yactl::null_type, yactl::null_type,
yactl::null_type, yactl::null_type>'
sample1.cpp:37:   instantiated from here
../src/tuple.hpp:40: erreur interne du compilateur: dans
instantiate_class_template, à cp/pt.c:5666
Veuillez soumettre un rapport complet d'anomalies,
avec le source pré-traité si nécessaire.
Consultez http://gcc.gnu.org/bugs.html> pour plus de détail.


-- 
   Summary: internal compiler error in instantiate_class_template,
at cp/pt.c:5666
   Product: gcc
   Version: 4.1.2
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: masse_nicolas at yahoo dot fr


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

[Bug c++/33239] internal compiler error in instantiate_class_template, at cp/pt.c:5666

[masse_nicolas at yahoo dot fr]

--- Comment #1 from masse_nicolas at yahoo dot fr  2007-08-29 21:57 ---
Created an attachment (id=14135)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14135&action=view)
Complete sources tree where the problem happens


-- 


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

[Bug c++/32128] [4.3 regression] ICE on variadic template with two parameter packs

[chris dot fairles at gmail dot com]

--- Comment #1 from chris dot fairles at gmail dot com  2007-08-29 22:04 
---
Not sure if this is same bug:

template
struct B; 

template
struct B {};

template
struct B : public B {
H h;
};

template 
class D : B<0,T...> {};

template
struct E;

template
struct E> {
typedef decltype(D::template B::h) type;
};

int main() {
   E<1,D>::type d = 4.5;

}

test2.cpp: In function ‘int main()’:
test2.cpp:24: internal compiler error: in unify, at cp/pt.c:12873
Please submit a full bug report,


-- 


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

[Bug target/33240] New: [4.3 regression] bootstrap failure for hppa-linux -> hppa64-linux cross compiler

[debian-gcc at lists dot debian dot org]

seen with SVN 20070828

  Matthias

/scratch/packages/gcc/snap/gcc-snapshot-20070827/build-hppa64/./gcc/xgcc
-B/scratch/packages/gcc/snap/gcc-snapshot-20070827/build-hppa64/./gcc/
-B/usr/lib/gcc-snapshot/hppa64-linux-gnu/bin/
-B/usr/lib/gcc-snapshot/hppa64-linux-gnu/lib/ -isystem
/usr/lib/gcc-snapshot/hppa64-linux-gnu/include -isystem
/usr/lib/gcc-snapshot/hppa64-linux-gnu/sys-include -O2 -g -O2 -O2  -O2 -g -O2  
-DIN_GCC -DCROSS_DIRECTORY_STRUCTURE   -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition  -isystem
./include  -fPIC -Dpa64=1 -DELF=1 -g  -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED
-Dinhibit_libc  -I. -I. -I../.././gcc -I../../../src/libgcc
-I../../../src/libgcc/. -I../../../src/libgcc/../gcc
-I../../../src/libgcc/../include   -o _divsc3.o -MT _divsc3.o -MD -MP -MF
_divsc3.dep -DL_divsc3 -c ../../../src/libgcc/../gcc/libgcc2.c \

../../../src/libgcc/../gcc/libgcc2.c: In function '__multc3':
../../../src/libgcc/../gcc/libgcc2.c:1890: internal compiler error: in
local_cprop_pass, at gcse.c:3240
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[4]: *** [_multc3.o] Error 1
make[4]: *** Waiting for unfinished jobs
make[4]: Leaving directory
`/scratch/packages/gcc/snap/gcc-snapshot-20070827/build-hppa64/hppa64-linux-gnu/libgcc'
make[3]: *** [all-target-libgcc] Error 2
make[3]: Leaving directory
`/scratch/packages/gcc/snap/gcc-snapshot-20070827/build-hppa64'
make[2]: *** [all] Error 2


-- 
   Summary: [4.3 regression] bootstrap failure for hppa-linux ->
hppa64-linux cross compiler
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: debian-gcc at lists dot debian dot org
GCC target triplet: hppa64-linux-gnu


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

[Bug middle-end/33029] [4.3 Regression] libgcc2.c:1890: internal compiler error: in local_cprop_pass, at gcse.c:3236

[pinskia at gcc dot gnu dot org]

--- Comment #9 from pinskia at gcc dot gnu dot org  2007-08-29 22:14 ---
*** Bug 33240 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||debian-gcc at lists dot
   ||debian dot org


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

[Bug target/33240] [4.3 regression] bootstrap failure for hppa-linux -> hppa64-linux cross compiler

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2007-08-29 22:14 ---


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


-- 

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

[Bug middle-end/33029] [4.3 Regression] libgcc2.c:1890: internal compiler error: in local_cprop_pass, at gcse.c:3236

[pinskia at gcc dot gnu dot org]

--- Comment #10 from pinskia at gcc dot gnu dot org  2007-08-29 22:14 
---
Any news on this bug?


-- 


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

[Bug libfortran/33225] [4.3 regression] Missing last digit is some formatted output

[dominiq at lps dot ens dot fr]

--- Comment #2 from dominiq at lps dot ens dot fr  2007-08-29 22:18 ---
I have run the NIST test suite and I got:

...
6 runtime errors
FM111 has NIST regression.
FM406 has NIST regression.
FM903 has NIST regression.
FM907 has NIST regression.
FM909 has NIST regression.
FM912 has NIST regression.
...

FM111 has both a missing last digit in the exponent:

   COMPUTED: * .12345E+10 .12345E+01 *** .12345E+10
   CORRECT:  * .12345E+10 .12345E+010 *** .12345E+10

disappearing with -m64, and

   COMPUTED:  0   .0   .00   .0E+0   **   -.4E-2
   CORRECT:   0   .0   .00   .0E+0   .0   -.4E-2

for both cases.

FM406 gives:

...
 COMPUTED=-0.0  
 CORRECT=   0.0 
...

for both cases.

These failures in both cases are not new, I see them with
gcc version 4.3.0 20070720 (experimental)

The last four failures disappear with -m64. The three first are missing 
last digits and the last one fails with:

...
TEST  22  FAIL  RECORD 1 - ON GW.DEN FORMAT
TEST  23  FAIL  RECORD 4 - ON IN.N FORMAT  
...


-- 


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

Re: [Bug libfortran/33225] [4.3 regression] Missing last digit is some formatted output

[Andrew Pinski]

On 29 Aug 2007 22:18:58 -, dominiq at lps dot ens dot fr
<[EMAIL PROTECTED]> wrote:

> FM406 gives:
>
> ...
>  COMPUTED=-0.0
>  CORRECT=   0.0

Actually this is expected if you did not supply -fno-sign-zero or
-std=f95 as the default is to print negative 0 as -0.0 as in the 2003
Fortran standard while F95 says don't print the negative sign for
-0.0.

Thanks,
Andrew Pinski

[Bug libfortran/33225] [4.3 regression] Missing last digit is some formatted output

[pinskia at gmail dot com]

--- Comment #3 from pinskia at gmail dot com  2007-08-29 22:23 ---
Subject: Re:  [4.3 regression] Missing last digit is some formatted output

On 29 Aug 2007 22:18:58 -, dominiq at lps dot ens dot fr
<[EMAIL PROTECTED]> wrote:

> FM406 gives:
>
> ...
>  COMPUTED=-0.0
>  CORRECT=   0.0

Actually this is expected if you did not supply -fno-sign-zero or
-std=f95 as the default is to print negative 0 as -0.0 as in the 2003
Fortran standard while F95 says don't print the negative sign for
-0.0.

Thanks,
Andrew Pinski


-- 


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

[Bug libfortran/33225] [4.3 regression] Missing last digit is some formatted output

[dominiq at lps dot ens dot fr]

--- Comment #4 from dominiq at lps dot ens dot fr  2007-08-29 23:02 ---
Subject: Re:  [4.3 regression] Missing last digit is
 some formatted output

> Actually this is expected if you did not supply -fno-sign-zero ...

You are right!-) I have added the option in the script I am using
and all the failures disappear with -m64, but only for FM406 without.
I think the ** is due to the attempt to output -.0.

Thanks for the infos.

Dominique


-- 


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

[Bug fortran/33241] New: ICE when compilation

[victor dot prosolin at gmail dot com]

When I try to compile the following file (attached at the end. quite big) I get
the folloring message
onefile.F90: In function ‘MAIN__’:
onefile.F90:778: internal compiler error: in gfc_get_symbol_decl, at
fortran/trans-decl.c:1020
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Compilation options: gfortran-4.3 -save-temps onefile.F90 -Wall
System: OpenSuse 10.2 64 bit
gcc configure options (gcc-4.3 -v) :
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --prefix=/home/vip/programs/gcc
--enable-threads=posix --enable-languages=fortran --enable-checking=release
--enable-ssp --disable-libssp --disable-libgcj --with-system-zlib
--disable-shared --program-suffix=-4.3 --enable-version-specific-runtime-libs
--without-system-libunwind --enable-static : (reconfigured) ../configure
--prefix=/home/vip/programs/gcc --enable-threads=posix
--enable-languages=fortran --enable-checking=release --enable-ssp
--disable-libssp --disable-libgcj --with-system-zlib --disable-shared
--program-suffix=-4.3 --enable-version-specific-runtime-libs
--without-system-libunwind --enable-static
Thread model: posix
gcc version 4.3.0 20070821 (experimental) (GCC)
Source file:


MODULE parameters
  !-  - - - - -
- -
  ! Specify data types
  !-  - - - - -
- -
  IMPLICIT NONE
  INTEGER, PARAMETER :: rn = KIND(0.0d0)  ! Precision of real numbers
  INTEGER, PARAMETER :: is = SELECTED_INT_KIND(1) ! Data type of bytecode
END MODULE parameters


MODULE fparser
  !---  - - - - - -
---
  ! Fortran 90 function parser v1.0
  !---  - - - - - -
---
  !
  ! This public domain function parser module is intended for applications
  ! where a set of mathematical expressions is specified at runtime and is
  ! then evaluated for a large number of variable values. This is done by
  ! compiling the set of function strings into byte code, which is interpreted
  ! very efficiently for the various variable values.
  !
  ! The source code is available from:
  ! http://www.its.uni-karlsruhe.de/~schmehl/opensource/fparser-v1.0.tar.gz
  !
  ! Please send comments, corrections or questions to the author:
  ! Roland Schmehl <[EMAIL PROTECTED]>
  !
  !---  - - - - - -
---
  ! The function parser concept is based on a C++ class library written by Warp
  ! <[EMAIL PROTECTED]> available from:
  ! http://www.students.tut.fi/~warp/FunctionParser/fparser.zip
  !---  - - - - - -
---
  USE parameters, ONLY: rn,is   ! Import KIND parameters
  IMPLICIT NONE
  !---  - - - - - -
---
  PUBLIC :: initf,& ! Initialize function parser for n
functions
parsef,   & ! Parse single function string
evalf,& ! Evaluate single function
EvalErrMsg  ! Error message (Use only when
EvalErrType>0)
  INTEGER, PUBLIC:: EvalErrType ! =0: no error occured, >0:
evaluation error
  !---  - - - - - -
---
  PRIVATE
  SAVE
  INTEGER(is),  PARAMETER :: cImmed   = 1, 
&
 cNeg = 2, 
&
 cAdd = 3, 
&
 cSub = 4, 
&
 cMul = 5, 
&
 cDiv = 6, 
&
 cPow = 7, 
&
 cAbs = 8, 
&
 cExp = 9, 
&
 cLog10   = 10,
&
 cLog = 11,
&
 cSqrt= 12,
&
 cSinh= 13,
&
 cCosh= 14,
&
 cTanh= 15,
&
 cSin = 16,
&
 cCos = 17,
&
  

[Bug libstdc++/33242] Getting error when including fstream.

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||gcc-bugs at gcc dot gnu dot
   ||org


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

[Bug libstdc++/33242] Getting error when including fstream.

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2007-08-30 00:01 ---
The copy constructor on a fstream is invalid.
And you caused it to be created here: Seg s1 = Seg("");


-- 


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

[Bug libstdc++/33242] Getting error when including fstream.

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2007-08-30 00:06 ---
Yep this code is invalid.

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


-- 

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