[Bug c++/39866] [c++0x] deleted functions not removed from "no match" error messages

[jason at gcc dot gnu dot org]

--- Comment #3 from jason at gcc dot gnu dot org  2009-10-14 06:28 ---
Subject: Bug 39866

Author: jason
Date: Wed Oct 14 06:27:50 2009
New Revision: 152752

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152752
Log:
PR c++/39866
* call.c (print_z_candidates): Don't print deleted candidates.
(print_z_candidate): Note deleted candidates.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/defaulted14.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c
trunk/gcc/testsuite/ChangeLog
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/testsuite/20_util/unique_ptr/assign/assign_neg.cc


-- 


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

[Bug c++/40092] [c++0x] expansion pattern fails with error about derived template instead of actual template

[jason at gcc dot gnu dot org]

--- Comment #16 from jason at gcc dot gnu dot org  2009-10-14 06:27 ---
Subject: Bug 40092

Author: jason
Date: Wed Oct 14 06:27:41 2009
New Revision: 152751

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152751
Log:
PR c++/40092
* tree.c (cp_tree_equal): Add test for TEMPLATE_PARM_PARAMETER_PACK
equality.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/vt-40092.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/tree.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug middle-end/30447] Evaluate complex math functions at compile-time

[ghazi at gcc dot gnu dot org]

--- Comment #11 from ghazi at gcc dot gnu dot org  2009-10-14 06:15 ---
(In reply to comment #10)
> > except for cproj because that has a wierd non-c99 implementation in glibc.
>
> I don't see why one particular library having a bug in its implementation 
> of cproj should prevent GCC from optimizing that function correctly for 
> constant arguments.

Had it been any other system, I would agree.  But that "one particular library"
is the C lib for the GNU system and I was reluctant to make the GNU compiler
incompatible with the GNU C library.

There is a bug report filed for cproj from July, but nothing appears to have
been done about it.
http://sourceware.org/bugzilla/show_bug.cgi?id=10401

If there is consensus that we don't care what glibc does, I can implement the
cproj opt.  However you may recall I have most of these MPFR/MPC
transformations back out if Inf is passed in.  The main rationale for cproj is
to handle Inf specially.  So it would require hacking the infrastructure to
allow Inf to pass through.  I did this for two-argument calls like mpc_div, but
not one-argument calls like mpc_proj.  Since it's stage3 I'd defer that till
later.

Another (perhaps interim) option would be to do the opt only for finite
numbers.  That would be a one-liner and perhaps suitable for stage3.


-- 


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

[Bug middle-end/41264] [4.5 Regression] variable-tracking unbelievably slow

[matz at gcc dot gnu dot org]

--- Comment #12 from matz at gcc dot gnu dot org  2009-10-14 06:14 ---
Yeah, I'm sorry, I attached the testcase to the wrong bug report as said in
comment #5.  It was about combinatoric explosion not about slow var-tracking.
I should probably have deleted the attachment from here.


-- 


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

[Bug c++/41703] New: Problems with SFINAE. Source works at gcc 3.4.6 but fails at 4.2.1 and 4.5.0.20091008

[DimanNe at ya dot ru]

Hello! I have FreeBSD 8.0-BETA4.
Why this

#include 
template 
class TSizeEnabler { public: typedef T TClass; };

template  unsigned int GetAllSize(const X &Var)
   { return sizeof(Var); }
template  unsigned int GetAllSize(const typename TSizeEnabler::TClass &Var)
   { return Var.CalcMySize(); }

template 
class THash
   {
  public:
  T Var;
  unsigned int CalcMySize() const { return 42 + GetAllSize(Var); }
   };
int main()
   {
  int a;
  THash b;
  std::cout << GetAllSize(a) << std::endl;
  std::cout << GetAllSize< THash >(b) << std::endl;
  return 0;
   }


works well at gcc 3.4.6 but fails at gcc 4.2.1 and gcc 4.5.0.20091008 with
these messages:
gcc 4.5.0.2009100 output:
%g++45 -std=c++0x main.cpp
main.cpp: In function 'int main()':
main.cpp:24:46: error: call of overloaded 'GetAllSize(THash&)' is
ambiguous
main.cpp:6:36: note: candidates are: unsigned int GetAllSize(const X&) [with X
= THash]
main.cpp:8:36: note: unsigned int GetAllSize(const typename TSizeEnabler::TClass&) [with X = THash, typename TSizeEnabler::TClass = THash]
%
And gcc 4.2.1 output:
%g++ main.cpp
main.cpp: In function 'int main()':
main.cpp:23: error: call of overloaded 'GetAllSize(THash&)' is ambiguous
main.cpp:5: note: candidates are: unsigned int GetAllSize(const X&) [with X =
THash]
main.cpp:7: note: unsigned int GetAllSize(const typename
TSizeEnabler::TClass&) [with X = THash]
%


And how i can fix it the problem?
Thanks.


-- 
   Summary: Problems with SFINAE. Source works at gcc 3.4.6 but
fails at 4.2.1 and 4.5.0.20091008
   Product: gcc
   Version: 4.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: DimanNe at ya dot ru


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

[Bug other/41338] High memory consumption when compiling with -O3 -g

[aoliva at gcc dot gnu dot org]

--- Comment #6 from aoliva at gcc dot gnu dot org  2009-10-14 05:01 ---
Subject: Bug 41338

Author: aoliva
Date: Wed Oct 14 05:01:24 2009
New Revision: 152749

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152749
Log:
PR debug/41343
PR debug/41447
PR debug/41264
PR debug/41338
* tree.c (tree_node_structure_for_code): DEBUG_EXPR_DECL uses
decl with rtl.
(tree_code_size): Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree.c


-- 


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

[Bug middle-end/41264] [4.5 Regression] variable-tracking unbelievably slow

[aoliva at gcc dot gnu dot org]

--- Comment #11 from aoliva at gcc dot gnu dot org  2009-10-14 05:01 ---
Subject: Bug 41264

Author: aoliva
Date: Wed Oct 14 05:01:24 2009
New Revision: 152749

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152749
Log:
PR debug/41343
PR debug/41447
PR debug/41264
PR debug/41338
* tree.c (tree_node_structure_for_code): DEBUG_EXPR_DECL uses
decl with rtl.
(tree_code_size): Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree.c


-- 


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

[Bug debug/41343] [4.5 Regression] sysdeps/ieee754/dbl-64/dosincos.c from glibc causes excessive memory use

[aoliva at gcc dot gnu dot org]

--- Comment #21 from aoliva at gcc dot gnu dot org  2009-10-14 05:01 ---
Subject: Bug 41343

Author: aoliva
Date: Wed Oct 14 05:01:24 2009
New Revision: 152749

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152749
Log:
PR debug/41343
PR debug/41447
PR debug/41264
PR debug/41338
* tree.c (tree_node_structure_for_code): DEBUG_EXPR_DECL uses
decl with rtl.
(tree_code_size): Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree.c


-- 


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

[Bug debug/41447] Wrong debug with VTA on temporaries initialized from memory variable

[aoliva at gcc dot gnu dot org]

--- Comment #5 from aoliva at gcc dot gnu dot org  2009-10-14 05:01 ---
Subject: Bug 41447

Author: aoliva
Date: Wed Oct 14 05:01:24 2009
New Revision: 152749

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152749
Log:
PR debug/41343
PR debug/41447
PR debug/41264
PR debug/41338
* tree.c (tree_node_structure_for_code): DEBUG_EXPR_DECL uses
decl with rtl.
(tree_code_size): Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree.c


-- 


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

[Bug tree-optimization/41661] [4.5 Regression] ICE due to IPCP trying to create/fold a REAL typed comparision

[pinskia at gcc dot gnu dot org]

--- Comment #6 from pinskia at gcc dot gnu dot org  2009-10-14 04:57 ---
*** Bug 41147 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||dominiq at lps dot ens dot
   ||fr


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

[Bug middle-end/41147] FAIL: gcc.dg/vmx/bug-2.c -O3 -g ICE in build_int_cst_wide, at tree.c:1140

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2009-10-14 04:57 ---
I should have looked for a bug report before filing a new bug report.  Anyways
this has been since fixed.

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


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug c++/41091] Using section attribute in c and c++ function causes section type conflict

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2009-10-14 04:50 ---
Actually, they have to have two different section types.

c::m()::TWO has to be in the comdat section for C::m().
While c()::ONE does not and can be in a normal section.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug c++/40948] ICE in lower_stmt, at gimple-low.c:408

[pinskia at gcc dot gnu dot org]

--- Comment #13 from pinskia at gcc dot gnu dot org  2009-10-14 04:47 
---
Fixed.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug testsuite/40625] [4.5 Regression] Errors in "make -k check-gcc RUNTESTFLAGS=plugin.exp"

[pinskia at gcc dot gnu dot org]

--- Comment #6 from pinskia at gcc dot gnu dot org  2009-10-14 04:46 ---
This works for me, does it work for you now?


-- 


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

[Bug bootstrap/40833] gcc configure problem with mpfr.h

[david dot sagan at gmail dot com]

--- Comment #6 from david dot sagan at gmail dot com  2009-10-14 04:40 
---
(In reply to comment #5)
> >  checking for correct version of mpfr.h... no
> 
> That is correct error since mpfr cannot be used as you configured gcc so it is
> not the correct version :).
> 

No. This is not correct. See comment #3. It has nothing to do with the version
of MPFR. The problem was that MPFR was built against a different version of GMP
than the GMP version specified on the configure line. 

So the error message is wrong.


-- 


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

[Bug c/40885] build_indirect_ref i18n problems

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2009-10-14 04:36 ---
Confirmed.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-10-14 04:36:30
   date||


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

[Bug bootstrap/40833] gcc configure problem with mpfr.h

[pinskia at gcc dot gnu dot org]

--- Comment #5 from pinskia at gcc dot gnu dot org  2009-10-14 04:14 ---
>  checking for correct version of mpfr.h... no

That is correct error since mpfr cannot be used as you configured gcc so it is
not the correct version :).


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug ada/40777] compile error on gcc-interface/targtyps.c

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2009-10-14 04:11 ---
Confirmed.
  /* This macro is only defined by the i386 port.  */

That is not true.  It is also defined by the sh port.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||build
   Last reconfirmed|-00-00 00:00:00 |2009-10-14 04:11:10
   date||


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

[Bug c++/15946] Unhelpful error message when "typename" is omitted

[pinskia at gcc dot gnu dot org]

--- Comment #4 from pinskia at gcc dot gnu dot org  2009-10-14 04:08 ---
*** Bug 40738 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||bkoz at gcc dot gnu dot org


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

[Bug c++/40738] missing typename error improvement

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2009-10-14 04:08 ---


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


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug bootstrap/40729] Build fails in libstdc++-v3

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2009-10-14 04:06 ---
This works for me on the trunk.  Can you try again?


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING


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

[Bug target/40720] Optimizer Bug: bad register name

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2009-10-14 04:05 ---
>I'm unsure how to proceed, as temp files
will be very large

Zip them up.

But please attach the preprocessed source that is able to reproduce this bug.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING


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

[Bug target/33505] spu target builtins and vectorizer don't get along

[pinskia at gcc dot gnu dot org]

--- Comment #5 from pinskia at gcc dot gnu dot org  2009-10-14 04:03 ---
Fixed by:
2009-04-23  Ulrich Weigand  

* config/spu/spu-builtins.h: Delete file.



-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.5.0


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

[Bug target/33505] spu target builtins and vectorizer don't get along

[pinskia at gcc dot gnu dot org]

--- Comment #4 from pinskia at gcc dot gnu dot org  2009-10-14 04:02 ---
*** Bug 40715 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||ryan dot sammartino at gmail
   ||dot com


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

[Bug pch/40715] SPU compiler does not work properly with precompiled headers

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2009-10-14 04:02 ---


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


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug target/40693] atomic built-ins malfunction with 64-bit signed ptrs and negative constants

[pinskia at gcc dot gnu dot org]

--- Comment #4 from pinskia at gcc dot gnu dot org  2009-10-14 04:00 ---
Fixed in 4.2.0 so closing.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug middle-end/30447] Evaluate complex math functions at compile-time

[joseph at codesourcery dot com]

--- Comment #10 from joseph at codesourcery dot com  2009-10-14 02:27 
---
Subject: Re:  Evaluate complex math functions at
 compile-time

On Wed, 14 Oct 2009, ghazi at gcc dot gnu dot org wrote:

> Support for the "arc" functions is done in the mpc svn repository which will 
> be
> released as mpc-0.8 at the end of October.  Use of these functions has been
> checked into mainline.  All C99 builtin complex math functions are done; well,
> except for cproj because that has a wierd non-c99 implementation in glibc.

I don't see why one particular library having a bug in its implementation 
of cproj should prevent GCC from optimizing that function correctly for 
constant arguments.


-- 


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

[Bug target/41702] New: FAIL: abi/demangle/abi_text/09.cc execution test

[danglin at gcc dot gnu dot org]

Program fails due to a segmentation fault:

Program received signal SIGSEGV, Segmentation fault.
0x40004264 in __gnu_test::verify_demangle (
mangled=, 
wanted=0x40002394 "error code = -2: invalid mangled name")
at /test/gnu/gcc/gcc/libstdc++-v3/testsuite/util/testsuite_hooks.cc:139
139 switch (status)


-- 
   Summary: FAIL: abi/demangle/abi_text/09.cc execution test
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: danglin at gcc dot gnu dot org
 GCC build triplet: hppa64-hp-hpux11.11
  GCC host triplet: hppa64-hp-hpux11.11
GCC target triplet: hppa64-hp-hpux11.11


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

[Bug testsuite/41701] New: scan-assembler-not has false positives

[meissner at gcc dot gnu dot org]

The scan-assembler-not should skip strings inside of .ident directives.  I have
a branch that I use for power7 development, power7-meissner.  In that branch, I
set the REVISION file to indicate that this is a branch.  Currently it is set
to:
[ibm/power7-meissner, mainline revision 152572]

This revision string gets put in the .ident section, which causes the test
gcc.dg/builtins-58.c to fail, because it has the directive:
/* scan-assembler-not pow */

It is a minor thing, but I'm sure somebody else will trigger it eventually.


-- 
   Summary: scan-assembler-not has false positives
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: testsuite
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: meissner at gcc dot gnu dot org
 GCC build triplet: powerpc64-linux-gnu
  GCC host triplet: powerpc64-linux-gnu
GCC target triplet: powerpc64-linux-gnu


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

[Bug other/40302] [4.5 Regression] GCC must hard-require MPC before release

[ghazi at gcc dot gnu dot org]

--- Comment #6 from ghazi at gcc dot gnu dot org  2009-10-14 01:59 ---
Remember to remove the testsuite effective-target code for mpc, mpc_pow and
mpc_arc.  Also remove the dg- commands in various individual tests.


-- 

ghazi at gcc dot gnu dot org changed:

   What|Removed |Added

   Last reconfirmed|2009-09-18 04:18:50 |2009-10-14 01:59:37
   date||


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

[Bug middle-end/30447] Evaluate complex math functions at compile-time

[ghazi at gcc dot gnu dot org]

--- Comment #9 from ghazi at gcc dot gnu dot org  2009-10-14 01:57 ---
Support for the "arc" functions is done in the mpc svn repository which will be
released as mpc-0.8 at the end of October.  Use of these functions has been
checked into mainline.  All C99 builtin complex math functions are done; well,
except for cproj because that has a wierd non-c99 implementation in glibc.

TODO:
Wait for mpc-0.8 to be released.
Update gcc's configure to look for mpc-0.8.
Hard require MPC.
Do remaining stuff from PR40302.


-- 

ghazi at gcc dot gnu dot org changed:

   What|Removed |Added

   Last reconfirmed|2009-09-20 16:21:55 |2009-10-14 01:57:26
   date||


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

[Bug fortran/35952] Segmentation fault with character strings only when compiling with -funroll-loops and -O3

[jvdelisle at gcc dot gnu dot org]

--- Comment #9 from jvdelisle at gcc dot gnu dot org  2009-10-14 01:49 
---
Closing. Works on latest gfortran.  Upgrade to later version.


-- 

jvdelisle at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||WORKSFORME


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

[Bug testsuite/41700] New: g++.dg/debug/dwarf2/icf.C

[danglin at gcc dot gnu dot org]

Executing on host: /test/gnu/gcc/objdir/gcc/testsuite/g++/../../g++
-B/test/gnu/
gcc/objdir/gcc/testsuite/g++/../../
/test/gnu/gcc/gcc/gcc/testsuite/g++.dg/debug
/dwarf2/icf.C  -nostdinc++
-I/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-
v3/include/hppa64-hp-hpux11.11
-I/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstd
c++-v3/include -I/test/gnu/gcc/gcc/libstdc++-v3/libsupc++
-I/test/gnu/gcc/gcc/li
bstdc++-v3/include/backward -I/test/gnu/gcc/gcc/libstdc++-v3/testsuite/util
-fme
ssage-length=0  -O0 -gdwarf-2 -fenable-icf-debug -dA  -S  -o icf.s(timeout
=
 300)
PASS: g++.dg/debug/dwarf2/icf.C (test for excess errors)
PASS: g++.dg/debug/dwarf2/icf.C scan-assembler \\.section.*.debug_dcall
FAIL: g++.dg/debug/dwarf2/icf.C scan-assembler \\.section.*.debug_vcall
PASS: g++.dg/debug/dwarf2/icf.C scan-assembler New caller
PASS: g++.dg/debug/dwarf2/icf.C scan-assembler Caller DIE offset
PASS: g++.dg/debug/dwarf2/icf.C scan-assembler Point of call
PASS: g++.dg/debug/dwarf2/icf.C scan-assembler Callee DIE offset
FAIL: g++.dg/debug/dwarf2/icf.C scan-assembler 0x0.*Vtable slot
FAIL: g++.dg/debug/dwarf2/icf.C scan-assembler 0x1.*Vtable slot


-- 
   Summary: g++.dg/debug/dwarf2/icf.C
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: danglin at gcc dot gnu dot org
 GCC build triplet: hppa64-hp-hpux11.11
  GCC host triplet: hppa64-hp-hpux11.11
GCC target triplet: hppa64-hp-hpux11.11


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

[Bug fortran/35952] Segmentation fault with character strings only when compiling with -funroll-loops and -O3

[jvdelisle at gcc dot gnu dot org]

--- Comment #8 from jvdelisle at gcc dot gnu dot org  2009-10-14 01:09 
---
With gfortran 4.5 trunk r152402 on Cygwin 1.7 the test case executes normally.


-- 


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

[Bug lto/41668] ICE in get_alias_set, at alias.c:698

[hjl dot tools at gmail dot com]

--- Comment #8 from hjl dot tools at gmail dot com  2009-10-14 00:14 ---
For Linux/ia32, I got

Executing on host: /export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/ c_lto_20091013-1_0.o
c_lto_20091013-1_1.o c_lto_20091013-1_2.o  -fPIC -shared -O2 -flto   -lm   -m32
-o gcc-dg-lto-20091013-1-11(timeout = 300)
In file included from
/net/gnu-13/export/gnu/src/gcc/gcc/gcc/testsuite/gcc.dg/lto/20091013-1_1.c:118:0,^M
 from
/net/gnu-13/export/gnu/src/gcc/gcc/gcc/testsuite/gcc.dg/lto/20091013-1_0.c:46,^M
 from :9:^M
/net/gnu-13/export/gnu/src/gcc/gcc/gcc/testsuite/gcc.dg/lto/20091013-1_2.c: In
function 'get_glyph_index_linked':^M
/net/gnu-13/export/gnu/src/gcc/gcc/gcc/testsuite/gcc.dg/lto/20091013-1_2.c:189:12:
internal compiler error: in get_alias_set, at alias.c:698^M
Please submit a full bug report,^M
with preprocessed source if appropriate.^M
See <http://gcc.gnu.org/bugs.html> for instructions.^M


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |


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

[Bug rtl-optimization/38948] unrecognizable insn, postreload.c:395

[hp at gcc dot gnu dot org]

-- 

hp at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.3.6


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

[Bug rtl-optimization/38948] unrecognizable insn, postreload.c:395

[hp at gcc dot gnu dot org]

--- Comment #9 from hp at gcc dot gnu dot org  2009-10-14 00:04 ---
Fixed .


-- 

hp at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug rtl-optimization/38948] unrecognizable insn, postreload.c:395

[hp at gcc dot gnu dot org]

--- Comment #8 from hp at gcc dot gnu dot org  2009-10-14 00:01 ---
Subject: Bug 38948

Author: hp
Date: Wed Oct 14 00:01:37 2009
New Revision: 152741

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152741
Log:
PR target/38948
* gcc.dg/torture/pr38948.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr38948.c
Modified:
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug rtl-optimization/38948] unrecognizable insn, postreload.c:395

[hp at gcc dot gnu dot org]

--- Comment #7 from hp at gcc dot gnu dot org  2009-10-14 00:01 ---
Subject: Bug 38948

Author: hp
Date: Wed Oct 14 00:01:09 2009
New Revision: 152740

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152740
Log:
PR target/38948
* config/cris/cris.h (SECONDARY_RELOAD_CLASS): Handle reload
requests between special registers.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/cris/cris.h


-- 


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

[Bug rtl-optimization/38948] unrecognizable insn, postreload.c:395

[hp at gcc dot gnu dot org]

--- Comment #6 from hp at gcc dot gnu dot org  2009-10-13 23:54 ---
Subject: Bug 38948

Author: hp
Date: Tue Oct 13 23:53:55 2009
New Revision: 152739

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152739
Log:
PR target/38948
* gcc.dg/torture/pr38948.c: New test.

Added:
branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/torture/pr38948.c
Modified:
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug rtl-optimization/38948] unrecognizable insn, postreload.c:395

[hp at gcc dot gnu dot org]

--- Comment #5 from hp at gcc dot gnu dot org  2009-10-13 23:53 ---
Subject: Bug 38948

Author: hp
Date: Tue Oct 13 23:53:20 2009
New Revision: 152738

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152738
Log:
PR target/38948
* config/cris/cris.h (SECONDARY_RELOAD_CLASS): Handle reload
requests between special registers.

Modified:
branches/gcc-4_4-branch/gcc/ChangeLog
branches/gcc-4_4-branch/gcc/config/cris/cris.h


-- 


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

[Bug rtl-optimization/38948] unrecognizable insn, postreload.c:395

[hp at gcc dot gnu dot org]

--- Comment #4 from hp at gcc dot gnu dot org  2009-10-13 23:49 ---
Subject: Bug 38948

Author: hp
Date: Tue Oct 13 23:49:46 2009
New Revision: 152737

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152737
Log:
PR target/38948
* gcc.dg/torture/pr38948.c: New test.

Added:
branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/torture/pr38948.c
Modified:
branches/gcc-4_3-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug rtl-optimization/38948] unrecognizable insn, postreload.c:395

[hp at gcc dot gnu dot org]

--- Comment #3 from hp at gcc dot gnu dot org  2009-10-13 23:48 ---
Subject: Bug 38948

Author: hp
Date: Tue Oct 13 23:48:39 2009
New Revision: 152736

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152736
Log:
PR target/38948
* config/cris/cris.h (SECONDARY_RELOAD_CLASS): Handle reload
requests between special registers.

Modified:
branches/gcc-4_3-branch/gcc/ChangeLog
branches/gcc-4_3-branch/gcc/config/cris/cris.h


-- 


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

[Bug lto/41565] -m32 causes an ICE when the object files were compiled with 64bit

[pinskia at gcc dot gnu dot org]

--- Comment #11 from pinskia at gcc dot gnu dot org  2009-10-13 22:40 
---
Simple testcase for powerpc64.
int main(void){ return 0; }
--- CUT --
gcc  t.c -flto -c -m64 
/home/apinski/gcc-mainline/libexec/gcc/powerpc64-unknown-linux-gnu/4.5.0/lto1
t.o  -m32

--- CUT ---
I have not tried after the patch though.


-- 


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

[Bug lto/41565] -m32 causes an ICE when the object files were compiled with 64bit

[pinskia at gcc dot gnu dot org]

--- Comment #10 from pinskia at gcc dot gnu dot org  2009-10-13 22:35 
---
Oh the ICE only happens for the -m32/-m64 case only when invoking lto1
directly.


-- 


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

[Bug target/41684] [4.4/4.5 regression] binutils testsuite failures when built with 4.4/4.5

[mikpe at it dot uu dot se]

--- Comment #1 from mikpe at it dot uu dot se  2009-10-13 22:02 ---
Confirmed. I've built binutils-2.19.1 and binutils-2.19.92 with gcc-4.3.4 (plus
loads of well-tested fixes) and gcc-4.4.1 vanilla on an armv5tel-linux-gnueabi
machine, and for both binutils versions using gcc-4.4.1 caused the 7 new
testsuite failures you listed.


-- 

mikpe at it dot uu dot se changed:

   What|Removed |Added

 CC||mikpe at it dot uu dot se


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

[Bug c/41698] "\uFFFF" converts incorrectly to two-byte character

[chasonr at newsguy dot com]

--- Comment #2 from chasonr at newsguy dot com  2009-10-13 21:08 ---
Created an attachment (id=18797)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18797&action=view)
Proposed patch for this bug

This patch is against the GCC 4.4.1 distribution.  The function altered is
one_utf8_to_utf16 in libcpp/charset.c .


-- 


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

[Bug c/41698] "\uFFFF" converts incorrectly to two-byte character

[chasonr at newsguy dot com]

--- Comment #1 from chasonr at newsguy dot com  2009-10-13 21:04 ---
Created an attachment (id=18796)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18796&action=view)
Test case for this bug

This test uses the built-in __CHAR16_TYPE__, so that it will demonstrate the
bug even when wchar_t is four bytes wide, and as such will only compile on 4.4.
 For earlier compilers, change __CHAR16_TYPE__ to wchar_t and the test strings
to L"\u" and L"\U0001".  When using wchar_t, the bug only appears when
wchar_t is two bytes wide.


-- 


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

[Bug c/41698] New: "\uFFFF" converts incorrectly to two-byte character

[chasonr at newsguy dot com]

GCC 4.4.1 incorrectly parses the code point U+ when generating a two-byte
character.  It mistakes this code point for a supplemental one, and generates
an improper surrogate pair U+D7FF U+DFFF.  This bug is present as far back as
GCC 3.4.6.

Here is a test program that demonstrates the bug, and could function as a
regression test.  This program uses char16_t, but GCC 3.4.5 as shipped with
MinGW also shows this bug when wchar_t is used.

--CUT HERE--CUT HERE--CUT HERE--CUT HERE--CUT HERE--CUT HERE--CUT HERE--
/* gcc-utf16-test.c -- demonstrate a bug in GCC 4.4.1, that causes the code
   point U+ to convert incorrectly to UTF-16.
   Compile on GCC 4.4.1 with -std=gnu99. */

#include 
#include 

int
main(void)
{
static const __CHAR16_TYPE__ teststr1[] = u"\u";
static const __CHAR16_TYPE__ teststr2[] = u"\U0001";
size_t i;

printf("The string \"\\u\" converts as:");
for (i = 0; teststr1[i] != 0; i++)
printf(" U+%04X", teststr1[i]);
printf("\n");
if (teststr1[0] != 0x || teststr1[1] != 0)
{
printf("This conversion is INCORRECT.  It should be U+.\n");
return EXIT_FAILURE;
}

printf("The string \"\\U0001\" converts as:");
for (i = 0; teststr2[i] != 0; i++)
printf(" U+%04X", teststr2[i]);
printf("\n");
if (teststr2[0] != 0xD800 || teststr2[1] != 0xDC00 || teststr2[2] != 0)
{
printf("This conversion is INCORRECT.  It should be U+D800 U+DC00.\n");
return EXIT_FAILURE;
}

return EXIT_SUCCESS;
}
--CUT HERE--CUT HERE--CUT HERE--CUT HERE--CUT HERE--CUT HERE--CUT HERE--

The problem is a simple off-by-one error in the function one_utf8_to_utf16 in
libcpp/charset.c .  The following patch against the GCC 4.4.1 source corrects
the bug:

--CUT HERE--CUT HERE--CUT HERE--CUT HERE--CUT HERE--CUT HERE--CUT HERE--
--- gcc-4.4.1/libcpp/charset.c.old  2009-04-09 19:23:07.0 -0400
+++ gcc-4.4.1/libcpp/charset.c  2009-10-12 04:06:25.0 -0400
@@ -354,7 +354,7 @@
   return EILSEQ;
 }

-  if (s < 0x)
+  if (s <= 0x)
 {
   if (*outbytesleftp < 2)
{
--CUT HERE--CUT HERE--CUT HERE--CUT HERE--CUT HERE--CUT HERE--CUT HERE--


-- 
   Summary: "\u" converts incorrectly to two-byte character
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: chasonr at newsguy dot com
 GCC build triplet: x86_64-unknown-linux
  GCC host triplet: x86_64-unknown-linux
GCC target triplet: x86_64-unknown-linux


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

[Bug rtl-optimization/41697] New: ICE on gcc.c-torture/compile/20090917-1.c

[sje at cup dot hp dot com]

The test case gcc.c-torture/compile/20090917-1.c looks pretty bogus
(particularly the first argument to am_vector_index_for_loop) but it shouldn't
ICE which it does on IA64 HP-UX and Linux when compiled with -O3.

The ICE happens in the selective scheduler.  I am not sure if the problem is
platform specific or not, I don't see it on any other platforms.

The error:

20090917-1.c: In function 'build_access_matrix':
20090917-1.c:55:1: internal compiler error: vector VEC(edge,base) index domain
error, in _eligible_successor_edge_p at sel-sched-ir.h:1398
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


-- 
   Summary: ICE on gcc.c-torture/compile/20090917-1.c
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sje at cup dot hp dot com
 GCC build triplet: ia64-*-*
  GCC host triplet: ia64-*-*
GCC target triplet: ia64-*-*


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

[Bug middle-end/41264] [4.5 Regression] variable-tracking unbelievably slow

[aoliva at gcc dot gnu dot org]

--- Comment #10 from aoliva at gcc dot gnu dot org  2009-10-13 20:08 ---
This means the testcase labeled pr41264-test.c was totally unrelated to the
original bug report :-(  Oh well...  I'll add the other testcase to my ongoing
efforts to speed up var-tracking.  I'm working on that on two fronts:

1. speed up dataflow analysis while reducing memory use, by chaining and
partially-sharing variable hash tables, and speeding up lookups with
bit-fields.

2. speed up emission of notes by caching the results of expanding location
expressions, rather than repeatedly expanding then and often throwing the
results away

I'm afraid both of these are lower priority than wrong debug-info introduced in
the scheduler, as in bug 41535.


-- 


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

[Bug fortran/41678] Format label as second item in io control list is rejected

[jvdelisle at gcc dot gnu dot org]

--- Comment #10 from jvdelisle at gcc dot gnu dot org  2009-10-13 19:20 
---
Dominiq, thanks for tracking this down.  So the example code in this
otherfortran manual is invalid.  I noticed a few other examples in there that
are obfuscated in some manner to not be valid.  I am sure just editorial
errors.

Closing as invalid. 


-- 

jvdelisle at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug libfortran/41683] [4.5 Regression] F2003 Repeat specification after P descriptor rejected

[jvdelisle at gcc dot gnu dot org]

--- Comment #4 from jvdelisle at gcc dot gnu dot org  2009-10-13 19:17 
---
Fixed.


-- 

jvdelisle at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug tree-optimization/41377] [4.5 Regression] gimple EH rewrite causes ICE with PPRE (enabled at -O3)

[rth at gcc dot gnu dot org]

--- Comment #7 from rth at gcc dot gnu dot org  2009-10-13 18:45 ---
Fixed.


-- 

rth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug tree-optimization/41377] [4.5 Regression] gimple EH rewrite causes ICE with PPRE (enabled at -O3)

[rth at gcc dot gnu dot org]

--- Comment #6 from rth at gcc dot gnu dot org  2009-10-13 18:42 ---
Subject: Bug 41377

Author: rth
Date: Tue Oct 13 18:41:56 2009
New Revision: 152728

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152728
Log:
PR tree-optimization/41377
* tree-eh.c (unsplit_eh): Propagate degenerate PHIs.
(cleanup_empty_eh_merge_phis): New change_region parameter;
pass it on to redirect_eh_edge_1.  Update callers.
(cleanup_empty_eh_unsplit): Don't require an existing EH label
at the destination block.

Added:
trunk/gcc/testsuite/g++.dg/opt/eh5.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-eh.c


-- 


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

[Bug fortran/41678] Format label as second item in io control list is rejected

[dominiq at lps dot ens dot fr]

--- Comment #9 from dominiq at lps dot ens dot fr  2009-10-13 18:03 ---
> It would be interesting to get the opinion of Richard Maine.

> > ...
> > The wording in the f2003/2008 drafts I have at hand is more ambiguous: 
> > ...
> > Does a io-unit in C917 includes the optional characters UNIT=? If yes, 
> > is it correct to understand that read(unit=2, 100) is allowed in 
> > f2003/2008? 

Richard Maine's answer:

dominiq  wrote: 
> read(unit=2, 100) is invalid under f95 because of: 
> Constraint:... [elided] 
> The wording in the f2003/2008 drafts I have at hand is more ambiguous: 


I'd disagree. I'd say it was more concise and precise in that it uses 
bnf terms instead of repeating them as textual descriptions. 
... 
> C917 (R913) If format appears without a preceding FMT=, it shall be 
> the 
> second item in the io-control-spec-list and the first item 
> shall 
> be io-unit. 
... 
> R901 io-unit is file-unit-number 
>  or * 
>  or internal-file-variable 
> Does a io-unit in C917 includes the optional characters UNIT=? If yes, 
> is it correct to understand that read(unit=2, 100) is allowed in 
> f2003/2008? 


No. You have misinterpreted this as illustrated by the extra word you 
added. It is a very small extra word, but an important one. C917 refers 
to "io-unit". It does not refer to "a io-unit". Note also that io-unit 
is italicized. (This doesn't show up if you have only a plain text copy, 
but the actual standard is not plain text). 
The italicized io-unit is a bnf term. You cited the definition (R901). 
That definition does not include UNIT=. The thing that includes an 
optional UNIT= is the UNIT= specifier. "Io-unit" is not a sloppy 
abbreviation for "the UNIT= specifier", which is how it looks like you 
are interpreting it. 
When the standard uses an bnf term, it means it literally - that exact 
syntax. The fact that a UNIT= specifier can have the form io-unit does 
not imply that "io-unit" is a synonym for the UNIT= specifier. 
-- 
Richard Maine| Good judgment comes from experience; 
email: last name at domain . net | experience comes from bad judgment. 
domain: summertriangle   |  -- Mark Twain 

So the PR can probably be closed as INVALID.


-- 


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

[Bug rtl-optimization/40775] [4.4/4.5 Regression] ICE in find_valid_class, at reload.c:701

[ebotcazou at gcc dot gnu dot org]

--- Comment #4 from ebotcazou at gcc dot gnu dot org  2009-10-13 17:47 
---
Reclassifying.  You need an ARM maintainer to debug this.


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu dot
   ||org
  Component|ada |rtl-optimization
Summary|[4.4/4.5 Regression] Ada on |[4.4/4.5 Regression] ICE in
   |ARM ICE in find_valid_class,|find_valid_class, at
   |at reload.c:701 |reload.c:701


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

[Bug fortran/41678] Format label as second item in io control list is rejected

[dominiq at lps dot ens dot fr]

--- Comment #8 from dominiq at lps dot ens dot fr  2009-10-13 17:01 ---
> It would be interesting to get the opinion of Richard Maine.

watch
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/fbd60d05c9e683e4#


-- 


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

[Bug fortran/41581] [OOP] Allocation of a CLASS with SOURCE= does not work

[janus at gcc dot gnu dot org]

--- Comment #5 from janus at gcc dot gnu dot org  2009-10-13 16:14 ---
Fixed with r152715. Closing.


-- 

janus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug fortran/41581] [OOP] Allocation of a CLASS with SOURCE= does not work

[janus at gcc dot gnu dot org]

--- Comment #4 from janus at gcc dot gnu dot org  2009-10-13 16:12 ---
Subject: Bug 41581

Author: janus
Date: Tue Oct 13 16:12:24 2009
New Revision: 152715

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152715
Log:
2009-10-13  Janus Weil  

PR fortran/41581
* decl.c (encapsulate_class_symbol): Add new component '$size'.
* resolve.c (resolve_allocate_expr): Move CLASS handling to
gfc_trans_allocate.
(resolve_class_assign): Replaced by gfc_trans_class_assign.
(resolve_code): Remove calls to resolve_class_assign.
* trans.c (gfc_trans_code): Use new function gfc_trans_class_assign.
* trans-expr.c (get_proc_ptr_comp): Fix a memory leak.
(gfc_conv_procedure_call): For CLASS dummies, set the
$size component.
(gfc_trans_class_assign): New function, replacing resolve_class_assign.
* trans-stmt.h (gfc_trans_class_assign): New prototype.
* trans-stmt.c (gfc_trans_allocate): Use correct size when allocating
CLASS variables. Do proper initialization. Move some code here from
resolve_allocate_expr.


2009-10-13  Janus Weil  

PR fortran/41581
* gfortran.dg/class_allocate_2.f03: Modified.
* gfortran.dg/class_allocate_3.f03: New test case.

Added:
trunk/gcc/testsuite/gfortran.dg/class_allocate_3.f03
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/decl.c
trunk/gcc/fortran/resolve.c
trunk/gcc/fortran/trans-expr.c
trunk/gcc/fortran/trans-stmt.c
trunk/gcc/fortran/trans-stmt.h
trunk/gcc/fortran/trans.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/class_allocate_2.f03


-- 


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

[Bug tree-optimization/41555] [4.5 regression] possible miscompilation in whole-program mode

[sje at cup dot hp dot com]

--- Comment #6 from sje at cup dot hp dot com  2009-10-13 16:05 ---
The new test case (gcc.dg/torture/pr41555.c) is failing on ia64-hp-hpux11.23.
It looks like the *_MAX and *_MIN macros are only defined when in c99 mode so
the test requires -std=c99 on this platform (and others?)


-- 

sje at cup dot hp dot com changed:

   What|Removed |Added

 CC||sje at cup dot hp dot com


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

[Bug fortran/41678] Format label as second item in io control list is rejected

[burnus at gcc dot gnu dot org]

--- Comment #7 from burnus at gcc dot gnu dot org  2009-10-13 15:39 ---
(In reply to comment #0)
> The following is rejected by gfortran.  I think it is valid.
> real i
> read(unit=2, 100) i
> 100 format (f10.7)

In case of Fortran 95 it is trivially invalid (cf. comment 3 and comment 5).

In case of Fortran 2003/2008 one has:

R913 io-control-spec is [ UNIT = ] io-unit
 or [ FMT = ] format
 or [ NML = ] namelist-group-name
   (long list of other arguments with required keyword specifier)

C910 (R913) An io-unit shall be specified; if the optional characters UNIT=
are omitted, the io-unit shall be the first item in the
io-control-spec-list.
C917 (R913) If format appears without a preceding FMT=, it shall be the
second item in the io-control-spec-list and the first item shall
be io-unit.
C918 (R913) If namelist-group-name appears without a preceding NML=, it shall 
be the second item in the io-control-spec-list and the first item
shall be io-unit.

R901 io-unit is file-unit-number
 or *
 or internal-file-variable

Thus it seems to be allowed. The only question is whether "the first item shall
be io-unit" is only fulfilled when it is not specified with keyword specifier,
i.e. whether "the first item shall be io-unit" is not fulfilled by "unit=2" and
only by "2". My reading is that it applies to both and that thus the example is
_valid_. 
(I think the allowing this syntax is a bit counterintuitive compared to the
common syntax in Fortran, but it is implementable. Possibly it is something
which has been unintentionally changed but won't be corrected as it is
implementable.)

It would be interesting to get the opinion of Richard Maine.


-- 


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

[Bug debug/41695] Invalid .debug_loc created

[jakub at gcc dot gnu dot org]

--- Comment #1 from jakub at gcc dot gnu dot org  2009-10-13 14:44 ---
Created an attachment (id=18794)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18794&action=view)
gcc45-pr41695.patch

Patch I'm going to bootstrap/regtest.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jakub at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED


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

Last Chance: Red Ribbon Week starts next week

[PGI Products]

Educator,

Red Ribbon Week is October 23rd-31st. Are you and your school 
prepared? 

Here's a great way to make sure your students and faculty know just 
how important living a drug-free lifestyle really is: promote Red 
Ribbon Week.

http://pgiproducts.net/?mId=-199593&ID=2726760621&L=37595B

Each October, the National Family Partnership is dedicated to 
promoting the development and awareness of a drug-free lifestyle by 
way of education, research and recognition through your families, 
students, staff, patients, employees and others. This October, help 
this Partnership bring attention to these important individuals, all 
week, by planning a Red Ribbon celebration and ordering and 
displaying Red Ribbon materials, which feature exclusive slogans and 
graphics!


Sincerely,
Thomas Lombardi
Progressive Gifts & Incentives
376 Technology Drive
Malvern, PA 19355

This message was sent from a send-only mailbox that is unable to 
accept replies. 

If you would like to update your email address, manage your email
preferences or if you do not want to receive PGI product updates in
the future go to:
http://www.pgiproducts.net/emailpref/default.asp?ID=2726760621&O=1

priority code = e6760621-2713.
ContactID#: -1251749566 








   

[Bug fortran/41685] [OOP] internal compiler error: verify_flow_info failed

[janus at gcc dot gnu dot org]

--- Comment #9 from janus at gcc dot gnu dot org  2009-10-13 14:22 ---
(In reply to comment #8)
> Yup, works for me at revision 152697 + pr41656.diff
> Nice to see it fixed so fast :-) 

Ok, so I assume it was indeed fixed by the patch for PR41583. Closing.


-- 

janus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug target/41693] [4.5 Regression] RTL Check Failure in expand_debug_expr, at cfgexpand.c:2371

[jakub at gcc dot gnu dot org]

--- Comment #4 from jakub at gcc dot gnu dot org  2009-10-13 14:16 ---
Fixed.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug debug/41695] New: Invalid .debug_loc created

[jakub at gcc dot gnu dot org]

int bar (int);

void
foo (void)
{
  int b = 0;
  b = bar (b);
  b = bar (b);
  b = bar (b);
  b = bar (b);
  bar (b);
}

compiled with -g -O2 on x86_64-linux results in bogus .debug_loc ranges:
.LLST1:
.quad   .LVL0-.Ltext0   # Location list begin address (*.LLST1)
.quad   .LVL1-.Ltext0   # Location list end address (*.LLST1)
.value  0x2 # Location expression size
.byte   0x30# DW_OP_lit0
.byte   0x9f# DW_OP_stack_value
.quad   .LVL1-.Ltext0   # Location list begin address (*.LLST1)
.quad   .LVL2-1-.Ltext0 # Location list end address (*.LLST1)
.value  0x1 # Location expression size
.byte   0x50# DW_OP_reg0
.quad   .LVL2-.Ltext0   # Location list begin address (*.LLST1)
.quad   .LVL2-1-.Ltext0 # Location list end address (*.LLST1)
.value  0x1 # Location expression size
.byte   0x50# DW_OP_reg0
.quad   .LVL3-.Ltext0   # Location list begin address (*.LLST1)
.quad   .LVL2-1-.Ltext0 # Location list end address (*.LLST1)
.value  0x1 # Location expression size
.byte   0x50# DW_OP_reg0
.quad   .LVL4-.Ltext0   # Location list begin address (*.LLST1)
.quad   .LFE0-.Ltext0   # Location list end address (*.LLST1)
.value  0x1 # Location expression size
.byte   0x50# DW_OP_reg0
.quad   0x0 # Location list terminator begin (*.LLST1)
.quad   0x0 # Location list terminator end (*.LLST1)

Some ranges have negative size.


-- 
   Summary: Invalid .debug_loc created
   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: x86_64-linux


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

[Bug target/41693] [4.5 Regression] RTL Check Failure in expand_debug_expr, at cfgexpand.c:2371

[jakub at gcc dot gnu dot org]

--- Comment #3 from jakub at gcc dot gnu dot org  2009-10-13 13:56 ---
Subject: Bug 41693

Author: jakub
Date: Tue Oct 13 13:56:07 2009
New Revision: 152707

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152707
Log:
PR target/41693
* rtl.h (DEBUG_EXPR_TREE_DECL): Define.
* sched-vis.c (print_value): Use it.
* cselib.c (cselib_hash_rtx): Likewise.
* print-rtl.c (print_rtx): Likewise.
* cfgexpand.c (expand_debug_rtx): Likewise.
* var-tracking.c (vt_expand_loc_callback): Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/cfgexpand.c
trunk/gcc/cselib.c
trunk/gcc/print-rtl.c
trunk/gcc/rtl.h
trunk/gcc/sched-vis.c
trunk/gcc/var-tracking.c


-- 


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

[Bug target/41156] [4.4/4.5 Regression] zlib segfault in inflate_table() compiled w/ -O -msse2 ftree-vectorize

[mahatma at eu dot by]

--- Comment #27 from mahatma at eu dot by  2009-10-13 13:26 ---
(In reply to comment #24)

> > unused wide. Why? What side-effects of "-mstackrealign"? Perfomance?
> 
> Please see PR 40838.

As seen on... a...
I found only ABI standard reasons. FIXME!
But SSE usage still optional like -mstackrealign option. I see no political
differences: "-msse" or "-march=pentium4" or "-mstackrealign". Default "i686"
builds will be same unaligned.


-- 


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

[Bug ada/40775] [4.4/4.5 Regression] Ada on ARM ICE in find_valid_class, at reload.c:701

[joel at gcc dot gnu dot org]

--- Comment #3 from joel at gcc dot gnu dot org  2009-10-13 13:11 ---
Still broken:

+===GNAT BUG DETECTED==+
| 4.5.0 20091012 (experimental) [trunk revision 152668] (arm-unknown-rtems4.10)
GCC error:|
| in find_valid_class, at reload.c:702 |
| Error detected around a-ngcefu.adb:115:8  


-- 


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

[Bug debug/40521] [4.4/4.5 Regression] -g causes GCC to generate .eh_frame

[mikpe at it dot uu dot se]

--- Comment #17 from mikpe at it dot uu dot se  2009-10-13 12:52 ---
Patch with proposed backport to 4.4 posted here:
http://gcc.gnu.org/ml/gcc-patches/2009-10/msg00818.html


-- 


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

[Bug lto/41565] -m32 causes an ICE when the object files were compiled with 64bit

[rguenth at gcc dot gnu dot org]

--- Comment #9 from rguenth at gcc dot gnu dot org  2009-10-13 12:43 ---
Still no testcase for the original report.  Target options in general should
be fixed now.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|WAITING


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

[Bug lto/41565] -m32 causes an ICE when the object files were compiled with 64bit

[rguenth at gcc dot gnu dot org]

--- Comment #8 from rguenth at gcc dot gnu dot org  2009-10-13 12:42 ---
Subject: Bug 41565

Author: rguenth
Date: Tue Oct 13 12:42:30 2009
New Revision: 152705

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152705
Log:
2009-10-13  Richard Guenther  

PR lto/41565
* opts.c (handle_option): Split out code to handle setting
the options flag var ...
(set_option): ... here.
* opts.h (set_option): Declare.
* lto-opts.c (register_user_option_p): Include -fexceptions
and all position independent code variants.
(handle_common_option): Remove.
(lto_reissue_options): Use set_option.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/lto-opts.c
trunk/gcc/opts.c
trunk/gcc/opts.h


-- 


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

[Bug lto/41668] ICE in get_alias_set, at alias.c:698

[rguenth at gcc dot gnu dot org]

--- Comment #7 from rguenth at gcc dot gnu dot org  2009-10-13 12:39 ---
Subject: Bug 41668

Author: rguenth
Date: Tue Oct 13 12:39:06 2009
New Revision: 152704

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152704
Log:
2009-10-13  Richard Guenther  

PR lto/41668
* gcc.dg/lto/20091006-2_0.c: New testcase.
* gcc.dg/lto/20091006-2_1.c: Likewise.
* gcc.dg/lto/20091006-2_2.c: Likewise.
* gcc.dg/lto/20091013-1_0.c: Likewise.
* gcc.dg/lto/20091013-1_1.c: Likewise.
* gcc.dg/lto/20091013-1_2.c: Likewise.

Added:
trunk/gcc/testsuite/gcc.dg/lto/20091006-2_0.c
trunk/gcc/testsuite/gcc.dg/lto/20091006-2_1.c
trunk/gcc/testsuite/gcc.dg/lto/20091006-2_2.c
trunk/gcc/testsuite/gcc.dg/lto/20091013-1_0.c
trunk/gcc/testsuite/gcc.dg/lto/20091013-1_1.c
trunk/gcc/testsuite/gcc.dg/lto/20091013-1_2.c
Modified:
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug lto/41668] ICE in get_alias_set, at alias.c:698

[rguenth at gcc dot gnu dot org]

--- Comment #6 from rguenth at gcc dot gnu dot org  2009-10-13 12:29 ---
Well.  Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug target/41156] [4.4/4.5 Regression] zlib segfault in inflate_table() compiled w/ -O -msse2 ftree-vectorize

[mahatma at eu dot by]

--- Comment #26 from mahatma at eu dot by  2009-10-13 12:16 ---
(In reply to comment #25)
> would you please just test the patch on PR 40838 and tell HJ if it works or
> not?
> 

In progress. There are only one Celeron PC leased without distcc to build and
runtime test big packages.


-- 


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

[Bug middle-end/41264] [4.5 Regression] variable-tracking unbelievably slow

[rguenth at gcc dot gnu dot org]

--- Comment #9 from rguenth at gcc dot gnu dot org  2009-10-13 12:07 ---
It's not fixed.

 variable tracking : 480.87 (90%) usr   1.42 (54%) sys 482.57 (90%) wall  
22699 kB ( 5%) ggc

it's even got slower.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |


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

[Bug c++/41690] Scoping is incorrect for inherited classes nested inside a templated class.

[paolo dot carlini at oracle dot com]

--- Comment #7 from paolo dot carlini at oracle dot com  2009-10-13 11:55 
---
Yes, Jon. By the way, I also wanted to link to that *very* old changes doc,
probably gave up only because the examples are slightly different. But indeed,
that's exactly the point.


-- 


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

[Bug tree-optimization/41661] [4.5 Regression] ICE due to IPCP trying to create/fold a REAL typed comparision

[jamborm at gcc dot gnu dot org]

--- Comment #5 from jamborm at gcc dot gnu dot org  2009-10-13 11:32 ---
Fixed.


-- 

jamborm at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug tree-optimization/41661] [4.5 Regression] ICE due to IPCP trying to create/fold a REAL typed comparision

[jamborm at gcc dot gnu dot org]

--- Comment #4 from jamborm at gcc dot gnu dot org  2009-10-13 11:31 ---
Subject: Bug 41661

Author: jamborm
Date: Tue Oct 13 11:31:08 2009
New Revision: 152702

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152702
Log:
2009-10-13  Martin Jambor  

PR tree-optimization/41661
* ipa-prop.c (compute_complex_pass_through): Allow only operations
that are tcc_comparisons or do not change the type in any
un-usleless way.
* ipa-cp.c (ipcp_lattice_from_jfunc): Request boolean type when
folding tcc_comparison operations.

* testsuite/gcc.c-torture/compile/pr41661.c: New test.



Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr41661.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-cp.c
trunk/gcc/ipa-prop.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug bootstrap/41691] -flto leads to bootstrap failure

[linuxl4 at sohu dot com]

--- Comment #3 from linuxl4 at sohu dot com  2009-10-13 11:27 ---
thanks for your message above.


-- 


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

[Bug c++/41690] Scoping is incorrect for inherited classes nested inside a templated class.

[redi at gcc dot gnu dot org]

--- Comment #6 from redi at gcc dot gnu dot org  2009-10-13 11:02 ---
Or see http://gcc.gnu.org/gcc-3.4/changes.html#cplusplus


-- 


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

[Bug fortran/41685] [OOP] internal compiler error: verify_flow_info failed

[sfilippone at uniroma2 dot it]

--- Comment #8 from sfilippone at uniroma2 dot it  2009-10-13 10:44 ---
(In reply to comment #7)
> Works for me at revision pr152662 and with the patches for pr41629 and pr41656
> (latest avatars).
> 

Yup, works for me at revision 152697 + pr41656.diff
Nice to see it fixed so fast :-) 


-- 


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

[Bug c++/41690] Scoping is incorrect for inherited classes nested inside a templated class.

[paolo dot carlini at oracle dot com]

--- Comment #5 from paolo dot carlini at oracle dot com  2009-10-13 10:26 
---
To be clear, the use of this-> isn't a "workaround", is the way C++ as
specified in the current International standard works. This is not the place
for general explanations, you may want to browse D. Vandevoorde and Nicolai M.
Josuttis, "C++ Templates", Addison Wesley, for a clear treatment of the this->,
typename, ::templte, .template, etc., subtleties and *much* more.


-- 


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

[Bug lto/41681] Feature request half way option between dynamic and static linking.

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2009-10-13 09:46 ---
So your half-way would be only useful for static analysis, but not for any
optimization decision.  Consider a function currently being

void doIt() {}

in the shared library.  Now, if GCC sees the body it can deduce that calls
to it are useless and it will DCE them.  Next, the shared library
implementation
changes to

void doIt() { printf("Hello"); }

which is perfectly valid.  Thus, GCC has miscompiled the program.

So - it's not going to work in any way that will give extra information
to GCC.


-- 

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

[Bug bootstrap/41691] -flto leads to bootstrap failure

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2009-10-13 09:42 ---
Well, you obviously would need a host compiler with LTO enabled:

cc1: error: LTO support has not been enabled in this configuration

or better use BOOT_CFLAGS and TARGET_CFLAGS, not CFLAGS.  Note you also
need to adjust BOOT_LDFLAGS and TARGET_LDFLAGS.  And note that bootstrap
with LTO is currently broken, see for example PR41598.


-- 

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

[Bug middle-end/41694] ICE with -fopenmp -O -g and -fwhopr or -flto

[burnus at gcc dot gnu dot org]

--- Comment #1 from burnus at gcc dot gnu dot org  2009-10-13 09:35 ---
Note: -g does not work yet with -fwhopr or -flto.

See also: PR 41521 and 41566


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|fortran |middle-end
   Keywords||lto


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

[Bug fortran/41656] [OOP] Unresolved GENERIC

[sfilippone at uniroma2 dot it]

--- Comment #5 from sfilippone at uniroma2 dot it  2009-10-13 09:06 ---
(In reply to comment #4)
The recent combined patch by Paul makes my compilation progress; however a
little later I get an ICE here: 

#0  0x00349887efa0 in strcmp () from /lib64/libc.so.6
#1  0x0050ffdd in gfc_find_symtree (st=0x128e7d0, name=0x0) at
../../gcc
/gcc/fortran/symbol.c:1810
#2  0x004dd749 in load_derived_extensions () at
../../gcc/gcc/fortran/mo
dule.c:3604
#3  read_module () at ../../gcc/gcc/fortran/module.c:4450
#4  0x004de834 in gfc_use_module () at
../../gcc/gcc/fortran/module.c:36
04
#5  0x004e2ca5 in accept_statement (st=) at
../../g
cc/gcc/fortran/parse.c:4047
#6  0x7fffd710 in ?? ()
#7  0x004e572e in parse_spec (st=) at
../../gcc/gcc
/fortran/parse.c:4047
#8  0x7fffd82c in ?? ()
#9  0x in ?? ()


If this is related to this patch, it needs some more work. Otherwise, I'll cut
the test case and open a new PR


-- 


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

[Bug lto/41681] Feature request half way option between dynamic and static linking.

[oiaohm at gmail dot com]

--- Comment #3 from oiaohm at gmail dot com  2009-10-13 08:03 ---
Currently for libstdc++ it must be either dynamic or static.  This separation
causes some problems.

There need to be two halfway points.  The static libs the dynamic both be
there.

Type one halfway is for secuirty reasons.  Having access to the bytecode lto of
like libstdc++ and others dynamic libs would allow deep scanning for code
defects like finding allocations of memory that don't get freed and buffer
overflows and others.   

To get this advantage lto needs know that the byte code assigned to dynamic
libs is not to integrated since the dynamic libs already contain those
functions.

The second would build on type one.  Optimizes would be allowed to look at the
lto code of the dynamic lib if functions can be optimized out it can be done. 
If not those functions done by dynamic linking.  

This is halfway between static and dynamic linking.  Pure dynamic compiler does
not know what is inside the .so or .dll files other than the function
interfaces.

Doing this does raise the question if dynamic and static linking files should
be two different things or should they be basically the same.  Static be lto
bytecode.  Dynamic be precomplied + the same static lto bytecode.

Allowing full static analyzation inside compiler would be a major gain to
secuirty.

lto closes down cross object flaws from being seen from the compiler.  But it
still leaves cross library flaws in dynamic that don't exist when static
linking with lto.  Reason static linking with lto all bytecode data can be seen
even inside the libraries.

Lets provide an option to close the flaw.   Being able to staticly solve out
with at .so lto bytecode in a lot of cases would give the same results as using
the static .a lto bytecode file.

Halfway could be used to remove duplication of lto bytecode to do either static
or highly audited dynamic linking.  1 copy to do both.


-- 

oiaohm at gmail dot com changed:

   What|Removed |Added

 Status|WAITING |UNCONFIRMED


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

[Bug fortran/41694] New: ICE with -fopenmp -O -g and -fwhopr or -flto

[anlauf at gmx dot de]

Hi,

when compiling and linking the following program:

% cat openmp-test.F90
implicit none
#if _OPENMP >= 200505
!$ integer :: OMP_GET_NUM_THREADS, OMP_GET_MAX_THREADS, OMP_GET_THREAD_NUM
#else
   integer :: OMP_GET_NUM_THREADS, OMP_GET_MAX_THREADS, OMP_GET_THREAD_NUM
#endif
   integer :: i
   print *, "OpenMP version:", _OPENMP
   print *
!$OMP parallel do
   do i = 1, OMP_GET_MAX_THREADS ()
  print *, "OMP_GET_THREAD_NUM
=",OMP_GET_THREAD_NUM(),OMP_GET_NUM_THREADS()
   end do
!$OMP end parallel do
end program
% gfc4x -O -g -fopenmp openmp-test.F90  -fwhopr
lto1: error: missing callgraph edge for call stmt:
# .MEM_26 = VDEF <.MEM_25>
_gfortran_st_write (&dt_parm.2);

lto1: error: missing callgraph edge for call stmt:
# .MEM_27 = VDEF <.MEM_26>
_gfortran_transfer_character (&dt_parm.2, &"OMP_GET_THREAD_NUM ="[1]{lb: 1 sz:
1}, 20);

lto1: error: edge points to wrong declaration:
 >
QI
size 
unit size 
align 8 symtab 0 alias set -1 canonical type 0x2b9f7e461300
arg-types 
chain >>
pointer_to_this >
public external QI file (null) line 0 col 0 align 8>
 Instead of: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41694

Re: Error "pointer to unimplemented type"

[prashant rawat]

How is the pointer-to-pointer type taken care of in function walk_type ()?
If I modify the if statement of line 2014 (gengtype.c) to
if ((!t->u.p->kind == TYPE_POINTER) && ! UNION_OR_STRUCT_P (t->u.p)
&& t->u.p->kind != TYPE_PARAM_STRUCT)
it works fine.



On Tue, Oct 13, 2009 at 12:59 PM, prashant rawat
 wrote:
> Hello,
> While trying to add a field 'tree * var_list' to struct cgraph_node
> (defined in cgraph.h), I got an error
>
> ../../gcc-4.3.1/gcc/cgraph.h:128: field `(*x).var_list' is pointer to
> unimplemented type
>  ../../gcc-4.3.1/gcc/cgraph.h:128: field `(*x).var_list' is pointer to
> unimplemented type
>  ../../gcc-4.3.1/gcc/cgraph.h:128: field `(*x).var_list' is pointer to
> unimplemented type
>  make[3]: *** [s-gtype] Error 1
>
> This happened all the times I tried adding a pointer-to-pointer type
> data structure in cgraph_node.
> The error is generated in line 2020 of file gengtype.c.
> Did anyone else notice the same problem? Is it a potential bug?
> Thanks!
>

[Bug fortran/41648] [OOP] Type-bound procedures refused

[pault at gcc dot gnu dot org]

--- Comment #2 from pault at gcc dot gnu dot org  2009-10-13 07:33 ---
Have just posted a patch for this

Paul


-- 

pault at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |pault at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-10-13 07:33:38
   date||


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

Error "pointer to unimplemented type"

[prashant rawat]

Hello,
While trying to add a field 'tree * var_list' to struct cgraph_node
(defined in cgraph.h), I got an error

../../gcc-4.3.1/gcc/cgraph.h:128: field `(*x).var_list' is pointer to
unimplemented type
 ../../gcc-4.3.1/gcc/cgraph.h:128: field `(*x).var_list' is pointer to
unimplemented type
 ../../gcc-4.3.1/gcc/cgraph.h:128: field `(*x).var_list' is pointer to
unimplemented type
 make[3]: *** [s-gtype] Error 1

This happened all the times I tried adding a pointer-to-pointer type
data structure in cgraph_node.
The error is generated in line 2020 of file gengtype.c.
Did anyone else notice the same problem? Is it a potential bug?
Thanks!