[Bug bootstrap/39739] Bootstrapping with in-tree mpfr-2.4.1 and --with-gmp=... errors

[ghazi at gcc dot gnu dot org]

--- Comment #3 from ghazi at gcc dot gnu dot org  2009-04-25 05:55 ---
Subject: Bug 39739

Author: ghazi
Date: Sat Apr 25 05:55:24 2009
New Revision: 146758

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146758
Log:
PR bootstrap/39739
* configure.ac (extra_mpfr_configure_flags): Set and AC_SUBST.
* Makefile.def (module=mpfr): Use extra_mpfr_configure_flags.

* configure, Makefile.in: Regenerate.


Modified:
branches/gcc-4_3-branch/ChangeLog
branches/gcc-4_3-branch/Makefile.def
branches/gcc-4_3-branch/Makefile.in
branches/gcc-4_3-branch/configure
branches/gcc-4_3-branch/configure.ac


-- 


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

[Bug fortran/39890] Link of a large application fails with spurious multiple symbol definition

[craig dot powers at gmail dot com]

--- Comment #3 from craig dot powers at gmail dot com  2009-04-25 05:29 
---
(In reply to comment #0)

Compiler invocation for each source file:
/usr/gcc44/bin/gfortran  -c -fbacktrace -x f95-cpp-input -DF2003
-DF2003_NO_ASSOCIATE (source file)


-- 


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

[Bug fortran/39890] Link of a large application fails with spurious multiple symbol definition

[craig dot powers at gmail dot com]

--- Comment #2 from craig dot powers at gmail dot com  2009-04-25 05:25 
---
(In reply to comment #0)

Also, I omitted the link invocation:
gfortran -O3 -o (exe_name) (big honkin' list of object files)


-- 


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

[Bug fortran/39890] Link of a large application fails with spurious multiple symbol definition

[craig dot powers at gmail dot com]

--- Comment #1 from craig dot powers at gmail dot com  2009-04-25 05:23 
---
(In reply to comment #0)

I neglected to give my compiler info...

/usr/gcc44/bin/gfortran -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.4.0/configure --prefix=/usr/gcc44
--enable-languages=all
Thread model: posix
gcc version 4.4.0 (GCC)


-- 


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

[Bug fortran/39890] New: Link of a large application fails with spurious multiple symbol definition

[craig dot powers at gmail dot com]

I attempted to build my research group's molecular simulation code.  Compiling
appears to proceed normally, but linking fails with a string of spurious
multiple definition errors, e.g.
nucleation.o(.bss+0x0): multiple definition of `__nucleation_MOD_atomicpress'
nucleation.o(.bss+0x0): first defined here

However, running nm on nucleation.o shows only one line for the referenced
symbol:
 B __nucleation_MOD_atomicpress

And a grep of the program source shows that atomicpress is only declared in
module nucleation, so there is no apparent source for the complaints.

This code has been compiled and linked successfully with ifort 11 and a version
of pathf95 (either 2.5 or 3.0).


-- 
   Summary: Link of a large application fails with spurious multiple
symbol definition
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: craig dot powers at gmail dot com
 GCC build triplet: x86_64-unknown-linux-gnu
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu


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

[Bug bootstrap/39739] Bootstrapping with in-tree mpfr-2.4.1 and --with-gmp=... errors

[ghazi at gcc dot gnu dot org]

--- Comment #2 from ghazi at gcc dot gnu dot org  2009-04-25 04:10 ---
Subject: Bug 39739

Author: ghazi
Date: Sat Apr 25 04:10:29 2009
New Revision: 146755

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146755
Log:
PR bootstrap/39739
* configure.ac (extra_mpfr_configure_flags): Set and AC_SUBST.
* Makefile.def (module=mpfr): Use extra_mpfr_configure_flags.

* configure, Makefile.in: Regenerate.


Modified:
branches/gcc-4_4-branch/ChangeLog
branches/gcc-4_4-branch/Makefile.def
branches/gcc-4_4-branch/Makefile.in
branches/gcc-4_4-branch/configure
branches/gcc-4_4-branch/configure.ac


-- 


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

[Bug bootstrap/39739] Bootstrapping with in-tree mpfr-2.4.1 and --with-gmp=... errors

[ghazi at gcc dot gnu dot org]

--- Comment #1 from ghazi at gcc dot gnu dot org  2009-04-25 03:24 ---
Subject: Bug 39739

Author: ghazi
Date: Sat Apr 25 03:24:17 2009
New Revision: 146754

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146754
Log:
PR bootstrap/39739
* configure.ac (extra_mpfr_configure_flags): Set and AC_SUBST.
* Makefile.def (module=mpfr): Use extra_mpfr_configure_flags.

* configure, Makefile.in: Regenerate.


Modified:
trunk/ChangeLog
trunk/Makefile.def
trunk/Makefile.in
trunk/configure
trunk/configure.ac


-- 


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

[Bug c/39889] [4.4 Regression] Bogus -Wunused-value warning

[jakub at gcc dot gnu dot org]

-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jakub at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-04-24 22:35:54
   date||
   Target Milestone|--- |4.4.1


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

[Bug c/39889] New: [4.4 Regression] Bogus -Wunused-value warning

[jakub at gcc dot gnu dot org]

/* { dg-do compile } */
/* { dg-options "-Wunused-value" } */

int x;
int foo (void)
{
  return (1 ? x = 0 : (void) 0), 0; /* { dg-bogus "value computed is not used"
} */
}

warns in 4.4, didn't warn in 4.3 (pre-tuples merge) and doesn't warn in 4.4
(since r145254).  I have a patch.


-- 
   Summary: [4.4 Regression] Bogus -Wunused-value warning
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org


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

[Bug fortran/39879] [4.3/4.4/4.5 Regression] double free or corruption abort with gfortran

[burnus at gcc dot gnu dot org]

-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu dot
   ||org
   Keywords||wrong-code
  Known to work||4.2.1
Summary|double free or corruption   |[4.3/4.4/4.5 Regression]
   |abort with gfortran |double free or corruption
   ||abort with gfortran
   Target Milestone|--- |4.3.4


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

[Bug middle-end/38846] [Graphite] 70% slower using -floop* than without graphite (gas_dyn of Polyhedron)

[burnus at gcc dot gnu dot org]

--- Comment #5 from burnus at gcc dot gnu dot org  2009-04-24 21:38 ---
Current gas_dyn runtime:
  16.161 - 4.5, graphite (options, see comment 0)
  13.122 - 4.5, no graphite
-> Now 20% slower
  16.399 - 4.4, graphite
(Why the run time is longer than in January, I don't understand; the computer
is the same.)


-- 


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

[Bug middle-end/27663] missed-optimization transforming a byte array to unsigned long

[rguenth at gcc dot gnu dot org]

--- Comment #5 from rguenth at gcc dot gnu dot org  2009-04-24 20:43 ---
Maybe it fits within the byteswap recognition pass (certainly the loads may
be because on-the-fly byteswap is requested).


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||krebbel at gcc dot gnu dot
   ||org


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

[Bug libstdc++/39491] [4.4/4.5 regression] symbol __signb...@glibcxx_3.4 in libstdc++ not exported anymore

[carlos at codesourcery dot com]

--- Comment #26 from carlos at codesourcery dot com  2009-04-24 20:41 
---
Action items left:

1) Checkin a patch to libc-ports to define __signbitl as an alias of __signbit
on hppa.
* Done: http://sourceware.org/ml/glibc-cvs/2009-q2/msg00277.html

2) Someone please add a stub to libstdc++ for __signb...@glibcxx_3.4 that calls
__signbitl in glibc.

3) Wait for Jakub to get his patch into glibc core.

4) Enable __NO_LONG_DOUBLE_MATH for hppa (different from NO_LONG_DOUBLE and
long-double-fcts = no).

#1, #3, and #4 are things I can work on. Can someone please do #2? When #1 and
#2 are done we can consider *this* issue closed.


-- 


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

[Bug middle-end/27663] missed-optimization transforming a byte array to unsigned long

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2009-04-24 20:39 ---
It's a target independent issue.  On non-strict alignment targets we can do a
32bit load instead of 4 byte loads.  This is what you ask for, correct?

combine unfortunately does not see enough insns to catch it.  Within a single
stmt we can teach fold to do it, otherwise forwprop is our tree level combiner.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|normal  |enhancement
  Component|target  |middle-end


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

[Bug libstdc++/39491] [4.4/4.5 regression] symbol __signb...@glibcxx_3.4 in libstdc++ not exported anymore

[carlos at codesourcery dot com]

--- Comment #25 from carlos at codesourcery dot com  2009-04-24 20:31 
---
Jakub's patch works for me on HPPA, and correctly exports the *l prototypes
with __NO_LONG_DOUBLE_MATH set.


-- 


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

[Bug target/27663] missed-optimization transforming a byte array to unsigned long

[urjaman at gmail dot com]

--- Comment #3 from urjaman at gmail dot com  2009-04-24 20:24 ---
Confirmed on 4.3.2 - it's a bit different and actually worse (longer):
(Please add 4.3.2 to known to fail - i cant)
 :
   0:   e8 2f   mov r30, r24
   2:   f9 2f   mov r31, r25
   4:   21 81   ldd r18, Z+1; 0x01
   6:   30 e0   ldi r19, 0x00   ; 0
   8:   40 e0   ldi r20, 0x00   ; 0
   a:   50 e0   ldi r21, 0x00   ; 0
   c:   52 2f   mov r21, r18
   e:   44 27   eor r20, r20
  10:   33 27   eor r19, r19
  12:   22 27   eor r18, r18
  14:   82 81   ldd r24, Z+2; 0x02
  16:   90 e0   ldi r25, 0x00   ; 0
  18:   a0 e0   ldi r26, 0x00   ; 0
  1a:   b0 e0   ldi r27, 0x00   ; 0
  1c:   a8 2f   mov r26, r24
  1e:   b9 2f   mov r27, r25
  20:   99 27   eor r25, r25
  22:   88 27   eor r24, r24
  24:   28 2b   or  r18, r24
  26:   39 2b   or  r19, r25
  28:   4a 2b   or  r20, r26
  2a:   5b 2b   or  r21, r27
  2c:   84 81   ldd r24, Z+4; 0x04
  2e:   90 e0   ldi r25, 0x00   ; 0
  30:   a0 e0   ldi r26, 0x00   ; 0
  32:   b0 e0   ldi r27, 0x00   ; 0
  34:   28 2b   or  r18, r24
  36:   39 2b   or  r19, r25
  38:   4a 2b   or  r20, r26
  3a:   5b 2b   or  r21, r27
  3c:   83 81   ldd r24, Z+3; 0x03
  3e:   90 e0   ldi r25, 0x00   ; 0
  40:   a0 e0   ldi r26, 0x00   ; 0
  42:   b0 e0   ldi r27, 0x00   ; 0
  44:   ba 2f   mov r27, r26
  46:   a9 2f   mov r26, r25
  48:   98 2f   mov r25, r24
  4a:   88 27   eor r24, r24
  4c:   28 2b   or  r18, r24
  4e:   39 2b   or  r19, r25
  50:   4a 2b   or  r20, r26
  52:   5b 2b   or  r21, r27
  54:   62 2f   mov r22, r18
  56:   73 2f   mov r23, r19
  58:   84 2f   mov r24, r20
  5a:   95 2f   mov r25, r21
  5c:   08 95   ret


-- 


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

[Bug fortran/39688] IMPORT of derived type fails

[janus at gcc dot gnu dot org]

--- Comment #2 from janus at gcc dot gnu dot org  2009-04-24 19:20 ---
Mine. The fix is completely trivial:

Index: gcc/fortran/decl.c
===
--- gcc/fortran/decl.c  (Revision 146676)
+++ gcc/fortran/decl.c  (Arbeitskopie)
@@ -2741,7 +2741,7 @@
  goto next_item;
}

- st = gfc_new_symtree (&gfc_current_ns->sym_root, name);
+ st = gfc_new_symtree (&gfc_current_ns->sym_root, sym->name);
  st->n.sym = sym;
  sym->refs++;
  sym->attr.imported = 1;


-- 

janus at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |janus at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2009-04-24 17:59:23 |2009-04-24 19:20:15
   date||


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

[Bug c++/38841] valgrind finds problem for broken C++ code

[dcb314 at hotmail dot com]

--- Comment #2 from dcb314 at hotmail dot com  2009-04-24 18:54 ---
(In reply to comment #1)
> With 4.5.0 snapshot (r146637) valgrind shows no errors for both utf16-4.C and
> utf32-4.C.  Closing for now, please reopen if you can reproduce it.

I can reproduce it with the snapshot 20090423.

No more recent snapshot available, so re-opening it.


-- 

dcb314 at hotmail dot com changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|WORKSFORME  |


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

[Bug other/39888] New: TLS emutls not linked to automatically on Darwin

[fago at earthlink dot net]

Using thread local storage (e.g. OpenMP ThreadPrivate variables) on Darwin
requires manually linking to TLS emutls, via either -lgcc_s.so.1 or -lgcc_eh

See the threads:
http://gcc.gnu.org/ml/gcc/2008-12/msg00145.html
http://gcc.gnu.org/ml/gcc/2008-12/msg00107.html

>From the above threads, this is evidently quite a mess. However, as I was just
bit by this I hoped it useful to have a bug tracking the issue.

I just ran across this with a fresh bootstrap of gcc 4.4.0 on MacOSX 10.5.6
x86_64, configured as: "--program-suffix=-4.4 --enable-languages=c,c++,fortran"

TLS works fine if I manually link to gcc_s.so.1 or gcc_eh as mentioned above.


-- 
   Summary: TLS emutls not linked to automatically on Darwin
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fago at earthlink dot net


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

[Bug fortran/39879] double free or corruption abort with gfortran

[kargl at gcc dot gnu dot org]

-- 

kargl at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-04-24 18:00:01
   date||


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

[Bug fortran/39688] IMPORT of derived type fails

[janus at gcc dot gnu dot org]

--- Comment #1 from janus at gcc dot gnu dot org  2009-04-24 17:59 ---
Confirmed. Here is a reduced test case, which does not have the problem with T2
discussed in comment #0, but still fails with the same error message:

MODULE MOD
  TYPE T1
TYPE(T1), POINTER :: P
  END TYPE
END

PROGRAM MAIN
  USE MOD, T3 => T1
  INTERFACE SUBR
SUBROUTINE SUBR1(X)
  IMPORT T3
  TYPE(T3) X
END SUBROUTINE
  END INTERFACE
END

The error only appears if the imported type is renamed in the USE statement.


-- 

janus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-04-24 17:59:23
   date||


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

[Bug fortran/39879] double free or corruption abort with gfortran

[kargl at gcc dot gnu dot org]

--- Comment #6 from kargl at gcc dot gnu dot org  2009-04-24 17:59 ---
The problem is due to the null() in 

character(200), pointer :: descrip => null() 

If you comment out this statement or remove '=> null()',
then the code compiles and runs.  A slighly reduced testcase
is

module test_struct

  interface assignment (=)
module procedure tao_lat_equal_tao_lat
  end interface

  type bunch_params_struct
integer n_live_particle  
  end type

  type tao_lattice_struct
type (bunch_params_struct), allocatable :: bunch_params(:)
type (bunch_params_struct), allocatable :: bunch_params2(:)
  end type

  type tao_universe_struct
type (tao_lattice_struct), pointer :: model, design
character(200), pointer :: descrip => null() 
  end type

  type tao_super_universe_struct
type (tao_universe_struct), allocatable :: u(:)  
  end type

  type (tao_super_universe_struct), save, target :: s

  contains

subroutine tao_lat_equal_tao_lat (lat1, lat2)
  implicit none
  type (tao_lattice_struct), intent(inout) :: lat1
  type (tao_lattice_struct), intent(in) :: lat2
end subroutine

end module

program tao_program
  use test_struct
  implicit none
  type (tao_universe_struct), pointer :: u
  integer n
  allocate (s%u(1))
  u => s%u(1)
  allocate (u%design, u%model)
  n = 112
  allocate (u%model%bunch_params(0:n), u%design%bunch_params(0:n))
  u%model = u%design
  u%model = u%design
end program


-- 


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

[Bug c++/38841] valgrind finds problem for broken C++ code

[lauras at gcc dot gnu dot org]

--- Comment #1 from lauras at gcc dot gnu dot org  2009-04-24 17:00 ---
With 4.5.0 snapshot (r146637) valgrind shows no errors for both utf16-4.C and
utf32-4.C.  Closing for now, please reopen if you can reproduce it.


-- 

lauras at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WORKSFORME


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

[Bug target/39856] [4.4/4.5 Regression] ICE in subst_stack_regs_pat, at reg-stack.c:1386

[vmakarov at redhat dot com]

--- Comment #7 from vmakarov at redhat dot com  2009-04-24 15:53 ---
In gcc4.4 we have before reg-stack.c

(insn 96 82 97 4 /home/vmakarov/build/bb.ii:8 (parallel [
(set (mem/c:SI (plus:SI (reg/f:SI 7 sp)
(const_int 28 [0x1c])) [0 S4 A32])
(fix:SI (reg:DF 9 st(1
(clobber (reg:XF 9 st(1)))
]) 119 {fix_truncsi_i387_fisttp} (expr_list:REG_DEAD (reg:DF 9 st(1))
(nil)))

in subst_stack_regs first it is changed to 

(insn:TI 96 82 97 4 /home/vmakarov/build/bb.ii:8 (parallel [
(set (mem/c:SI (plus:SI (reg/f:SI 7 sp)
(const_int 28 [0x1c])) [0 S4 A32])
(fix:SI (reg:DF 8 st)))
(clobber (reg:XF 9 st(1)))
]) 119 {fix_truncsi_i387_fisttp} (expr_list:REG_DEAD (reg:DF 8 st)
(nil)))

Then it is trying to change clobber and fail because there is no note
about dead or unused reg 9, it fails in subst_stack_regs_pat on the
assert:

if (note)
  emit_pop_insn (insn, regstack, *dest, EMIT_BEFORE);
else
  {
note = find_reg_note (insn, REG_UNUSED, *dest);
gcc_assert (note);
  }


The gcc4.3 has analogous insn before reg-stack.c

(insn 106 92 107 4 bb.ii:8 (parallel [
(set (mem/c:SI (plus:SI (reg/f:SI 7 sp)
(const_int 28 [0x1c])) [0 S4 A8])
(fix:SI (reg:DF 11 st(3
(clobber (reg:XF 11 st(3)))
]) 159 {fix_truncsi_i387_fisttp} (expr_list:REG_DEAD (reg:DF 11 st(3))
(expr_list:REG_UNUSED (reg:XF 11 st(3))
(nil

The difference is in presense of REG_UNUSED (reg:XF 11 st(3)) which
does not permit the gcc_assert aborts gcc4.3.  The note is present
because LR_OUT at BB 4 does not contain 11 st(3).  Quite opposite, 9
st(1) is in LR_OUT at BB 4 in gcc4.4.  Therefore REG_UNUSED note is
not generated for gcc4.4.

So why there is such difference in LR_OUT for 4.3 vs 4.4?  Gcc4.3 is
lucky to use 11 st (3) only in BB3 (where insn 116 is placed).  Gcc4.4
uses 9 st(1) in insn 96 and reuses it in many other BBs.  Because of
partially set register for variable R, we got that LR_OUT is set up in
BB 3.  If somebody is interesting here is the CFG with LR_OUT & LR_IN
and usage of 9 st (1):

0
|
v
2-->
|  |
v  |
3->|  lr_out:9 set 9;use 9;clobber 9
|  |
v  |
4  |  lr_out:9 call
|  |
v  |
5<-   lr_in:9 lr_out:9
|\
| \
6->|  lr_out:9 set 9
|  |
|  |
7  |  lr_in:9 lr_out:9 use 9 .. set 9
|  |
|  |
8<-   lr_in:9 lr_out:9
|\
| \
9  |  lr_in:9  use 9
|  |
|  |
10<-

So the code 

if (note)
  emit_pop_insn (insn, regstack, *dest, EMIT_BEFORE);
else
  {
note = find_reg_note (insn, REG_UNUSED, *dest);
gcc_assert (note);
  }

does not take situation of reusage of hard register for partially set
variable.

IMHO, the code should be

Index: reg-stack.c
===
--- reg-stack.c (revision 146648)
+++ reg-stack.c (working copy)
@@ -1381,11 +1381,9 @@ subst_stack_regs_pat (rtx insn, stack re
if (note)
  emit_pop_insn (insn, regstack, *dest, EMIT_BEFORE);
else
- {
-   note = find_reg_note (insn, REG_UNUSED, *dest);
-   gcc_assert (note);
- }
-   remove_note (insn, note);
+ note = find_reg_note (insn, REG_UNUSED, *dest);
+   if (note)
+ remove_note (insn, note);
replace_reg (dest, FIRST_STACK_REG + 1);
  }
else

I'll send the patch soon.


-- 


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

[Bug tree-optimization/39870] VRP can't see through cast to unsigned

[rguenth at gcc dot gnu dot org]

--- Comment #14 from rguenth at gcc dot gnu dot org  2009-04-24 16:47 
---
May be worth fixing this simple case without fully fixing PR30318.  Like with

Index: tree-vrp.c
===
--- tree-vrp.c  (revision 146590)
+++ tree-vrp.c  (working copy)
@@ -2248,6 +2248,22 @@ extract_range_from_binary_expr (value_ra
 the same end of each range.  */
   min = vrp_int_const_binop (code, vr0.min, vr1.min);
   max = vrp_int_const_binop (code, vr0.max, vr1.max);
+
+  /* If both additions overflowed the range kind is still correct.
+This happens regularly with subtracting something in unsigned
+arithmetic.
+ ???  See PR30318 for all the cases we do not handle.  */
+  if (code == PLUS_EXPR
+ && (TREE_OVERFLOW (min) && !is_overflow_infinity (min))
+ && (TREE_OVERFLOW (max) && !is_overflow_infinity (max)))
+   {
+ min = build_int_cst_wide (TREE_TYPE (min),
+   TREE_INT_CST_LOW (min),
+   TREE_INT_CST_HIGH (min));
+ max = build_int_cst_wide (TREE_TYPE (max),
+   TREE_INT_CST_LOW (max),
+   TREE_INT_CST_HIGH (max));
+   }
 }
   else if (code == MULT_EXPR
   || code == TRUNC_DIV_EXPR


I am testing that patch.


-- 


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

[Bug tree-optimization/39870] VRP can't see through cast to unsigned

[rguenth at gcc dot gnu dot org]

--- Comment #13 from rguenth at gcc dot gnu dot org  2009-04-24 16:41 
---
:
  x_11 = ASSERT_EXPR ;
  x.0_3 = (unsigned int) x_11;
  D.1241_4 = x.0_3 + 0x0;
  if (D.1241_4 > 9)

x.0_3: [1, 10]
D.1241_4: [0, +INF]

so it's only only the usual case of not handling overflow properly during
evaluation.  [1, 10] + -1U is [0(overflow), 9(overflow)] for VRP and so
it falls back to VARYING.  To fix this we need to know the direction
of overflow.  See also PR30318.

The patch I was refering to made VRP able to derive a range from
the D.1241_4 > 9 test.


-- 


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

[Bug target/38571] [arm] -mthumb generates unnecessary padding between functions

[ramana at gcc dot gnu dot org]

--- Comment #7 from ramana at gcc dot gnu dot org  2009-04-24 16:00 ---
(In reply to comment #6)
> The reason why this happens is because FUNCTION_BOUNDARY is defined as just 32
> for both arm and thumb mode.
> 

FUNCTION_BOUNDARY should be 32 for ARM mode and 16 for Thumb mode as defined by
the ARM ELF standard. Testing a patch for this.


-- 

ramana at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |ramana at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2009-04-22 23:09:35 |2009-04-24 16:00:52
   date||


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

[Bug tree-optimization/39870] VRP can't see through cast to unsigned

[ebotcazou at gcc dot gnu dot org]

--- Comment #12 from ebotcazou at gcc dot gnu dot org  2009-04-24 16:15 
---
> The folded a >= C1 && a <= C2 case is correctly handled by VRP btw (I added
> that long time ago).

e...@atlantis:~/build/gcc/native32> cat t.c
extern void link_failure (void);

static int __attribute__ ((noinline)) foo (int x)
{
  if (x >= 1)
if (x <= 10)
  {
if (x < 1 || x > 10)
  link_failure ();
x = x + 1;
  }
  return x;
}

int main (void)
{
  int i = foo (0);
  return 0;
}
e...@atlantis:~/build/gcc/native32> gcc/xgcc -Bgcc -o t t.c -O2
/tmp/ccMEXYFN.o: In function `foo':
t.c:(.text+0x24): undefined reference to `link_failure'
collect2: ld returned 1 exit status
e...@atlantis:~/build/gcc/native32>


-- 


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

[Bug bootstrap/39645] genattrtab.c does not compile under sparc Linux

[ro at techfak dot uni-bielefeld dot de]

--- Comment #4 from ro at techfak dot uni-bielefeld dot de  2009-04-24 
15:41 ---
Subject: Re:  genattrtab.c does not compile under sparc Linux

michael dot a dot richmond at nasa dot gov writes:

> I have not investigated further

Ok, thanks.  The question was addressed more to Laurent, who had taken on
the bug.

Rainer


-- 


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

[Bug c/39886] [4.5 Regression] ICE in purge_dead_edges, at cfgrtl.c:2274

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2009-04-24 15:41 ---
Confirmed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||ice-on-valid-code
   Last reconfirmed|-00-00 00:00:00 |2009-04-24 15:41:03
   date||
Summary|ICE in purge_dead_edges, at |[4.5 Regression] ICE in
   |cfgrtl.c:2274   |purge_dead_edges, at
   ||cfgrtl.c:2274
   Target Milestone|--- |4.5.0
Version|unknown |4.5.0


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

[Bug bootstrap/39645] genattrtab.c does not compile under sparc Linux

[michael dot a dot richmond at nasa dot gov]

--- Comment #3 from michael dot a dot richmond at nasa dot gov  2009-04-24 
15:37 ---
(In reply to comment #2)
> Happens on sparc-sun-solaris2.11 as well, so this seems to be a generic sparc
> issue.  Have you investigated further yet?  Otherwise, I can start a reghunt 
> to
> find the culprit patch.
> 

I have not investigated further


-- 


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

[Bug c++/39887] New: g++ incorrectly reports type error when calling spu_promote()

[jadamcze at utas dot edu dot au]

$ cat break.cpp
#include 

void f(unsigned int ui1) {
vec_uint4 iv1 = spu_promote (ui1, 0);
}

$ spu-elf-g++ break.cpp -c
break.cpp: In function ‘void f(unsigned int)’:
break.cpp:4: note: use -flax-vector-conversions to permit conversions between
vectors with differing element types or numbers of subparts
break.cpp:4: error: cannot convert ‘unsigned char __vector__’ to ‘unsigned int
__vector__’ in initialization


No error if compiled as C.

Using mainline r146726.


-- 
   Summary: g++ incorrectly reports type error when calling
spu_promote()
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jadamcze at utas dot edu dot au
  GCC host triplet: x86_64-pc-linux-gnu
GCC target triplet: spu-elf


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

[Bug bootstrap/39645] genattrtab.c does not compile under sparc Linux

[ro at gcc dot gnu dot org]

--- Comment #2 from ro at gcc dot gnu dot org  2009-04-24 15:34 ---
Happens on sparc-sun-solaris2.11 as well, so this seems to be a generic sparc
issue.  Have you investigated further yet?  Otherwise, I can start a reghunt to
find the culprit patch.


-- 


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

[Bug middle-end/39885] Missed fre optimization

[rguenth at gcc dot gnu dot org]

--- Comment #7 from rguenth at gcc dot gnu dot org  2009-04-24 15:30 ---
But in the end the different types are really the problem.  Several issues
in the value-numberer though:

 - throwing stmts are not value numbered
 - pointers are needlessly value numbered with their types
 - reference ops all have types, but during valueization the types are not
   valueized
 - component refs refer to field decls, thus reference ops are not only
   based on offset/size of the access.

I am testing if value-numbering throwing stmts will pass Java testing.  That
helps functions besides foo at least.


-- 


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

[Bug middle-end/39885] Missed fre optimization

[rguenth at gcc dot gnu dot org]

--- Comment #6 from rguenth at gcc dot gnu dot org  2009-04-24 15:16 ---
One thing is that for Java likely SCCVN isn't very effective for loads/stores
as:

   else if (!gimple_has_lhs (stmt)
   || gimple_has_volatile_ops (stmt)
   || stmt_could_throw_p (stmt))
changed = defs_to_varying (stmt);

and loads/stores may throw.


-- 


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

[Bug c/39886] New: ICE in purge_dead_edges, at cfgrtl.c:2274

[regehr at cs dot utah dot edu]

reg...@john-home:~/volatile/tmp147$ current-gcc -O2 small.c -Wall -c
small.c: In function ‘uint8func’:
small.c:9: internal compiler error: in purge_dead_edges, at cfgrtl.c:2274
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

reg...@john-home:~/volatile/tmp147$ cat small.c

int func(int);

volatile unsigned char g_100;

void uint8func (int p_34)
{
  char l_125 = 0xE1;
  func ((func ((p_34 & g_100) <= l_125), 1));
}

reg...@john-home:~/volatile/tmp147$ current-gcc -v

Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../configure --prefix=/home/regehr/z/tmp/gcc-r146634-install
--program-prefix=r146634- --enable-languages=c,c++
Thread model: posix
gcc version 4.5.0 20090423 (experimental) (GCC)


-- 
   Summary: ICE in purge_dead_edges, at cfgrtl.c:2274
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: regehr at cs dot utah dot edu
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


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

[Bug middle-end/39885] Missed fre optimization

[rguenth at gcc dot gnu dot org]

--- Comment #5 from rguenth at gcc dot gnu dot org  2009-04-24 15:00 ---
:
  # VUSE <.MEMD.1098_46(D)>
  D.254_7 = mmD.199;
  #ref#1#5D.258_8 = D.254_7;

  # D.270_1 = PHI <0(2), D.270_40(6)>
  # D.260_2 = PHI <0(2), D.260_42(6)>
*.LJpc=1008L.0:
  D.262_14 = (struct java.lang.ObjectD.33 *) #ref#1#5D.258_8;
  #ref#4#9D.264_15 = D.262_14;
  #ref#4#9.1D.276_16 = (struct java.lang.ObjectD.33 *) #ref#4#9D.264_15;
  #ref#4#9.2D.277_17 = (struct java.lang.Object[]D.265 *) #ref#4#9.1D.276_16;
  # VUSE <.MEMD.1098_46(D)>
  #slot#4#10D.269_18 = #ref#4#9.2D.277_17->lengthD.266;
  if (D.260_2 >= #slot#4#10D.269_18)
goto  (*.LJpc=1026);
  else
goto ;

:
  D.271_22 = D.262_14;
  #ref#4#9D.264_23 = D.271_22;
  #ref#4#9.3D.279_26 = D.254_7;
  D.280_27 = &#ref#4#9.3D.279_26->dataD.195;
  #slot#5#11.6D.286_30 = (unsigned intD.6) D.260_2;
  # VUSE <.MEMD.1098_46(D)>
  D.287_31 = #ref#4#9.3D.279_26->lengthD.194;


The issue is that both accesses to lenght, while based off the same pointer
in the end are done via dereferences of different types.  The first
one, #ref#4#9.2D.277_17 is of type struct java.lang.Object[]D.265 *
while the second one, #ref#4#9.3D.279_26, is of type struct int[]D.193 *.


-- 


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

[Bug middle-end/39885] Missed fre optimization

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2009-04-24 14:52 ---
  # VUSE <.MEMD.1167_170>
  D.827_47 = #ref#1#4.23D.819_42->lengthD.194;
  D.828_49 = (unsigned intD.6) D.827_47;
  if (D.828_49 <= 2)
goto ;
  else
goto ;

:
  # VUSE <.MEMD.1167_170>
  _Jv_ThrowBadArrayIndexD.121 (2);

:
  # .MEMD.1167_171 = VDEF <.MEMD.1167_170>
  (*D.820_43)[2] = 3;
  #ref#1#4.27D.833_58 = #ref#1#4.15D.791_10;
  D.834_59 = &#ref#1#4.27D.833_58->dataD.195;
  # VUSE <.MEMD.1167_171>
  D.841_63 = #ref#1#4.27D.833_58->lengthD.194;

the store to (*D.820_43)[2] aliases length.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu dot
   ||org


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

[Bug c++/17395] [4.5 Regression] Incorrect lookup for parameters

[dodji at gcc dot gnu dot org]

-- 

dodji at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |dodji at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2005-06-19 15:02:23 |2009-04-24 14:48:07
   date||


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

[Bug middle-end/39885] Missed fre optimization

[aph at gcc dot gnu dot org]

--- Comment #3 from aph at gcc dot gnu dot org  2009-04-24 14:46 ---
Created an attachment (id=17689)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17689&action=view)
Source file


-- 


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

[Bug middle-end/39885] Missed fre optimization

[aph at gcc dot gnu dot org]

--- Comment #2 from aph at gcc dot gnu dot org  2009-04-24 14:45 ---
Created an attachment (id=17688)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17688&action=view)
Smaller class file


-- 

aph at gcc dot gnu dot org changed:

   What|Removed |Added

  Attachment #17687|0   |1
is obsolete||


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

[Bug middle-end/39885] Missed fre optimization

[aph at gcc dot gnu dot org]

--- Comment #1 from aph at gcc dot gnu dot org  2009-04-24 14:42 ---
Created an attachment (id=17687)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17687&action=view)
Class file


-- 


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

[Bug middle-end/39885] New: Missed fre optimization

[aph at gcc dot gnu dot org]

In this case, fre does notnotice some equivalences.


-- 
   Summary: Missed fre optimization
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: aph at gcc dot gnu dot org
  GCC host triplet: x86_64-pc-linux-gnu


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

[Bug fortran/39879] double free or corruption abort with gfortran

[david dot sagan at gmail dot com]

--- Comment #5 from david dot sagan at gmail dot com  2009-04-24 14:27 
---
Sorry. I was going by the documentation on the link ("crashes, loss of data,
severe memory leak"). Thanks for the information.


-- 


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

[Bug fortran/39879] double free or corruption abort with gfortran

[kargl at gcc dot gnu dot org]

--- Comment #4 from kargl at gcc dot gnu dot org  2009-04-24 14:17 ---
This is a fortran problem.  It will never be given
a Severity of Critical or Major, which are typically
used by the GCC developers to denote bootstrap problems
or a problems with the C compiler.


-- 

kargl at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|critical|normal
   Priority|P3  |P4


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

[Bug c++/39884] New: undefined reference

[nilesh dot barange at gmail dot com]

hi 
I am getting following error.
Can any one knows why it is?

[clusu...@vlsiserver mod_lbm1]$ g++  -o testmain testmain.cpp
/tmp/ccQqRHb8.o(.text+0x17c): In function `main':
: undefined reference to `Preprocess(int&, int&, int&, Input*, char*)'
/tmp/ccQqRHb8.o(.text+0x18d): In function `main':
: undefined reference to `DisplayInputArray(Input*, int&)'
/tmp/ccQqRHb8.o(.text+0x1d3): In function `main':
: undefined reference to `Domain::Domain(int&, int&, int&, int, double&,
double)'
/tmp/ccQqRHb8.o(.text+0x20c): In function `main':
: undefined reference to `Domain::InitializeDomain(Input*, int&)'
/tmp/ccQqRHb8.o(.text+0x215): In function `main':
: undefined reference to `Domain::DisplayDomain()'
/tmp/ccQqRHb8.o(.text+0x22d): In function `main':
: undefined reference to `Domain::SimulateDomain()'
/tmp/ccQqRHb8.o(.text+0x236): In function `main':
: undefined reference to `Domain::DisplayDomain()'
/tmp/ccQqRHb8.o(.text+0x269): In function `main':
: undefined reference to `Domain::DisplayDomain()'
collect2: ld returned 1 exit status


-- 
   Summary: undefined reference
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: nilesh dot barange at gmail dot com
 GCC build triplet: undefined reference


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

[Bug fortran/39879] double free or corruption abort with gfortran

[david dot sagan at gmail dot com]

--- Comment #3 from david dot sagan at gmail dot com  2009-04-24 13:06 
---
Corrected severity.


-- 

david dot sagan at gmail dot com changed:

   What|Removed |Added

   Severity|major   |critical


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

[Bug preprocessor/39883] New: preprocessor fails with myassertion

[Denis dot Excoffier at airbus dot com]

glib-2.16.1 fails to compile in scannerapi.c and produces "internal
compiler error". I've dramatically reduced the test case, here it is:
- scannerapi.c
- scannerapi.i
- stderr
- command used: gcc -v -save-temps -o scannerapi.o -c scannerapi.c >& stderr

- scannerapi.c (start) 
#define myassert(n1, cmp, n2) do { signed long __n1 = (n1), \
__n2 = (n2); if (__n1 cmp __n2) ; else myassert_message \
(__FILE__, __PRETTY_FUNCTION__, #n1 " " #cmp " " #n2, __n1, \
#cmp, __n2); } while (0)

void myassert_message (
 char const   *file,
 char const   *func,
 char const   *expr,
 long double  g1,
 char const   *cmp,
 long double  g2
   ) __attribute__((__noreturn__));

typedef struct {
  struct _GScanner *scanner;
} SF;

void test_scanner_tokens (void) {
  SF *fix;
  char buf[] = "1234567";
  int const buflen = undeclared0(buf);
  char mytokbuf[] = "abcde";
  int i;

  undeclared2 (fix->scanner, buf, buflen);
  myassert (undeclared3 (fix->scanner), ==, 1);
  undeclared5 (fix->scanner);
  myassert (undeclared1 (fix->scanner), ==, 0);
  myassert (undeclared4 (fix->scanner), ==, mytokbuf[0]);
  for (i = 1; i < 1; i++) {
myassert (undeclared5 (fix->scanner), ==, mytokbuf[i]);
  };
  myassert (undeclared5 (fix->scanner), ==, 0);
  return;
}
- scannerapi.c (end) 

- scannerapi.i (start) 
# 1 "scannerapi.c"
# 1 ""
# 1 ""
# 1 "scannerapi.c"





void myassert_message (
 char const *file,
 char const *func,
 char const *expr,
 long double g1,
 char const *cmp,
 long double g2
   ) __attribute__((__noreturn__));

typedef struct {
  struct _GScanner *scanner;
} SF;

void test_scanner_tokens (void) {
  SF *fix;
  char buf[] = "1234567";
  int const buflen = undeclared0(buf);
  char mytokbuf[] = "abcde";
  int i;

  undeclared2 (fix->scanner, buf, buflen);
  do { signed long __n1 = (undeclared3 (fix->scanner)), __n2 = (1); if (__n1 ==
__n2) ; else myassert_message ("scannerapi.c", __PRETTY_FUNCTION__,
"undeclared3 (fix->scanner)" " " "==" " " "1", __n1, "==", __n2); } while (0);
  undeclared5 (fix->scanner);
  do { signed long __n1 = (undeclared1 (fix->scanner)), __n2 = (0); if (__n1 ==
__n2) ; else myassert_message ("scannerapi.c", __PRETTY_FUNCTION__,
"undeclared1 (fix->scanner)" " " "==" " " "0", __n1, "==", __n2); } while (0);
  do { signed long __n1 = (undeclared4 (fix->scanner)), __n2 = (mytokbuf[0]);
if (__n1 == __n2) ; else myassert_message ("scannerapi.c", __PRETTY_FUNCTION__,
"undeclared4 (fix->scanner)" " " "==" " " "mytokbuf[0]", __n1, "==", __n2); }
while (0);
  for (i = 1; i < 1; i++) {
do { signed long __n1 = (undeclared5 (fix->scanner)), __n2 = (mytokbuf[i]);
if (__n1 == __n2) ; else myassert_message ("scannerapi.c", __PRETTY_FUNCTION__,
"undeclared5 (fix->scanner)" " " "==" " " "mytokbuf[i]", __n1, "==", __n2); }
while (0);
  };
  do { signed long __n1 = (undeclared5 (fix->scanner)), __n2 = (0); if (__n1 ==
__n2) ; else myassert_message ("scannerapi.c", __PRETTY_FUNCTION__,
"undeclared5 (fix->scanner)" " " "==" " " "0", __n1, "==", __n2); } while (0);
  return;
}
- scannerapi.i (end) 

- stderr (start) 
Using built-in specs.
Target: sparc64-sun-solaris2.8
Configured with: /tmp/local/tmp/gcc/gcc-4.4.0/configure
--prefix=/tmp/local/unixutil/gcc-4.4.0 --with-local-prefix=/usr/local/myplace
--enable-languages=c,c++,fortran --with-gmp=/tmp/local/unixutil/gmpTMP
--with-mpfr=/tmp/local/unixutil/mpfrTMP --with-cpu=v9
--build=sparc64-sun-solaris2.8 --disable-multilib
Thread model: posix
gcc version 4.4.0 (GCC) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-o' 'scannerapi.o' '-c' '-mcpu=v9'

/tmp/local/unixutil/gcc-4.4.0/bin/../libexec/gcc/sparc64-sun-solaris2.8/4.4.0/cc1
-E -quiet -v -iprefix
/tmp/local/unixutil/gcc-4.4.0/bin/../lib/gcc/sparc64-sun-solaris2.8/4.4.0/
-D__arch64__ -D__sparcv9 scannerapi.c -mcpu=v9 -fpch-preprocess -o scannerapi.i
ignoring nonexistent directory
"/tmp/local/unixutil/gcc-4.4.0/bin/../lib/gcc/sparc64-sun-solaris2.8/4.4.0/../../../../sparc64-sun-solaris2.8/include"
ignoring nonexistent directory "/usr/local/myplace/include"
ignoring duplicate directory
"/tmp/local/unixutil/gcc-4.4.0/bin/../lib/gcc/../../lib/gcc/sparc64-sun-solaris2.8/4.4.0/include"
ignoring duplicate directory
"/tmp/local/unixutil/gcc-4.4.0/bin/../lib/gcc/../../lib/gcc/sparc64-sun-solaris2.8/4.4.0/include-fixed"
ignoring nonexistent directory
"/tmp/local/unixutil/gcc-4.4.0/bin/../lib/gcc/../../lib/gcc/sparc64-sun-solaris2.8/4.4.0/../../../../sparc64-sun-solaris2.8/include"
#include "..." search starts here:
#include <...> search starts here:

/tmp/local/unixutil/gcc-4.4.0/bin/../lib/gcc/sparc64-sun-solaris2.8/4.4.0/include

/tmp/local/unixutil/gcc-4.4.0/bin/../lib/gcc/sparc64-sun-solaris2.8/4.4.0/include-fixed
 /tmp/local/unixutil/gcc-4.4.0/bin/../lib/gcc/../../include
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-o' 'scanner

[Bug fortran/39876] module procedure name that collides with the GNU intrinsic

[dominiq at lps dot ens dot fr]

--- Comment #3 from dominiq at lps dot ens dot fr  2009-04-24 12:32 ---
> This patch allows the code in comment #2 to compile with -std=f95.
> Don't know if it is correct.
> ...

This will remove diagnostic, but not the cause.  I think the problem comes from
redundant information that are inconsistant, probably 

  attr = {
allocatable = 0, 
dimension = 0, 
external = 1,<---
intrinsic = 0, 
...
if_source = IFSRC_DECL, 
proc = PROC_MODULE,<--- 
cray_pointer = 0, 
cray_pointee = 0, 
alloc_comp = 0, 
pointer_comp = 0, 
private_comp = 0, 
zero_comp = 0, 
volatile_ns = 0x0
  }, 

>From the little I understand 'external' should not be set to 1 for functions
listed as intrinsics but not f95 intrinsics.


-- 


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

[Bug middle-end/39867] [4.4/4.5 Regression] Wrong result of conditional operator exp < 2 ? 2U : (unsigned int) exp

[bonzini at gnu dot org]

--- Comment #5 from bonzini at gnu dot org  2009-04-24 11:35 ---
Subject: Bug 39867

Author: bonzini
Date: Fri Apr 24 11:34:59 2009
New Revision: 146702

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146702
Log:
2009-04-24  Paolo Bonzini  

PR middle-end/39867
* fold-const.c (fold_cond_expr_with_comparison): When folding
> and >= to MAX, make sure the MAX uses the same type as the
comparison's operands.

testsuite:
2009-04-24  Paolo Bonzini  

PR middle-end/39867
* gcc.dg/pr39867.c: New.


Added:
branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/pr39867.c
  - copied unchanged from r146695, trunk/gcc/testsuite/gcc.dg/pr39867.c
Modified:
branches/gcc-4_4-branch/gcc/ChangeLog
branches/gcc-4_4-branch/gcc/fold-const.c
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog


--- Comment #6 from bonzini at gnu dot org  2009-04-24 11:35 ---
committed to both branches.


-- 

bonzini at gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug middle-end/39867] [4.4/4.5 Regression] Wrong result of conditional operator exp < 2 ? 2U : (unsigned int) exp

[bonzini at gcc dot gnu dot org]

--- Comment #5 from bonzini at gnu dot org  2009-04-24 11:35 ---
Subject: Bug 39867

Author: bonzini
Date: Fri Apr 24 11:34:59 2009
New Revision: 146702

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146702
Log:
2009-04-24  Paolo Bonzini  

PR middle-end/39867
* fold-const.c (fold_cond_expr_with_comparison): When folding
> and >= to MAX, make sure the MAX uses the same type as the
comparison's operands.

testsuite:
2009-04-24  Paolo Bonzini  

PR middle-end/39867
* gcc.dg/pr39867.c: New.


Added:
branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/pr39867.c
  - copied unchanged from r146695, trunk/gcc/testsuite/gcc.dg/pr39867.c
Modified:
branches/gcc-4_4-branch/gcc/ChangeLog
branches/gcc-4_4-branch/gcc/fold-const.c
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug middle-end/39867] [4.4/4.5 Regression] Wrong result of conditional operator exp < 2 ? 2U : (unsigned int) exp

[bonzini at gcc dot gnu dot org]

--- Comment #4 from bonzini at gnu dot org  2009-04-24 10:29 ---
Subject: Bug 39867

Author: bonzini
Date: Fri Apr 24 10:29:18 2009
New Revision: 146695

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146695
Log:
2009-04-24  Paolo Bonzini  

PR middle-end/39867
* fold-const.c (fold_cond_expr_with_comparison): When folding
> and >= to MAX, make sure the MAX uses the same type as the
comparison operands.

testsuite:
2009-04-24  Paolo Bonzini  

PR middle-end/39867
* gcc.dg/pr39867.c: New.


Added:
trunk/gcc/testsuite/gcc.dg/pr39867.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/fold-const.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug libstdc++/39882] New: error_code constructor and assignment postconditions not met

[chris_kohlhoff at internet-mail dot org]

This is the same problem as 39881, but for error_code.

The constructor and assignment operator that take a ErrorCodeEnum both have the
postcondition: *this == make_error_code(e). The system_error header as of 4.4.0
does not meet this postcondition, because it always initialises the error_code
using the generic_category().

The following code:

  #include 
  #include 

  enum my_errc { my_err = 0 };

  class my_error_category_impl
: public std::error_category
  {
  public:
const char* name() const { return ""; }
std::string message(int) const { return ""; }
  } my_error_category_instance;

  std::error_code make_error_code(my_errc e)
  {
return std::error_code(
static_cast(e),
my_error_category_instance);
  }

  namespace std {
template <>
struct is_error_code_enum
  : public true_type {};
  }

  int main()
  {
std::error_code ec1(my_err);
if (ec1 == make_error_code(my_err))
  std::cout << "postcondition met\n";
else
  std::cout << "postcondition not met\n";

std::error_code ec2;
ec2 = my_err;
if (ec2 == make_error_code(my_err))
  std::cout << "postcondition met\n";
else
  std::cout << "postcondition not met\n";
  }

Currently outputs:

  postcondition not met
  postcondition not met

when it should output:

  postcondition met
  postcondition met


-- 
   Summary: error_code constructor and assignment postconditions not
met
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: chris_kohlhoff at internet-mail dot org


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

[Bug libstdc++/39881] New: error_condition constructor and assignment postconditions not met

[chris_kohlhoff at internet-mail dot org]

The constructor and assignment operator that take a ErrorConditionEnum both
have the postcondition: *this == make_error_condition(e). The system_error
header as of 4.4.0 does not meet this postcondition, because it always
initialises the error_condition using the generic_category().

The following code:

  #include 
  #include 

  enum my_errc { my_err = 0 };

  class my_error_category_impl
: public std::error_category
  {
  public:
const char* name() const { return ""; }
std::string message(int) const { return ""; }
  } my_error_category_instance;

  std::error_condition make_error_condition(my_errc e)
  {
return std::error_condition(
static_cast(e),
my_error_category_instance);
  }

  namespace std {
template <>
struct is_error_condition_enum
  : public true_type {};
  }

  int main()
  {
std::error_condition ec1(my_err);
if (ec1 == make_error_condition(my_err))
  std::cout << "postcondition met\n";
else
  std::cout << "postcondition not met\n";

std::error_condition ec2;
ec2 = my_err;
if (ec2 == make_error_condition(my_err))
  std::cout << "postcondition met\n";
else
  std::cout << "postcondition not met\n";
  }

Currently outputs:

  postcondition not met
  postcondition not met

when it should output:

  postcondition met
  postcondition met


-- 
   Summary: error_condition constructor and assignment
postconditions not met
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: chris_kohlhoff at internet-mail dot org


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

[Bug libstdc++/39880] New: Specialisation is_error_code_enum should not exist

[chris_kohlhoff at internet-mail dot org]

The system_error header incorrectly provides the specialisation:

 template<>
   struct is_error_code_enum
   : public true_type { };

Only is_error_condition_enum should be specialised. The spurious
specialisation causes the following code to fail to compile:

  #include 

  int main()
  {
std::error_code ec;
if (ec == std::errc::not_supported)
  ;
  }

with error:

a.cpp: In function âint main()â:
a.cpp:6: error: ambiguous overload for âoperator==â in âec == (std::errc)95â
/usr/include/c++/4.4/system_error:279: note: candidates are: bool
std::operator==(const std::error_code&, const std::error_condition&)
/usr/include/c++/4.4/system_error:274: note: bool
std::operator==(const std::error_code&, const std::error_code&)

Expected result: code should compile without warning or error.


-- 
   Summary: Specialisation is_error_code_enum should not exist
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: chris_kohlhoff at internet-mail dot org


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

[Bug c++/39875] [4.5 regression] Wrong "value computed is not used" warning

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.5.0


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

[Bug middle-end/28685] Multiple comparisons are not simplified

[rguenth at gcc dot gnu dot org]

--- Comment #6 from rguenth at gcc dot gnu dot org  2009-04-24 09:24 ---
*** Bug 39874 has been marked as a duplicate of this bug. ***


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||alexvod at google dot com


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

[Bug tree-optimization/39874] [4.4 regression] missing VRP (submission)

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2009-04-24 09:24 ---


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


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug middle-end/28685] Multiple comparisons are not simplified

[rguenth at gcc dot gnu dot org]

--- Comment #5 from rguenth at gcc dot gnu dot org  2009-04-24 09:24 ---
Another case:

void func();
void test(char *signature)
{
  char ch = signature[0];
  if (ch == 15 || ch == 3)
  {
if (ch == 15) func();
  }
}


-- 


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

[Bug tree-optimization/39870] VRP can't see through cast to unsigned

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|normal  |enhancement
   Keywords||missed-optimization


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

[Bug tree-optimization/39870] VRP can't see through cast to unsigned

[rguenth at gcc dot gnu dot org]

--- Comment #11 from rguenth at gcc dot gnu dot org  2009-04-24 09:21 
---
The folded a >= C1 && a <= C2 case is correctly handled by VRP btw (I added
that long time ago).


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu dot
   ||org


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

[Bug rtl-optimization/39871] [4.3/4.4/4.5 regression] CSE doesn't work

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords||missed-optimization
   Target Milestone|--- |4.3.4


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

[Bug target/33036] LINUX_DYNAMIC_LINKER undefined in gcc-4.2.1/gcc/config/arm/linux-elf.h

[ramana at gcc dot gnu dot org]

--- Comment #3 from ramana at gcc dot gnu dot org  2009-04-24 09:05 ---
(In reply to comment #2)
> Does this mean the target "arm-none-uclinux" is unsupported?
> 
> I checked again, using (binutils-2.17 and) gcc-4.3.3 from mirror site
> ftp://ftp.gwdg.de/pub/misc/gcc/releases/gcc-4.3.3/gcc-4.3.3.tar.bz2
> 
> Configuration was:
> 
> ./configure --prefix=/prefix --build=i686-pc-linux-gnu 
> --host=i686-pc-linux-gnu
> --target=arm-none-uclinux --disable-nls --disable-shared --enable-languages=c
> --disable-threads --disable-tls --with-sysroot=/prefix/sysroot --with-gnu-as
> --with-gnu-ld --without-headers
> 
> I can confirm, that fixing my typo resolved the above issues. But I get 
> several
> other errors. I guess this is a different issue?!
> 

that must be a different issue . I'd suggest you file a fresh bug entry for
that as well as consider using the new ABI with arm-uclinux-eabi if you need
to.

Thanks.
Ramana


-- 

ramana at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||INVALID


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

[Bug fortran/39879] double free or corruption abort with gfortran

[dominiq at lps dot ens dot fr]

--- Comment #2 from dominiq at lps dot ens dot fr  2009-04-24 08:54 ---
Confirmed for gfortran 4.3.3, 4.4.0, and trunk; no error with 4.2.3.

g95 0.91 gives:

 Setting bunch_params 113 113
 Have set
 After 1st set
 Setting bunch_params 113 113
 Have set
 End
Remaining memory: 10848 bytes at 00800218 allocated at line 95 of pr39879.f90
Remaining memory: 60 bytes at 00100418 allocated at line 92 of pr39879.f90
Remaining memory: 224 bytes at 00100318 allocated at line 89 of pr39879.f90
Remaining memory: 60 bytes at 00100478 allocated at line 92 of pr39879.f90
Remaining memory: 10848 bytes at 00802e18 allocated at line 96 of pr39879.f90

and g95 0.92 (Apr 22 2009)

...
 End
Remaining memory: 68 bytes at 001003b8 allocated at line 92 of pr39879.f90
Remaining memory: 228 bytes at 001002b8 allocated at line 89 of pr39879.f90
Remaining memory: 68 bytes at 00100418 allocated at line 92 of pr39879.f90
Remaining memory: 10848 bytes at 00802e18 allocated at line 96 of pr39879.f90

Adding the lines

  deallocate (u%model%bunch_params)
  deallocate (u%design%bunch_params)
  deallocate (u%design, u%model)
  deallocate (s%u)

make g95 0.91 happy, g95 0.92 gives

...
 End
At line 102 of file pr39879_db.f90
Traceback: not available, compile with -ftrace=frame or -ftrace=full
Fortran runtime error: Deallocated a bad pointer

gfortran 4.2.3 is also happy, while the other versions give

...
 Have set
a.out(67213) malloc: *** error for object 0x809200: double free
*** set a breakpoint in malloc_error_break to debug
 End
a.out(67213) malloc: *** error for object 0x809200: double free
*** set a breakpoint in malloc_error_break to debug


-- 


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

[Bug fortran/39864] [4.5 Regression] INTRINSIC :: RESHAPE causes spurious error

[janus at gcc dot gnu dot org]

--- Comment #4 from janus at gcc dot gnu dot org  2009-04-24 08:39 ---
Fixed by r146677. Closing.


-- 

janus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug fortran/39861] [4.5 Regression] ICE with INTRINSIC in module: write_symbol(): bad module symbol

[janus at gcc dot gnu dot org]

--- Comment #5 from janus at gcc dot gnu dot org  2009-04-24 08:39 ---
Fixed by r146677. Closing.


-- 

janus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug fortran/39864] [4.5 Regression] INTRINSIC :: RESHAPE causes spurious error

[janus at gcc dot gnu dot org]

--- Comment #3 from janus at gcc dot gnu dot org  2009-04-24 08:34 ---
Subject: Bug 39864

Author: janus
Date: Fri Apr 24 08:34:14 2009
New Revision: 146677

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146677
Log:
2009-04-24  Janus Weil  

PR fortran/39861
PR fortran/39864
* symbol.c (gfc_copy_formal_args_intr): Set attr.flavor and attr.dummy
for the formal arguments.


2009-04-24  Janus Weil  

PR fortran/39861
PR fortran/39864
* gfortran.dg/intrinsic_1.f90: New.


Added:
trunk/gcc/testsuite/gfortran.dg/intrinsic_1.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/symbol.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug fortran/39861] [4.5 Regression] ICE with INTRINSIC in module: write_symbol(): bad module symbol

[janus at gcc dot gnu dot org]

--- Comment #4 from janus at gcc dot gnu dot org  2009-04-24 08:34 ---
Subject: Bug 39861

Author: janus
Date: Fri Apr 24 08:34:14 2009
New Revision: 146677

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146677
Log:
2009-04-24  Janus Weil  

PR fortran/39861
PR fortran/39864
* symbol.c (gfc_copy_formal_args_intr): Set attr.flavor and attr.dummy
for the formal arguments.


2009-04-24  Janus Weil  

PR fortran/39861
PR fortran/39864
* gfortran.dg/intrinsic_1.f90: New.


Added:
trunk/gcc/testsuite/gfortran.dg/intrinsic_1.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/symbol.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug fortran/39791] [4.3 Regression] Bad Dwarf debug information from gfortran for a character string.

[burnus at gcc dot gnu dot org]

--- Comment #4 from burnus at gcc dot gnu dot org  2009-04-24 07:25 ---
FIXED for 4.3.4. The original patch for the 4.4 trunk was
http://gcc.gnu.org/ml/gcc-patches/2008-08/msg01700.html


-- 

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

[Bug fortran/39791] [4.3 Regression] Bad Dwarf debug information from gfortran for a character string.

[burnus at gcc dot gnu dot org]

--- Comment #3 from burnus at gcc dot gnu dot org  2009-04-24 07:19 ---
Subject: Bug 39791

Author: burnus
Date: Fri Apr 24 07:19:12 2009
New Revision: 146672

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146672
Log:
2009-04-24  Tobias Burnus  

PR fortran/39791
Backport from mainline:

2008-08-22  Jakub Jelinek  

* dwarf2out.c (add_subscript_info): Stop on Fortran
* TYPE_STRING_FLAG
types.
(gen_array_type_die): Emit DW_TAG_string_type for Fortran
character types.


Modified:
branches/gcc-4_3-branch/gcc/ChangeLog
branches/gcc-4_3-branch/gcc/dwarf2out.c


-- 


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