[Bug fortran/32382] missed optimization in internal read

2010-02-14 Thread jvdelisle at gcc dot gnu dot org


--- Comment #9 from jvdelisle at gcc dot gnu dot org  2010-02-14 08:29 
---
Subject: Bug 32382

Author: jvdelisle
Date: Sun Feb 14 08:28:50 2010
New Revision: 156755

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156755
Log:
2010-02-14  Jerry DeLisle  

PR fortran/32382
* trans-stmt.h: Add prototype for gfc_trans_code_cond. Add tree cond to
gfc_trans_do prototype.
* trans-stmt.c (gfc_trans_simple_do): Add optional argument to pass in
a loop exit condition.  If exit condition is given, build the loop exit
code, checking IO results of implied do loops in READ and WRITE.
(gfc_trans_do): Likewise.
* trans.c (trans_code): New static work function, previously
gfc_trans_code. Passes exit condition to gfc_trans_do.
(gfc_trans_code): Calls trans_code with NULL_TREE condition.
(gfc_trans_code_cond): Calls trans_code with loop exit condition.
* trans-io.c (build_dt): Build an exit condition to allow checking IO
result status bits in the dtparm structure. Use this condition in call
to gfc_trans_code_cond.

Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-io.c
trunk/gcc/fortran/trans-stmt.c
trunk/gcc/fortran/trans-stmt.h
trunk/gcc/fortran/trans.c


-- 


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



[Bug fortran/32382] missed optimization in internal read

2010-02-14 Thread jvdelisle at gcc dot gnu dot org


--- Comment #10 from jvdelisle at gcc dot gnu dot org  2010-02-14 08:33 
---
Fixed on trunk.


-- 

jvdelisle at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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



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

2010-02-14 Thread pault at gcc dot gnu dot org


--- Comment #5 from pault at gcc dot gnu dot org  2010-02-14 09:47 ---
(In reply to comment #4)
> mv 'Build' to 'CC' , Paul, please see previous comment.
> 

Joost,

You scared the life out of me when you said that it failed!  I had to exclude
dummies but I now do not recall why.  I'll look into it.

Cheers

Paul 


-- 


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



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

2010-02-14 Thread paolo dot carlini at oracle dot com


--- Comment #13 from paolo dot carlini at oracle dot com  2010-02-14 10:10 
---
Let's add Jason in CC instead, Doug doesn't contribute to GCC anymore.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 CC||jason at gcc dot gnu dot org
Summary|[4.3/4.4/4.5 Regresion] c++ |[4.3/4.4/4.5 Regression] c++
   |compilation hang|compilation hang


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



[Bug c/43059] Unstable behavior of --include option with gcc

2010-02-14 Thread paolo dot carlini at oracle dot com


--- Comment #1 from paolo dot carlini at oracle dot com  2010-02-14 10:15 
---
Cannot reproduce anything similar with currently maintained GCC branches. If
you can with gcc4.3.x or, better, gcc4.4.x, please re-open. By the way, you
definitely want const char* for printf, /not/ char *.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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



[Bug c/43059] Unstable behavior of --include option with gcc

2010-02-14 Thread RaghwendraKumar dot M at hcl dot in


--- Comment #2 from RaghwendraKumar dot M at hcl dot in  2010-02-14 10:38 
---
It is gcc (GCC) 3.4.6 20060404 (Red Hat 3.4.6-8)
I have made the neccessary change suggected by Paolo Carlini. Please note that
this is not related with coding bug. It is a compilation option related bug. It
shows the unpredictaed behavior of --include option with gcc. Please note that
CentOs (CentOS release 4.5) is used to execute the program.


-- 

RaghwendraKumar dot M at hcl dot in changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |


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



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

2010-02-14 Thread rguenth at gcc dot gnu dot org


--- Comment #14 from rguenth at gcc dot gnu dot org  2010-02-14 10:40 
---
Err, you can't simply adjust a types main variant like

t = build_cplus_array_type_1 (element_type, TYPE_DOMAIN (type));

if (TYPE_MAIN_VARIANT (t) != TYPE_MAIN_VARIANT (type))
  {
/* Set the main variant of the newly-created ARRAY_TYPE
   (with cv-qualified element type) to the main variant of
   the unqualified ARRAY_TYPE we started with.  */

as types are shared and build_cplus_array_type_1 can return an already
existing type.

I suppose the hashing machinery isn't working well with multidimensional
array types.

A way out is to build a distinct type copy here in the
TYPE_MAIN_VARIANT (t) != TYPE_MAIN_VARIANT (type) case.  Though you have
to watch out for proper TYPE_CANONICAL.


-- 


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



[Bug c/43059] Unstable behavior of --include option with gcc

2010-02-14 Thread paolo dot carlini at oracle dot com


--- Comment #3 from paolo dot carlini at oracle dot com  2010-02-14 10:41 
---
Yes, and again, I can't reproduce anything similar with current, maintained (at
variance with 3.4.x) GCCs, that is 4.3.x and 4.4.x.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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



[Bug fortran/43042] [-fwhole-file] ICE in gfc_conv_structure for c_ptr_tests_14.f90

2010-02-14 Thread tkoenig at gcc dot gnu dot org


--- Comment #1 from tkoenig at gcc dot gnu dot org  2010-02-14 11:49 ---
Reduced test case:

odule m
  use iso_c_binding
  type, public :: fgsl_file
 type(c_ptr):: gsl_file  = c_null_ptr
  end type fgsl_file
contains
  subroutine sub(aaa,bbb)
type(fgsl_file), intent(out)   :: aaa
type(fgsl_file), intent(inout) :: bbb
  end subroutine
end module m

program test
  use m
  implicit none
  type(fgsl_file) :: file, noreinit
  integer, target :: tgt

  call sub(file, noreinit)
end program test

The ICE goes away if the initialization with c_null_pointer is omitted.

This is probably due to the type punning we do with C interop.


-- 

tkoenig at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||tkoenig at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-02-14 11:49:36
   date||


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



[Bug c++/31755] Clarify NULL pointer conversion to other types in initialiser

2010-02-14 Thread jg at jguk dot org


--- Comment #2 from jg at jguk dot org  2010-02-14 12:34 ---

(In reply to comment #1)
> (In reply to comment #0)
> > Could the warning message below be revised to include a warning that NULL 
> > will
> > evaluate to false or zero?
> 
> What else would it evaluate to?

In C++ NULL is defined as 0, or 0L. However, as it is a special keyword, I
would like g++ to identify that it is special, and warn when initialising non
pointer types to be NULL.


> N.B. with recent versions of GCC -Wconversion is needed and the conversion to
> bool no longer warns

Ah ok, so it does this already, with the -Wconversion.. I had expected that
would be in -Wall!  Can it be added to -Wall?

Jon


-- 


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



[Bug fortran/43039] [lto/-fwhole-file] ICE in gfc_conv_component_ref dynamic_dispatch_5.f03

2010-02-14 Thread tkoenig at gcc dot gnu dot org


--- Comment #2 from tkoenig at gcc dot gnu dot org  2010-02-14 12:38 ---
The problem appears to be a lack of a backend_decl with
-fwhole-file:

Breakpoint 1, fancy_abort (file=0xd474a0
"../../trunk/gcc/fortran/trans-expr.c", line=466,
function=0xd47e40 "gfc_conv_component_ref") at
../../trunk/gcc/diagnostic.c:727
727 {
(gdb) up
#1  0x00557e63 in gfc_conv_component_ref () at
../../trunk/gcc/fortran/trans-expr.c:466
466   gcc_assert (c->backend_decl);
(gdb) p c->backend_decl
$1 = (tree) 0x0
(gdb) p *c
$2 = {name = 0x75d0af18 "$vptr", ts = {type = BT_DERIVED, kind = 0, u =
{derived = 0x13d11b0,
  cl = 0x13d11b0}, interface = 0x0, is_c_interop = 0, is_iso_c = 0,
f90_type = BT_DERIVED}, attr = {
allocatable = 0, dimension = 0, external = 0, intrinsic = 0, optional = 0,
pointer = 1, target = 0,
value = 0, volatile_ = 0, temporary = 0, dummy = 0, result = 0, assign = 0,
threadprivate = 0,
not_always_present = 0, implied_index = 0, subref_array_pointer = 0,
proc_pointer = 0, asynchronous = 0,
class_pointer = 0, save = SAVE_NONE, data = 0, is_protected = 0, use_assoc
= 0, use_only = 0,
use_rename = 0, imported = 0, in_namelist = 0, in_common = 0,
in_equivalence = 0, function = 0,
subroutine = 0, procedure = 0, generic = 0, generic_copy = 0, implicit_type
= 0, untyped = 0,
is_bind_c = 0, extension = 0, is_class = 0, class_ok = 0, vtab = 0,
is_c_interop = 0, is_iso_c = 0,
sequence = 0, elemental = 0, pure = 0, recursive = 0, unmaskable = 0,
masked = 0, contained = 0,
mod_proc = 0, abstract = 0, noreturn = 0, entry = 0, entry_master = 0,
mixed_entry_master = 0,
always_explicit = 0, referenced = 0, is_main_program = 0, access =
ACCESS_UNKNOWN, intent = INTENT_UNKNOWN,
flavor = FL_UNKNOWN, if_source = IFSRC_UNKNOWN, proc = PROC_UNKNOWN,
cray_pointer = 0, cray_pointee = 0,
alloc_comp = 0, pointer_comp = 0, proc_pointer_comp = 0, private_comp = 0,
zero_comp = 0, ext_attr = 0,
volatile_ns = 0x0, asynchronous_ns = 0x0}, as = 0x0, backend_decl = 0x0,
loc = {nextc = 0x0, lb = 0x0},
  initializer = 0x13d06e0, next = 0x0, formal = 0x0, formal_ns = 0x0, tb = 0x0}

Confirmed.


-- 

tkoenig at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||tkoenig at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-02-14 12:39:00
   date||


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



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

2010-02-14 Thread dominiq at lps dot ens dot fr
Between revisions156515 and 156527 many new failures have appeared in the objc
test suite (see http://gcc.gnu.org/ml/gcc-regression/2010-02/msg00013.html ).
These errors are still there at revision 156749 (see
http://gcc.gnu.org/ml/gcc-testresults/2010-02/msg01291.html or
http://gcc.gnu.org/ml/gcc-testresults/2010-02/msg01290.html ) and seem to need
'-On  -fnext-runtime' with n!=0.

Note that the errors do not appear on the Jack Howarth tests for
x86_64-apple-darwin10.3.0 (see
http://gcc.gnu.org/ml/gcc-testresults/2010-02/msg01258.html ) while they do on 
x86_64-apple-darwin10.2 (see
http://gcc.gnu.org/ml/gcc-testresults/2010-02/msg00747.html ).


-- 
   Summary: 47 new GCC h...@156527 regressions
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: objc
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dominiq at lps dot ens dot fr
 GCC build triplet: *-apple-darwin*
  GCC host triplet: *-apple-darwin*
GCC target triplet: *-apple-darwin*


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



[Bug fortran/43062] New: NAMELIST attribute conflicts with ALLOCATABLE attribute

2010-02-14 Thread zazzou at gmail dot com
Report :

Using built-in specs.
Target: powerpc-apple-darwin9.8.0
Configured with: ./configure
Thread model: posix
gcc version 4.4.3 (GCC) 
COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.5.8' '-v' '-save-temps' '-c'
 /usr/local/libexec/gcc/powerpc-apple-darwin9.8.0/4.4.3/f951 prog.f90 -fPIC
-quiet -dumpbase prog.f90 -mmacosx-version-min=10.5.8 -auxbase prog -version
-fintrinsic-modules-path
/usr/local/lib/gcc/powerpc-apple-darwin9.8.0/4.4.3/finclude -o prog.s
GNU Fortran (GCC) version 4.4.3 (powerpc-apple-darwin9.8.0)
compiled by GNU C version 4.4.3, GMP version 5.0.1, MPFR version 2.4.2.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
prog.f90:3.17:

NAMELIST/TOTO/TAB
 1
Error: NAMELIST attribute conflicts with ALLOCATABLE attribute in 'tab' at (1)


Test file :

PROGRAM MAIN
REAL, DIMENSION(:), ALLOCATABLE :: TAB
NAMELIST/TOTO/TAB
END PROGRAM MAIN


It should work with F2003 new features.


-- 
   Summary: NAMELIST attribute conflicts with ALLOCATABLE attribute
   Product: gcc
   Version: 4.4.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: zazzou at gmail dot com


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



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

2010-02-14 Thread developer at sandoe-acoustics dot co dot uk


--- Comment #1 from developer at sandoe-acoustics dot co dot uk  2010-02-14 
13:46 ---
confirmed, this can be reproduced outside the testsuite framework:
for example... [ppc/darwin9/156749];

$ ./gcc/xgcc -B gcc ../gcc-4-5-trunk/gcc/testsuite/objc/execute/cascading-1.m
-fnext-runtime -O1 -o tc -lobjc -g -save-temps

$ gdb tc
GNU gdb 6.3.50-20050815 (Apple version gdb-967) (Tue Jul 14 02:15:14 UTC 2009)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "powerpc-apple-darwin"...Reading symbols for shared
libraries . done

(gdb) run
Starting program: /Volumes/ScratchCS/gcc-4-5-trunk-build/tc 
Reading symbols for shared libraries +++... done

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x466f6f20
0x9622dfd8 in objc_msgSend ()
(gdb) backtrace
#0  0x9622dfd8 in objc_msgSend ()
#1  0x1f8c in main (argc=, argv=) at
../gcc-4-5-trunk/gcc/testsuite/objc/execute/cascading-1.m:33
(gdb) 


-- 


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



[Bug fortran/32382] missed optimization in internal read

2010-02-14 Thread hjl dot tools at gmail dot com


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

   Target Milestone|--- |4.5.0


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



[Bug c++/41997] [C++0x] constant initializer_list not optimised

2010-02-14 Thread jason at gcc dot gnu dot org


--- Comment #4 from jason at gcc dot gnu dot org  2010-02-14 15:17 ---
Subject: Bug 41997

Author: jason
Date: Sun Feb 14 15:17:30 2010
New Revision: 156760

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156760
Log:
PR c++/41997
* semantics.c (finish_compound_literal): Use
cp_apply_type_quals_to_decl when creating a static variable.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/initlist-opt.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/semantics.c
trunk/gcc/testsuite/ChangeLog


-- 


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



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

2010-02-14 Thread rguenth at gcc dot gnu dot org


--- Comment #2 from rguenth at gcc dot gnu dot org  2010-02-14 15:25 ---
Track down the regression that caused this and see what actually is the
difference in generated code and/or tree/rtl dumps.  Access to non-free
operating systems is restricted.


-- 


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



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

2010-02-14 Thread developer at sandoe-acoustics dot co dot uk


--- Comment #3 from developer at sandoe-acoustics dot co dot uk  2010-02-14 
16:04 ---
(In reply to comment #2)
> Track down the regression that caused this

r156519

>and see what actually is the  difference in generated code and/or tree/rtl 
>dumps. 

what output would be the most useful?


-- 


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



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

2010-02-14 Thread rguenth at gcc dot gnu dot org


--- Comment #4 from rguenth at gcc dot gnu dot org  2010-02-14 16:28 ---
(In reply to comment #3)
> (In reply to comment #2)
> > Track down the regression that caused this
> 
> r156519
> 
> >and see what actually is the  difference in generated code and/or tree/rtl 
> >dumps. 
> 
> what output would be the most useful?

Make one directory for each revision for outputs from -fdump-tree-all,
tar them up and attach them.  A single testcase that passes before and
fails after the revision should be enough.  You can leave out dumps
that are identical for both revisions.


-- 


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



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

2010-02-14 Thread developer at sandoe-acoustics dot co dot uk


--- Comment #5 from developer at sandoe-acoustics dot co dot uk  2010-02-14 
16:32 ---
Created an attachment (id=19860)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19860&action=view)
generated asm differences with/without r156519


-- 


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



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

2010-02-14 Thread developer at sandoe-acoustics dot co dot uk


--- Comment #6 from developer at sandoe-acoustics dot co dot uk  2010-02-14 
16:33 ---
Created an attachment (id=19861)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19861&action=view)
optimized tree diffs.


-- 


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



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

2010-02-14 Thread developer at sandoe-acoustics dot co dot uk


--- Comment #7 from developer at sandoe-acoustics dot co dot uk  2010-02-14 
16:45 ---
Created an attachment (id=19862)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19862&action=view)
diffs for all fdump-tree-all output


-- 


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



[Bug fortran/43062] NAMELIST attribute conflicts with ALLOCATABLE attribute

2010-02-14 Thread pault at gcc dot gnu dot org


--- Comment #1 from pault at gcc dot gnu dot org  2010-02-14 17:21 ---
Yes indeed!  Section 5.4 of F2003 removes most of the restrictions for
namelist-group-objects. Ifort 11.1 does the right thing with your testcase. 

Thanks for the report.

Paul


-- 

pault at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||rejects-valid
   Last reconfirmed|-00-00 00:00:00 |2010-02-14 17:21:24
   date||


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



[Bug fortran/43062] NAMELIST attribute conflicts with ALLOCATABLE attribute

2010-02-14 Thread kargl at gcc dot gnu dot org


--- Comment #2 from kargl at gcc dot gnu dot org  2010-02-14 17:27 ---

> NAMELIST/TOTO/TAB
>  1
> Error: NAMELIST attribute conflicts with ALLOCATABLE attribute in 'tab' at (1)
> 
> 
> Test file :
> 
> PROGRAM MAIN
> REAL, DIMENSION(:), ALLOCATABLE :: TAB
> NAMELIST/TOTO/TAB
> END PROGRAM MAIN
> 
> 
> It should work with F2003 new features.

Interesting.  I can't find a passage in the F2003 standard that
specifically allows this form.  I do find a passage that indicates
that it is not allowed.  In section 5.4:

A namelist group object shall either be accessed by use or
host association or shall have its type, type parameters, and
shape specified by previous specification statements ...

In your code, the shape of the array has not been specified by a
previous specification statement.  OTOH, I do find in 9.5.3.6,

Every allocatable namelist-group-object in the namelist group
shall be allocated and every namelist-group-object that is a
pointer shall be associated with a target.

which suggests that the form is legal.


-- 


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



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

2010-02-14 Thread rguenth at gcc dot gnu dot org


--- Comment #8 from rguenth at gcc dot gnu dot org  2010-02-14 17:44 ---
Hm.  So CCP through get_symbol_constant_value causes

 :
-  _OBJC_CLASS_REFERENCES_0.2_1 = _OBJC_CLASS_REFERENCES_0;
+  _OBJC_CLASS_REFERENCES_0.2_1 = (struct objc_class *) &_OBJC_CLASS_NAME_0;
   _OBJC_CLASS_REFERENCES_0.3_2 = (struct objc_object *)
_OBJC_CLASS_REFERENCES_0.2_1;
-  _OBJC_SELECTOR_REFERENCES_0.4_3 = _OBJC_SELECTOR_REFERENCES_0;
+  _OBJC_SELECTOR_REFERENCES_0.4_3 = (struct objc_selector *)
&_OBJC_METH_VAR_NAME_1;
   D.3683_4 = OBJ_TYPE_REF(objc_msgSend;_OBJC_CLASS_REFERENCES_0.3_2->0)
(_OBJC_CLASS_REFERENCES_0.3_2, _OBJC_SELECTOR_REFERENCES_0.4_3);
-  _OBJC_SELECTOR_REFERENCES_1.5_5 = _OBJC_SELECTOR_REFERENCES_1;
+  _OBJC_SELECTOR_REFERENCES_1.5_5 = (struct objc_selector *)
&_OBJC_METH_VAR_NAME_0;
   OBJ_TYPE_REF(objc_msgSend;D.3683_4->0) (D.3683_4,
_OBJC_SELECTOR_REFERENCES_1.5_5);
   return 0;

which means that _OBJC_CLASS_REFERENCES_0 must be a TREE_READONLY static
with an initializer.  I wonder how exactly that tree looks like, so can
you run the compile inside gdb, break on get_symbol_constant_value
until you get _OBJC_CLASS_REFERENCES_0 as argument (may happen multiple
times) and paste the output of

(gdb) call debug_tree (sym)
(gdb) call debug_tree (sym->decl_common.initial)

?

Thanks.


-- 


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



[Bug libmudflap/43063] New: libmudflap: errors when accessing struct lconv members

2010-02-14 Thread stefan-usenet at bytereef dot org
libmudflap reports invalid reads when the result of localeconv() is accessed:


lconv.c:
=
#include 
#include 


int
main(void)
{
struct lconv *lc;

lc = localeconv();
printf("%s\n", lc->grouping);

return 0;
}
=


Compiled with:

gcc-4.3 -Wall -W -O2 -fmudflap -o lconv lconv.c -lmudflap


Output:

***
mudflap violation 1 (check/read): time=1266169553.865149 ptr=0x7fda790a80c0
size=24
pc=0x7fda790b63d1 location=`lconv.c:11:2 (main)'
  /usr/lib/libmudflap.so.0(__mf_check+0x41) [0x7fda790b63d1]
  ./lconv(main+0x8f) [0x400aaf]
  /lib/libc.so.6(__libc_start_main+0xe6) [0x7fda78d59466]
Nearby object 1: checked region begins 1929B after and ends 1952B after
mudflap object 0xc83770: name=`stderr'
bounds=[0x7fda790a7860,0x7fda790a7937] size=216 area=static check=0r/0w
liveness=0
alloc time=1266169553.865140 pc=0x7fda790b6d71
Nearby object 2: checked region begins 2153B after and ends 2176B after
mudflap object 0xc836b0: name=`stdout'
bounds=[0x7fda790a7780,0x7fda790a7857] size=216 area=static check=0r/0w
liveness=0
alloc time=1266169553.865140 pc=0x7fda790b6d71
number of nearby objects: 2


-- 
   Summary: libmudflap: errors when accessing struct lconv members
   Product: gcc
   Version: 4.3.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libmudflap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: stefan-usenet at bytereef dot org
 GCC build triplet: x86_64-unknown-linux-gnu
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu


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



[Bug c++/43064] New: Include member name in C++ warning

2010-02-14 Thread jg at jguk dot org
I noticed the C++ warnings in the following example have incorrect line
numbers, and the member name is missing. Is it possible to improve the warning
output?



$ g++ -Wconversion -o t main.cpp
main.cpp: In constructor ‘A::A()’:
main.cpp:18: warning: converting to non-pointer type ‘int’ from NULL
main.cpp:18: warning: converting to non-pointer type ‘unsigned int’ from NULL


I think the output should be like:

main.cpp:15: In constructor ‘A::A()’:
main.cpp:18: warning: converting to m_int non-pointer type ‘int’ from NULL
main.cpp:18: warning: converting to m_unit non-pointer type ‘unsigned int’ from
NULL


sample:
==
// g++ -Wconversion -o t main.cpp

// include to get definition of NULL
#include 

class A
{
public:
A();
bool m_bool;
int m_int;
unsigned int m_uint;
};

A::A()
: m_bool(NULL),
m_int(NULL),
m_uint(NULL)
{
}

int main()
{   
}



-- 
   Summary: Include member name in C++ warning
   Product: gcc
   Version: 4.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jg at jguk dot org


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



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

2010-02-14 Thread developer at sandoe-acoustics dot co dot uk


--- Comment #9 from developer at sandoe-acoustics dot co dot uk  2010-02-14 
18:50 ---
(In reply to comment #8)
> Hm.  So CCP through get_symbol_constant_value causes

> you run the compile inside gdb, break on get_symbol_constant_value

maybe I've messed something up - but setting a break on
get_symbol_constant_value ..
.. the cc1obj just completes with "Program exited normally'.


-- 


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



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

2010-02-14 Thread rguenth at gcc dot gnu dot org


--- Comment #10 from rguenth at gcc dot gnu dot org  2010-02-14 19:00 
---
(In reply to comment #9)
> (In reply to comment #8)
> > Hm.  So CCP through get_symbol_constant_value causes
> 
> > you run the compile inside gdb, break on get_symbol_constant_value
> 
> maybe I've messed something up - but setting a break on
> get_symbol_constant_value ..
> .. the cc1obj just completes with "Program exited normally'.

That can't be.  Make sure to enable optimization though.


-- 


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



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

2010-02-14 Thread rguenth at gcc dot gnu dot org


--- Comment #11 from rguenth at gcc dot gnu dot org  2010-02-14 19:01 
---
Btw, I cannot make -fnext-runtime work on i?86-linux, it errors at link time
with
undefined references.  Any configure options I need to supply?


-- 


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



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

2010-02-14 Thread pinskia at gcc dot gnu dot org


--- Comment #12 from pinskia at gcc dot gnu dot org  2010-02-14 19:07 
---
(In reply to comment #11)
> Btw, I cannot make -fnext-runtime work on i?86-linux, it errors at link time
> with
> undefined references.  Any configure options I need to supply?
> 

The next runtime only works on Darwin.


-- 


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



[Bug fortran/41113] spurious _gfortran_internal_pack

2010-02-14 Thread pault at gcc dot gnu dot org


--- Comment #18 from pault at gcc dot gnu dot org  2010-02-14 19:25 ---
(In reply to comment #15)
> Created an attachment (id=19824)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19824&action=view) [edit]
> Second  test giving a segmentation fault with the patch applied to fortran-dev
> 

At line 5520:

  if (!sym->attr.pointer
&& sym->as
&& sym->as->type != AS_ASSUMED_SHAPE 
&& !sym->attr.allocatable)

where the test for sym->as has been added, does the job.

I have included this in the fix to PR39632/3, so that the merge goes OK.

Cheers

Paul


-- 


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



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

2010-02-14 Thread jv244 at cam dot ac dot uk


--- Comment #6 from jv244 at cam dot ac dot uk  2010-02-14 19:27 ---
(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 c++/43064] improve location and text of Wconversion warning for initializer list

2010-02-14 Thread manu at gcc dot gnu dot org


--- Comment #1 from manu at gcc dot gnu dot org  2010-02-14 19:44 ---
Currently, the location given is at the end of the initializer list. Probably
each initialization expression is assigned that location instead of their own
position. It should be possible to improve this. 

On the other hand, printing the name of the variable may not be that easy,
since I think we do not have that information at the moment we give the
warning.


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||manu at gcc dot gnu dot org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-02-14 19:44:58
   date||
Summary|Include member name in C++  |improve location and text of
   |warning |Wconversion warning for
   ||initializer list


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



[Bug c++/43064] improve location and text of Wconversion warning for initializer list

2010-02-14 Thread manu at gcc dot gnu dot org


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|normal  |enhancement


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



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

2010-02-14 Thread paul dot richard dot thomas at gmail dot com


--- Comment #7 from paul dot richard dot thomas at gmail dot com  
2010-02-14 19:54 ---
Subject: Re:  unneeded temporary (2x)

Joost,

This time I beat you to it :-)

Dominique's problems on fortran-dev are fixed by a test for the
array_spec, which also fixes this one.

As soon as somebody gives me the green light, I'll apply the patch.
The present version is attached.

Cheers

Paul

On Sun, Feb 14, 2010 at 8:27 PM, jv244 at cam dot ac dot uk
 wrote:
>
>
> --- Comment #6 from jv244 at cam dot ac dot uk  2010-02-14 19:27 ---
> (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
>
> --- You are receiving this mail because: ---
> You are on the CC list for the bug, or are watching someone who is.
>


--- Comment #8 from paul dot richard dot thomas at gmail dot com  
2010-02-14 19:54 ---
Created an attachment (id=19863)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19863&action=view)


-- 


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



[Bug fortran/41113] spurious _gfortran_internal_pack

2010-02-14 Thread dominiq at lps dot ens dot fr


--- Comment #19 from dominiq at lps dot ens dot fr  2010-02-14 19:58 ---
(In reply to comment #18)
> ... where the test for sym->as has been added, does the job.

It does not fix the problem in my tree, I'll try the branch. 

> I have included this in the fix to PR39632/3, so that the merge goes OK.

Probably pr36932/3;-)


-- 


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



[Bug c++/31755] Clarify NULL pointer conversion to other types in initialiser

2010-02-14 Thread manu at gcc dot gnu dot org


--- Comment #3 from manu at gcc dot gnu dot org  2010-02-14 20:04 ---
(In reply to comment #2)
> In C++ NULL is defined as 0, or 0L. However, as it is a special keyword, I
> would like g++ to identify that it is special, and warn when initialising non
> pointer types to be NULL.

This is on purpose. See PR c++/24745.

> Ah ok, so it does this already, with the -Wconversion.. I had expected that
> would be in -Wall!  Can it be added to -Wall?

No, it can't. Wconversion is too noisy at the moment and it warns for perfectly
legitimate code that is difficult to change. I think it is to imprecise even
for -Wextra.

http://gcc.gnu.org/wiki/NewWconversion

Since there is another bug for the other issues you mention, I am closing this
one as INVALID.


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||manu at gcc dot gnu dot org
 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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



[Bug fortran/41113] spurious _gfortran_internal_pack

2010-02-14 Thread dominiq at lps dot ens dot fr


--- Comment #20 from dominiq at lps dot ens dot fr  2010-02-14 20:06 ---
(In reply to comment #18)
> ... where the test for sym->as has been added, does the job.

This works for a clean fortran-dev+ patch in comment #6. Note that my tree
includes patch for pr36932/3.


-- 


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



[Bug target/29189] Error during CPP build of Mozilla

2010-02-14 Thread manu at gcc dot gnu dot org


--- Comment #11 from manu at gcc dot gnu dot org  2010-02-14 20:07 ---
Is this still an issue? 4.1 is too old already.


-- 


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



[Bug fortran/41113] spurious _gfortran_internal_pack

2010-02-14 Thread dominiq at lps dot ens dot fr


--- Comment #21 from dominiq at lps dot ens dot fr  2010-02-14 20:16 ---
The ICEs are fixed by the last change in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36932#c8 :

@@ -5548,7 +5550,8 @@ gfc_conv_array_parameter (gfc_se * se, g
 }

   if (contiguous && g77 && !this_array_result
-   && !expr->symtree->n.sym->attr.dummy)
+&& expr->symtree->n.sym->as
+   && expr->symtree->n.sym->as->type != AS_ASSUMED_SHAPE)
 {
   gfc_conv_expr_descriptor (se, expr, ss);
   if (expr->ts.type == BT_CHARACTER)


-- 


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



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

2010-02-14 Thread manu at gcc dot gnu dot org


--- Comment #17 from manu at gcc dot gnu dot org  2010-02-14 20:18 ---
(In reply to comment #16)
> 
> This PR, then, is not an accepts-invalid.  It's an enhancement request to
> reinstate one of the warnings, about accidentally inappropriate use of NULL,
> that became disabled by default between gcc-4.1 and gcc-4.2.

Which one? We are not going to warn for conversions to boolean and we are not
going to warn for explicit conversions. And we are not going to warn by
default, only with -Wconversion. So, please post a testcase as minimal and
self-contained (with the smallest number of includes) as possible and point out
exactly what you expect to happen.


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING


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



[Bug c++/41779] Wconversion cannot see throught real*integer promotions

2010-02-14 Thread manu at gcc dot gnu dot org


--- Comment #3 from manu at gcc dot gnu dot org  2010-02-14 20:28 ---
I think this is a bug in Wconversion. It should be able to see through
promotions that the conversion cannot lead to a change of value.


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||manu at gcc dot gnu dot org
   Severity|minor   |enhancement
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||diagnostic
   Last reconfirmed|-00-00 00:00:00 |2010-02-14 20:28:45
   date||
Summary|Spurious integral promotion |Wconversion cannot see
   ||throught real*integer
   ||promotions


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



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

2010-02-14 Thread developer at sandoe-acoustics dot co dot uk


--- Comment #13 from developer at sandoe-acoustics dot co dot uk  
2010-02-14 21:13 ---
Created an attachment (id=19864)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19864&action=view)
gdb-output for CLASS_REFERENCES_0 


-- 


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



[Bug tree-optimization/43065] New: gcc.c-torture/execute/20051215-1.c is miscompiled with -fgraphite-identity

2010-02-14 Thread zsojka at seznam dot cz
Command line:
gcc -O1 -fgraphite-identity 20051215-1.c && ./a.out

Tested revisons:
trunk r156745 - crash
trunk r156693 - crash
trunk r155833 - crash
trunk r153685 - crash
4.4 r156256 - OK
4.4 r153668 - OK

$ /mnt/svn/gcc-trunk/binary-156745-lto/bin/gcc -O1 -fgraphite-identity
20051215-1.c && ./a.out
Segmentation fault (SIGSEGV)

Valgrind reports no problems during compilation.


-- 
   Summary: gcc.c-torture/execute/20051215-1.c is miscompiled with -
fgraphite-identity
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: zsojka at seznam dot cz
  GCC host triplet: x86_64-pc-linux-gnu
GCC target triplet: x86_64-pc-linux-gnu


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



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

2010-02-14 Thread rguenth at gcc dot gnu dot org


--- Comment #14 from rguenth at gcc dot gnu dot org  2010-02-14 21:29 
---
That doesn't make sense.  The symbol is not TREE_READONLY.

Was that dump from inside get_symbol_constant_value?

As the extract only happens from CCP2 I suppose that ipa-reference might
be setting TREE_READONLY on the decl becaue it's static and not written to?
So, can you try with -fno-ipa-reference?  (-fdump-ipa-reference should
show "read-only var OBJC_CLASS_REFERENCES_0" if that is the problem)

Can it be that the next runtime causes functions to be emitted in the
back of cgraph?  Or maybe the objc frontend fails to set TREE_ADDRESSABLE
on those vars? Or it forgets to pass them to the varpool?

Can you attach the full ipa-reference dump and the full 004.gimple dump?


-- 


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



[Bug tree-optimization/43065] [4.5 Regression] gcc.c-torture/execute/20051215-1.c is miscompiled with -fgraphite-identity

2010-02-14 Thread rguenth at gcc dot gnu dot org


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords||wrong-code
  Known to work||4.4.3
Summary|gcc.c-  |[4.5 Regression] gcc.c-
   |torture/execute/20051215-1.c|torture/execute/20051215-1.c
   |is miscompiled with -   |is miscompiled with -
   |fgraphite-identity  |fgraphite-identity
   Target Milestone|--- |4.5.0


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



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

2010-02-14 Thread l dot lunak at suse dot cz


--- Comment #18 from l dot lunak at suse dot cz  2010-02-14 21:47 ---
(In reply to comment #17)
> Which one? We are not going to warn for conversions to boolean and we are not
> going to warn for explicit conversions.

 I don't see anybody asking for that.

> And we are not going to warn by default, only with -Wconversion.

 If you fail to see the difference between NULL being converted to integer
being almost always a mistake and the flood of warnings caused by -Wcoversion
to be almost almost harmless in real-world code, then you probably might as
well not bother at all. A warning about something that's almost for sure a
mistake being part of a flag that almost nobody uses is next to useless.

> So, please post a testcase as minimal and self-contained (with the smallest
> number of includes) as possible and point out
> exactly what you expect to happen.

Well, it's all in the original comment of this bugreport, but if you insist:

Testcase (a.c):

#include 
void foo( int a );
int main()
{
foo( NULL );
foo( 0 );
int a = NULL;
return 0;
}

Expected output (like 'gcc -Wall -c a.c' provides):

a.c: In function ‘main’:
a.c:5: warning: passing argument 1 of ‘foo’ makes integer from
pointer without a cast
a.c:2: note: expected ‘int’ but argument is of type ‘void
*’
a.c:7: warning: initialization makes integer from pointer without a cast
a.c:7: warning: unused variable ‘a’

Actual output (what 'g++ -Wall -c a.c' provides):

a.c: In function ‘int main()’:
a.c:7: warning: unused variable ‘a’

The warning about the unused variable is obviously irrelevant.


-- 

l dot lunak at suse dot cz changed:

   What|Removed |Added

 Status|WAITING |UNCONFIRMED


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



[Bug c++/43024] [4.4 Regression] ICE on template code with -O2 or -O3, regression from 4.4.2

2010-02-14 Thread reichelt at gcc dot gnu dot org


--- Comment #9 from reichelt at gcc dot gnu dot org  2010-02-14 21:52 
---
Created an attachment (id=19865)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19865&action=view)
Further reduced testcase


-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

  Attachment #19836|0   |1
is obsolete||
  Attachment #19854|0   |1
is obsolete||
  Attachment #19855|0   |1
is obsolete||


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



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

2010-02-14 Thread developer at sandoe-acoustics dot co dot uk


--- Comment #15 from developer at sandoe-acoustics dot co dot uk  
2010-02-14 21:53 ---
(In reply to comment #14)
> That doesn't make sense.  The symbol is not TREE_READONLY.
> 
> Was that dump from inside get_symbol_constant_value?

yes.
that was from a clean bootstrap of trunk 156760.

> As the extract only happens from CCP2 I suppose that ipa-reference might
> be setting TREE_READONLY on the decl becaue it's static and not written to?
> So, can you try with -fno-ipa-reference?  (-fdump-ipa-reference should
> show "read-only var OBJC_CLASS_REFERENCES_0" if that is the problem)

-fdump-ipa-reference - is unrecognized on my build - do I need a config. option
to enable?
-fdump-ipa-all doesn't seem to give a file named as reference...


-- 


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



[Bug c++/43024] [4.4 Regression] ICE on template code with -O2 or -O3, regression from 4.4.2

2010-02-14 Thread reichelt at gcc dot gnu dot org


--- Comment #10 from reichelt at gcc dot gnu dot org  2010-02-14 21:54 
---
The reduced testcase from comment #9 crashes with -O2 on i686-pc-linux-gnu
since GCC 4.4.0, so the problem is not a regression from 4.4.2, but from 4.3.x.


-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||reichelt at gcc dot gnu dot
   ||org
  Known to fail|4.4.3 4.4.4 |4.4.0 4.4.3 4.4.4
  Known to work|4.4.2 4.5.0 |4.5.0


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



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

2010-02-14 Thread developer at sandoe-acoustics dot co dot uk


--- Comment #16 from developer at sandoe-acoustics dot co dot uk  
2010-02-14 21:55 ---
Created an attachment (id=19866)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19866&action=view)
gimple for cascading-1.m @ trunk 156760


-- 


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



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

2010-02-14 Thread rguenth at gcc dot gnu dot org


--- Comment #17 from rguenth at gcc dot gnu dot org  2010-02-14 21:56 
---
(In reply to comment #15)
> (In reply to comment #14)
> > That doesn't make sense.  The symbol is not TREE_READONLY.
> > 
> > Was that dump from inside get_symbol_constant_value?
> 
> yes.
> that was from a clean bootstrap of trunk 156760.
> 
> > As the extract only happens from CCP2 I suppose that ipa-reference might
> > be setting TREE_READONLY on the decl becaue it's static and not written to?
> > So, can you try with -fno-ipa-reference?  (-fdump-ipa-reference should
> > show "read-only var OBJC_CLASS_REFERENCES_0" if that is the problem)
> 
> -fdump-ipa-reference - is unrecognized on my build - do I need a config. 
> option
> to enable?
> -fdump-ipa-all doesn't seem to give a file named as reference...

Ah, sorry.  The dump file is called static-var.


-- 


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



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

2010-02-14 Thread manu at gcc dot gnu dot org


--- Comment #19 from manu at gcc dot gnu dot org  2010-02-14 22:06 ---
(In reply to comment #18)
> 
> Expected output (like 'gcc -Wall -c a.c' provides):

Since those warnings are already part of Wconversion, what you are asking is to
move them to default or another option enabled by -Wall. Contrary to what I
said above, I don't see any problem if this construct does not have any valid
use. Such option, e.g., -Wconversion-nul could be enabled by -Wall (or by
default) and -Wconversion, independently.

If you get a C++ maintainer to say that they would approve such patch, I will
write it, test it and commit it for you.


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||mark at gcc dot gnu dot org


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



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

2010-02-14 Thread developer at sandoe-acoustics dot co dot uk


--- Comment #18 from developer at sandoe-acoustics dot co dot uk  
2010-02-14 22:11 ---
Created an attachment (id=19867)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19867&action=view)
-fdump-ipa-all/static-var cascading-1.m @ trunk 156760

this is with normal options (i.e. the default for ipa-reference)


-- 


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



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

2010-02-14 Thread developer at sandoe-acoustics dot co dot uk


--- Comment #19 from developer at sandoe-acoustics dot co dot uk  
2010-02-14 22:16 ---
Created an attachment (id=19868)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19868&action=view)
cascading-1.m/-fdump-ipa-all/pure-const @ trunk 15670

this is with -fno-ipa-reference.


-- 


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



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

2010-02-14 Thread rguenth at gcc dot gnu dot org


--- Comment #20 from rguenth at gcc dot gnu dot org  2010-02-14 22:25 
---
Not TREE_ADDRESSABLE var _OBJC_CLASS_REFERENCES_0
Not TREE_ADDRESSABLE var _OBJC_SELECTOR_REFERENCES_0
Not TREE_ADDRESSABLE var _OBJC_SELECTOR_REFERENCES_1
read-only var _OBJC_CLASS_REFERENCES_0
read-only var _OBJC_SELECTOR_REFERENCES_0
read-only var _OBJC_SELECTOR_REFERENCES_1

So it's indeed ipa-reference that promotes the static vars and CCP that
propagates the initializer.  I see nothing wrong here, so the ObjC frontend
must do something behind the middle-ends back.

If you look at the final assembler code, is there anything modifying
the contents of those three variables?


-- 


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



[Bug tree-optimization/43066] New: ICE: SIGFPE with empty struct and va_arg

2010-02-14 Thread zsojka at seznam dot cz
Command line:
gcc -O1 -c testcase.c

Tested revisions:
trunk r156745 - crash
trunk r156293 - crash
trunk r155966 - OK
trunk r155609 - OK
trunk r155363 - OK
4.4 r156256 - OK

Output:
$ /mnt/svn/gcc-trunk/binary-156745-lto/bin/gcc -O1 -c testcase.c
testcase.c: In function 'foo':
testcase.c:14:1: internal compiler error: Floating point exception
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


-- 
   Summary: ICE: SIGFPE with empty struct and va_arg
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: zsojka at seznam dot cz


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



[Bug tree-optimization/43066] ICE: SIGFPE with empty struct and va_arg

2010-02-14 Thread zsojka at seznam dot cz


--- Comment #1 from zsojka at seznam dot cz  2010-02-14 22:59 ---
Created an attachment (id=19869)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19869&action=view)
reduced testcase

Command line:
gcc -O1 -c pr43066.c


-- 


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



[Bug libstdc++/15047] libstdc++ testing does not work remotely

2010-02-14 Thread paolo dot carlini at oracle dot com


--- Comment #14 from paolo dot carlini at oracle dot com  2010-02-14 23:15 
---
Thanks Joseph. Could you possibly reach Daniel and ask him to provide a bit of
feedback here? Thanks in advance.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 CC||joseph at codesourcery dot
   ||com


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



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

2010-02-14 Thread developer at sandoe-acoustics dot co dot uk


--- Comment #21 from developer at sandoe-acoustics dot co dot uk  
2010-02-14 23:22 ---
Created an attachment (id=19870)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19870&action=view)
asm out from -O1 -g cascading-1.m @trunk 156760

this is the current asm output - it segfaults on the objc msg call.


-- 


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



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

2010-02-14 Thread rguenth at gcc dot gnu dot org


--- Comment #22 from rguenth at gcc dot gnu dot org  2010-02-14 23:26 
---
There are no modifications visible in the assembly.  But there is magic:

.objc_cls_refs
.align 2
L_OBJC_CLASS_REFERENCES_0:
.long   L_OBJC_CLASS_NAME_0

what is .objc_cls_refs?

Well, obviously some Objective-C maintainer needs to chime in and explain
things.


-- 


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



[Bug rtl-optimization/43067] New: ICE: SIGSEGV with -fschedule-insns -mxop

2010-02-14 Thread zsojka at seznam dot cz
Command line:
gcc -O1 -ftree-vectorize -fschedule-insns -mxop -c testcase.c

Tested revisions:
r156745 - crash
r156693 - crash
r156293 - crash
r154830 - crash
r153685 - doesn't know -mxop

Output:
$ /mnt/svn/gcc-trunk/binary-156745-lto/bin/gcc -O1 -ftree-vectorize
-fschedule-insns -mxop -c testcase.c
testcase.c: In function 'imul32_to_64':
testcase.c:12:1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Valgrind:
==16930== Invalid read of size 2
==16930==at 0x73F912: memory_operand (recog.c:1300)
==16930==by 0x9D953E: get_attr_memory (i386.md:18975)
==16930==by 0x9897E7: ix86_adjust_cost (i386.c:19781)
==16930==by 0xC0A20D: dep_cost_1 (haifa-sched.c:909)
==16930==by 0xC0A599: priority (haifa-sched.c:1066)
==16930==by 0xC0CFB8: set_priorities (haifa-sched.c:3311)
==16930==by 0x77B269: compute_priorities (sched-rgn.c:2914)
==16930==by 0x77CCB5: schedule_insns (sched-rgn.c:2943)
==16930==by 0x77D26D: rest_of_handle_sched (sched-rgn.c:3512)
==16930==by 0x7233EA: execute_one_pass (passes.c:1561)
==16930==by 0x723674: execute_pass_list (passes.c:1616)
==16930==by 0x723686: execute_pass_list (passes.c:1617)
==16930==  Address 0xabababababababab is not stack'd, malloc'd or (recently)
free'd


-- 
   Summary: ICE: SIGSEGV with -fschedule-insns -mxop
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: zsojka at seznam dot cz
  GCC host triplet: x86_64-pc-linux-gnu
GCC target triplet: x86_64-pc-linux-gnu


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



[Bug rtl-optimization/43067] ICE: SIGSEGV with -fschedule-insns -mxop

2010-02-14 Thread zsojka at seznam dot cz


--- Comment #1 from zsojka at seznam dot cz  2010-02-14 23:29 ---
Created an attachment (id=19871)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19871&action=view)
reduced testcase, from gcc.target/i386/xop-imul32widen-vector.c

Command line:
gcc -O1 -ftree-vectorize -fschedule-insns -mxop -c pr43067.c


-- 


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



[Bug tree-optimization/41490] tree-ssa-sink does not really work

2010-02-14 Thread rguenth at gcc dot gnu dot org


--- Comment #2 from rguenth at gcc dot gnu dot org  2010-02-14 23:32 ---
Created an attachment (id=19872)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19872&action=view)
WIP patch

I think it miscompiles sth in libstdc++


-- 


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



[Bug testsuite/42854] [4.4/4.5 Regression] FAIL: gcc.dg/darwin-weakimport-[13].c scan-assembler-not *

2010-02-14 Thread howarth at nitro dot med dot uc dot edu


--- Comment #12 from howarth at nitro dot med dot uc dot edu  2010-02-14 
23:34 ---
Posted revised patch at http://gcc.gnu.org/ml/gcc-patches/2010-02/msg00549.html
with regression test results at
http://gcc.gnu.org/ml/gcc-testresults/2010-02/msg01339.html.


-- 


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



[Bug tree-optimization/43068] New: [4.5 Regression] ICE: in estimate_operator_cost, at tree-inline.c:3141 with -freorder-blocks -ftracer

2010-02-14 Thread zsojka at seznam dot cz
Command line:
g++ -O1 -freorder-blocks -ftracer -c testcase.cpp

Tested revisions:
r156745 - crash
r155363 - crash
r154830 - crash
r153685 - OK
4.4 r156256 - OK

Output:
$ /mnt/svn/gcc-trunk/binary-156745-lto/bin/g++ -O1 -freorder-blocks -ftracer -c
testcase.cpp
testcase.cpp: In member function ‘B* B::_ZTch0_v0_n32_N1B1fEv()’:
testcase.cpp:5:16: internal compiler error: in estimate_operator_cost, at
tree-inline.c:3141
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Valgrind:
no errors reported


-- 
   Summary: [4.5 Regression] ICE: in estimate_operator_cost, at
tree-inline.c:3141 with -freorder-blocks -ftracer
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: zsojka at seznam dot cz
  GCC host triplet: x86_64-pc-linux-gnu
GCC target triplet: x86_64-pc-linux-gnu


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



[Bug tree-optimization/43068] [4.5 Regression] ICE: in estimate_operator_cost, at tree-inline.c:3141 with -freorder-blocks -ftracer

2010-02-14 Thread zsojka at seznam dot cz


--- Comment #1 from zsojka at seznam dot cz  2010-02-14 23:57 ---
Created an attachment (id=19873)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19873&action=view)
reduced testcase, from g++.dg/abi/covariant2.C

Command line:
g++ -O1 -freorder-blocks -ftracer -c pr43068.cpp


-- 


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



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

2010-02-14 Thread developer at sandoe-acoustics dot co dot uk


--- Comment #23 from developer at sandoe-acoustics dot co dot uk  
2010-02-14 23:57 ---
(In reply to comment #22)
> There are no modifications visible in the assembly.  But there is magic:
> 
> .objc_cls_refs
> .align 2
> L_OBJC_CLASS_REFERENCES_0:
> .long   L_OBJC_CLASS_NAME_0
> 
> what is .objc_cls_refs?

DEF_SECTION (objc_cls_refs_section, SECTION_MERGE, ".objc_cls_refs", 1)

If I've got this correct - this is implementing the constraint that class names
are global in the NeXT runtime [at least at release 0/1].  I assume that the
section merge arranges that all references to class FOO point to the same and
unique class definition. 

> > Well, obviously some Objective-C maintainer needs to chime in and explain
> things.

indeed.


-- 


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



[Bug c++/43069] New: ICE: tree check: expected tree that contains ‘decl minimal’ structure, have ‘overload’ in set_decl_namespace, at cp/name-lookup.c:3105

2010-02-14 Thread zsojka at seznam dot cz
Command line:
g++ testcase.cpp

-- testcase.cpp --
namespace std {
  template < typename >
  void swap ();
}
template std::swap
--

Tested revisions:
r156745 - crash
r153685 - crash
4.4 r156256 - OK

Output - 4.4:
$ /mnt/svn/gcc-4_4/binary-156256-enable-checking/bin/g++ testcase.cpp
testcase.cpp:5: error: ISO C++ forbids declaration of ‘swap’ with
no type
testcase.cpp:5: error: explicit instantiation of non-template ‘int
std::swap’
testcase.cpp:5: error: expected ‘;’ at end of input

Output - trunk:
$ /mnt/svn/gcc-trunk/binary-156745-lto/bin/g++ testcase.cpp
testcase.cpp:5:15: error: ISO C++ forbids declaration of ‘swap’
with no type
testcase.cpp:5:15: internal compiler error: tree check: expected tree that
contains ‘decl minimal’ structure, have ‘overload’ in
set_decl_namespace, at cp/name-lookup.c:3105
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


-- 
   Summary: ICE: tree check: expected tree that contains ‘decl
minimal’ structure, have ‘overload’ in
set_decl_namespace, at cp/name-lookup.c:3105
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: zsojka at seznam dot cz


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



[Bug tree-optimization/43070] New: [4.5 Regression] g++.dg/ext/label2.C fails to compile at -O1

2010-02-14 Thread zsojka at seznam dot cz
Command line:
g++ -O1 label2.C

Tested revisions:
r156745 - crash
r155966 - crash
r153685 - crash
4.4 r156256 - OK

Output with checking:
$ /mnt/svn/gcc-trunk/binary-156745-lto/bin/g++ -O1
/mnt/svn/gcc-trunk/gcc/testsuite/g++.dg/ext/label2.C
/mnt/svn/gcc-trunk/gcc/testsuite/g++.dg/ext/label2.C: In function ‘void
f() [with T = int]’:
/mnt/svn/gcc-trunk/gcc/testsuite/g++.dg/ext/label2.C:11:23: error: address
taken, but ADDRESSABLE bit not set
p
cc1plus: note: in statement
goto &p;

/mnt/svn/gcc-trunk/gcc/testsuite/g++.dg/ext/label2.C:11:23: internal compiler
error: verify_stmts failed
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Output with release checking:
$ /mnt/svn/gcc-trunk/binary-155966-lto-checking-release/bin/g++ -O1
/mnt/svn/gcc-trunk/gcc/testsuite/g++.dg/ext/label2.C
/mnt/svn/gcc-trunk/gcc/testsuite/g++.dg/ext/label2.C: In function ‘void
f() [with T = int]’:
/mnt/svn/gcc-trunk/gcc/testsuite/g++.dg/ext/label2.C:4:6: internal compiler
error: in expand_expr_addr_expr_1, at expr.c:6895
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


-- 
   Summary: [4.5 Regression] g++.dg/ext/label2.C fails to compile at
-O1
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: zsojka at seznam dot cz
  GCC host triplet: x86_64-pc-linux-gnu
GCC target triplet: x86_64-pc-linux-gnu


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



[Bug tree-optimization/43070] [4.5 Regression] g++.dg/ext/label2.C fails to compile at -O1

2010-02-14 Thread zsojka at seznam dot cz


--- Comment #1 from zsojka at seznam dot cz  2010-02-15 01:14 ---
Created an attachment (id=19874)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19874&action=view)
reduced testcase

Command line:
gcc -O1 pr43070.cpp


-- 


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



[Bug fortran/43062] NAMELIST attribute conflicts with ALLOCATABLE attribute

2010-02-14 Thread kargl at gcc dot gnu dot org


--- Comment #3 from kargl at gcc dot gnu dot org  2010-02-15 01:29 ---
I've posted a question to c.l.f about this code.  I 
believe the language of the standard is contradictory
and as such the code can be interpreted as illegal or
legal.

http://groups.google.com/group/comp.lang.fortran/browse_frm/thread/76b23c9927b52161#


-- 


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



[Bug libstdc++/12854] libstdc++ vs. -Weffc++

2010-02-14 Thread paolo dot carlini at oracle dot com


--- Comment #11 from paolo dot carlini at oracle dot com  2010-02-15 01:45 
---
I think this can be closed: now the system header pragma is pretty solid and I
don't think warnings can be triggered from library headers, by any -W option.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 Status|SUSPENDED   |RESOLVED
 Resolution||WORKSFORME


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



[Bug lto/43071] New: ICE: SIGSEGV with -fwhopr -fcompare-debug

2010-02-14 Thread zsojka at seznam dot cz
Command line:
g++ -fwhopr -fcompare-debug testcase.cpp

Tested revisions:
r156745 - crash
r154886 - crash

Output:
$ /mnt/svn/gcc-trunk/binary-156745-lto/bin/g++ -fwhopr -fcompare-debug
testcase.cpp
In file included from :1:0:
testcase.cpp: In function 'main':
testcase.cpp:5:5: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
g++: during -fcompare-debug recompilation
g++: /tmp/cchnAJao.wpa.o: -fcompare-debug failure (length)
lto1: fatal error: /mnt/svn/gcc-trunk/binary-156745-lto/bin/g++ terminated with
status 256
compilation terminated.
lto-wrapper: /mnt/svn/gcc-trunk/binary-156745-lto/bin/g++ returned 1 exit
status
collect2: lto-wrapper returned 1 exit status

Valgrind:
several times, probably not related:
==23604== Conditional jump or move depends on uninitialised value(s)
==23604==at 0xDEA6E5: longest_match (deflate.c:1143)
==23604==by 0xDEACAA: deflate_slow (deflate.c:1595)
==23604==by 0xDEBC54: deflate (deflate.c:790)
==23604==by 0xD6759C: lto_end_compression (lto-compress.c:196)
==23604==by 0xD64644: lto_end_section (lto-section-out.c:192)
==23604==by 0xD64B3D: lto_destroy_simple_output_block
(lto-section-out.c:556)
==23604==by 0xD63323: lto_output (lto-streamer-out.c:2112)
==23604==by 0x84F3A0: ipa_write_summaries_2 (passes.c:1645)
==23604==by 0x84F49E: ipa_write_summaries_1 (passes.c:1671)
==23604==by 0x851EDA: ipa_write_summaries (passes.c:1720)
==23604==by 0xACBF25: cgraph_optimize (cgraphunit.c:1790)
==23604==by 0xACC194: cgraph_finalize_compilation_unit (cgraphunit.c:1093)

crash is at:
==24096== Invalid read of size 2
==24096==at 0x54E732: gen_type_die_with_usage (dwarf2out.c:7687)
==24096==by 0x552708: gen_decl_die (dwarf2out.c:19553)
==24096==by 0x54AACF: decls_for_scope (dwarf2out.c:19188)
==24096==by 0x557B68: gen_block_die (dwarf2out.c:18436)
==24096==by 0x54AB3D: decls_for_scope (dwarf2out.c:19202)
==24096==by 0x54AF8B: gen_subprogram_die (dwarf2out.c:18045)
==24096==by 0x5527CC: gen_decl_die (dwarf2out.c:19507)
==24096==by 0x599CEC: rest_of_handle_final (final.c:4287)
==24096==by 0x6B395A: execute_one_pass (passes.c:1561)
==24096==by 0x6B3BE4: execute_pass_list (passes.c:1616)
==24096==by 0x6B3BF6: execute_pass_list (passes.c:1617)
==24096==by 0x6B3BF6: execute_pass_list (passes.c:1617)
==24096==  Address 0x0 is not stack'd, malloc'd or (recently) free'd


-- 
   Summary: ICE: SIGSEGV with -fwhopr -fcompare-debug
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: zsojka at seznam dot cz


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



[Bug lto/43071] ICE: SIGSEGV with -fwhopr -fcompare-debug

2010-02-14 Thread zsojka at seznam dot cz


--- Comment #1 from zsojka at seznam dot cz  2010-02-15 02:48 ---
Created an attachment (id=19875)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19875&action=view)
full valgrind log


-- 


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



[Bug c++/43024] [4.4 Regression] ICE on template code with -O2 or -O3, regression from 4.4.2

2010-02-14 Thread jason at gcc dot gnu dot org


--- Comment #11 from jason at gcc dot gnu dot org  2010-02-15 04:01 ---
Subject: Bug 43024

Author: jason
Date: Mon Feb 15 04:01:10 2010
New Revision: 156766

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156766
Log:
PR c++/43024
* g++.dg/opt/ice1.C: New.

Added:
trunk/gcc/testsuite/g++.dg/opt/ice1.C
Modified:
trunk/gcc/testsuite/ChangeLog


-- 


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



[Bug c++/43024] [4.4 Regression] ICE on template code with -O2 or -O3, regression from 4.4.2

2010-02-14 Thread jason at gcc dot gnu dot org


--- Comment #12 from jason at gcc dot gnu dot org  2010-02-15 04:02 ---
Testcase added to testsuite, thanks a lot.


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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



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

2010-02-14 Thread jason at gcc dot gnu dot org


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jason at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2010-02-11 13:51:19 |2010-02-15 04:04:07
   date||


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



[Bug target/40667] [4.4/4.5 Regression] stack frames are generated even with -fomit-frame-pointer

2010-02-14 Thread pinskia at gcc dot gnu dot org


--- Comment #25 from pinskia at gcc dot gnu dot org  2010-02-15 04:22 
---
>stack frame is generated for no apparent reason.

It is generated because of noreturn which is done as a regular call instead of
a sibcall.  So this is expected.  Closing as fixed as it was previously. 
Please open a new bug next time for a new testcase.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED


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



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

2010-02-14 Thread jv244 at cam dot ac dot uk


--- Comment #9 from jv244 at cam dot ac dot uk  2010-02-15 07:35 ---
(In reply to comment #7)
> As soon as somebody gives me the green light, I'll apply the patch.
> The present version is attached.

the latest version works now without ICE. pack/unpack are down to about 1000
(down from 4400). I will add another PR with another (but independent) missed
case. Thanks a lot for fixing these.


-- 


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



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

2010-02-14 Thread jv244 at cam dot ac dot uk
Another case that doesn't need a temp:

MODULE M1
  PRIVATE
  REAL, PARAMETER :: c(2)=(/(i,i=1,2)/)
CONTAINS
  ! OK
  SUBROUTINE S0
real :: r
 r=0
 r=S2(c)
  END SUBROUTINE S0
  ! NOT OK
  SUBROUTINE S1
real :: r
 r=0
 r=r+S2(c)
  END SUBROUTINE S1

  FUNCTION S2(c)
 REAL, INTENT(IN) :: c(2)
 s2=0
  END FUNCTION S2
END MODULE M1

In S1, somehow it seems that 'c' is being packed if S2 is part of an expression


-- 
   Summary: unneeded temporary (s=s+f(a))
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jv244 at cam dot ac dot uk


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



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

2010-02-14 Thread pault at gcc dot gnu dot org


--- Comment #1 from pault at gcc dot gnu dot org  2010-02-15 07:51 ---
Yes, indeed.

In fact, S2((/(real (i),i=1,2)/)) produces calls to pack and unpack in both S0
and S1.

I'll take a look at it.

Thanks

Paul


-- 

pault at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-02-15 07:51:01
   date||


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



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

2010-02-14 Thread jv244 at cam dot ac dot uk


--- Comment #2 from jv244 at cam dot ac dot uk  2010-02-15 07:58 ---
(In reply to comment #1)
> Yes, indeed.
> 
> In fact, S2((/(real (i),i=1,2)/)) produces calls to pack and unpack in both S0
> and S1.
> 
> I'll take a look at it.

You did beat me again, I wanted to file the following testcase, which I believe
is actually independent, but is similar to what you mentioned above:

MODULE M1
CONTAINS
  ! OK
  SUBROUTINE S0
 REAL, PARAMETER :: c(2)=(/1.0,2.0/)
 CALL S2(c)
  END SUBROUTINE S0

  ! NOT OK
  SUBROUTINE S1
 CALL S2((/1.0,2.0/))
  END SUBROUTINE S1

  SUBROUTINE S2(c)
 REAL, INTENT(IN) :: c(2)
  END SUBROUTINE S2

END MODULE M1

this 'S1' style appears also to be a rather common source of packs in CP2K


-- 


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