[Bug rtl-optimization/41917] [4.3 Regression] Strange athrithmetic result with -O3

[bonzini at gcc dot gnu dot org]

--- Comment #6 from bonzini at gnu dot org  2010-02-16 08:15 ---
Subject: Bug 41917

Author: bonzini
Date: Tue Feb 16 08:15:37 2010
New Revision: 156795

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156795
Log:
PR rtl-optimization/41917

* rtlanal.c (num_sign_bit_copies1) : If sign bit of second
operand isn't known to be 0, return 1.

testsuite:
* gcc.c-torture/execute/pr41917.c: New test.


Added:
branches/gcc-4_3-branch/gcc/testsuite/gcc.c-torture/execute/pr41917.c
Modified:
branches/gcc-4_3-branch/gcc/ChangeLog
branches/gcc-4_3-branch/gcc/rtlanal.c
branches/gcc-4_3-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug rtl-optimization/41917] [4.3 Regression] Strange athrithmetic result with -O3

[bonzini at gnu dot org]

--- Comment #7 from bonzini at gnu dot org  2010-02-16 08:16 ---
Committed the patch to 4.3 too


-- 

bonzini at gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
  Known to work|4.2.4 4.4.3 4.5.0   |4.2.4 4.3.5 4.4.3 4.5.0
 Resolution||FIXED


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

[Bug fortran/43040] Wrong decl for mathbuiltins -> wrong code with LTO

[burnus at gcc dot gnu dot org]

--- Comment #4 from burnus at gcc dot gnu dot org  2010-02-16 08:35 ---
Subject: Bug 43040

Author: burnus
Date: Tue Feb 16 08:35:05 2010
New Revision: 156796

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156796
Log:
2010-02-16  Tobias Burnus  

PR fortran/43040
* gfortran.h (gfc_isym_id): Rename GFS_ISYM_GAMMA to
* GFS_ISYM_TGAMMA.
* intrinsic.c (add_functions): Ditto.
* iresolve.c (gfc_resolve_gamma): Call tgamma instead of gamma.
* mathbuiltins.def: Use TGAMMA instead of GAMMA with "tgamma".


Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/gfortran.h
trunk/gcc/fortran/intrinsic.c
trunk/gcc/fortran/iresolve.c
trunk/gcc/fortran/mathbuiltins.def


-- 


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

[Bug fortran/43078] gfortran: spurious warning of line truncation at col 72

[patrick dot wallace at stfc dot ac dot uk]

--- Comment #3 from patrick dot wallace at stfc dot ac dot uk  2010-02-16 
08:49 ---
Subject: RE:  gfortran: spurious warning of line truncation at col 72

> Works for me with both 4.4.2 and trunk.

Mystery solved.  It is to do with line endings.  When gfortran sees
a file with DOS line endings it interprets the CR and LF as separate
characters.  This is why demonstrating the effect is so slippery.

I guess gfortran is within its rights to work this way, and only
accept Unix line endings.  But I would argue that this is unhelpful,
and that it would be better to make gfortran detect the condition
and deal with it sympathetically.


Patrick Wallace

Space Science & Technology Department+44-1235-445372 tel
STFC / Rutherford Appleton Laboratory+44-1235-446362 fax
Harwell Science and Innovation Campus  p...@star.rl.ac.uk
Didcot, Oxfordshire, OX11 0QX, UK patrick.wall...@stfc.ac.uk

--
Scanned by iCritical.


-- 


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

[Bug fortran/41869] ICE segfault when reading module file

[paul dot richard dot thomas at gmail dot com]

--- Comment #9 from paul dot richard dot thomas at gmail dot com  
2010-02-16 08:59 ---
Subject: Re:  ICE segfault when reading module file

> Ditto. (Don't forget "gfc_symbol *sym;" as I did in my posted patch as I 
> failed
> to split three patches correctly.)

***grin***

OK - Paul


-- 


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

[Bug fortran/36932] unneeded temporary (2x)

[pault at gcc dot gnu dot org]

--- Comment #10 from pault at gcc dot gnu dot org  2010-02-16 09:04 ---
(In reply to comment #6)

Joost,

I held back from committing the patch this morning because I noticed that your
testcase below is also calling pack/unpack like it is going out of business. 

I have to confess that I looked into this because one of the maintainers
(Dominique, I think) asked me if I understood the fix to this segfault.  My
off-the-cuff response was CLASSes but I see that this cannot entirely be the
case.  In investigating, I found these extra temporaries and have eliminated
them.  However, I did not have time to regtest and get the new patch to you.

Paul
> (In reply to comment #5)
> > I had to exclude
> > dummies but I now do not recall why.  I'll look into it.
> 
> Hi Paul,
> 
> tested your patch at http://gcc.gnu.org/ml/fortran/2010-02/msg00106.html.
> 
> However, this ICEs with:
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x00550816 in gfc_conv_array_parameter (se=0x7fff19b82f90,
> expr=0x13af600, ss=0x13b1e20, g77=1, fsym=0x0,
> proc_name=0x7f450fd48ee8 "newuob", size=0x0) at
> /data03/vondele/gcc_trunk/gcc/gcc/fortran/trans-array.c:5550
> 5550  if (contiguous && g77 && !this_array_result
> (gdb) list
> 5545  se->expr = gfc_conv_array_data (tmp);
> 5546  return;
> 5547}
> 5548}
> 5549
> 5550  if (contiguous && g77 && !this_array_result
> 5551&& expr->symtree->n.sym->as->type != AS_ASSUMED_SHAPE)
> 5552{
> 5553  gfc_conv_expr_descriptor (se, expr, ss);
> 5554  if (expr->ts.type == BT_CHARACTER)
> (gdb) q
> 
> on the following reduced testcase.
> 
> MODULE powell
>   INTEGER, PARAMETER :: dp=8
>   TYPE opt_state_type
> REAL(dp), DIMENSION(:), POINTER  :: w
>   END TYPE opt_state_type
> CONTAINS
>   SUBROUTINE newuoa (n,x,optstate)
> TYPE(opt_state_type) :: optstate
> CALL newuob (optstate%w(ixb:),optstate%w(ixo:),&
>  optstate%w(ivl:),optstate%w(iw:),optstate)
>   END SUBROUTINE newuoa
> END MODULE powell
> 


-- 


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

[Bug fortran/36932] unneeded temporary (2x)

[jv244 at cam dot ac dot uk]

--- Comment #11 from jv244 at cam dot ac dot uk  2010-02-16 09:22 ---
(In reply to comment #10)
> (In reply to comment #6)
> 
> Joost,
> 
> I held back from committing the patch this morning because I noticed that your
> testcase below is also calling pack/unpack like it is going out of business. 
> 
> I have to confess that I looked into this because one of the maintainers
> (Dominique, I think) asked me if I understood the fix to this segfault.  My
> off-the-cuff response was CLASSes but I see that this cannot entirely be the
> case.  In investigating, I found these extra temporaries and have eliminated
> them.  However, I did not have time to regtest and get the new patch to you.

Hi Paul

not sure I understand your full reply. However, for the testcase below, I guess
there have to be pack/unpacks, since newuob has an implicit interface and
optstate%w(i:) is a slice from a 'pointer array', and thus packing is needed to
guarantee things are contiguous. But I'm sure you know :-)

Having said that, there is no pressure from my side to commit patches. Just
commit whenever you think they are in good shape, ready, understood...

Joost

> > MODULE powell
> >   INTEGER, PARAMETER :: dp=8
> >   TYPE opt_state_type
> > REAL(dp), DIMENSION(:), POINTER  :: w
> >   END TYPE opt_state_type
> > CONTAINS
> >   SUBROUTINE newuoa (n,x,optstate)
> > TYPE(opt_state_type) :: optstate
> > CALL newuob (optstate%w(ixb:),optstate%w(ixo:),&
> >  optstate%w(ivl:),optstate%w(iw:),optstate)
> >   END SUBROUTINE newuoa
> > END MODULE powell
> > 
> 


-- 


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

[Bug objc/43061] 47 new GCC h...@156527 regressions

[developer at sandoe-acoustics dot co dot uk]

--- Comment #30 from developer at sandoe-acoustics dot co dot uk  
2010-02-16 09:23 ---
apropos 
http://gcc.gnu.org/ml/gcc-patches/2010-02/msg00587.html

do you think that _OBJC_CLASS_REFERENCES_* and _OBJC_SELECTOR_REFERENCES_*
should be marked as TREE_ADDRESSABLE and DECL_PRESERVE_P in anticipation that
this change (ipa* and cgraphunit responding to PRESERVE_P) will occur in the
future?

(I took those changes out of this patch on the grounds that they didn't
currently achieve anything).


-- 


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

[Bug tree-optimization/43089] New: Optimizer ignores type in a conversion

[0xe2 dot 0x9a dot 0x9b at gmail dot com]

#include 
#include 

struct AB {
unsigned a:1;
unsigned b:31;
};

int main(int argc, char **argv) {
unsigned in;
struct AB ab;
unsigned b2;

sscanf(argv[1], "%x", &in);
ab = (struct AB){0,in};

b2 = ab.b + ab.b;
assert(!(b2 <= 0x7fff));

return 0;
}

Architecture: i386
Command line: ./a.out 7fff
Succeeds when compiled with: gcc -O0 ...
Fails when compiled with: gcc -O2 ...
Expected behavior: the program should execute successfully

Possible explanation: In the expression (ab.b + ab.b), the bit-field "b" gets
converted into an int. The addition is therefore of type (int+int), with an
(int) as result. The (int) result is then converted into an (unsigned int) -
but this step is skipped when using -O2, which leads the compiler to the wrong
conclusion that (b2 <= 0x7fff) is always true.


-- 
   Summary: Optimizer ignores type in a conversion
   Product: gcc
   Version: 4.4.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: 0xe2 dot 0x9a dot 0x9b at gmail dot com


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

[Bug objc/43061] 47 new GCC h...@156527 regressions

[jakub at gcc dot gnu dot org]

--- Comment #31 from jakub at gcc dot gnu dot org  2010-02-16 10:06 ---
Not sure about TREE_ADDRESSABLE, but certainly DECL_PRESERVED_P should be set
as well.


-- 


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

[Bug other/43090] New: Why gcc can't invoke -as and uses 'as' instead?

[miro dot kropacek at gmail dot com]

This thing quite annoys me and it's present in all cross gcc/binutils
environments. If you install cross binutils+gcc, it looks like this (example
with --prefix=/usr --target=m68k-atari-mint):

/usr/bin/m68k-atari-mint-as
/usr/bin/m68k-atari-mint-gcc
:
:
/usr/m68k-atari-mint/bin/as (but not gcc, only binutils here)

Except from the fact this 'as' is not symlinked but copied I fail to see the
reason why it must be here. Why gcc can't search for m68k-atari-mint-as in this
case? Especially when it's found under this name and path during ./configure?

IMO, /usr/m68k-atari-mint/bin should be either empty (as the host is
incompatible with build) or reserved for host binaries (if we don't mind we
might not be able to use them).


-- 
   Summary: Why gcc can't invoke -as and uses 'as'
instead?
   Product: gcc
   Version: 4.4.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: miro dot kropacek at gmail dot com
 GCC build triplet: i386 Linux
  GCC host triplet: i386 Linux
GCC target triplet: m68k


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

[Bug objc/43061] 47 new GCC h...@156527 regressions

[rguenth at gcc dot gnu dot org]

--- Comment #32 from rguenth at gcc dot gnu dot org  2010-02-16 10:14 
---
(In reply to comment #24)
> Yes, I think IainS is on the right track, all things in objc_cls_refs escape
> and can be read and written to in unexpected ways by the runtime.  Setting
> TREE_ADDRESSABLE sounds like a reasonable step forward.

Why are they marked TREE_READONLY then?  That sounds like the bug.


-- 


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

[Bug objc/43061] 47 new GCC h...@156527 regressions

[rguenth at gcc dot gnu dot org]

--- Comment #33 from rguenth at gcc dot gnu dot org  2010-02-16 10:14 
---
(In reply to comment #32)
> (In reply to comment #24)
> > Yes, I think IainS is on the right track, all things in objc_cls_refs escape
> > and can be read and written to in unexpected ways by the runtime.  Setting
> > TREE_ADDRESSABLE sounds like a reasonable step forward.
> 
> Why are they marked TREE_READONLY then?  That sounds like the bug.

Err, forget that ;)  Still early today...


-- 


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

[Bug fortran/43091] New: ICE with gfortran when compiling the following source file

[francois dot jacq at irsn dot fr]

MODULE test
  USE iso_c_binding
  TYPE, BIND(c) :: odig
INTEGER(c_int) :: value
  END TYPE
  TYPE, BIND(c) :: odig_type
INTEGER(c_int64_t) :: name
INTEGER(c_int) :: value
  END TYPE
  INTEGER(c_int),PARAMETER :: od_ig=11
  INTERFACE
SUBROUTINE odessa_segment_all(iseg,ityp,itype,isize,n,n1,p)
BIND(C,NAME="odessa_segment_all")
  USE iso_c_binding
  INTEGER(c_int),INTENT(in),VALUE :: iseg,ityp
  INTEGER(c_int),INTENT(out) :: itype,isize,n,n1
  TYPE(C_PTR)   ,INTENT(out) :: p
END SUBROUTINE
  END INTERFACE
  CONTAINS
  SUBROUTINE odgetptrigval(vector,value)
TYPE(odig),INTENT(in)  :: vector
INTEGER(c_int),POINTER,INTENT(out) :: value(:)
TYPE(odig_type),POINTER :: d(:)
TYPE(C_PTR) :: p
INTEGER :: itype,n,n1,isize
CALL odessa_segment_all(vector%value,od_ig,itype,isize,n,n1,p)
CALL C_F_POINTER(p,d,(/n/))
value => d(:)%value
  END SUBROUTINE
END MODULE

$ gfortran -c test.f90
test.f90: In function 'odgetptrigval':
test.f90:27:0: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

$ gfortran --version
GNU Fortran (GCC) 4.5.0 20100214 (experimental) [trunk revision 156762]
Copyright (C) 2010 Free Software Foundation, Inc.


-- 
   Summary: ICE with gfortran when compiling the following source
file
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: francois dot jacq at irsn dot fr
  GCC host triplet: linux i686


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

[Bug tree-optimization/43089] Optimizer ignores type in a conversion

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2010-02-16 10:16 ---
0x7fff + 1 overflows.  Signed overflow invokes undefined behavior.
Use -fwrapv if you want wrapping signed overflow.


-- 

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

[Bug tree-optimization/43084] [4.5 Regression] ICE: in find_new_var_of_type, at ipa-struct-reorg.c:604 with -fipa-struct-reorg -g

[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=43084

[Bug tree-optimization/43083] [4.5 Regression] ICE: SIGSEGV with -fgraphite-identity

[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=43083

[Bug c/43082] ICE in tree check: expected class 'type', have 'exceptional' (error_mark) in useless_type_conversion_p

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2010-02-16 10:21 ---
We get

6493  STRIP_USELESS_TYPE_CONVERSION (*expr_p);
(gdb) call debug_tree (*expr_p)
 
unit size 
align 8 symtab 0 alias set -1 canonical type 0x77ee4888 precision 1
min  max >

arg 0 


The FEs shouldn't feed us random crap really ...


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Component|other   |c
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-02-16 10:21:57
   date||


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

[Bug c++/43075] [4.5 Regression] 20_util/bind/ref2.cc FAILs

[rguenth at gcc dot gnu dot org]

--- Comment #9 from rguenth at gcc dot gnu dot org  2010-02-16 10:22 ---
FE issue.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|libstdc++   |c++
   Keywords||wrong-code
Summary|[4.5 Regression]|[4.5 Regression]
   |20_util/bind/ref2.cc FAILs  |20_util/bind/ref2.cc FAILs
   |at -O0  |


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

[Bug middle-end/41043] [4.4/4.5 Regression] virtual memory exhausted: Cannot allocate memory

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to work||4.3.4
   Target Milestone|--- |4.4.4


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

[Bug target/27016] [4.3/4.4/4.5 Regression] ARM optimizer produces severely suboptimal code

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.3.5


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

[Bug rtl-optimization/27357] 20 % increase code size in 4.1 vs 3.4.5

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2010-02-16 10:30 ---
rguent...@murzim:/tmp> gcc-3.3 -Os -c t.i -m32
rguent...@murzim:/tmp> size t.o
   textdata bss dec hex filename
222   0   0 222  de t.o
rguent...@murzim:/tmp> gcc-4.1 -Os -c t.i -m32
rguent...@murzim:/tmp> size t.o
   textdata bss dec hex filename
280   0   0 280 118 t.o
rguent...@murzim:/tmp> gcc-4.3 -Os -c t.i -m32
rguent...@murzim:/tmp> size t.o
   textdata bss dec hex filename
269   0   0 269 10d t.o
rguent...@murzim:/tmp> gcc-4.4 -Os -c t.i -m32
rguent...@murzim:/tmp> size t.o
   textdata bss dec hex filename
290   0   0 290 122 t.o
rguent...@murzim:/tmp> gcc-4.5 -Os -c t.i -m32
rguent...@murzim:/tmp> size t.o
   textdata bss dec hex filename
237   0   0 237  ed t.o


-- 


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

[Bug c++/43087] [4.5 Regression] ICE in tsubst, at cp/pt.c:9923

[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|2010-02-16 05:04:28 |2010-02-16 10:31:30
   date||


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

[Bug java/42143] [4.3/4.4/4.5 Regression] gcj creates "dummy" variables

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2010-02-16 10:34 ---
It works for me with FSF 4.3.4.  You might want to report this to Debian.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Target Milestone|--- |4.3.5


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

[Bug middle-end/42505] [4.4/4.5 Regression] loop canonicalization causes a lot of unnecessary temporary variables

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|[4.4 / 4.5 regression] loop |[4.4/4.5 Regression] loop
   |canonicalization causes a   |canonicalization causes a
   |lot of unnecessary temporary|lot of unnecessary temporary
   |variables   |variables
   Target Milestone|--- |4.4.4


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

[Bug c++/43036] [4.3/4.4/4.5 Regression] c++ compilation hang

[Roger dot Jeurninck at home dot nl]

--- Comment #20 from Roger dot Jeurninck at home dot nl  2010-02-16 10:36 
---
great job, couldn't even hope that I got a solution that fast!!
The patch did the trick for 4.4.2 on Solaris and the 'hanging' file builds
without any issues.
pls let me know if I can be of any help in further verification of this issue

thanks a lot again!
Roger


-- 


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

[Bug debug/42648] [4.5 Regression] gcc.dg/guality/pr41353-1.c FAILs at -On, n > 0

[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=42648

[Bug rtl-optimization/42699] [4.3/4.4/4.5 Regression] ZERO_EXTRACT on lhs never optimized out

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2010-02-16 10:37 ---
So, was this fixed on trunk?


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|enhancement |normal
   Keywords||missed-optimization
   Target Milestone|--- |4.3.5


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

[Bug fortran/42851] [4.3/4.4/4.5] ICE (segfault) at gfc_trans_pointer_assignment for subpointer

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.3.5


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

[Bug target/42886] [4.5 Regression] GCC is not relocatable anymore on Windows (mingw32)

[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=42886

[Bug testsuite/42997] [4.4 Regression] Backported tests fail with checking

[rguenth at gcc dot gnu dot org]

--- Comment #9 from rguenth at gcc dot gnu dot org  2010-02-16 10:39 ---
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.4.4


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

[Bug middle-end/42233] [4.3/4.4 regression] c++ builtin_expect code generation regression

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|c++ |middle-end
   Keywords||missed-optimization
  Known to work||4.1.2 4.5.0
Summary|[4.4 regression] c++|[4.3/4.4 regression] c++
   |builtin_expect code |builtin_expect code
   |generation regression   |generation regression
   Target Milestone|--- |4.3.5
Version|unknown |4.4.3


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

[Bug ada/42073] [4.4 regression] Infinite loop when parsing a project file, alpha only

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.4.4


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

[Bug rtl-optimization/34791] [avr] optimisation of 8-bit logic sometimes fails

[david at westcontrol dot com]

--- Comment #1 from david at westcontrol dot com  2010-02-16 10:46 ---
There are many other cases where 8-bit optimisation is missing - C's integer
promotion gets in the way.  This is particularly common when dealing with a
compile-time constant - there is no way in C to say that "0x3f" is 8-bit rather
than a 16-bit int.

Another example of code with this problem is:

void foo(void) {
static unsigned char count;

if (++count & 0x3f) {
PORTC &= ~0x01;
} else {
PORTC |= 0x01;
}
}

Both the "&" and the comparison with zero are done as 16-bit.


One work-around is to use this macro:

#define const_byte(x) ({ static const __attribute__((__progmem__)) \
 unsigned char v = x; v; })

Then we can write:

#define const_byte(x) ({ static const __attribute__((__progmem__)) \
 unsigned char v = x; v; })

uint8_t bar3(uint8_t x, uint8_t y) {
return data[y ^ (x & const_byte(0x0f))];
} 

147 bar3:
 148/* prologue: function */
 149/* frame size = 0 */
 150 008c 8F70  andi r24,lo8(15) ;  tmp45,
 151 008e 8627  eor r24,r22  ;  tmp45, y
 152 0090 E0E0  ldi r30,lo8(data);  tmp48,
 153 0092 F0E0  ldi r31,hi8(data);  tmp48,
 154 0094 E80F  add r30,r24  ;  tmp48, tmp45
 155 0096 F11D  adc r31,__zero_reg__ ;  tmp48
 156 0098 8081  ld r24,Z ; , data
 157/* epilogue start */
 158 009a 0895  ret
 160 


As far as I can see, this generated code is optimal.

The macro works because it forces the value to be 8-bit, rather than a 16-bit
compile-time constant.  However, the compiler is still smart enough to see that
since it's a "const" with known value, it's value can be used directly.  As a
side effect, the static "variable" must be created somewhere - by using
__progmen__, we create it in flash rather than wasting ram.  Even that waste
could be spared by garbage-collection linking, or by using a dedicated segment
rather than .progmem.data.


-- 


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

[Bug fortran/41869] ICE segfault when reading module file

[burnus at gcc dot gnu dot org]

--- Comment #10 from burnus at gcc dot gnu dot org  2010-02-16 10:51 ---
Subject: Bug 41869

Author: burnus
Date: Tue Feb 16 10:50:56 2010
New Revision: 156799

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156799
Log:
2010-02-16  Paul Thomas  

PR fortran/41869
* module.c (fix_mio_expr): Fix for private generic procedures.

2010-02-16  Tobias Burnus  

PR fortran/41869
* gfortran.dg/module_write_1.f90: New test.


Added:
branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/module_write_1.f90
Modified:
branches/gcc-4_4-branch/gcc/fortran/ChangeLog
branches/gcc-4_4-branch/gcc/fortran/module.c
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug fortran/41869] ICE segfault when reading module file

[burnus at gcc dot gnu dot org]

--- Comment #11 from burnus at gcc dot gnu dot org  2010-02-16 10:53 ---
... and FIXED it myself.

Thanks again for the fix, Paul. (I refrain from thanking myself for reporting
the bug ;-)


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug tree-optimization/43089] Optimizer ignores type in a conversion

[0xe2 dot 0x9a dot 0x9b at gmail dot com]

--- Comment #2 from 0xe2 dot 0x9a dot 0x9b at gmail dot com  2010-02-16 
10:59 ---
(In reply to comment #1)
> 0x7fff + 1 overflows.  Signed overflow invokes undefined behavior.

Like so what? Is this your way of saying "I am not going to fix it"? Do you
find it convenient to hide your laziness behind the words "undefined behavior".

If I were to modify the test case like this:

int i = ab.b;
b2 = i + i;

I would be ALSO triggering undefined behavior. But the modified test-case would
succeed at any optimization level.

I don't think you understand what I am demanding here: I demand the compiler to
have CONSISTENT BEHAVIOR in cases which are not defined by the standard. The
modified code does clearly the SAME thing as the code in the test-case, only
the intermediate conversion to the integer is now more explicit.


-- 

0xe2 dot 0x9a dot 0x9b at gmail dot com changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |


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

[Bug testsuite/42997] [4.4 Regression] Backported tests fail with checking

[pault at gcc dot gnu dot org]

--- Comment #10 from pault at gcc dot gnu dot org  2010-02-16 10:59 ---
(In reply to comment #9)
> Fixed.
> 
Richard,

With one thing and another this slipped my mind.

Sorry

Paul


-- 


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

[Bug fortran/41869] ICE segfault when reading module file

[paul dot richard dot thomas at gmail dot com]

--- Comment #12 from paul dot richard dot thomas at gmail dot com  
2010-02-16 11:01 ---
Subject: Re:  ICE segfault when reading module file

Aahhh... thanks, I was going to attend to it myself.

Well thank you for the report :-)

Paul

On Tue, Feb 16, 2010 at 11:53 AM, burnus at gcc dot gnu dot org
 wrote:
>
>
> --- Comment #11 from burnus at gcc dot gnu dot org  2010-02-16 10:53 
> ---
> ... and FIXED it myself.
>
> Thanks again for the fix, Paul. (I refrain from thanking myself for reporting
> the bug ;-)
>
>
> --
>
> burnus at gcc dot gnu dot org changed:
>
>           What    |Removed                     |Added
> 
>             Status|ASSIGNED                    |RESOLVED
>         Resolution|                            |FIXED
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41869
>
> --- You are receiving this mail because: ---
> You are on the CC list for the bug, or are watching someone who is.
> You are the assignee for the bug, or are watching the assignee.
>


-- 


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

[Bug fortran/43091] ICE with gfortran when compiling the following source file

[burnus at gcc dot gnu dot org]

--- Comment #1 from burnus at gcc dot gnu dot org  2010-02-16 11:14 ---
Confirm. (Compiles with NAG, ifort, g95; fails with gfortran 4.3/4.4/4.5.)

Though, I think this is a duplicate of PR 42851, based on the location.

Valgrind shows:

 Invalid read of size 8
at 0x55FAF5: gfc_trans_pointer_assignment (trans-expr.c:4775)
by 0x540975: trans_code (trans.c:1099)
by 0x55A16E: gfc_generate_function_code (trans-decl.c:4373)

The issue occurs for:
  if (expr1->symtree->n.sym->attr.subref_array_pointer)
[...]
  gfc_add_modify (&lse.post, GFC_DECL_SPAN(decl), tmp);


Note: The BIND(...) line needs to moved back to the SUBROUTINE line - otherwise
the code is invalid.

Note 2: If one does not move the line back, one gets also an ICE - first there
are a bunch of ERROR messages, followed by
  f951: internal compiler error: Segmentation fault
The output (compiler under valgrind) is:

test.f90:27.66:

CALL odessa_segment_all(vector%value,od_ig,itype,isize,n,n1,p)
  1
==18265== Invalid read of size 8
==18265==at 0x4C8CB6: show_locus (error.c:271)
==18265==by 0x4C8B8E: error_print (error.c:626)
==18265==by 0x4C94C6: gfc_error (error.c:881)
==18265==by 0x511767: resolve_global_procedure (resolve.c:1790)


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

  BugsThisDependsOn||42851
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   GCC host triplet|linux i686  |
   Keywords||error-recovery, ice-on-
   ||invalid-code, ice-on-valid-
   ||code
  Known to fail||4.4.2 4.5.0 4.3.4
   Last reconfirmed|-00-00 00:00:00 |2010-02-16 11:14:49
   date||


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

[Bug bootstrap/43073] building arm cross-compiler fails when attempting to build regex library

[ramana at gcc dot gnu dot org]

--- Comment #1 from ramana at gcc dot gnu dot org  2010-02-16 11:20 ---

What happens if you use make all-gcc all-target-libgcc on the top level of your
object tree rather than using make all.


Also, it's not necessary that all options supported by the Codesourcery
toolchain should work with the FSF toolchain.

For instance using this with the FSF toolchain is not correct and will create
more problems for you later. 

  --enable-extra-sgxxlite-multilibs \
  --with-specs=%{O2:%{!fno-remove-local-statics: -fremove-local-statics}}
%{O*:%{O|O0|O1|O2|Os:;:%{!fno-remove-local-statics: -fremove-local-statics}}}
\


-- 

ramana at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING


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

[Bug tree-optimization/43089] Optimizer ignores type in a conversion

[0xe2 dot 0x9a dot 0x9b at gmail dot com]

--- Comment #3 from 0xe2 dot 0x9a dot 0x9b at gmail dot com  2010-02-16 
11:23 ---
(In reply to comment #2)
> 
> If I were to modify the test case like this:
> 
> int i = ab.b;
> b2 = i + i;
> 
> I would be ALSO triggering undefined behavior. But the modified test-case 
> would
> succeed at any optimization level.

Whoops. This obviously is one of my bad days: the modified test-case would fail
at -O2 as well. Anyway, the test-case was extracted from a much larger piece of
code which works OK if I compile it with -O2 but generates a segmentation fault
when compiled with -O3, because the optimization is deeper and allows the
compiler to evaluate the conditional expression at compile-time.

Let me return to the original issue: the inconsistency between the behavior at
-Oi vs -O(i+1). Are you going to fix it, or not?

> I don't think you understand what I am demanding here: I demand the compiler 
> to
> have CONSISTENT BEHAVIOR in cases which are not defined by the standard. The
> modified code does clearly the SAME thing as the code in the test-case, only
> the intermediate conversion to the integer is now more explicit.


-- 


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

[Bug tree-optimization/43074] [4.4/4.5 Regression] ICE in vectorizable_reduction, at tree-vect-loop.c:3491

[irar at gcc dot gnu dot org]

--- Comment #1 from irar at gcc dot gnu dot org  2010-02-16 11:35 ---
Subject: Bug 43074

Author: irar
Date: Tue Feb 16 11:35:03 2010
New Revision: 156800

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

PR tree-optimization/43074
* tree-vectorizer.h (VECTORIZABLE_CYCLE_DEF): New.
* tree-vect-loop.c (vect_analyze_loop_operations): Add
vectorizable cycles in hybrid SLP check.
* tree-vect-slp.c (vect_detect_hybrid_slp_stmts): Likewise.


Added:
trunk/gcc/testsuite/gcc.dg/vect/fast-math-pr43074.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-loop.c
trunk/gcc/tree-vect-slp.c
trunk/gcc/tree-vectorizer.h


-- 


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

[Bug rtl-optimization/42699] [4.3/4.4/4.5 Regression] ZERO_EXTRACT on lhs never optimized out

[jakub at gcc dot gnu dot org]

--- Comment #3 from jakub at gcc dot gnu dot org  2010-02-16 11:35 ---
Yes.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug tree-optimization/43074] [4.4/4.5 Regression] ICE in vectorizable_reduction, at tree-vect-loop.c:3491

[irar at gcc dot gnu dot org]

--- Comment #2 from irar at gcc dot gnu dot org  2010-02-16 11:42 ---
Subject: Bug 43074

Author: irar
Date: Tue Feb 16 11:41:55 2010
New Revision: 156802

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

PR tree-optimization/43074
* tree-vect-analyze.c (vect_detect_hybrid_slp_stmts): Add
vectorizable cycles in hybrid SLP check.


Added:
branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/vect/fast-math-pr43074.c
Modified:
branches/gcc-4_4-branch/gcc/ChangeLog
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog
branches/gcc-4_4-branch/gcc/tree-vect-analyze.c


-- 


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

[Bug tree-optimization/43089] Optimizer ignores type in a conversion

[jakub at gcc dot gnu dot org]

--- Comment #4 from jakub at gcc dot gnu dot org  2010-02-16 11:56 ---
There is nothing to fix.  Your program triggers undefined behavior.  It can do
anything, which can include something you'd expect, or something completely
different and it can depend on compiler options, position of stars, etc.

As Richard said, if you want signed overflow to be well defined, compile with
-fwrapv.  Or, avoid doing the addition in this case in a signed type when you
want it to wrap.  E.g. b2 = (unsigned) ab.b + ab.b; does the addition in
unsigned type where wrapping is well defined (and even no wrapping occurs for
0x7fffU + 0x7fffU).


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug fortran/43078] gfortran: spurious warning of line truncation at col 72

[joseph at codesourcery dot com]

--- Comment #4 from joseph at codesourcery dot com  2010-02-16 12:09 ---
Subject: Re:  gfortran: spurious warning of line truncation
 at col 72

On Tue, 16 Feb 2010, patrick dot wallace at stfc dot ac dot uk wrote:

> Mystery solved.  It is to do with line endings.  When gfortran sees
> a file with DOS line endings it interprets the CR and LF as separate
> characters.  This is why demonstrating the effect is so slippery.
> 
> I guess gfortran is within its rights to work this way, and only
> accept Unix line endings.  But I would argue that this is unhelpful,
> and that it would be better to make gfortran detect the condition
> and deal with it sympathetically.

I think all the front ends should behave like the C-family ones in this 
regard, and accept all of CR, LF and CRLF as meaning end-of-line 
regardless of the host OS.


-- 


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

[Bug other/43090] Why gcc can't invoke -as and uses 'as' instead?

[joseph at codesourcery dot com]

--- Comment #1 from joseph at codesourcery dot com  2010-02-16 12:14 ---
Subject: Re:   New: Why gcc can't invoke -as
 and uses 'as' instead?

The key thing to remember about $prefix/$target/bin 
(/usr/m68k-atari-mint/bin in this case) is that it is an *internal* 
directory of the toolchain for *internal* use by one toolchain binary 
calling another, just like libexec/gcc/$target/$version is an *internal* 
directory.  The only problem with it is that people get confused by it and 
do inappropriate things such as putting it on their PATH.  The fact that 
the toolchain has various such internal directories is not in any way a 
bug, and changing the internal directories for the sake of it is pretty 
pointless; only the confusing nature of those directories might possibly 
be a bug.


-- 


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

[Bug debug/41371] [4.5 Regression] var-tracking is slow and memory hungry

[l dot lunak at suse dot cz]

--- Comment #16 from l dot lunak at suse dot cz  2010-02-16 12:47 ---
Created an attachment (id=19887)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19887&action=view)
testcase from kdesdk/umbrello

If it helps, here's another testcase where 2G RAM is not enough. This is "g++
(SUSE Linux) 4.5.0 20100212 (experimental) [trunk revision 156733]" on x86_64
with -g -O2.


-- 


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

[Bug middle-end/41043] [4.4/4.5 Regression] virtual memory exhausted: Cannot allocate memory

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2010-02-16 12:59 ---
Mine.

C testcase showing exponential behavior:

> ~/bin/maxmem.sh /usr/bin/time ./cc1 -quiet -O2 t.i
6.20user 0.09system 0:06.32elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+8outputs (0major+30333minor)pagefaults 0swaps
total: 130410 kB

add one j *= j line:

> ~/bin/maxmem.sh /usr/bin/time ./cc1 -quiet -O2 t.i
11.74user 0.20system 0:11.99elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+8outputs (0major+57721minor)pagefaults 0swaps
total: 237930 kB


int foo (int i)
{
  long j = i;
  j *= j;
  j *= j;
  j *= j;
  j *= j;
  j *= j;
  j *= j;
  j *= j;
  j *= j;
  j *= j;
  j *= j;
  j *= j;
  j *= j;
  j *= j;
  j *= j;
  j *= j;
  j *= j;
  j *= j;
  j *= j;
  j *= j;
  j *= j;
  j *= j;
  return j;
}


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rguenth at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2010-01-02 21:02:20 |2010-02-16 12:59:54
   date||


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

[Bug debug/41371] [4.5 Regression] var-tracking is slow and memory hungry

[jakub at gcc dot gnu dot org]

--- Comment #17 from jakub at gcc dot gnu dot org  2010-02-16 13:06 ---
You should retry with r156794 or newer.


-- 


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

[Bug middle-end/41043] [4.4/4.5 Regression] virtual memory exhausted: Cannot allocate memory

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2010-02-16 13:17 ---
#define FOO ((long)i * (long)i)
#define FOO2 (FOO * FOO)
#define FOO3 (FOO2 * FOO2)
#define FOO4 (FOO3 * FOO3)
#define FOO5 (FOO4 * FOO4)
#define FOO6 (FOO5 * FOO5)
#define FOO7 (FOO6 * FOO6)
#define FOO8 (FOO7 * FOO7)
#define FOO9 (FOO8 * FOO8)
#define FOO10 (FOO9 * FOO9)
#define FOO11 (FOO10 * FOO10)
#define FOO12 (FOO11 * FOO11)
#define FOO13 (FOO12 * FOO12)
#define FOO14 (FOO13 * FOO13)
#define FOO15 (FOO14 * FOO14)
#define FOO16 (FOO15 * FOO15)
int foo (int i)
{
  return (int)(FOO14);
}

At -O0:

FOO12: 1.6s
FOO13: 3.2s
FOO14: 6.7s
FOO15: 13s

we just take endless time with the above, memory usage isn't as bad as
with VRP.


-- 


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

[Bug middle-end/41043] [4.4/4.5 Regression] virtual memory exhausted: Cannot allocate memory

[dominiq at lps dot ens dot fr]

--- Comment #5 from dominiq at lps dot ens dot fr  2010-02-16 13:22 ---
I think http://gcc.gnu.org/ml/gcc/2010-02/msg00156.html is the same problem.


-- 


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

[Bug debug/43092] New: [4.5 Regression] Wrong debuginfo with VTA and -fomit-frame-pointer/-mno-accumulate-outgoing-args

[jakub at gcc dot gnu dot org]

/* { dg-do run } */
/* { dg-options "-O2 -march=i586 -dA -g -fomit-frame-pointer" { target { {
i?86-*-* x86_64-*-* } && ilp32 } } } */

void __attribute__((noinline))
bar (int *p)
{
  (*p)++;
  asm volatile ("" : "=r" (*p) : "0" (*p) : "memory");
}

void __attribute__((noinline))
baz (int a, int b, int c, int d, int e, int f)
{
  asm volatile ("" : : "r" (a + b + c + d + e + f) : "memory");
}

int __attribute__((noinline))
foo (int x)
{
  int y;
  y = 5;
  bar (&y);
  baz (0, 1, 2, 3, 4, 5);
  bar (&x);
  y++;
  baz (1, 2, 3, 4, 5, 6);
  bar (&y);
  return x + y;
}

int
main ()
{
  if (foo (17) != 8 + 18)
__builtin_abort ();
  return 0;
}

has wrong debuginfo for variable y - (mem (sp + offset)) live across several sp
adjustments.  In the debugger inside foo when using nexti and printing y after
each nexti, it first starts as  (expected), then y = 5 is
executed and it prints 5, but then sp is adjusted and it prints garbage because
sp changed.

I believe we should be de-eliminating stack_pointer_rtx resp.
hard_frame_pointer_rtx based MEMs in var-tracking generated notes back to
arg_pointer_rtx / frame_pointer_rtx based notes when they aren't meant to
change whenever sp resp. fp changes.

On the http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43051#c1 testcase this
doesn't show up as wrong debug, but just inefficient location list (LVL1
through LVL2 the argument is fbreg 0, while from LVL2 to LVL12 it is breg5 8
when both
locations are actually the same memory.  There is also the additional problem
that we leave out the epilogue ret insn, as if the parameter wasn't defined at
that spot.


-- 
   Summary: [4.5 Regression] Wrong debuginfo with VTA and -fomit-
frame-pointer/-mno-accumulate-outgoing-args
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Keywords: wrong-debug
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
GCC target triplet: i686-linux


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

[Bug other/43090] Why gcc can't invoke -as and uses 'as' instead?

[d dot g dot gorbachev at gmail dot com]

--- Comment #2 from d dot g dot gorbachev at gmail dot com  2010-02-16 
13:25 ---
> Except from the fact this 'as' is not symlinked but copied

It must be hardlinked, not copied, on the systems which support hard links.

> The fact that the toolchain has various such internal directories
> is not in any way a bug, and changing the internal directories for
> the sake of it is pretty pointless; only the confusing nature of
> those directories might possibly be a bug.

All right, but I still think that there is a bug. IMHO, the driver first should
use "as" from $prefix/$target/bin; if not found, look for $target-as in the
$PATH; and only after that, try to invoke plain "as".

For example, I have two cross-gcc installations with different ${prefix}es. It
would be nice to share one copy of cross-binutils between them. Currently I use
symlinks for that, but it would be easier to put the binutils directory on the
$PATH.


-- 


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

[Bug debug/43092] [4.5 Regression] Wrong debuginfo with VTA and -fomit-frame-pointer/-mno-accumulate-outgoing-args

[jakub at gcc dot gnu dot org]

-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P1
   Target Milestone|--- |4.5.0


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

[Bug c++/43031] [4.5 Regression] internal compiler error: verify_gimple failed after non-trivial conversion error when crosscompiling Firefox

[jacek at codeweavers dot com]

--- Comment #7 from jacek at codeweavers dot com  2010-02-16 13:35 ---
I've confirmed that it's fixed for Mozilla code. Thank you!


-- 


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

[Bug c++/43093] New: [4.5 Regression] internal compiler error: Segmentation fault when compiling Firefox

[jacek at codeweavers dot com]

I get following compiler error when cross compiling Mozilla:

i686-mingw32-g++ -mno-cygwin -o nsSVGOuterSVGFrame.o -c  -DMOZILLA_INTERNAL_API
-D_IMPL_NS_COM -DEXPORT_XPT_API -DEXPORT_XPTC_API -D_IMPL_NS_GFX
-D_IMPL_NS_WIDGET -DIMPL_XREAPI -DIMPL_NS_NET -DIMPL_THEBES  -DZLIB_INTERNAL
-DOSTYPE=\"WINNT\" -DOSARCH=WINNT -D_IMPL_NS_LAYOUT
-I/home/jacek/mozilla-build/wine-gecko-git/layout/svg/base/src/../../../base
-I/home/jacek/mozilla-build/wine-gecko-git/layout/svg/base/src/../../../generic
-I/home/jacek/mozilla-build/wine-gecko-git/layout/svg/base/src/../../../style
-I/home/jacek/mozilla-build/wine-gecko-git/layout/svg/base/src/../../../xul/base/src
-I/home/jacek/mozilla-build/wine-gecko-git/layout/svg/base/src/../../../../content/svg/content/src
-I/home/jacek/mozilla-build/wine-gecko-git/layout/svg/base/src/../../../../content/base/src
 -I/home/jacek/mozilla-build/wine-gecko-git/layout/svg/base/src -I.
-I../../../../dist/include -I../../../../dist/include/nsprpub 
-I/home/jacek/mozilla-build/mozilla-build/dist/include/nspr
-I/home/jacek/mozilla-build/mozilla-build/dist/include/nss -fno-rtti
-fno-exceptions -Wall -Wpointer-arith -Woverloaded-virtual -Wsynth
-Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wcast-align -Wno-invalid-offsetof
-Wno-variadic-macros -Werror=return-type -Wno-long-long -pedantic
-fno-strict-aliasing -mms-bitfields -pipe  -DDEBUG -D_DEBUG -DDEBUG_ -DTRACING
-g   -DCROSS_COMPILE=1 -DMOZ_DISABLE_VISTA_SDK_REQUIREMENTS=1 -DWINVER=0x502
-D_WIN32_WINNT=0x502 -D_WIN32_IE=0x0500 -DMOZ_WINSDK_TARGETVER=0x0502
-DMOZ_NTDDI_WS03=0x0502 -DMOZ_NTDDI_LONGHORN=0x0600
-DMOZ_NTDDI_WIN7=0x0601 -DMOZILLA_VERSION=\"1.9.3a2pre\"
-DMOZILLA_VERSION_U=1.9.3a2pre -DHAVE_SNPRINTF=1 -D_WINDOWS=1 -DWIN32=1
-DXP_WIN=1 -DXP_WIN32=1 -DHW_THREADS=1 -DSTDC_HEADERS=1 -DWIN32_LEAN_AND_MEAN=1
-DNO_X11=1 -D_X86_=1 -DD_INO=d_ino -DSTDC_HEADERS=1 -DHAVE_DIRENT_H=1
-DHAVE_GETOPT_H=1 -DHAVE_MEMORY_H=1 -DHAVE_UNISTD_H=1 -DHAVE_MALLOC_H=1
-DHAVE_IO_H=1 -DHAVE_LIBM=1 -DNO_X11=1 -DHAVE_STRERROR=1 -DHAVE_SNPRINTF=1
-DHAVE_MEMMOVE=1 -DHAVE_RINT=1 -DHAVE_SETBUF=1 -DHAVE_ISATTY=1
-DHAVE_THREAD_TLS_KEYWORD=1 -DNS_ENABLE_TSF=1 -DMOZ_PHOENIX=1
-DMOZ_BUILD_APP=browser -DMOZ_DEFAULT_TOOLKIT=\"cairo-windows\"
-DMOZ_DISTRIBUTION_ID=\"org.mozilla\" -DIBMBIDI=1 -DMOZ_VIEW_SOURCE=1
-DMOZ_XPINSTALL=1 -DMOZ_JSLOADER=1 -DNS_PRINTING=1 -DNS_PRINT_PREVIEW=1
-DMOZ_OGG=1 -DATTRIBUTE_ALIGNED_MAX=64 -DMOZ_WAVE=1 -DMOZ_SYDNEYAUDIO=1
-DMOZ_MEDIA=1 -DMOZ_XTF=1 -DMOZ_CRASHREPORTER_ENABLE_PERCENT=100 -DMOZ_MATHML=1
-DMOZ_SVG=1 -DMOZ_SMIL=1 -DMOZ_UPDATE_CHANNEL=default
-DMOZ_DISABLE_PARENTAL_CONTROLS=1 -DMOZ_PLACES=1 -DMOZ_FEEDS=1 -DMOZ_STORAGE=1
-DMOZ_SAFE_BROWSING=1 -DMOZ_URL_CLASSIFIER=1 -DMOZ_LOGGING=1
-DHAVE___CXA_DEMANGLE=1 -DMOZ_DEMANGLE_SYMBOLS=1 -DHAVE__UNWIND_BACKTRACE=1
-DMOZ_CHROME_FILE_FORMAT_JAR=1 -DMOZ_USER_DIR=\"Mozilla\" -DMOZ_ENABLE_LIBXUL=1
-DHAVE_STDINT_H=1 -DHAVE_INTTYPES_H=1 -DMOZ_TREE_CAIRO=1 -DHAVE_UINT64_T=1
-DMOZ_XUL=1 -DMOZ_PROFILELOCKING=1 -DMOZ_RDF=1 -DBUILD_CTYPES=1
-DMOZ_MORKREADER=1 -DMOZ_DLL_SUFFIX=\".dll\" -DMOZ_REFLOW_PERF=1
-DMOZ_REFLOW_PERF_DSP=1  -D_MOZILLA_CONFIG_H_ -DMOZILLA_CLIENT
/home/jacek/mozilla-build/wine-gecko-git/layout/svg/base/src/nsSVGOuterSVGFrame.cpp
/home/jacek/mozilla-build/wine-gecko-git/layout/svg/base/src/nsSVGOuterSVGFrame.cpp:
In member function 'PRBool
nsSVGOuterSVGFrame::UpdateAndInvalidateCoveredRegion(nsIFrame*)':
/home/jacek/mozilla-build/wine-gecko-git/layout/svg/base/src/nsSVGOuterSVGFrame.cpp:640:49:
internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.

GCC 4.4.3 works fine. My GCC version:
$ i686-mingw32-g++ -v
Using built-in specs.
COLLECT_GCC=i686-mingw32-g++
COLLECT_LTO_WRAPPER=/home/jacek/gcc/mingw/libexec/gcc/i686-mingw32/4.5.0/lto-wrapper
Target: i686-mingw32
Configured with: ../gcc/configure --prefix=/home/jacek/gcc/mingw
--target=i686-mingw32 --with-gnu-ld --with-gnu-as --enable-__cxa_atexit
target_alias=i686-mingw32 --enable-languages=c,c++
Thread model: win32
gcc version 4.5.0 20100216 (experimental) (GCC)


-- 
   Summary: [4.5 Regression] internal compiler error: Segmentation
fault when compiling Firefox
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jacek at codeweavers dot com
  GCC host triplet: x86_64-pc-linux-gnu
GCC target triplet: i686-mingw32


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

[Bug c++/43093] [4.5 Regression] internal compiler error: Segmentation fault when compiling Firefox

[jacek at codeweavers dot com]

--- Comment #1 from jacek at codeweavers dot com  2010-02-16 13:45 ---
Created an attachment (id=19888)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19888&action=view)
Preprocessed nsSVGOuterSVGFrame.cpp

Result of command

$ i686-mingw32-g++ -mno-cygwin -o nsSVGOuterSVGFrame.o -c 
-DMOZILLA_INTERNAL_API -D_IMPL_NS_COM -DEXPORT_XPT_API -DEXPORT_XPTC_API
-D_IMPL_NS_GFX -D_IMPL_NS_WIDGET -DIMPL_XREAPI -DIMPL_NS_NET -DIMPL_THEBES 
-DZLIB_INTERNAL -DOSTYPE=\"WINNT\" -DOSARCH=WINNT -D_IMPL_NS_LAYOUT
-I/home/jacek/mozilla-build/wine-gecko-git/layout/svg/base/src/../../../base
-I/home/jacek/mozilla-build/wine-gecko-git/layout/svg/base/src/../../../generic
-I/home/jacek/mozilla-build/wine-gecko-git/layout/svg/base/src/../../../style
-I/home/jacek/mozilla-build/wine-gecko-git/layout/svg/base/src/../../../xul/base/src
-I/home/jacek/mozilla-build/wine-gecko-git/layout/svg/base/src/../../../../content/svg/content/src
-I/home/jacek/mozilla-build/wine-gecko-git/layout/svg/base/src/../../../../content/base/src
 -I/home/jacek/mozilla-build/wine-gecko-git/layout/svg/base/src -I.
-I../../../../dist/include -I../../../../dist/include/nsprpub 
-I/home/jacek/mozilla-build/mozilla-build/dist/include/nspr
-I/home/jacek/mozilla-build/mozilla-build/dist/include/nss -fno-rtti
-fno-exceptions -Wall -Wpointer-arith -Woverloaded-virtual -Wsynth
-Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wcast-align -Wno-invalid-offsetof
-Wno-variadic-macros -Werror=return-type -Wno-long-long -pedantic
-fno-strict-aliasing -mms-bitfields -pipe  -DDEBUG -D_DEBUG -DDEBUG_ -DTRACING
-g   -DCROSS_COMPILE=1 -DMOZ_DISABLE_VISTA_SDK_REQUIREMENTS=1 -DWINVER=0x502
-D_WIN32_WINNT=0x502 -D_WIN32_IE=0x0500 -DMOZ_WINSDK_TARGETVER=0x0502
-DMOZ_NTDDI_WS03=0x0502 -DMOZ_NTDDI_LONGHORN=0x0600
-DMOZ_NTDDI_WIN7=0x0601 -DMOZILLA_VERSION=\"1.9.3a2pre\"
-DMOZILLA_VERSION_U=1.9.3a2pre -DHAVE_SNPRINTF=1 -D_WINDOWS=1 -DWIN32=1
-DXP_WIN=1 -DXP_WIN32=1 -DHW_THREADS=1 -DSTDC_HEADERS=1 -DWIN32_LEAN_AND_MEAN=1
-DNO_X11=1 -D_X86_=1 -DD_INO=d_ino -DSTDC_HEADERS=1 -DHAVE_DIRENT_H=1
-DHAVE_GETOPT_H=1 -DHAVE_MEMORY_H=1 -DHAVE_UNISTD_H=1 -DHAVE_MALLOC_H=1
-DHAVE_IO_H=1 -DHAVE_LIBM=1 -DNO_X11=1 -DHAVE_STRERROR=1 -DHAVE_SNPRINTF=1
-DHAVE_MEMMOVE=1 -DHAVE_RINT=1 -DHAVE_SETBUF=1 -DHAVE_ISATTY=1
-DHAVE_THREAD_TLS_KEYWORD=1 -DNS_ENABLE_TSF=1 -DMOZ_PHOENIX=1
-DMOZ_BUILD_APP=browser -DMOZ_DEFAULT_TOOLKIT=\"cairo-windows\"
-DMOZ_DISTRIBUTION_ID=\"org.mozilla\" -DIBMBIDI=1 -DMOZ_VIEW_SOURCE=1
-DMOZ_XPINSTALL=1 -DMOZ_JSLOADER=1 -DNS_PRINTING=1 -DNS_PRINT_PREVIEW=1
-DMOZ_OGG=1 -DATTRIBUTE_ALIGNED_MAX=64 -DMOZ_WAVE=1 -DMOZ_SYDNEYAUDIO=1
-DMOZ_MEDIA=1 -DMOZ_XTF=1 -DMOZ_CRASHREPORTER_ENABLE_PERCENT=100 -DMOZ_MATHML=1
-DMOZ_SVG=1 -DMOZ_SMIL=1 -DMOZ_UPDATE_CHANNEL=default
-DMOZ_DISABLE_PARENTAL_CONTROLS=1 -DMOZ_PLACES=1 -DMOZ_FEEDS=1 -DMOZ_STORAGE=1
-DMOZ_SAFE_BROWSING=1 -DMOZ_URL_CLASSIFIER=1 -DMOZ_LOGGING=1
-DHAVE___CXA_DEMANGLE=1 -DMOZ_DEMANGLE_SYMBOLS=1 -DHAVE__UNWIND_BACKTRACE=1
-DMOZ_CHROME_FILE_FORMAT_JAR=1 -DMOZ_USER_DIR=\"Mozilla\" -DMOZ_ENABLE_LIBXUL=1
-DHAVE_STDINT_H=1 -DHAVE_INTTYPES_H=1 -DMOZ_TREE_CAIRO=1 -DHAVE_UINT64_T=1
-DMOZ_XUL=1 -DMOZ_PROFILELOCKING=1 -DMOZ_RDF=1 -DBUILD_CTYPES=1
-DMOZ_MORKREADER=1 -DMOZ_DLL_SUFFIX=\".dll\" -DMOZ_REFLOW_PERF=1
-DMOZ_REFLOW_PERF_DSP=1  -D_MOZILLA_CONFIG_H_ -DMOZILLA_CLIENT
/home/jacek/mozilla-build/wine-gecko-git/layout/svg/base/src/nsSVGOuterSVGFrame.cpp
-save-temps

(compressed due to attachment size limit)


-- 


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

[Bug other/43090] Why gcc can't invoke -as and uses 'as' instead?

[miro dot kropacek at gmail dot com]

--- Comment #3 from miro dot kropacek at gmail dot com  2010-02-16 13:47 
---
>It must be hardlinked, not copied, on the systems which support hard links.
I don't know, Linux copies it, too.

>it is an *internal* directory of the toolchain for *internal* use by one 
>toolchain binary calling another, just like libexec/gcc/$target/$version is an 
>*internal* directory.
This is not 100% true. GCC is looking for #include  paths in
$prefix/$target/include, libs in $prefix/$target/lib so saying
$prefix/$target/bin is internal directory only for gcc/binutils purposes does
not seem to be correct to me. Don't forget many libraries which provide some
executables (libxml2 comes into my mind) install headers and libs into
mentioned places _and_ executables into mentioned bin directory. So what we
have ended with? Mixed host and native/cross binaries in one directory. But I
don't say this is only gcc bug, there's no convention what should be there
(cross tools, host tools, nothing?). I just wanted to make this mess a little
bit less painful.

>IMHO, the driver first should use "as" from $prefix/$target/bin; if not found, 
>look for $target-as in the $PATH; and only after that, try to invoke plain 
>"as".
Exactly my thoughts.


-- 


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

[Bug fortran/43040] Wrong decl for mathbuiltins -> wrong code with LTO

[burnus at gcc dot gnu dot org]

--- Comment #5 from burnus at gcc dot gnu dot org  2010-02-16 13:51 ---
I think the comment applies only to FLOOR and ROUND - at least when it was
first written those were the only ones present. If I read the source code
correctly, the ME floor(l,f) is not directly called but instead the following
is generated:
  FLOOR(x) = INT(x) <= x ? INT(x) : INT(x) - 1
cf. trans-intrinsic.c. I also believe that ROUND [(l)round(l,f)] is properly
handled, which means that the PR could be closed. However, I leave it open for
someone else to cross check.


-- 


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

[Bug fortran/43091] ICE with gfortran when compiling the following source file

[francois dot jacq at irsn dot fr]

--- Comment #2 from francois dot jacq at irsn dot fr  2010-02-16 14:07 
---
Sorry,

this is a duplication of 34640 I found 2 years ago ... It has nothing to do
with BIND(C) but only with "value => d(:)%..." when value is a dummy !

I thought that this bug was already corrected and I did not check that it was
not ...

Sorry again


-- 


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

[Bug c++/43093] [4.5 Regression] internal compiler error: Segmentation fault when compiling Firefox

[jacek at codeweavers dot com]

--- Comment #2 from jacek at codeweavers dot com  2010-02-16 14:38 ---
Here is simplified test:

struct S {
  int x;
  S(const S &s) {}
};

S __attribute__((__stdcall__)) getS();

void test()
{
  S s = getS();
}

It seems like calling stdcall function that returns a struct (or class) with
copying constructor causes the problem.


-- 


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

[Bug objc/43061] 47 new GCC h...@156527 regressions

[developer at sandoe-acoustics dot co dot uk]

--- Comment #34 from developer at sandoe-acoustics dot co dot uk  
2010-02-16 14:58 ---
Created an attachment (id=19889)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19889&action=view)
patch with CLASS and SELECTOR refs. marked as TREE_ADDRESSABLE &
DECL_PRESERVE_P (for NeXT runtime)

In view of the comments in
http://gcc.gnu.org/ml/gcc-patches/2010-02/msg00597.html and
http://gcc.gnu.org/ml/gcc-patches/2010-02/msg00587.html it's clear that people
feel that the bug is actually in ipa* and cgraphunit.c.  

However, a grep of lookup_attribute ipa* etc. suggests that altering these has
possibly wide-reaching effects, which might not be welcome at this stage.

I've added back in the marking of CLASS_REFERENCES_* and SELECTOR_REFERENCES_*
as TREE_ADDRESSABLE and DECL_PRESERVE_P.  Of course, this doesn't solve the
problem unless the addition of the "used" attribute in finish_var_decl() is
left in place too (although that can be removed once the underlying problem is
resolved).

Would it be best to close this bug with the lookup_attribute fix - and open a
new bug for ipa*.c and cgraphunit.c to support DECL_PRESERVE_P and/or
TREE_USED? 

In fact, I'm a bit confused about what combination of flags is really needed. 
TREE_USED appears to match in intent with "used" attribute - which is placed on
the vars in objc-act.c/finish_var_decl().

DECL_PRESERVE_P presumably should only be used on the
CLASS_REFERENCES/SELECTOR_REFERENCES - and thus I've placed it local to those
two definitions.


-- 

developer at sandoe-acoustics dot co dot uk changed:

   What|Removed |Added

  Attachment #19884|0   |1
is obsolete||


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

[Bug middle-end/41043] [4.4/4.5 Regression] virtual memory exhausted: Cannot allocate memory

[rguenth at gcc dot gnu dot org]

--- Comment #6 from rguenth at gcc dot gnu dot org  2010-02-16 15:06 ---
I can mitigate the effect of VRP calling SCEV somewhat, but still we'll
the following trigger the issue.

int foo (int i)
{
  long j = i;
  int k = 0;
  while (j < 1)
{
  j *= i;
  j *= j;
  j *= j;
  j *= j;
  j *= j;
  j *= j;
  j *= j;
  j *= j;
  j *= j;
  j *= j;
  j *= j;
  j *= j;
  j *= j;
  j *= j;
  j *= j;
  j *= j;
  j *= j;
  j *= j;
  j *= j;
  j *= j;
  j *= j;
  k += j;
}
  return k;
}

when analyzing the scalar evolution of k we find (int) {0, +, D.2723_10}_1
and instantiating parameters causes us to analyze the scalar evolution
of all other temporaries creating a ripple-down effect of caching
expanded evolutions.


-- 


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

[Bug debug/43092] [4.5 Regression] Wrong debuginfo with VTA and -fomit-frame-pointer/-mno-accumulate-outgoing-args

[jakub at gcc dot gnu dot org]

--- Comment #1 from jakub at gcc dot gnu dot org  2010-02-16 15:17 ---
For sp based addresses in the -fno-var-tracking-assignments case we have
vt_stack_adjustments that replaces the sp based MEMs with CFA based ones
(frame_pointer_rtx resp. arg_pointer_rtx based ones).
Unfortunately, add_uses replaces the addresses of the MEMs with VALUEs as they
are REG + CONST_INT instead of just REG or MEM, and therefore
vt_stack_adjustments does nothing.

Either add_uses should also special case REG + CONST_INT (or perhaps just sp/fp
+ CONST_INT), or we need to do the replacement from sp (and ideally also fp)
afterwards.


-- 


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

[Bug c++/43093] [4.5 Regression] internal compiler error: Segmentation fault when compiling Firefox

[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=43093

[Bug middle-end/42859] [4.5 regression] ICE in verify_flow_info

[abel at gcc dot gnu dot org]

--- Comment #6 from abel at gcc dot gnu dot org  2010-02-16 15:43 ---
How about the below patch?  It fixes all testcases for me.  I'm not sure
whether it makes sense to filter duplicate labels this late, but I don't know
how to do this earlier, as catches seem to be lowering independently of each
other.

diff --git a/gcc/tree-eh.c b/gcc/tree-eh.c
index 2cb334f..c18b807 100644
--- a/gcc/tree-eh.c
+++ b/gcc/tree-eh.c
@@ -28,6 +28,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "flags.h"
 #include "function.h"
 #include "except.h"
+#include "pointer-set.h"
 #include "tree-flow.h"
 #include "tree-dump.h"
 #include "tree-inline.h"
@@ -3063,6 +3064,7 @@ lower_eh_dispatch (basic_block src, gimple stmt)
eh_catch c;
edge_iterator ei;
edge e;
+   struct pointer_set_t *seen_values = pointer_set_create ();

/* Collect the labels for a switch.  Zero the post_landing_pad
   field becase we'll no longer have anything keeping these labels
@@ -3071,6 +3073,7 @@ lower_eh_dispatch (basic_block src, gimple stmt)
for (c = r->u.eh_try.first_catch; c ; c = c->next_catch)
  {
tree tp_node, flt_node, lab = c->label;
+   bool have_label = false;

c->label = NULL;
tp_node = c->type_list;
@@ -3083,14 +3086,26 @@ lower_eh_dispatch (basic_block src, gimple stmt)
  }
do
  {
-   tree t = build3 (CASE_LABEL_EXPR, void_type_node,
-TREE_VALUE (flt_node), NULL, lab);
-   VEC_safe_push (tree, heap, labels, t);
+   /* Filter out duplicate labels that arise when this handler 
+  is shadowed by an earlier one.  When no labels are 
+  attached to the handler anymore, we remove 
+  the corresponding edge and then we delete unreachable 
+  blocks at the end of this pass.  */
+   if (! pointer_set_contains (seen_values, TREE_VALUE
(flt_node)))
+ {
+   tree t = build3 (CASE_LABEL_EXPR, void_type_node,
+TREE_VALUE (flt_node), NULL, lab);
+   VEC_safe_push (tree, heap, labels, t);
+   pointer_set_insert (seen_values, TREE_VALUE (flt_node));
+   have_label = true;
+ }

tp_node = TREE_CHAIN (tp_node);
flt_node = TREE_CHAIN (flt_node);
  }
while (tp_node);
+   if (! have_label)
+ remove_edge (find_edge (src, label_to_block (lab)));
  }

/* Clean up the edge flags.  */
@@ -3132,6 +3147,7 @@ lower_eh_dispatch (basic_block src, gimple stmt)

VEC_free (tree, heap, labels);
  }
+   pointer_set_destroy (seen_values);
   }
   break;

@@ -3185,6 +3201,8 @@ execute_lower_eh_dispatch (void)
}
 }

+  if (any_rewritten)
+delete_unreachable_blocks ();
   return any_rewritten ? TODO_update_ssa_only_virtuals : 0;
 }



-- 

abel at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||abel at gcc dot gnu dot org


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

[Bug fortran/43072] unneeded temporary (s=s+f(a))

[pault at gcc dot gnu dot org]

--- Comment #3 from pault at gcc dot gnu dot org  2010-02-16 15:46 ---
(In reply to comment #2)

I have just patched a tree with the fix for PR36932 on an i686 at work.  None
of these temporaries appear!

Something is different between 32 and 64 bits..

Paul


-- 


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

[Bug fortran/43078] gfortran: spurious warning of line truncation at col 72

[kargl at gcc dot gnu dot org]

--- Comment #5 from kargl at gcc dot gnu dot org  2010-02-16 16:01 ---
(In reply to comment #4)
> Subject: Re:  gfortran: spurious warning of line truncation
>  at col 72
> 
> On Tue, 16 Feb 2010, patrick dot wallace at stfc dot ac dot uk wrote:
> 
> > Mystery solved.  It is to do with line endings.  When gfortran sees
> > a file with DOS line endings it interprets the CR and LF as separate
> > characters.  This is why demonstrating the effect is so slippery.
> > 
> > I guess gfortran is within its rights to work this way, and only
> > accept Unix line endings.  But I would argue that this is unhelpful,
> > and that it would be better to make gfortran detect the condition
> > and deal with it sympathetically.
> 
> I think all the front ends should behave like the C-family ones in this 
> regard, and accept all of CR, LF and CRLF as meaning end-of-line 
> regardless of the host OS.
> 

Well, it's a counting issue. Fixed-form Fortran is required to have
exactly 72 characters in a line of code.  Does CRLF count as one 
character or two?  gfortran currently counts CRLF as two characters,
which is the source of the problem and the reason why I could not
reproduce the problem. It might be possible to ignore CR in the 
gfortran parser.


-- 


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

[Bug c++/26261] Rejects template with local static variable used in return type

[jorrit at jorrit dot de]

--- Comment #3 from jorrit at jorrit dot de  2010-02-16 16:03 ---
This still fails with "gcc version 4.3.4 (Debian 4.3.4-6)" and "gcc version
4.4.3 20100108 (prerelease) (Debian 4.4.2-9)"
In addition the workaround suggested in the last comment stopped working for
gcc 4.4


-- 

jorrit at jorrit dot de changed:

   What|Removed |Added

 CC||jorrit at jorrit dot de


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

[Bug c++/26261] Rejects template with local static variable used in return type

[paolo dot carlini at oracle dot com]

--- Comment #4 from paolo dot carlini at oracle dot com  2010-02-16 16:08 
---
Jason, can we still do something about this? See Comment #3, in particular...


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 CC||jason at gcc dot gnu dot org


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

[Bug fortran/43078] gfortran: spurious warning of line truncation at col 72

[patrick dot wallace at stfc dot ac dot uk]

--- Comment #6 from patrick dot wallace at stfc dot ac dot uk  2010-02-16 
16:10 ---
Subject: RE:  gfortran: spurious warning of line truncation at col 72

> Well, it's a counting issue. Fixed-form Fortran is required to
> have exactly 72 characters in a line of code.  Does CRLF count as
> one character or two?

Zero.  CR and LF are not in the Fortran 77 character set (ANSI
X3.9-1978 Sect. 3.1), and I think it is sensible to regard them
as part of the environment rather than the Fortran statement.


Patrick Wallace

Space Science & Technology Department+44-1235-445372 tel
STFC / Rutherford Appleton Laboratory+44-1235-446362 fax
Harwell Science and Innovation Campus  p...@star.rl.ac.uk
Didcot, Oxfordshire, OX11 0QX, UK patrick.wall...@stfc.ac.uk

--
Scanned by iCritical.


-- 


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

[Bug middle-end/41043] [4.4/4.5 Regression] virtual memory exhausted: Cannot allocate memory

[rguenth at gcc dot gnu dot org]

--- Comment #7 from rguenth at gcc dot gnu dot org  2010-02-16 16:11 ---
Subject: Bug 41043

Author: rguenth
Date: Tue Feb 16 16:11:28 2010
New Revision: 156808

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156808
Log:
2010-02-16  Richard Guenther  

PR tree-optimization/41043
* tree-vrp.c  (vrp_var_may_overflow): Only ask SCEV for
real loops.
(vrp_visit_assignment_or_call): Do not ask SCEV for regular
statements ...
(vrp_visit_phi_node): ... but only for loop PHI nodes.

* gfortran.dg/pr41043.f90: New testcase.
* gcc.dg/Wstrict-overflow-18.c: XFAIL.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/Wstrict-overflow-18.c
trunk/gcc/tree-vrp.c


-- 


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

[Bug middle-end/41043] [4.4 Regression] virtual memory exhausted: Cannot allocate memory

[rguenth at gcc dot gnu dot org]

--- Comment #8 from rguenth at gcc dot gnu dot org  2010-02-16 16:12 ---
"Fixed" on trunk.  Let's see if it causes any performance fallout.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to fail|4.4.1 4.5.0 |4.4.1
  Known to work|4.3.4   |4.3.4 4.5.0
Summary|[4.4/4.5 Regression] virtual|[4.4 Regression] virtual
   |memory exhausted: Cannot|memory exhausted: Cannot
   |allocate memory |allocate memory


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

[Bug objc/43061] 47 new GCC h...@156527 regressions

[mikestump at comcast dot net]

--- Comment #35 from mikestump at comcast dot net  2010-02-16 16:25 ---
Ok to the last patch for now.  Feel free to file a bug about checking
DECL_PRESERVE_P and add a pointer to remove the setting of DECL_ATTRIBUTES from
the frontend, thanks.


-- 


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

[Bug fortran/43078] gfortran: spurious warning of line truncation at col 72

[burnus at gcc dot gnu dot org]

--- Comment #7 from burnus at gcc dot gnu dot org  2010-02-16 16:25 ---
(In reply to comment #3)
> Mystery solved.  It is to do with line endings.  When gfortran sees
> a file with DOS line endings it interprets the CR and LF as separate
> characters.  This is why demonstrating the effect is so slippery.

I think that has been fixed in GCC/gfortran 4.4 as I found the following in the
Changelog - it also matches my testing with 4.3 and 4.4/4.5.

2009-02-19  Daniel Franke  
* scanner.c (load_line): At end of line, skip '\r' without setting
the truncation flag.
which matches what I currently see in the code (the "i++" etc. part is jumped
over if the character is "\r").

Thus: Can you re-try with 4.4/4.5 and see whether it is really fixed? I think
we can close the problem report as the fix will not be backported to the 4.3
branch.


-- 


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

[Bug debug/43092] [4.5 Regression] Wrong debuginfo with VTA and -fomit-frame-pointer/-mno-accumulate-outgoing-args

[jakub at gcc dot gnu dot org]

--- Comment #2 from jakub at gcc dot gnu dot org  2010-02-16 16:27 ---
Created an attachment (id=19890)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19890&action=view)
patch

Incomplete patch I've tried, didn't make any difference unfortunately.


-- 


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

[Bug fortran/43078] gfortran: spurious warning of line truncation at col 72

[kargl at gcc dot gnu dot org]

--- Comment #8 from kargl at gcc dot gnu dot org  2010-02-16 16:29 ---
(In reply to comment #6)
> Subject: RE:  gfortran: spurious warning of line truncation at col 72
> 
> > Well, it's a counting issue. Fixed-form Fortran is required to
> > have exactly 72 characters in a line of code.  Does CRLF count as
> > one character or two?
> 
> Zero.  CR and LF are not in the Fortran 77 character set (ANSI
> X3.9-1978 Sect. 3.1), and I think it is sensible to regard them
> as part of the environment rather than the Fortran statement.
>

The Fortran character set isn't the relevant character set.

>From the Fortran 95 standard:

3.1  Processor character set

The processor character set is processor dependent. The structure of a
processor character set is:
(1)Control characters ("newline", for example)
(2)Graphic characters
   (a) Letters (3.1.1)
   (b) Digits (3.1.2)
   (c) Underscore (3.1.3)
   (d) Special characters (3.1.4)
   (e) Other characters (3.1.5)
The letters, digits, underscore, and special characters make up the Fortran
character set.

3.3.2 Fixed source form

In fixed source form, there are restrictions on where a statement
may appear within a line. If a source line contains only default
kind characters, it shall contain exactly 72 characters; otherwise,
its maximum number of characters is processor dependent.

3.1.5   Other characters

Additional characters may be representable in the processor, but may
appear only in comments (3.3.1.1, 3.3.2.1), character constants (4.3.2.1),
input/output records (9.1.1), and character string edit descriptors (10.2.1).

The default character type shall support a character set that includes the
Fortran character set.


-- 


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

[Bug c++/26261] Rejects template with local static variable used in return type

[jorrit at jorrit dot de]

--- Comment #5 from jorrit at jorrit dot de  2010-02-16 16:30 ---
Here is a workaround that works with gcc "gcc version 4.1.3 20080704
(prerelease) (Debian 4.1.2-27)" as well as the gcc 3.4 and 4.4 mentioned in
Comment #3.

==
template  class X {};

template  class Y {
  static const unsigned int dim = 1;
  typedef X Z;
  Z f();
};

template 
typename Y::Z Y::f() { return X(); }
==


-- 


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

[Bug libgcj/40860] [4.4/4.5 regression] regressions in libjava testsuite on arm-linux

[doko at ubuntu dot com]

--- Comment #9 from doko at ubuntu dot com  2010-02-16 16:34 ---
confirmed with binutils trunk 20100216, checking with gold from the trunk.


-- 

doko at ubuntu dot com changed:

   What|Removed |Added

 CC||jsm28 at gcc dot gnu dot org


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

[Bug c++/43094] New: 2.19.51.20090527-10.26.4 internal error

[pierrelud at yahoo dot com]

Linking CXX executable semnotes
cd /home/pielud/creator/semnotes/build/src && /usr/bin/cmake -E
cmake_link_script CMakeFiles/semnotes.dir/link.txt --verbose=1
/usr/bin/c++ -Wnon-virtual-dtor -Wno-long-long -ansi -Wundef -Wcast-align
-Wchar-subscripts -Wall -W -Wpointer-arith -Wformat-security -fno-exceptions
-DQT_NO_EXCEPTIONS -fno-check-new -fno-common -Woverloaded-virtual
-fno-threadsafe-statics -fvisibility=hidden -fvisibility-inlines-hidden -g -O2
-fno-reorder-blocks -fno-schedule-insns -fno-inline -fPIC
-Wl,--enable-new-dtags CMakeFiles/semnotes.dir/semnotes_automoc.o
CMakeFiles/semnotes.dir/application.o CMakeFiles/semnotes.dir/mainwindow.o
CMakeFiles/semnotes.dir/main.o CMakeFiles/semnotes.dir/note.o
CMakeFiles/semnotes.dir/tools.o CMakeFiles/semnotes.dir/notemodel.o
CMakeFiles/semnotes.dir/notesortproxymodel.o
CMakeFiles/semnotes.dir/notedelegate.o CMakeFiles/semnotes.dir/noteview.o
CMakeFiles/semnotes.dir/noteeditorwidget.o
CMakeFiles/semnotes.dir/tagcloudwidget.o
CMakeFiles/semnotes.dir/filtermanager.o
CMakeFiles/semnotes.dir/resourcewidget.o
CMakeFiles/semnotes.dir/mentionannotation.o
CMakeFiles/semnotes.dir/annotatortextedit.o
CMakeFiles/semnotes.dir/movingutils.o
CMakeFiles/semnotes.dir/annotationmanager.o
CMakeFiles/semnotes.dir/annotationswidget.o
CMakeFiles/semnotes.dir/possibleannotationwidget.o
CMakeFiles/semnotes.dir/annotationhighlighter.o
CMakeFiles/semnotes.dir/lodpublisher.o
CMakeFiles/semnotes.dir/simpleannotation/simpleannotation.o
CMakeFiles/semnotes.dir/simpleannotation/annotation.o
CMakeFiles/semnotes.dir/listsearchline.o CMakeFiles/semnotes.dir/tageditor.o -o
semnotes -rdynamic /usr/lib/libQtGui.so -lpng -lSM -lICE -lXi -lXrender
-lXrandr -lXcursor -lXinerama -lXfixes -lfreetype -lfontconfig -lXext -lX11 -lm
/usr/lib/libQtCore.so -lpthread -lz -lgthread-2.0 -lglib-2.0 -lgobject-2.0 -lrt
-lpthread -ldl /usr/lib/libkdeui.so.5.4.0 -lnepomuk -lsoprano -lsopranoindex
-lnepomukutils /usr/lib/libQtGui.so /usr/lib/libkdecore.so.5.4.0
/usr/lib/libQtCore.so -lpthread /usr/lib/libQtDBus.so /usr/lib/libQtSvg.so
/usr/lib/gcc/i586-suse-linux/4.4/../../../../i586-suse-linux/bin/ld: BFD (GNU
Binutils; openSUSE 11.2) 2.19.51.20090527-10.26.4 internal error, aborting at
../../bfd/merge.c line 869 in _bfd_merged_section_offset

/usr/lib/gcc/i586-suse-linux/4.4/../../../../i586-suse-linux/bin/ld: Please
report this bug.

collect2: ld returned 1 exit status
make[2]: Leaving directory `/home/pielud/creator/semnotes/build'
make[1]: Leaving directory `/home/pielud/creator/semnotes/build'
make[2]: *** [src/semnotes] Error 1
make[1]: *** [src/CMakeFiles/semnotes.dir/all] Error 2
make: *** [all] Error 2
Exited with code 2.
Error while building project semnotes
When executing build step 'Make'



> gcc -v
Using built-in specs.
Target: i586-suse-linux
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib --libexecdir=/usr/lib
--enable-languages=c,c++,objc,fortran,obj-c++,java,ada
--enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.4
--enable-ssp --disable-libssp --with-bugurl=http://bugs.opensuse.org/
--with-pkgversion='SUSE Linux' --disable-libgcj --disable-libmudflap
--with-slibdir=/lib --with-system-zlib --enable-__cxa_atexit
--enable-libstdcxx-allocator=new --disable-libstdcxx-pch
--enable-version-specific-runtime-libs --program-suffix=-4.4
--enable-linux-futex --without-system-libunwind --with-arch-32=i586
--with-tune=generic --build=i586-suse-linux
Thread model: posix
gcc version 4.4.1 [gcc-4_4-branch revision 150839] (SUSE Linux)


=

uname -a
Linux quty 2.6.31.12-0.1-desktop #1 SMP PREEMPT 2010-01-27 08:20:11 +0100 i686
i686 i386 GNU/Linux




-- 
   Summary: 2.19.51.20090527-10.26.4 internal error
   Product: gcc
   Version: 4.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pierrelud at yahoo dot com


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

[Bug c++/26261] Rejects template with const static data member used in return type

[jason at gcc dot gnu dot org]

--- Comment #6 from jason at gcc dot gnu dot org  2010-02-16 16:46 ---
Clarified summary.  Since this isn't a regression and there is a workaround, it
doesn't seem like a high priority for 4.5.


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|Rejects template with local |Rejects template with const
   |static variable used in |static data member used in
   |return type |return type


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

[Bug rtl-optimization/43095] New: [avr] GCC produces poor code for 4- and 8-byte values

[jdpotter at andrew dot cmu dot edu]

Given the following input:

char greater_than_64(long long x, long long y) {
return x > y;
}
char greater_than_32(long x, long y) {
return x > y;
}

And running "avr-gcc -Os -c lol.c -o lol.o", I get the following output

0064 :
  64:   ef 92   pushr14
  66:   ff 92   pushr15
  68:   0f 93   pushr16
  6a:   1f 93   pushr17
  6c:   e2 2e   mov r14, r18
  6e:   f3 2e   mov r15, r19
  70:   04 2f   mov r16, r20
  72:   15 2f   mov r17, r21
  74:   31 e0   ldi r19, 0x01   ; 1
  76:   e6 16   cp  r14, r22
  78:   f7 06   cpc r15, r23
  7a:   08 07   cpc r16, r24
  7c:   19 07   cpc r17, r25
  7e:   04 f0   brlt.+0 ; 0x80 
  80:   30 e0   ldi r19, 0x00   ; 0
  82:   83 2f   mov r24, r19
  84:   1f 91   pop r17
  86:   0f 91   pop r16
  88:   ff 90   pop r15
  8a:   ef 90   pop r14
  8c:   08 95   ret

This is much longer than necessary; the input values could be left in their
original registers, rather than moved before comparison. I'm not sure why GCC
does this. The 8-byte version is even worse:

 :
   0:   af 92   pushr10
   2:   bf 92   pushr11
   4:   cf 92   pushr12
   6:   df 92   pushr13
   8:   ef 92   pushr14
   a:   ff 92   pushr15
   c:   0f 93   pushr16
   e:   1f 93   pushr17
  10:   e1 e0   ldi r30, 0x01   ; 1
  12:   19 17   cp  r17, r25
  14:   04 f0   brlt.+0 ; 0x16 
  16:   91 17   cp  r25, r17
  18:   01 f4   brne.+0 ; 0x1a 
  1a:   08 17   cp  r16, r24
  1c:   00 f0   brcs.+0 ; 0x1e 
  1e:   80 17   cp  r24, r16
  20:   01 f4   brne.+0 ; 0x22 
  22:   f7 16   cp  r15, r23
  24:   00 f0   brcs.+0 ; 0x26 
  26:   7f 15   cp  r23, r15
  28:   01 f4   brne.+0 ; 0x2a 
  2a:   e6 16   cp  r14, r22
  2c:   00 f0   brcs.+0 ; 0x2e 
  2e:   6e 15   cp  r22, r14
  30:   01 f4   brne.+0 ; 0x32 
  32:   d5 16   cp  r13, r21
  34:   00 f0   brcs.+0 ; 0x36 
  36:   5d 15   cp  r21, r13
  38:   01 f4   brne.+0 ; 0x3a 
  3a:   c4 16   cp  r12, r20
  3c:   00 f0   brcs.+0 ; 0x3e 
  3e:   4c 15   cp  r20, r12
  40:   01 f4   brne.+0 ; 0x42 
  42:   b3 16   cp  r11, r19
  44:   00 f0   brcs.+0 ; 0x46 
  46:   3b 15   cp  r19, r11
  48:   01 f4   brne.+0 ; 0x4a 
  4a:   a2 16   cp  r10, r18
  4c:   00 f0   brcs.+0 ; 0x4e 
  4e:   e0 e0   ldi r30, 0x00   ; 0
  50:   8e 2f   mov r24, r30
  52:   1f 91   pop r17
  54:   0f 91   pop r16
  56:   ff 90   pop r15
  58:   ef 90   pop r14
  5a:   df 90   pop r13
  5c:   cf 90   pop r12
  5e:   bf 90   pop r11
  60:   af 90   pop r10
  62:   08 95   ret

Here there are many redundant jumps as well as pushes and pops. It seems like
these could be trivially eliminated with a peephole pass.

I'm running a build straight out of trunk as of today:
Using built-in specs.
COLLECT_GCC=avr-gcc
COLLECT_LTO_WRAPPER=/usr/local/avr/libexec/gcc/avr/4.5.0/lto-wrapper
Target: avr
Configured with: ../configure --prefix=/usr/local/avr --target=avr
--enable-languages=c --disable-nls --disable-libssp --with-dwarf2 :
(reconfigured) ../configure --prefix=/usr/local/avr --target=avr
--enable-languages=c --disable-nls --disable-libssp --with-dwarf2
Thread model: single
gcc version 4.5.0 20100216 (experimental) (GCC)


-- 
   Summary: [avr] GCC produces poor code for 4- and 8-byte values
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jdpotter at andrew dot cmu dot edu


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

[Bug other/43094] 2.19.51.20090527-10.26.4 internal error

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2010-02-16 17:05 ---
>/usr/lib/gcc/i586-suse-linux/4.4/../../../../i586-suse-linux/bin/ld: BFD (GNU
Binutils; openSUSE 11.2) 2.19.51.20090527-10.26.4 internal error, aborting at
../../bfd/merge.c line 869 in _bfd_merged_section_offset


LD is crashing. LD is part of the binutils project and not GCC.  Please report
it to them: http:sourcewware.org/bugzilla but really you should report it to
opensuse as it is their version that crashes.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Component|c++ |other
 Resolution||INVALID


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

[Bug middle-end/41043] [4.4 Regression] virtual memory exhausted: Cannot allocate memory

[dominiq at lps dot ens dot fr]

--- Comment #9 from dominiq at lps dot ens dot fr  2010-02-16 17:06 ---
Apparently gfortran.dg/pr41043.f90 has not been committed. 
Thanks for the fix.


-- 


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

[Bug c++/35669] NULL (__null) not considered different from 0 with C++

[jason at gcc dot gnu dot org]

--- Comment #20 from jason at gcc dot gnu dot org  2010-02-16 17:10 ---
I would approve a patch to enable the warnings in conversion_null_warnings, and
the similar warning in build_expr_type_conversion, by default.  That is,
reverting revision 109847.  I don't know what Eric's rationale was for making
the warning off by default, so I'll add him to the CC list.


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||jason at gcc dot gnu dot
   ||org, echristo at apple dot
   ||com
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-02-16 17:10:54
   date||


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

[Bug ada/43096] New: ACATS c37105a wrong-code on arm-linux

[laurent at guerby dot net]

The following ACATS started failing:

,.,. C37105A ACATS 2.5 10-02-16 15:35:22^M
 C37105A RECORDS WITH ONLY DISCRIMINANTS.^M
   * C37105A DISCRIMINANT-ONLY RECORDS DON'T WORK.^M
 C37105A FAILED .^M

between:

PASS: LAST_UPDATED: Fri Jan 29 14:43:55 UTC 2010 (revision 156351)
http://gcc.gnu.org/ml/gcc-testresults/2010-01/msg02773.html

FAIL: LAST_UPDATED: Sat Jan 30 14:08:06 UTC 2010 (revision 156383)
http://gcc.gnu.org/ml/gcc-testresults/2010-01/msg02859.html

It has been consistently FAILing since.

Likely patch from looking at ChangeLog:

+2010-01-29  Eric Botcazou  
+
+   * tree-ssa-alias.c (same_type_for_tbaa): Return -1 if the types have
+   the same alias set and their sizes different constantness.
+   (aliasing_component_refs_p): Revert 2009-10-24 change.

I do not see it FAILing on other platforms.


-- 
   Summary: ACATS c37105a wrong-code on arm-linux
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: laurent at guerby dot net
 GCC build triplet: armv5tel-unknown-linux-gnueabi
  GCC host triplet: armv5tel-unknown-linux-gnueabi
GCC target triplet: armv5tel-unknown-linux-gnueabi


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

[Bug tree-optimization/43089] Optimizer ignores type in a conversion

[0xe2 dot 0x9a dot 0x9b at gmail dot com]

--- Comment #5 from 0xe2 dot 0x9a dot 0x9b at gmail dot com  2010-02-16 
17:37 ---
(In reply to comment #4)
> There is nothing to fix.  Your program triggers undefined behavior.  It can do
> anything, which can include something you'd expect, or something completely
> different and it can depend on compiler options, position of stars, etc.

I understand what you are saying, but I do not agree with that. I my opinion,
an *optimization* option should never result in any change of a program's
behavior for this particular kind of undefined behaviors. I mean, there are
basically two different kinds of undefined behaviors:

1. Where the compiler has to choose a *particular* implementation.

2. Where the compiler does not choose anything or cannot choose anything
particular. (For example, what happens if accessing deallocated memory.)

The conversion test-case is of the 1st kind. Not of the 2nd kind. GCC -O0
chooses to generate a particular sequence of instructions to implement the
undefined behavior. GCC -O2 does not respect the choice made at -O0 (or vice
versa).

So, my question is: If it is possible for the problematic code to be
implemented in all contexts by the same operation, and in this case it indeed
is possible, why is GCC using two different operations? How do you justify
that?


-- 

0xe2 dot 0x9a dot 0x9b at gmail dot com changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |


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

[Bug tree-optimization/43097] New: ICE in rename_map_elt_info for Graphite, vect in 173.applu

[janis at gcc dot gnu dot org]

GCC trunk gets an internal compiler error when building SPEC CPU2000 test
173.applu on powerpc64-linux with options "-O2 -fgraphite-identity
-ftree-vectorize" for either -m32 or -m64.  Here's a minimized testcase:

  subroutine foo (ldmx,ldmy,nx,ny,v)
  implicit real*8 (a-h, o-z)
  dimension v(5,ldmx,ldmy,*)
  dimension tmat(5,5)

  k = 2
  do j = 2, ny-1
 do i = 2, nx-1
do ip = 1, 4
   do m = ip+1, 5
  v(m,i,j,k) = v(m,i,j,k) * m
   end do
end do
do m = 5, 1, -1
   do l = m+1, 5
  v(m,i,j,k) = v(l,i,j,k)
   end do
   v(m,i,j,k) = m
   end do
 end do
  end do
  return
  end

elm3b149% /home/janis/tools/gcc-trunk-anonsvn/bin/gfortran -c -O2
-fgraphite-identity -ftree-vectorize bug.f
bug.f: In function ‘foo’:
bug.f:1:0: internal compiler error: tree check: expected ssa_name, have
var_decl in rename_map_elt_info, at sese.c:81
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

The benchmark and testcase compile cleanly with GCC 4.4.2.  The failure
begins with this patch:

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

r156711 | spop | 2010-02-11 19:42:38 + (Thu, 11 Feb 2010)


-- 
   Summary: ICE in rename_map_elt_info for Graphite, vect in
173.applu
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: janis at gcc dot gnu dot org
GCC target triplet: powerpc64-linux


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

[Bug middle-end/42220] [4.5 Regression] FAIL: gfortran.dg/complex_intrinsic_5.f90 -m64 -O -frename-registers

[bernds_cb1 at t-online dot de]

--- Comment #20 from bernds_cb1 at t-online dot de  2010-02-16 17:40 ---
Sorry I've seen this so late; the mails I got have been hidden in my unread
fortran folder so far.  Need to change the filters.

Comment #9 suggests you can reproduce this without -frename-registers.  Is this
correct?

What I'd be looking at is if mpc has functions written in assembly that maybe
clobber registers they shouldn't.


-- 


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

[Bug ada/43096] ACATS c37105a wrong-code on arm-linux

[laurent at guerby dot net]

--- Comment #1 from laurent at guerby dot net  2010-02-16 17:43 ---
Might be related to the same patch on powerpc-linux two different ACATS started
FAILing around the same time:

LAST_UPDATED: Fri Jan 29 08:20:22 UTC 2010 (revision 156342)
http://gcc.gnu.org/ml/gcc-testresults/2010-01/msg02125.html

LAST_UPDATED: Fri Jan 29 20:14:37 UTC 2010 (revision 156364)
http://gcc.gnu.org/ml/gcc-testresults/2010-01/msg02758.html
FAIL:   c46051a
FAIL:   c87b39a


--- gcc/ChangeLog   (revision 156342)
+++ gcc/ChangeLog   (revision 156364)
@@ -1,3 +1,33 @@
+2010-01-29  Eric Botcazou  
+
+   * tree-ssa-alias.c (same_type_for_tbaa): Return -1 if the types have
+   the same alias set and their sizes different constantness.
+   (aliasing_component_refs_p): Revert 2009-10-24 change.
+
+2010-01-29  Rainer Orth  
+
+   * config/sparc/sparc.c (sparc_elf_asm_named_section): Declare decl
+   unused.
+
+2010-01-29  Richard Guenther  
+
+   * tree-ssa-ccp.c (ccp_fold_stmt): Unshare values we substitute.
+   Assert we successfully updated the call.
+
+2010-01-29  Jakub Jelinek  
+
+   PR rtl-optimization/42889
+   * df.h (df_set_bb_dirty_nonlr): New prototype.
+   * df-core.c (df_set_bb_dirty_nonlr): New function.
+   * df-scan.c (df_insn_rescan): Call it instead of
+   df_set_bb_dirty for DEBUG_INSNs.
+
+2010-01-29  Richard Guenther  
+
+   PR middle-end/37448
+   * ipa-inline.c (cgraph_decide_inlining_incrementally): Avoid
+   quadratic behavior in most cases.
+


-- 


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

[Bug tree-optimization/36905] [4.3/4.4/4.5 Regression] IV-opts needs a little help with a[i+1]

[amonakov at gcc dot gnu dot org]

--- Comment #7 from amonakov at gcc dot gnu dot org  2010-02-16 17:43 
---
(In reply to comment #6)

Looks like this has been fixed.  We do generate good code:

fred:
li 0,100
mtctr 0
.L2:
sthu 3,2(4)
bdnz .L2
blr
.size   fred, .-fred
.ident  "GCC: (GNU) 4.5.0 20100215 (experimental)"

And ivopts dump is quite sane:

:
  ivtmp.13_17 = (unsigned int) out1_5(D);

:
  # i_13 = PHI 
  # ivtmp.13_15 = PHI 
  i_3 = i_13 + 1;
  ivtmp.13_16 = ivtmp.13_15 + 2;
  D.2031_18 = (void *) ivtmp.13_16;
  MEM[base: D.2031_18] = in_7(D);
  if (i_3 != 100)
goto ;
  else
goto ;

:
  goto ;


-- 

amonakov at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu dot
   ||org


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

Re: [Bug tree-optimization/43089] Optimizer ignores type in a conversion

[Andrew Pinski]

Sent from my iPhone

On Feb 16, 2010, at 9:37 AM, "0xe2 dot 0x9a dot 0x9b at gmail dot com"  
 wrote:





--- Comment #5 from 0xe2 dot 0x9a dot 0x9b at gmail dot com   
2010-02-16 17:37 ---

(In reply to comment #4)
There is nothing to fix.  Your program triggers undefined  
behavior.  It can do
anything, which can include something you'd expect, or something  
completely
different and it can depend on compiler options, position of stars,  
etc.


I understand what you are saying, but I do not agree with that. I my  
opinion,
an *optimization* option should never result in any change of a  
program's
behavior for this particular kind of undefined behaviors. I mean,  
there are

basically two different kinds of undefined behaviors:

1. Where the compiler has to choose a *particular* implementation.


Huh, this is the opposite effect of undefined behavior. In fact for  
signed interger overflow, gcc sometimes optimizes it as wrapping and  
others as clamping. In this case it is clamping. It is hard sometimes  
to optimize constiently undefined behavior because of inlining and  
other optimizations that can change the ir before the optimization of  
undefined behavior.




2. Where the compiler does not choose anything or cannot choose  
anything
particular. (For example, what happens if accessing deallocated  
memory.)


The conversion test-case is of the 1st kind. Not of the 2nd kind.  
GCC -O0
chooses to generate a particular sequence of instructions to  
implement the
undefined behavior. GCC -O2 does not respect the choice made at -O0  
(or vice

versa).

So, my question is: If it is possible for the problematic code to be
implemented in all contexts by the same operation, and in this case  
it indeed
is possible, why is GCC using two different operations? How do you  
justify

that?


--

0xe2 dot 0x9a dot 0x9b at gmail dot com changed:

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

Status|RESOLVED|UNCONFIRMED
Resolution|INVALID |


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

[Bug tree-optimization/43089] Optimizer ignores type in a conversion

[pinskia at gmail dot com]

--- Comment #6 from pinskia at gmail dot com  2010-02-16 17:51 ---
Subject: Re:  Optimizer ignores type in a conversion



Sent from my iPhone

On Feb 16, 2010, at 9:37 AM, "0xe2 dot 0x9a dot 0x9b at gmail dot com"  
 wrote:

>
>
> --- Comment #5 from 0xe2 dot 0x9a dot 0x9b at gmail dot com   
> 2010-02-16 17:37 ---
> (In reply to comment #4)
>> There is nothing to fix.  Your program triggers undefined  
>> behavior.  It can do
>> anything, which can include something you'd expect, or something  
>> completely
>> different and it can depend on compiler options, position of stars,  
>> etc.
>
> I understand what you are saying, but I do not agree with that. I my  
> opinion,
> an *optimization* option should never result in any change of a  
> program's
> behavior for this particular kind of undefined behaviors. I mean,  
> there are
> basically two different kinds of undefined behaviors:
>
> 1. Where the compiler has to choose a *particular* implementation.

Huh, this is the opposite effect of undefined behavior. In fact for  
signed interger overflow, gcc sometimes optimizes it as wrapping and  
others as clamping. In this case it is clamping. It is hard sometimes  
to optimize constiently undefined behavior because of inlining and  
other optimizations that can change the ir before the optimization of  
undefined behavior.

>
> 2. Where the compiler does not choose anything or cannot choose  
> anything
> particular. (For example, what happens if accessing deallocated  
> memory.)
>
> The conversion test-case is of the 1st kind. Not of the 2nd kind.  
> GCC -O0
> chooses to generate a particular sequence of instructions to  
> implement the
> undefined behavior. GCC -O2 does not respect the choice made at -O0  
> (or vice
> versa).
>
> So, my question is: If it is possible for the problematic code to be
> implemented in all contexts by the same operation, and in this case  
> it indeed
> is possible, why is GCC using two different operations? How do you  
> justify
> that?
>
>
> -- 
>
> 0xe2 dot 0x9a dot 0x9b at gmail dot com changed:
>
>   What|Removed |Added
> --- 
> --- 
> --
> Status|RESOLVED|UNCONFIRMED
> Resolution|INVALID |
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43089
>


-- 


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

[Bug c/43098] New: ICE in tree-sra.c with floating point exception

[bmei at broadcom dot com]

GCC (156804, x86_64-unknown-linux-gnu) generates an ICE in compiling the
following code. 

typedef __builtin_va_list va_list;


struct __attribute__((aligned (4))) S238 { struct{}a[24]; short b; } ; 
struct __attribute__((aligned (4))) S238 a238[5]; 

extern int fails;

void foo (int z, ...) { 
  struct __attribute__((aligned (4))) S238 arg, *p; 
  va_list ap; 
  int i; 

__builtin_va_start(ap,z);
for (i = 0; i < 5; ++i) 
{ 
  p = ((void *)0); 
  p = &a238[2]; 
  arg = __builtin_va_arg(ap,struct __attribute__((aligned (4))) S238); 
  if (p->b != arg.b) ++fails; 
}
 __builtin_va_end(ap); 
}

~/work/install-x86/bin/gcc t001_y.c -O2 -w
t001_y.c: In function 'foo':
t001_y.c:24:1: internal compiler error: Floating point exception
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

The error happens in tree-sra.c:1445, where el_size is 0
offset = offset % el_size;

It is likely caused by the following change:

   if (lacc && racc
   && (sra_mode == SRA_MODE_EARLY_INTRA || sra_mode == SRA_MODE_INTRA)
   && !lacc->grp_unscalarizable_region
@@ -1288,7 +1398,12 @@
  if (!tr_size || !host_integerp (tr_size, 1))
continue;
  size = tree_low_cst (tr_size, 1);
- if (pos > offset || (pos + size) <= offset)
+ if (size == 0)
+   {
+ if (pos != offset)
+   continue;
+   }
+ else if (pos > offset || (pos + size) <= offset)
continue;


Here, size = 0, pos = 0, offset = 0. So "continue" is executed in past,
but not with this patch, which causes the ICE later. I am not sure what
is intention of the patch, so would leave others to fix it.


-- 
   Summary: ICE in tree-sra.c  with floating point exception
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bmei at broadcom dot com
GCC target triplet: x86_64-unknown-linux-gnu


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

[Bug c++/35669] NULL (__null) not considered different from 0 with C++

[echristo at apple dot com]

--- Comment #21 from echristo at apple dot com  2010-02-16 18:01 ---
I remember that we originally ran into this warning in a huge number of places
building OSX.  Now I'd agree that null checking would be something good to
have, but there should be some way to turn it off if it's on by default.


-- 


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

[Bug c++/35669] NULL (__null) not considered different from 0 with C++

[manu at gcc dot gnu dot org]

--- Comment #22 from manu at gcc dot gnu dot org  2010-02-16 18:05 ---
Testing this:

Index: gcc/doc/invoke.texi
===
--- gcc/doc/invoke.texi (revision 156812)
+++ gcc/doc/invoke.texi (working copy)
@@ -3835,18 +3835,23 @@ like @code{unsigned ui = -1}; and conver
 ((int) x)} and @code{ui = (unsigned) -1}, or if the value is not
 changed by the conversion like in @code{abs (2.0)}.  Warnings about
 conversions between signed and unsigned integers can be disabled by
 using @option{-Wno-sign-conversion}.

-For C++, also warn for conversions between @code{NULL} and non-pointer
-types; confusing overload resolution for user-defined conversions; and
-conversions that will never use a type conversion operator:
-conversions to @code{void}, the same type, a base class or a reference
-to them. Warnings about conversions between signed and unsigned
-integers are disabled by default in C++ unless
+For C++, also warn for confusing overload resolution for user-defined
+conversions; and conversions that will never use a type conversion
+operator: conversions to @code{void}, the same type, a base class or a
+reference to them. Warnings about conversions between signed and
+unsigned integers are disabled by default in C++ unless
 @option{-Wsign-conversion} is explicitly enabled.

+...@item -Wno-conversion-nul
+...@opindex Wconversion-nul
+...@opindex Wno-conversion-nul
+Do not warn for conversions between @code{NULL} and non-pointer
+types. @option{-Wconversion-nul} is enabled by default.
+
 @item -Wempty-body
 @opindex Wempty-body
 @opindex Wno-empty-body
 Warn if an empty body occurs in an @samp{if}, @samp{else} or @samp{do
 while} statement.  This warning is also enabled by @option{-Wextra}.
Index: gcc/cp/call.c
===
--- gcc/cp/call.c   (revision 156812)
+++ gcc/cp/call.c   (working copy)
@@ -4802,19 +4802,19 @@ conversion_null_warnings (tree totype, t

   /* Issue warnings about peculiar, but valid, uses of NULL.  */
   if (expr == null_node && TREE_CODE (t) != BOOLEAN_TYPE && ARITHMETIC_TYPE_P
(t))
 {
   if (fn)
-   warning (OPT_Wconversion, "passing NULL to non-pointer argument %P of
%qD",
+   warning (OPT_Wconversion_nul, "passing NULL to non-pointer argument %P
of %qD",
 argnum, fn);
   else
-   warning (OPT_Wconversion, "converting to non-pointer type %qT from
NULL", t);
+   warning (OPT_Wconversion_nul, "converting to non-pointer type %qT from
NULL", t);
 }

   /* Issue warnings if "false" is converted to a NULL pointer */
   else if (expr == boolean_false_node && fn && POINTER_TYPE_P (t))
-warning (OPT_Wconversion,
+warning (OPT_Wconversion_nul,
 "converting % to pointer type for argument %P of %qD",
 argnum, fn);
 }

 /* Perform the conversions in CONVS on the expression EXPR.  FN and
Index: gcc/cp/cvt.c
===
--- gcc/cp/cvt.c(revision 156812)
+++ gcc/cp/cvt.c(working copy)
@@ -1139,11 +1139,11 @@ build_expr_type_conversion (int desires,
   tree winner = NULL_TREE;

   if (expr == null_node
   && (desires & WANT_INT)
   && !(desires & WANT_NULL))
-warning (OPT_Wconversion, "converting NULL to non-pointer type");
+warning (OPT_Wconversion_nul, "converting NULL to non-pointer type");

   basetype = TREE_TYPE (expr);

   if (basetype == error_mark_node)
 return error_mark_node;
Index: gcc/c.opt
===
--- gcc/c.opt   (revision 156812)
+++ gcc/c.opt   (working copy)
@@ -169,10 +169,14 @@ Synonym for -Wcomment

 Wconversion
 C ObjC C++ ObjC++ Var(warn_conversion) Warning
 Warn for implicit type conversions that may change a value

+Wconversion-nul
+C++ ObjC++ Var(warn_conversion_nul) Init(1) Warning
+Warn for converting NULL from/to a non-pointer type
+
 Wsign-conversion
 C ObjC C++ ObjC++ Var(warn_sign_conversion) Init(-1)
 Warn for implicit type conversions between signed and unsigned integers

 Wctor-dtor-privacy


-- 


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

[Bug c++/35669] NULL (__null) not considered different from 0 with C++

[echristo at apple dot com]

--- Comment #23 from echristo at apple dot com  2010-02-16 18:09 ---
That looks fine to me, though you'll probably want to use "null" instead of
null in the command line option. :)


-- 


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

[Bug middle-end/42220] [4.5 Regression] FAIL: gfortran.dg/complex_intrinsic_5.f90 -m64 -O -frename-registers

[dominiq at lps dot ens dot fr]

--- Comment #21 from dominiq at lps dot ens dot fr  2010-02-16 18:13 ---
> Comment #9 suggests you can reproduce this without -frename-registers.  Is 
> this
> correct?

>From comment #12:

> -funroll-loops triggers -frename-registers which again would hint at
> Bernds change.

I think the answer is no: the test passes with '-m64 -O1' but fails with '-m64
-O1 -frename-registers'.

For the record I am using GMP version 4.3.1, MPFR version 2.4.1, MPC version
0.8. If needed I can try to update to mpc 0.8.1 (so far I failed to update GMP,
both 4.3.2 and 5.0.1).


-- 


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