[Bug rtl-optimization/39837] [4.3/4.4/4.5 regression] extra spills due to RTL LICM

[bonzini at gnu dot org]

--- Comment #12 from bonzini at gnu dot org  2010-07-11 07:51 ---
I agree.


-- 

bonzini at gnu dot org changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|DUPLICATE   |


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

[Bug rtl-optimization/36758] [4.3/4.4/4.5/4.6 Regression] addition moved out of the loop when used with an argument

[bonzini at gnu dot org]

--- Comment #23 from bonzini at gnu dot org  2010-07-11 07:51 ---
This is fixed on ARM, what about PPC?


-- 


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

[Bug debug/44689] -fenable-icf-debug -fprofile-generate causes segfault in cp_function_decl_explicit_p

[janus at gcc dot gnu dot org]

--- Comment #1 from janus at gcc dot gnu dot org  2010-07-11 07:55 ---
Subject: Bug 44689

Author: janus
Date: Sun Jul 11 07:55:11 2010
New Revision: 162052

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162052
Log:
2010-07-11  Janus Weil  

PR fortran/44689
* decl.c (build_sym,attr_decl1): Only build the class container if the
symbol has sufficient attributes.
* expr.c (gfc_check_pointer_assign): Use class_pointer instead of
pointer attribute for classes.
* match.c (gfc_match_allocate,gfc_match_deallocate): Ditto.
* module.c (MOD_VERSION): Bump.
(enum ab_attribute,attr_bits): Add AB_CLASS_POINTER.
(mio_symbol_attribute): Handle class_pointer attribute.
* parse.c (parse_derived): Use class_pointer instead of pointer
attribute for classes.
* primary.c (gfc_variable_attr,gfc_expr_attr): Ditto.
* resolve.c (resolve_structure_cons,resolve_deallocate_expr,
resolve_allocate_expr,resolve_fl_derived): Ditto.
(resolve_fl_var_and_proc): Check for class_ok attribute.

2010-07-11  Janus Weil  

PR fortran/44689
* gfortran.dg/class_24.f03: New.

Added:
trunk/gcc/testsuite/gfortran.dg/class_24.f03
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/decl.c
trunk/gcc/fortran/expr.c
trunk/gcc/fortran/match.c
trunk/gcc/fortran/module.c
trunk/gcc/fortran/parse.c
trunk/gcc/fortran/primary.c
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug debug/44689] -fenable-icf-debug -fprofile-generate causes segfault in cp_function_decl_explicit_p

[janus at gcc dot gnu dot org]

--- Comment #2 from janus at gcc dot gnu dot org  2010-07-11 07:58 ---
(In reply to comment #1)
> Subject: Bug 44689
> 
> Author: janus
> Date: Sun Jul 11 07:55:11 2010
> New Revision: 162052
> 
> URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162052

Sorry, this commit was actually for PR 44869. I mixed up the numbers.


-- 


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

[Bug fortran/44869] [OOP] Missing TARGET check - and wrong code or accepts-invalid?

[janus at gcc dot gnu dot org]

--- Comment #6 from janus at gcc dot gnu dot org  2010-07-11 08:09 ---
The TARGET check is fixed by r162052:

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


The runtime segfault persist.


-- 


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

[Bug fortran/44869] [OOP] Missing TARGET check - and wrong code or accepts-invalid?

[janus at gcc dot gnu dot org]

--- Comment #7 from janus at gcc dot gnu dot org  2010-07-11 08:26 ---
(In reply to comment #6)
> The runtime segfault persist.

It seems this segfault comes from the call to 'self%assert' in 'test_a'.

The dump shows

self->$vptr->assert->assert_int ((struct class$test_case *) self, &C.1978,
&C.1979, &C.1980, &"generic_tbp.f90"[1]{lb: 1 sz: 1}, &"purposely
failed"[1]{lb: 1 sz: 1}, 15, 16);

which looks ok.

The problem seems to be that the generic TBPs in the vtab are not initialized
properly. The dump contains the correct initialization code for the specific
TBPs, but the init for the generics seems to be missing.


-- 


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

[Bug ada/43731] Missing ada multilib on i686-w64-mingw32 target

[ktietz at gcc dot gnu dot org]

--- Comment #2 from ktietz at gcc dot gnu dot org  2010-07-11 09:15 ---
Subject: Bug 43731

Author: ktietz
Date: Sun Jul 11 09:15:12 2010
New Revision: 162057

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162057
Log:
2010-07-11  Kai Tietz  

Merged back from trunk
* config/i386/winnt.c (i386_pe_file_end): Quote symbol name
in directive -export.


2010-07-11  Kai Tietz  

Merged back from trunk
PR ada/43731
* gcc-interface/Makefile.in: Add rules for multilib x86/x64
mingw targets.


Modified:
branches/gcc-4_5-branch/gcc/ChangeLog
branches/gcc-4_5-branch/gcc/ada/ChangeLog
branches/gcc-4_5-branch/gcc/ada/gcc-interface/Makefile.in
branches/gcc-4_5-branch/gcc/config/i386/winnt.c


-- 


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

[Bug ada/43731] Missing ada multilib on i686-w64-mingw32 target

[ktietz at gcc dot gnu dot org]

--- Comment #3 from ktietz at gcc dot gnu dot org  2010-07-11 09:20 ---
Fixed for head and 4.5.1


-- 

ktietz at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug fortran/43945] [OOP] Derived type with GENERIC: resolved to the wrong specific TBP

[janus at gcc dot gnu dot org]

--- Comment #28 from janus at gcc dot gnu dot org  2010-07-11 09:40 ---
I'll take over this one. Have a fix.


-- 

janus at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|pault at gcc dot gnu dot org|janus at gcc dot gnu dot org
 Status|REOPENED|ASSIGNED
   Last reconfirmed|2010-05-01 17:16:57 |2010-07-11 09:40:21
   date||


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

[Bug fortran/44565] [4.6 Regression] [OOP] ICE in gimplify_expr with array-valued generic TBP

[janus at gcc dot gnu dot org]

--- Comment #4 from janus at gcc dot gnu dot org  2010-07-11 09:41 ---
Mine. Patch coming soon.


-- 

janus at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |janus at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2010-06-17 22:24:27 |2010-07-11 09:41:26
   date||


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

[Bug testsuite/44518] [4.5/4.6 regression] objc++ encode-2.mm and encode-3.mm fail on several platforms

[iains at gcc dot gnu dot org]

--- Comment #12 from iains at gcc dot gnu dot org  2010-07-11 09:55 ---
back-ported to 4.5 as r162037, closing as fixed


-- 

iains at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug target/44903] [4.6 Regression] FAIL: gcc.dg/pr35258.c execution test

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2010-07-11 10:47 ---
(In reply to comment #3)
> Subject: Re:  [4.6 Regression] FAIL: gcc.dg/pr35258.c
> execution test
> 
> On Sat, 10 Jul 2010, rguenth at gcc dot gnu dot org wrote:
> 
> > I get for all memory accesses an alignment of 8 at expansion time which 
> > looks
> > correct (on i?86).  Please debug this a bit, set_mem_attributes_minus_bitpos
> > looks conservative enough.
> 
> The rtl in question is the following:
> 
> (insn 8 6 11 /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pr35258.c:16 (set (reg:SI
> 28 %r28 [orig:94 D.1980 ] [94])
>  (mem/c:SI (plus:SI (reg/f:SI 1 %r1 [95])
>  (const_int 1 [0x1])) [0 MEM[(char * {ref-all})&str +
> 1B]+0 S4 A8])) 37 {*pa.md:2102} (nil))
> 
> An alignment of 8 is not sufficient for a 4 byte (SImode) load on targets
> that define STRICT_ALIGNMENT.  We need an alignment of 32.
>
> I believe the i?86 hardware allows unaligned addresses, so you wouldn't
> see the problem.

Hm.  So the MEM_REF path goes the same way as the INDIRECT_REF path for

typedef int t __attribute__((aligned(1),may_alias));
int foo(t *p)
{
  return *p;
}
int main()
{
  char c[5] = {};
  if (foo(&c[1]) != 0)
abort ();
  return 0;
}

for example on the 4.5 branch.  I see no provision to handle not properly
aligned pointer dereferences in expansion.  So I believe this is a latent
issue - but I am quite lost here in the myriads of RTL expansion (which
isn't exactly a piece of GCC I am familiar with).

In fact with Erics fix for PRxyz (all 32bit sparc tests fail) we now claim
an alignment of 32 for the integer load.  (CCing Eric - we should factor
in the alignemnt of the pointer type as minimum here).

But back to the above testcase.  On the 4.5 branch I get on i?86:

(insn 6 5 7 3 t.c:4 (set (reg:SI 58 [ D.1952 ])
(mem:SI (reg/f:SI 60) [0 S4 A8])) -1 (nil))

(good), but with a cross to ia64-hp-hpux11.23 (I happened to have that around)

(insn 7 6 8 3 t.c:4 (set (reg/f:DI 341)
(unspec:DI [
(reg:SI 342)
] 24)) -1 (nil))

(insn 8 7 9 3 t.c:4 (set (reg:SI 339 [ D.2007 ])
(mem:SI (reg/f:DI 341) [0 S4 A32])) -1 (nil))

thus an alignment of 32!?  A nice way of "fixing" ;)

I am curious if the above testcase works for you on the 4.5 branch (or
for any version).


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu dot
   ||org


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

[Bug lto/44904] Maybe bogus Use of type ?struct nsCSSStyleSheet? with two mismatching declarations at field ?mRuleProcessors? warnings in Mozilla

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2010-07-11 10:58 ---
Differing array sizes of the mAutoBuf member, type decls:

 
unit size 
align 64 symtab 0 alias set -1 canonical type 0x75b20c78
fields 
ignored BLK file ../../dist/include/nsTArray.h line 1036 col 7
size 
unit size 
align 64 offset_align 128
offset 
bit offset  context
 chain >
pointer_to_this >
public BLK file ../../dist/include/nsTArray.h line 1036 col 7
align 8>

 
unit size 
align 64 symtab 0 alias set -1 canonical type 0x75af39d8
fields 
ignored BLK file ../../dist/include/nsTArray.h line 1036 col 7
size 
unit size 
align 64 offset_align 128
offset 
bit offset  context
 chain >
pointer_to_this >
public BLK file ../../dist/include/nsTArray.h line 1036 col 7
align 8>


-- 

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

[Bug bootstrap/44455] GCC fails to build if MPFR 3.0.0 (Release Candidate) is used

[a dot heider at gmail dot com]

--- Comment #6 from a dot heider at gmail dot com  2010-07-11 11:17 ---
4.4.4 is affected as well


-- 


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

[Bug target/44900] The variable of SSE will be broken

[ubizjak at gmail dot com]

--- Comment #2 from ubizjak at gmail dot com  2010-07-11 11:25 ---
Confirmed on i686-pc-linux-gnu (with errno fully removed).

4.6.0 works OK.


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Component|c++ |target
 Ever Confirmed|0   |1
  Known to fail||4.5.1
  Known to work||4.6.0
   Last reconfirmed|-00-00 00:00:00 |2010-07-11 11:25:40
   date||


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

[Bug lto/44904] Maybe bogus Use of type ?struct nsCSSStyleSheet? with two mismatching declarations at field ?mRuleProcessors? warnings in Mozilla

[steven at gcc dot gnu dot org]

--- Comment #3 from steven at gcc dot gnu dot org  2010-07-11 11:37 ---
Should this (and the other one) not be mentioned upstream somehow?


-- 


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

[Bug lto/44904] Maybe bogus Use of type ?struct nsCSSStyleSheet? with two mismatching declarations at field ?mRuleProcessors? warnings in Mozilla

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2010-07-11 11:38 ---
Seems to be bogus merging of complete/incomplete types.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |


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

[Bug lto/44904] Maybe bogus Use of type ?struct nsCSSStyleSheet? with two mismatching declarations at field ?mRuleProcessors? warnings in Mozilla

[rguenth at gcc dot gnu dot org]

--- Comment #5 from rguenth at gcc dot gnu dot org  2010-07-11 11:39 ---
(In reply to comment #3)
> Should this (and the other one) not be mentioned upstream somehow?

Honza is filing bugs with them.


-- 


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

[Bug target/44900] The variable of SSE will be broken

[ubizjak at gmail dot com]

--- Comment #3 from ubizjak at gmail dot com  2010-07-11 11:39 ---
For some reason, we got:

movl$0x4180, 112(%esp)
movl$0x4170, 116(%esp)
movl$0x4160, 120(%esp)
movl$0x4150, 124(%esp)
movl$0x4140, 128(%esp)
movl$0x4130, 132(%esp)
movl$0x4120, 136(%esp)
movl$0x4110, 140(%esp)
movl$0x4100, 144(%esp)
movl$0x40e0, 148(%esp)
movl$0x40c0, 152(%esp)
movl$0x40a0, 156(%esp)
movups  136(%esp), %xmm0
movaps  %xmm0, 96(%esp)
movups  120(%esp), %xmm0
movaps  %xmm0, 80(%esp)
movaps  %xmm0, 160(%esp)
movaps  96(%esp), %xmm0
movaps  %xmm0, 176(%esp)
>>> fldz
fstpl   60(%esp)
flds184(%esp)
fstpl   52(%esp)
flds180(%esp)
fstpl   44(%esp)
flds176(%esp)
fstpl   36(%esp)
flds172(%esp)
fstpl   28(%esp)
flds168(%esp)
fstpl   20(%esp)
flds164(%esp)
fstpl   12(%esp)
flds160(%esp)
fstpl   4(%esp)
movl$.LC12, (%esp)
callprintf

Changing fldz to "flds  188(%esp)" produces correct output.


-- 


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

[Bug rtl-optimization/39837] [4.3/4.4/4.5 regression] extra spills due to RTL LICM

[steven at gcc dot gnu dot org]

--- Comment #13 from steven at gcc dot gnu dot org  2010-07-11 11:40 ---
Does the prototype fix of http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36758#c21
help?


-- 


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

[Bug target/44900] [4.5 Regression] The variable of SSE will be broken

[ubizjak at gmail dot com]

--- Comment #4 from ubizjak at gmail dot com  2010-07-11 11:42 ---
4.4 works OK, so this is 4.5 regression.


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

  Known to work|4.6.0   |4.6.0 4.4.4
Summary|The variable of SSE will be |[4.5 Regression] The
   |broken  |variable of SSE will be
   ||broken


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

[Bug target/44900] [4.5 Regression] The variable of SSE will be broken

[ubizjak at gmail dot com]

--- Comment #5 from ubizjak at gmail dot com  2010-07-11 11:59 ---
Expand expands with uninitialized register r68:

   41 [r54:SI-0x20]=r73:V4SF
   42 [r54:SI-0x10]=r72:V4SF
>  43 [r56:SI+0x3c]=float_extend(r68:SF)
   44 [r56:SI+0x34]=float_extend([r54:SI-0x8])
   45 [r56:SI+0x2c]=float_extend([r54:SI-0xc])
   46 [r56:SI+0x24]=float_extend([r54:SI-0x10])
   47 [r56:SI+0x1c]=float_extend([r54:SI-0x14])
   48 [r56:SI+0x14]=float_extend([r54:SI-0x18])
   49 [r56:SI+0xc]=float_extend([r54:SI-0x1c])
   50 [r56:SI+0x4]=float_extend([r54:SI-0x20])
   51 [r56:SI]=`*.LC12'
   52 call <...>

.optimized tree dump looks suspicious, load from uninitialized var:

  SR.14_103 = __builtin_ia32_loadups (&data[6]);
  SR.13_104 = __builtin_ia32_loadups (&data[2]);
  a._v1.D.1895.v = SR.13_104;
  a._v2.D.1895.v = SR.14_103;
  a$_v2$D1895$e$0_98 = a._v2.D.1895.e[0];
  a$_v2$D1895$e$1_110 = a._v2.D.1895.e[1];
  a$_v2$D1895$e$2_105 = a._v2.D.1895.e[2];
  v1$D1895$e$0_99 = a._v1.D.1895.e[0];
  v1$D1895$e$1_40 = a._v1.D.1895.e[1];
  v1$D1895$e$2_95 = a._v1.D.1895.e[2];
  v1$D1895$e$3_79 = a._v1.D.1895.e[3];
  D.2043_5 = (double) a$_v2$D1895$e$3_82(D); <--- here
  D.2045_7 = (double) a$_v2$D1895$e$2_105;
  D.2047_9 = (double) a$_v2$D1895$e$1_110;
  D.2049_11 = (double) a$_v2$D1895$e$0_98;
  D.2051_13 = (double) v1$D1895$e$3_79;
  D.2053_15 = (double) v1$D1895$e$2_95;
  D.2055_17 = (double) v1$D1895$e$1_40;
  D.2057_19 = (double) v1$D1895$e$0_99;

Needs tree expert. CC'd.


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

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


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

Re: [Bug lto/44904] Maybe bogus Use of type ?struct nsCSSStyleSheet? with two mismatching declarations at field ?mRuleProcessors? warnings in Mozilla

[Jan Hubicka]

> Should this (and the other one) not be mentioned upstream somehow?
I filled in PRs for the ODR violations at Mozilla side already.

Honza

[Bug lto/44904] Maybe bogus Use of type ?struct nsCSSStyleSheet? with two mismatching declarations at field ?mRuleProcessors? warnings in Mozilla

[hubicka at ucw dot cz]

--- Comment #6 from hubicka at ucw dot cz  2010-07-11 12:06 ---
Subject: Re:  Maybe bogus Use of type ?struct
nsCSSStyleSheet? with two mismatching declarations at field
?mRuleProcessors? warnings in Mozilla

> Should this (and the other one) not be mentioned upstream somehow?
I filled in PRs for the ODR violations at Mozilla side already.

Honza


-- 


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

[Bug tree-optimization/44900] [4.5 Regression] The variable of SSE will be broken

[rguenth at gcc dot gnu dot org]

--- Comment #6 from rguenth at gcc dot gnu dot org  2010-07-11 12:48 ---
Confirmed, caused by SRA, maybe latent on the trunk.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||jamborm at gcc dot gnu dot
   ||org
  Component|target  |tree-optimization
   Keywords||wrong-code
  Known to fail|4.5.1   |4.5.0 4.5.1
   Target Milestone|--- |4.5.1


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

[Bug c++/44827] g++4.3.4 segfaults when using boost::intrusive::list

[davek at gcc dot gnu dot org]

--- Comment #6 from davek at gcc dot gnu dot org  2010-07-11 12:56 ---
(In reply to comment #5)
> Program received signal SIGSEGV, Segmentation fault.
> 0x006f25bd in lvalue_p_1 (ref=0x70c4fb98) at
> ../../gcc-4.x/gcc/cp/tree.c:71
> 71if (TREE_CODE (TREE_TYPE (ref)) == REFERENCE_TYPE)
> 

  I don't even know what a one of these is:

(gdb) call debug_tree (ref)
 
VOID
align 1 symtab 0 alias set -1 canonical type 0x7ff7e580
pointer_to_this  reference_to_this
>

functions 
function >
arg 1 >>
binfo 
unit size 
align 32 symtab 0 alias set -1 canonical type 0x7fd1b1c0 fields

full-name "struct data_holder"
needs-constructor needs-destructor X() X(constX&) this=(X&)
n_parents=0 use_template=0 interface-unknown
pointer_to_this  chain >
private> access_binfo >
(gdb)

  This needs a C++ FE maintainer to take a look.


-- 

davek at gcc dot gnu dot org changed:

   What|Removed |Added

   Last reconfirmed|2010-07-05 23:26:24 |2010-07-11 12:56:24
   date||


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

[Bug c++/44909] New: Copy constructors implicitly deleted

[marc dot glisse at normalesup dot org]

The following code compiles fine in C++98 with any version of g++, compiles
fine in C++0X with g++-4.4, but fails in C++0X with g++-4.6 with the error
message:

bug.cc: In function ‘void ouin(const Ray&)’:
bug.cc:35:9: error: use of deleted function ‘Ray::Ray(const Ray&)’
bug.cc:28:8: error: ‘Ray::Ray(const Ray&)’ is implicitly deleted because the
default definition would be ill-formed:

I hope I didn't remove anything essential while reducing the example (started
with 500k lines...).

struct Coord
{
Coord();
Coord(const Coord&);
};

template
struct array
{
array();
_Tp _M_instance[1];
};

struct Ray;

struct Vector
{
array base;
Vector();
Vector(const Ray &) ;
};

struct Point
{
Vector base;
};

struct Ray
{
array base;
};

void ouin (Ray const& r1)
{
Ray r2=r1;
}


-- 
   Summary: Copy constructors implicitly deleted
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: marc dot glisse at normalesup dot org
  GCC host triplet: x86_64-unknown-linux-gnu


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

[Bug c++/44910] New: Incorrect template with C linkage errors

[alex at alex-smith dot me dot uk]

I have a x-compiler with a custom target for my hobby operating system. In the
x-compiler's installation directory sys-include is symlinked to the directory
in my OS's source tree containing all the userspace headers. Despite this my
build system was passing -I to G++.

When I removed that argument, I started getting "template with C linkage"
errors from C++ code. There were no differences between the preprocessed input
with and without that argument, except that the file/line number information
was different, which obviously shouldn't be causing that error.

>From comparing the two sets of preprocessed input, I have determined that the
following code will cause the errors:

# 1 "somefilename" 1 3 4
template  class Test {};

This code, however, compiles without issues:

# 1 "somefilename" 1
template  class Test {};

Both are compiled with "x86_64-kiwi-g++ -c -o testcase.o testcase.cc". The full
error that I receive with the first piece of code is:

In file included from testcase.cc:1:0:
somefilename:1:1: error: template with C linkage

GCC was configured with the following options:

../gcc-4.5.0/configure --prefix=/home/alex/bin/kiwi-cross/x86_64-kiwi
--target=x86_64-kiwi --enable-languages=c,c++ --disable-libstdcxx-pch
--disable-shared --enable-lto


-- 
   Summary: Incorrect template with C linkage errors
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: alex at alex-smith dot me dot uk
 GCC build triplet: x86_64-redhat-linux
  GCC host triplet: x86_64-redhat-linux
GCC target triplet: x86_64-kiwi


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

[Bug bootstrap/44433] [meta-bug] --enable-build-with-cxx issues

[dougsemler at gmail dot com]

--- Comment #3 from dougsemler at gmail dot com  2010-07-11 15:11 ---
Does anyone know if pr43538 affects this as well (cxx flags fir target
inheriting from cxxflags on Linux targets)?


-- 


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

[Bug target/44903] [4.6 Regression] FAIL: gcc.dg/pr35258.c execution test

[dave at hiauly1 dot hia dot nrc dot ca]

--- Comment #5 from dave at hiauly1 dot hia dot nrc dot ca  2010-07-11 
15:17 ---
Subject: Re:  [4.6 Regression] FAIL: gcc.dg/pr35258.c
execution test

On Sun, 11 Jul 2010, rguenth at gcc dot gnu dot org wrote:

> 
> 
> --- Comment #4 from rguenth at gcc dot gnu dot org  2010-07-11 10:47 
> ---
> (In reply to comment #3)
> > Subject: Re:  [4.6 Regression] FAIL: gcc.dg/pr35258.c
> > execution test
> > 
> > On Sat, 10 Jul 2010, rguenth at gcc dot gnu dot org wrote:
> > 
> > > I get for all memory accesses an alignment of 8 at expansion time which 
> > > looks
> > > correct (on i?86).  Please debug this a bit, 
> > > set_mem_attributes_minus_bitpos
> > > looks conservative enough.
> > 
> > The rtl in question is the following:
> > 
> > (insn 8 6 11 /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pr35258.c:16 (set 
> > (reg:SI
> > 28 %r28 [orig:94 D.1980 ] [94])
> >  (mem/c:SI (plus:SI (reg/f:SI 1 %r1 [95])
> >  (const_int 1 [0x1])) [0 MEM[(char * {ref-all})&str 
> > +
> > 1B]+0 S4 A8])) 37 {*pa.md:2102} (nil))
> > 
> > An alignment of 8 is not sufficient for a 4 byte (SImode) load on targets
> > that define STRICT_ALIGNMENT.  We need an alignment of 32.
> >
> > I believe the i?86 hardware allows unaligned addresses, so you wouldn't
> > see the problem.
> 
> Hm.  So the MEM_REF path goes the same way as the INDIRECT_REF path for
> 
> typedef int t __attribute__((aligned(1),may_alias));
> int foo(t *p)
> {
>   return *p;
> }
> int main()
> {
>   char c[5] = {};
>   if (foo(&c[1]) != 0)
> abort ();
>   return 0;
> }
> 
> for example on the 4.5 branch.  I see no provision to handle not properly
> aligned pointer dereferences in expansion.  So I believe this is a latent
> issue - but I am quite lost here in the myriads of RTL expansion (which
> isn't exactly a piece of GCC I am familiar with).

Yes, I don't believe that there ever was a general provision to handle
improperly aligned pointer dereferences in expansion.  However, I think
memcpy was special.

> But back to the above testcase.  On the 4.5 branch I get on i?86:
> 
> (insn 6 5 7 3 t.c:4 (set (reg:SI 58 [ D.1952 ])
> (mem:SI (reg/f:SI 60) [0 S4 A8])) -1 (nil))
> 
> (good), but with a cross to ia64-hp-hpux11.23 (I happened to have that around)
> 
> (insn 7 6 8 3 t.c:4 (set (reg/f:DI 341)
> (unspec:DI [
> (reg:SI 342)
> ] 24)) -1 (nil))
> 
> (insn 8 7 9 3 t.c:4 (set (reg:SI 339 [ D.2007 ])
> (mem:SI (reg/f:DI 341) [0 S4 A32])) -1 (nil))
> 
> thus an alignment of 32!?  A nice way of "fixing" ;)
> 
> I am curious if the above testcase works for you on the 4.5 branch (or
> for any version).

The test always passed before.  I've attached the .expand file generated using
the 4.5 branch (32-bit) for comparison.

Dave


--- Comment #6 from dave at hiauly1 dot hia dot nrc dot ca  2010-07-11 
15:17 ---
Created an attachment (id=21179)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21179&action=view)


-- 


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

[Bug c++/44910] Incorrect template with C linkage errors

[jakub at gcc dot gnu dot org]

--- Comment #1 from jakub at gcc dot gnu dot org  2010-07-11 15:32 ---
That means the configuration of your hobby target doesn't define
NO_IMPLICIT_EXTERN_C and thus all system headers are considered to be
implicitly surrounded by extern "C".


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug fortran/44773] [4.6 Regression] Unnecessary temporaries increase the runtime for channel.f90 by ~70%

[pault at gcc dot gnu dot org]

--- Comment #19 from pault at gcc dot gnu dot org  2010-07-11 16:07 ---
Subject: Bug 44773

Author: pault
Date: Sun Jul 11 16:06:53 2010
New Revision: 162059

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162059
Log:
2010-07-11  Paul Thomas  

PR fortran/44773
* trans-expr.c (arrayfunc_assign_needs_temporary): No temporary
if the lhs has never been host associated, as well as not being
use associated, a pointer or a target.
* resolve.c (resolve_variable): Mark variables that are host
associated.
* gfortran.h: Add the host_assoc bit to the symbol_attribute
structure.


Modified:
branches/gcc-4_5-branch/gcc/fortran/ChangeLog
branches/gcc-4_5-branch/gcc/fortran/gfortran.h
branches/gcc-4_5-branch/gcc/fortran/resolve.c
branches/gcc-4_5-branch/gcc/fortran/trans-expr.c


-- 


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

[Bug target/44911] New: [4.6 Regression] line breaks in asm comments break assembly with -fverbose-asm

[zsojka at seznam dot cz]

Command line:
$ gcc -O1 -fverbose-asm testcase.c

Compiler output:
$ /mnt/svn/gcc-trunk/binary-162056-lto-fortran-checking-yes-rtl-df/bin/gcc -O1
-fverbose-asm -c testcase.c 
/tmp/ccfCayS2.s: Assembler messages:
/tmp/ccfCayS2.s:48: Error: junk at end of line, first unrecognized character is
`{'
/tmp/ccfCayS2.s:49: Error: no such instruction: `char c[4]'
/tmp/ccfCayS2.s:50: Error: junk at end of line, first unrecognized character is
`}'

The broken assembly looks like:
.L2:
movb%dl, (%rax) # c, MEM[(union 
{
  char c[4];
} *)D.2728_11]
addq$1, %rax#, ivtmp.3
jmp .L2 #

Tested revisions:
r162056 - fail
r161659 - OK
4.4.4, 4.5.0 - OK


-- 
   Summary: [4.6 Regression] line breaks in asm comments break
assembly with -fverbose-asm
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
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=44911

[Bug target/44911] [4.6 Regression] line breaks in asm comments break assembly with -fverbose-asm

[zsojka at seznam dot cz]

--- Comment #1 from zsojka at seznam dot cz  2010-07-11 16:16 ---
Created an attachment (id=21180)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21180&action=view)
reduced testcase

$ gcc -O1 -fverbose-asm -c pr44911.c


-- 


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

[Bug target/44903] [4.6 Regression] FAIL: gcc.dg/pr35258.c execution test

[rguenth at gcc dot gnu dot org]

--- Comment #7 from rguenth at gcc dot gnu dot org  2010-07-11 16:23 ---
(In reply to comment #5)
> Subject: Re:  [4.6 Regression] FAIL: gcc.dg/pr35258.c
> execution test
> 
> On Sun, 11 Jul 2010, rguenth at gcc dot gnu dot org wrote:
> 
> > 
> > 
> > --- Comment #4 from rguenth at gcc dot gnu dot org  2010-07-11 10:47 
> > ---
> > (In reply to comment #3)
> > > Subject: Re:  [4.6 Regression] FAIL: gcc.dg/pr35258.c
> > > execution test
> > > 
> > > On Sat, 10 Jul 2010, rguenth at gcc dot gnu dot org wrote:
> > > 
> > > > I get for all memory accesses an alignment of 8 at expansion time which 
> > > > looks
> > > > correct (on i?86).  Please debug this a bit, 
> > > > set_mem_attributes_minus_bitpos
> > > > looks conservative enough.
> > > 
> > > The rtl in question is the following:
> > > 
> > > (insn 8 6 11 /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pr35258.c:16 (set 
> > > (reg:SI
> > > 28 %r28 [orig:94 D.1980 ] [94])
> > >  (mem/c:SI (plus:SI (reg/f:SI 1 %r1 [95])
> > >  (const_int 1 [0x1])) [0 MEM[(char * 
> > > {ref-all})&str +
> > > 1B]+0 S4 A8])) 37 {*pa.md:2102} (nil))
> > > 
> > > An alignment of 8 is not sufficient for a 4 byte (SImode) load on targets
> > > that define STRICT_ALIGNMENT.  We need an alignment of 32.
> > >
> > > I believe the i?86 hardware allows unaligned addresses, so you wouldn't
> > > see the problem.
> > 
> > Hm.  So the MEM_REF path goes the same way as the INDIRECT_REF path for
> > 
> > typedef int t __attribute__((aligned(1),may_alias));
> > int foo(t *p)
> > {
> >   return *p;
> > }
> > int main()
> > {
> >   char c[5] = {};
> >   if (foo(&c[1]) != 0)
> > abort ();
> >   return 0;
> > }
> > 
> > for example on the 4.5 branch.  I see no provision to handle not properly
> > aligned pointer dereferences in expansion.  So I believe this is a latent
> > issue - but I am quite lost here in the myriads of RTL expansion (which
> > isn't exactly a piece of GCC I am familiar with).
> 
> Yes, I don't believe that there ever was a general provision to handle
> improperly aligned pointer dereferences in expansion.  However, I think
> memcpy was special.

In the above case the int type the pointer points to is specified as
being unaligned, so the testcase is valid.

> > But back to the above testcase.  On the 4.5 branch I get on i?86:
> > 
> > (insn 6 5 7 3 t.c:4 (set (reg:SI 58 [ D.1952 ])
> > (mem:SI (reg/f:SI 60) [0 S4 A8])) -1 (nil))
> > 
> > (good), but with a cross to ia64-hp-hpux11.23 (I happened to have that 
> > around)
> > 
> > (insn 7 6 8 3 t.c:4 (set (reg/f:DI 341)
> > (unspec:DI [
> > (reg:SI 342)
> > ] 24)) -1 (nil))
> > 
> > (insn 8 7 9 3 t.c:4 (set (reg:SI 339 [ D.2007 ])
> > (mem:SI (reg/f:DI 341) [0 S4 A32])) -1 (nil))
> > 
> > thus an alignment of 32!?  A nice way of "fixing" ;)
> > 
> > I am curious if the above testcase works for you on the 4.5 branch (or
> > for any version).
> 
> The test always passed before.  I've attached the .expand file generated using
> the 4.5 branch (32-bit) for comparison.

The above testcase worked?  Not the pr35258.c, but the one I gave, with
the int aligned(1)?  The difference on the 4.5 branch is that we left the
memcpy call alone and did not inline-expand it on the tree level.

I am trying to say that we hit a latent bug here, and that it's finally time
to fix it (but I don't easily see how to do that in the most efficient way).

> Dave


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|WAITING |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-07-11 16:23:49
   date||


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

[Bug middle-end/44911] [4.6 Regression] line breaks in asm comments break assembly with -fverbose-asm

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2010-07-11 16:30 ---
Confirmed.  Mine.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rguenth at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
  Component|target  |middle-end
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-07-11 16:30:49
   date||
   Target Milestone|--- |4.6.0


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

[Bug target/44903] [4.6 Regression] FAIL: gcc.dg/pr35258.c execution test

[danglin at gcc dot gnu dot org]

--- Comment #8 from danglin at gcc dot gnu dot org  2010-07-11 16:33 ---
With 4.5, the block move was emitted as follows:

Breakpoint 2, emit_block_move_hints (x=0x7afcb550, y=0x7afcb630, 
size=0x7af312d8, method=BLOCK_OP_NORMAL, expected_align=64, 
expected_size=-1) at ../../gcc/gcc/expr.c:1170
1170  rtx retval = 0;
(gdb) bt
#0  emit_block_move_hints (x=0x7afcb550, y=0x7afcb630, size=0x7af312d8, 
method=BLOCK_OP_NORMAL, expected_align=64, expected_size=-1)
at ../../gcc/gcc/expr.c:1170
#1  0x002d5e8c in expand_builtin_memcpy (exp=0x7afaae10, target=0x7af312b8)
at ../../gcc/gcc/builtins.c:3326
#2  0x002dc884 in expand_builtin (exp=0x7afaae10, target=0x7af312b8, 
subtarget=0x0, mode=VOIDmode, ignore=1) at ../../gcc/gcc/builtins.c:5972
#3  0x004d0cbc in expand_expr_real_1 (exp=0x7afaae10, target=0x0, 
tmode=VOIDmode, modifier=EXPAND_NORMAL, alt_rtl=0x0)
at ../../gcc/gcc/expr.c:9262
#4  0x00e043dc in expand_call_stmt (stmt=0x7af299c0)
at ../../gcc/gcc/cfgexpand.c:1789
#5  0x00e045cc in expand_gimple_stmt_1 (stmt=0x7af299c0)
at ../../gcc/gcc/cfgexpand.c:1822
#6  0x00e04bfc in expand_gimple_stmt (stmt=0x7af299c0)
at ../../gcc/gcc/cfgexpand.c:1978
#7  0x00e09348 in expand_gimple_basic_block (bb=0x7afcc240)
at ../../gcc/gcc/cfgexpand.c:3401
#8  0x00e0ab3c in gimple_expand_cfg () at ../../gcc/gcc/cfgexpand.c:3851
#9  0x0077b644 in execute_one_pass (pass=0x4003c990)
at ../../gcc/gcc/passes.c:1568
#10 0x0077b928 in execute_pass_list (pass=0x4003c990)
at ../../gcc/gcc/passes.c:1623
#11 0x016891fc in tree_rest_of_compilation (fndecl=0x7afa4900)
at ../../gcc/gcc/tree-optimize.c:413
#12 0x00bd40f8 in cgraph_expand_function (node=0x7afb3000)
at ../../gcc/gcc/cgraphunit.c:1574
#13 0x00bd4460 in cgraph_expand_all_functions ()
at ../../gcc/gcc/cgraphunit.c:1653
#14 0x00bd4ea4 in cgraph_optimize () at ../../gcc/gcc/cgraphunit.c:1909
#15 0x00bd2cc4 in cgraph_finalize_compilation_unit ()
at ../../gcc/gcc/cgraphunit.c:1122
#16 0x000a8524 in c_write_global_declarations ()
at ../../gcc/gcc/c-decl.c:9519
#17 0x0087a810 in compile_file () at ../../gcc/gcc/toplev.c:1065
#18 0x0087ddb4 in do_compile () at ../../gcc/gcc/toplev.c:2417
#19 0x0087df34 in toplev_main (argc=17, argv=0x7eff05bc)
at ../../gcc/gcc/toplev.c:2459
#20 0x00252d94 in main (argc=17, argv=0x7eff05bc) at ../../gcc/gcc/main.c:35


-- 


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

[Bug target/44903] [4.6 Regression] FAIL: gcc.dg/pr35258.c execution test

[dave at hiauly1 dot hia dot nrc dot ca]

--- Comment #9 from dave at hiauly1 dot hia dot nrc dot ca  2010-07-11 
16:54 ---
Subject: Re:  [4.6 Regression] FAIL: gcc.dg/pr35258.c execution test

> The above testcase worked?  Not the pr35258.c, but the one I gave, with
> the int aligned(1)?  The difference on the 4.5 branch is that we left the
> memcpy call alone and did not inline-expand it on the tree level.

The above testcase doesn't work with 4.5 and I doubt it ever worked on
PA.  The pointer passed to foo is used as is.  It's only the memcpy special
case that is handled by 4.5 and earlier.

> I am trying to say that we hit a latent bug here, and that it's finally time
> to fix it (but I don't easily see how to do that in the most efficient way).

Dave


-- 


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

[Bug fortran/44912] New: [OOP] Segmentation fault on TBP

[bdsatish at gmail dot com]

Reported by Satish.BD at http://gcc.gnu.org/ml/fortran/2010-07/msg00109.html

The shown (cf. URL) program compiles without any errors, but segfaults at
run time.

It seems that the call to 'get_coefficients' is what produces the segfault.


-- 
   Summary: [OOP] Segmentation fault on TBP
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bdsatish at gmail dot com


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

[Bug middle-end/44911] [4.6 Regression] line breaks in asm comments break assembly with -fverbose-asm

[zsojka at seznam dot cz]

--- Comment #3 from zsojka at seznam dot cz  2010-07-11 17:40 ---
This might be related:

$ gcc testsuite/gcc.dg/debug/pr33316.c -O1 -fverbose-asm
gcc: internal compiler error: Segmentation fault (program cc1)
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Backtrace is:
(gdb) bt
#0  0x007c7bd5 in pp_base_string (pp=0x1640820, str=0x103f2f9 "struct
")
at /mnt/svn/gcc-trunk/gcc/pretty-print.c:785
#1  0x0090b346 in dump_generic_node (buffer=0x1640820,
node=0x77ef5a10, spc=0, flags=0, is_stmt=0 '\000')
at /mnt/svn/gcc-trunk/gcc/tree-pretty-print.c:1129
#2  0x00905b8e in dump_generic_node (buffer=0x1640820,
node=0x75a9f540, spc=0, flags=0, is_stmt=0 '\000')
at /mnt/svn/gcc-trunk/gcc/tree-pretty-print.c:938
#3  0x0090b35b in dump_generic_node (buffer=0x1640820,
node=0x77ef5a10, spc=0, flags=0, is_stmt=0 '\000')
at /mnt/svn/gcc-trunk/gcc/tree-pretty-print.c:1132
#4  0x00905b8e in dump_generic_node (buffer=0x1640820,
node=0x75a9f540, spc=0, flags=0, is_stmt=0 '\000')
at /mnt/svn/gcc-trunk/gcc/tree-pretty-print.c:938
#5  0x0090b35b in dump_generic_node (buffer=0x1640820,
node=0x77ef5a10, spc=0, flags=0, is_stmt=0 '\000')
at /mnt/svn/gcc-trunk/gcc/tree-pretty-print.c:1132
...
#30815 0x00905b8e in dump_generic_node (buffer=0x1640820,
node=0x75a9f540, spc=0, flags=0, is_stmt=0 '\000') at
/mnt/svn/gcc-trunk/gcc/tree-pretty-print.c:938
#30816 0x00905a10 in dump_generic_node (buffer=0x1640820,
node=0x75a9f5e8, spc=0, flags=0, is_stmt=0 '\000') at
/mnt/svn/gcc-trunk/gcc/tree-pretty-print.c:770
#30817 0x00905f51 in dump_generic_node (buffer=0x1640820,
node=0x77ff9930, spc=0, flags=0, is_stmt=0 '\000') at
/mnt/svn/gcc-trunk/gcc/tree-pretty-print.c:830
#30818 0x00906db2 in dump_generic_node (buffer=0x1640820,
node=0x77edc100, spc=0, flags=0, is_stmt=0 '\000') at
/mnt/svn/gcc-trunk/gcc/tree-pretty-print.c:1177
#30819 0x0068fb6a in output_asm_operand_names (operands=0x1624ca0,
oporder=, nops=2) at /mnt/svn/gcc-trunk/gcc/final.c:3186
#30820 0x006945ff in output_asm_insn (templ=,
operands=0x1624ca0) at /mnt/svn/gcc-trunk/gcc/final.c:3411
#30821 output_asm_insn (templ=, operands=0x1624ca0) at
/mnt/svn/gcc-trunk/gcc/final.c:3212
#30822 0x00695adb in final_scan_insn (insn=0x75aa1900,
file=0x168cb20, optimize=, nopeepholes=, seen=) at /mnt/svn/gcc-trunk/gcc/final.c:2682
#30823 0x0069746e in final (first=0x77edc400, file=0x168cb20,
optimize=1) at /mnt/svn/gcc-trunk/gcc/final.c:1720
#30824 0x006976b9 in rest_of_handle_final () at
/mnt/svn/gcc-trunk/gcc/final.c:4244
#30825 0x007b813e in execute_one_pass (pass=0x151a800) at
/mnt/svn/gcc-trunk/gcc/passes.c:1565
#30826 0x007b83d5 in execute_pass_list (pass=0x151a800) at
/mnt/svn/gcc-trunk/gcc/passes.c:1620
#30827 0x007b83e7 in execute_pass_list (pass=0x151b3a0) at
/mnt/svn/gcc-trunk/gcc/passes.c:1621
#30828 0x007b83e7 in execute_pass_list (pass=0x151b400) at
/mnt/svn/gcc-trunk/gcc/passes.c:1621
#30829 0x008f8416 in tree_rest_of_compilation (fndecl=0x75aba000)
at /mnt/svn/gcc-trunk/gcc/tree-optimize.c:421
#30830 0x00aad196 in cgraph_expand_function (node=0x75abf000) at
/mnt/svn/gcc-trunk/gcc/cgraphunit.c:1629
#30831 0x00aaffba in cgraph_expand_all_functions () at
/mnt/svn/gcc-trunk/gcc/cgraphunit.c:1708
#30832 cgraph_optimize () at /mnt/svn/gcc-trunk/gcc/cgraphunit.c:1964
#30833 0x00ab05ab in cgraph_finalize_compilation_unit () at
/mnt/svn/gcc-trunk/gcc/cgraphunit.c:1171
#30834 0x004df2d3 in c_write_global_declarations () at
/mnt/svn/gcc-trunk/gcc/c-decl.c:9698
#30835 0x008a41e6 in compile_file (argc=4, argv=0x7fffdeb8) at
/mnt/svn/gcc-trunk/gcc/toplev.c:997
#30836 do_compile (argc=4, argv=0x7fffdeb8) at
/mnt/svn/gcc-trunk/gcc/toplev.c:2340
#30837 toplev_main (argc=4, argv=0x7fffdeb8) at
/mnt/svn/gcc-trunk/gcc/toplev.c:2381
#30838 0x76365bbd in __libc_start_main () from /lib/libc.so.6
#30839 0x004c6dad in _start ()


-- 


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

[Bug fortran/44596] [OOP] Dynamic dispatch uses broken types

[pault at gcc dot gnu dot org]

--- Comment #20 from pault at gcc dot gnu dot org  2010-07-11 17:45 ---
(In reply to comment #19)
> Subject: Re:  [OOP] Dynamic dispatch uses broken types
> 
> Dear Tobias,
> 
> > Paul, thanks for the check in. Do you plan to backport it to 4.5, which 
> > sems to
> > use the same code?

When I add the vtype attribute and the above patch, almost every OOP test fails
with, for example:

/svn/gcc-4_5-branch/gcc/testsuite/gfortran.dg/class_6.f03:7:0: internal
compiler error: in gimplify_expr, at gimplify.c:7346
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

I think that, since we do not need this (yet!), I am disinclined to spend any
more time on it, unless Richard understands what is happening.

Paul


-- 


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

[Bug rtl-optimization/39837] [4.3/4.4/4.5 regression] extra spills due to RTL LICM

[sandra at codesourcery dot com]

--- Comment #14 from sandra at codesourcery dot com  2010-07-11 17:47 
---
Yes, it looks like the prototype fix for PR 36758 fixes the test case at the
top of this issue.  The patch needs a little updating, though, and I can't say
I grok the changes to the surrounding code sufficiently to be sure I've gotten
it right.  


-- 


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

[Bug tree-optimization/44913] New: [4.6 Regression] -ftree-vectorize causes FAIL: gcc.dg/pr44838.c execution test

[zsojka at seznam dot cz]

Command line:
$ gcc -O[123] -ftree-vectorize gcc.dg/pr44838.c && ./a.out

Output:
$ /mnt/svn/gcc-trunk/binary-162056-lto-fortran-checking-yes-rtl-df/bin/gcc -O1
-ftree-vectorize pr44838.i
$ ./a.out 
Aborted

Tested revisions:
r162056 - fail
r161659 - fail
r161170 - OK


-- 
   Summary: [4.6 Regression] -ftree-vectorize causes FAIL:
gcc.dg/pr44838.c execution test
   Product: gcc
   Version: 4.6.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=44913

[Bug fortran/44697] I/O testsuite failures: \r\n vs \n - gfortran.dg/ftell_3.f90

[jvdelisle at gcc dot gnu dot org]

--- Comment #2 from jvdelisle at gcc dot gnu dot org  2010-07-11 20:30 
---
I will commit a similar patch, but I would like to add a check for the specific
line ends to make sure we don't get a NULL character inserted some day.


-- 

jvdelisle at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jvdelisle at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-07-11 20:30:42
   date||


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

[Bug fortran/44698] I/O: FLUSH does not actually flush the buffer?

[jvdelisle at gcc dot gnu dot org]

--- Comment #8 from jvdelisle at gcc dot gnu dot org  2010-07-11 20:43 
---
Subject: Bug 44698

Author: jvdelisle
Date: Sun Jul 11 20:43:25 2010
New Revision: 162060

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162060
Log:
2010-07-11  Kai Tietz  

PR libfortran/44698
* io/unix.c (flush_buf): Add _commit for WIN32.

Modified:
trunk/libgfortran/ChangeLog
trunk/libgfortran/io/unix.c


-- 


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

[Bug fortran/44698] I/O: FLUSH does not actually flush the buffer?

[jvdelisle at gcc dot gnu dot org]

--- Comment #9 from jvdelisle at gcc dot gnu dot org  2010-07-11 20:52 
---
Closing


-- 

jvdelisle at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug tree-optimization/44900] [4.5 Regression] The variable of SSE will be broken

[hjl dot tools at gmail dot com]

--- Comment #7 from hjl dot tools at gmail dot com  2010-07-11 20:59 ---
It works with gcc 4.5.0.  It is a 4.5.1 regression.


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

  Known to fail|4.5.0 4.5.1 |4.5.1
  Known to work|4.6.0 4.4.4 |4.6.0 4.4.4 4.5.0


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

[Bug fortran/44702] ISO_C_BINDING does not allow multiple "USE, ONLY" local names.

[burnus at gcc dot gnu dot org]

--- Comment #3 from burnus at gcc dot gnu dot org  2010-07-11 21:29 ---
Subject: Bug 44702

Author: burnus
Date: Sun Jul 11 21:29:30 2010
New Revision: 162061

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162061
Log:
t...@archimedes:~/scratch/gcc> head -n 15 ../intrinsic_use.diff
2010-07-11  Tobias Burnus  

PR fortran/44702
* module.c (sort_iso_c_rename_list): Remove.
(import_iso_c_binding_module,use_iso_fortran_env_module):
Allow multiple imports of the same symbol.

2010-07-11  Tobias Burnus  

PR fortran/44702
* gfortran.dg/use_rename_6.f90: New.
* gfortran.dg/use_iso_c_binding.f90: Update dg-error.


Added:
trunk/gcc/testsuite/gfortran.dg/use_rename_6.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/module.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/use_iso_c_binding.f90


-- 


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

[Bug fortran/44702] ISO_C_BINDING does not allow multiple "USE, ONLY" local names.

[burnus at gcc dot gnu dot org]

--- Comment #4 from burnus at gcc dot gnu dot org  2010-07-11 21:48 ---
FIXED on the trunk (4.6).

Thanks for the bug report!


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug tree-optimization/44913] [4.6 Regression] -ftree-vectorize causes FAIL: gcc.dg/pr44838.c execution test

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords||wrong-code
   Target Milestone|--- |4.6.0


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

[Bug tree-optimization/44900] [4.5 Regression] The variable of SSE will be broken

[rguenth at gcc dot gnu dot org]

--- Comment #8 from rguenth at gcc dot gnu dot org  2010-07-11 21:59 ---
Hm?  I checked 4.5.0 and it was broken as well, so someone should double-check
(I can't at the moment).


-- 


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

[Bug target/44903] [4.6 Regression] FAIL: gcc.dg/pr35258.c execution test

[rguenth at gcc dot gnu dot org]

--- Comment #10 from rguenth at gcc dot gnu dot org  2010-07-11 22:04 
---
(In reply to comment #9)
> Subject: Re:  [4.6 Regression] FAIL: gcc.dg/pr35258.c execution test
> 
> > The above testcase worked?  Not the pr35258.c, but the one I gave, with
> > the int aligned(1)?  The difference on the 4.5 branch is that we left the
> > memcpy call alone and did not inline-expand it on the tree level.
> 
> The above testcase doesn't work with 4.5 and I doubt it ever worked on
> PA.  The pointer passed to foo is used as is.  It's only the memcpy special
> case that is handled by 4.5 and earlier.

On i?86 we get correct 1-byte alignment for the pointer access while on
my ia64-cross the MEM has 4-byte alignment which is wrong.  t is properly
1-byte aligned (and pointer-to packed structs for example will work only
because there's a handled_component_ref around the pointer dereference).

> > I am trying to say that we hit a latent bug here, and that it's finally time
> > to fix it (but I don't easily see how to do that in the most efficient way).
> 
> Dave
> 


-- 


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

[Bug target/44903] [4.6 Regression] FAIL: gcc.dg/pr35258.c execution test

[dave at hiauly1 dot hia dot nrc dot ca]

--- Comment #11 from dave at hiauly1 dot hia dot nrc dot ca  2010-07-11 
22:22 ---
Subject: Re:  [4.6 Regression] FAIL: gcc.dg/pr35258.c execution test

> > The above testcase doesn't work with 4.5 and I doubt it ever worked on
> > PA.  The pointer passed to foo is used as is.  It's only the memcpy special
> > case that is handled by 4.5 and earlier.
> 
> On i?86 we get correct 1-byte alignment for the pointer access while on
> my ia64-cross the MEM has 4-byte alignment which is wrong.  t is properly
> 1-byte aligned (and pointer-to packed structs for example will work only
> because there's a handled_component_ref around the pointer dereference).

On hppa64, I see

(insn 7 6 8 3 xxx.c:3 (set (reg:SI 71)
(mem:SI (reg/v/f:DI 69 [ p ]) [0 *p_1(D)+0 S4 A32])) -1 (nil))

in expand.  The alignment is passed into the move expander.

Dave


-- 


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

[Bug target/44903] [4.6 Regression] FAIL: gcc.dg/pr35258.c execution test

[rguenth at gcc dot gnu dot org]

--- Comment #12 from rguenth at gcc dot gnu dot org  2010-07-11 22:37 
---
(In reply to comment #11)
> Subject: Re:  [4.6 Regression] FAIL: gcc.dg/pr35258.c execution test
> 
> > > The above testcase doesn't work with 4.5 and I doubt it ever worked on
> > > PA.  The pointer passed to foo is used as is.  It's only the memcpy 
> > > special
> > > case that is handled by 4.5 and earlier.
> > 
> > On i?86 we get correct 1-byte alignment for the pointer access while on
> > my ia64-cross the MEM has 4-byte alignment which is wrong.  t is properly
> > 1-byte aligned (and pointer-to packed structs for example will work only
> > because there's a handled_component_ref around the pointer dereference).
> 
> On hppa64, I see
> 
> (insn 7 6 8 3 xxx.c:3 (set (reg:SI 71)
> (mem:SI (reg/v/f:DI 69 [ p ]) [0 *p_1(D)+0 S4 A32])) -1 (nil))
> 
> in expand.  The alignment is passed into the move expander.

For reference, on i?86 I see (on the 4.5 branch):

(insn 6 5 7 3 t.c:3 (set (reg:SI 62)
(mem:SI (reg/v/f:DI 60 [ p ]) [0 S4 A8])) -1 (nil))

and on trunk:

(insn 6 5 7 3 t.c:3 (set (reg:SI 62)
(mem:SI (reg/v/f:DI 60 [ p ]) [0 *p_1(D)+0 S4 A8])) -1 (nil))

Richard.


-- 


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

[Bug tree-optimization/44900] [4.5 Regression] The variable of SSE will be broken

[pinskia at gcc dot gnu dot org]

--- Comment #9 from pinskia at gcc dot gnu dot org  2010-07-11 22:47 ---
Works with:
GNU C++ (GCC) version 4.5.0 20100401 (experimental) [trunk revision 157933]
(x86_64-unknown-linux-gnu)
compiled by GNU C version 4.5.0 20100401 (experimental) [trunk revision
157933], GMP version 4.3.2, MPFR version 2.4.2, MPC version 0.8.1

Which is before the branch of 4.5.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to fail|4.5.1   |
  Known to work|4.6.0 4.4.4 4.5.0   |4.6.0 4.4.4


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

[Bug rtl-optimization/39837] [4.3/4.4/4.5 regression] extra spills due to RTL LICM

[steven at gcc dot gnu dot org]

--- Comment #15 from steven at gcc dot gnu dot org  2010-07-11 22:48 ---
Well, it's probably worth trying a little harder to grok them, then. Zdenek has
already said that the fix looks OK in principle, but I am not interested at all
in working on this patch anymore (especially not when others with an interest
in the patch get paid for caring :-).


-- 


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

[Bug tree-optimization/44914] New: [4.6 Regression] ICE: in calc_dfs_tree, at dominance.c:395 with -fipa-sra -fnon-call-exceptions

[zsojka at seznam dot cz]

Command line:
$ gcc -O[123s] -fipa-sra -fnon-call-exceptions testcase.C

Compiler output:
$ gcc -O1 -fipa-sra -fnon-call-exceptions testcase.C 
testcase.C: In function 'B::B(int)':
testcase.C:17:4: internal compiler error: in calc_dfs_tree, at dominance.c:396
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Tested revisions:
r162056 - crash
r161170 - crash
r159696 - OK
r158969 - OK
4.5 r160526 - OK


-- 
   Summary: [4.6 Regression] ICE: in calc_dfs_tree, at
dominance.c:395 with -fipa-sra -fnon-call-exceptions
   Product: gcc
   Version: 4.6.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=44914

[Bug rtl-optimization/39837] [4.3/4.4/4.5 regression] extra spills due to RTL LICM

[steven at gcc dot gnu dot org]

--- Comment #16 from steven at gcc dot gnu dot org  2010-07-11 22:55 ---
Brief explanation about what the patch does:

* have a pointer to the location of the invariant within an rtx. The existing
code assumes a complete RHS is invariant, but with the patch GCC can move
invariants out of the RHS of a SET even if the whole RHS itself is not
invariant.

* Do not bail out in find_invariant_insn if the complete RHS is not invariant.
Instead see if there is an address (i.e. XEXP (MEM, 0)) that is invariant.

* Update invariant motion code to handle partially invariant RHSs


One TODO for the patch (IIRC) is to only move an invariant address if it would
otherwise be moved anyway. That is, only move the invariant address if there is
a dependent invariant that would cause the address to be hoisted anyway. This
is to avoid excessive LICM.


-- 


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

[Bug tree-optimization/44914] [4.6 Regression] ICE: in calc_dfs_tree, at dominance.c:395 with -fipa-sra -fnon-call-exceptions

[zsojka at seznam dot cz]

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

Command line:
$ gcc -O1 -fipa-sra -fnon-call-exceptions pr44914.C


-- 


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

[Bug tree-optimization/44914] [4.6 Regression] ICE: in calc_dfs_tree, at dominance.c:395 with -fipa-sra -fnon-call-exceptions

[steven at gcc dot gnu dot org]

--- Comment #2 from steven at gcc dot gnu dot org  2010-07-11 22:56 ---
Martin, SRA related => yours?


-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||jamborm at gcc dot gnu dot
   ||org


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

[Bug middle-end/44911] [4.6 Regression] line breaks in asm comments break assembly with -fverbose-asm

[steven at gcc dot gnu dot org]

--- Comment #4 from steven at gcc dot gnu dot org  2010-07-11 22:58 ---
Add TDF_SLIM?


-- 


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

[Bug tree-optimization/44900] [4.5 Regression] The variable of SSE will be broken

[yottui at yahoo dot co dot jp]

--- Comment #10 from yottui at yahoo dot co dot jp  2010-07-11 23:11 ---
Please use '-m32' if host is x64.


-- 


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

[Bug tree-optimization/44913] [4.6 Regression] -ftree-vectorize causes FAIL: gcc.dg/pr44838.c execution test

[hjl dot tools at gmail dot com]

--- Comment #1 from hjl dot tools at gmail dot com  2010-07-11 23:11 ---
This is caused by revision 161655:

http://gcc.gnu.org/ml/gcc-cvs/2010-07/msg6.html


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

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


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

[Bug tree-optimization/44900] [4.5 Regression] The variable of SSE will be broken

[hjl dot tools at gmail dot com]

--- Comment #11 from hjl dot tools at gmail dot com  2010-07-11 23:35 
---
It is very likely caused by revision 158826:

http://gcc.gnu.org/ml/gcc-cvs/2010-04/msg00933.html

I will verify it and find out which checkin on trunk
fixes/hides this bug.


-- 


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

[Bug middle-end/44824] [4.6 regression] internal compiler error: verify_stmts failed

[davek at gcc dot gnu dot org]

--- Comment #11 from davek at gcc dot gnu dot org  2010-07-12 00:14 ---
(In reply to comment #10)
> (In reply to comment #2)
> > I can't reproduce it with r161865. (on x86_64-linux with -m32)
> > 
> 
> please confirm that this error introduces from -O1? surely, it would not be
> reproducible just giving -m32 as you says.
> 
> failed in gcc with target i686-pc-mingw32 again...

Confirmed with Attachment 21112 at -O1 on i686-pc-cygwin at r.161958 


-- 

davek 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-07-12 00:14:46
   date||


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

[Bug middle-end/44824] [4.6 regression] internal compiler error: verify_stmts failed

[jojelino at gmail dot com]

--- Comment #12 from jojelino at gmail dot com  2010-07-12 00:43 ---
reduced testcase


 typedef struct _object {
 int ob_refcnt; struct _typeobject *ob_type;
} PyObject;
typedef struct bufferinfo {
 void *buf;
 PyObject *obj;
int len;
int itemsize;

int readonly;
int ndim;
char *format;
int *shape;
int *strides;
int *suboffsets;
void *internal;
} Py_buffer;
typedef PyObject * (*unaryfunc)(PyObject *);
typedef PyObject * (*binaryfunc)(PyObject *, PyObject *);
typedef PyObject * (*ternaryfunc)(PyObject *, PyObject *, PyObject *);
typedef int (*inquiry)(PyObject *);
typedef int (*lenfunc)(PyObject *);
typedef int (*coercion)(PyObject **, PyObject **);
typedef PyObject *(*intargfunc)(PyObject *, int)
__attribute__((__deprecated__));
typedef PyObject *(*intintargfunc)(PyObject *, int, int)
__attribute__((__deprecated__));
typedef PyObject *(*ssizeargfunc)(PyObject *, int);
typedef PyObject *(*ssizessizeargfunc)(PyObject *, int, int);
typedef int(*intobjargproc)(PyObject *, int, PyObject *);
typedef int(*intintobjargproc)(PyObject *, int, int, PyObject *);
typedef int(*ssizeobjargproc)(PyObject *, int, PyObject *);
typedef int(*ssizessizeobjargproc)(PyObject *, int, int, PyObject *);
typedef int(*objobjargproc)(PyObject *, PyObject *, PyObject *);
typedef int (*objobjproc)(PyObject *, PyObject *);
typedef int (*readbufferproc)(PyObject *, int, void **);
typedef int (*writebufferproc)(PyObject *, int, void **);
typedef int (*segcountproc)(PyObject *, int *);
typedef int (*charbufferproc)(PyObject *, int, char **);
typedef int (*getbufferproc)(PyObject *, Py_buffer *, int);
typedef void (*releasebufferproc)(PyObject *, Py_buffer *);
typedef int (*visitproc)(PyObject *, void *);
typedef int (*traverseproc)(PyObject *, visitproc, void *);
typedef struct {
 lenfunc sq_length;
 binaryfunc sq_concat;
 ssizeargfunc sq_repeat;
 ssizeargfunc sq_item;
 ssizessizeargfunc sq_slice;
 ssizeobjargproc sq_ass_item;
 ssizessizeobjargproc sq_ass_slice;
 objobjproc sq_contains;

 binaryfunc sq_inplace_concat;
 ssizeargfunc sq_inplace_repeat;
} PySequenceMethods;
typedef struct {
 lenfunc mp_length;
 binaryfunc mp_subscript;
 objobjargproc mp_ass_subscript;
} PyMappingMethods;

typedef struct {
 readbufferproc bf_getreadbuffer;
 writebufferproc bf_getwritebuffer;
 segcountproc bf_getsegcount;
 charbufferproc bf_getcharbuffer;
getbufferproc bf_getbuffer;
 releasebufferproc bf_releasebuffer;
} PyBufferProcs;

typedef struct {
# 226
"/usr/lib/gcc/i686-pc-cygwin/4.6.0/../../../../i686-pc-cygwin/include/python2.6/object.h"
3
 binaryfunc nb_add;
 binaryfunc nb_subtract;
 binaryfunc nb_multiply;
 binaryfunc nb_divide;
 binaryfunc nb_remainder;
 binaryfunc nb_divmod;
 ternaryfunc nb_power;
 unaryfunc nb_negative;
 unaryfunc nb_positive;
 unaryfunc nb_absolute;
 inquiry nb_nonzero;
 unaryfunc nb_invert;
 binaryfunc nb_lshift;
 binaryfunc nb_rshift;
 binaryfunc nb_and;
 binaryfunc nb_xor;
 binaryfunc nb_or;
 coercion nb_coerce;
 unaryfunc nb_int;
 unaryfunc nb_long;
 unaryfunc nb_float;
 unaryfunc nb_oct;
 unaryfunc nb_hex;

 binaryfunc nb_inplace_add;
 binaryfunc nb_inplace_subtract;
 binaryfunc nb_inplace_multiply;
 binaryfunc nb_inplace_divide;
 binaryfunc nb_inplace_remainder;
 ternaryfunc nb_inplace_power;
 binaryfunc nb_inplace_lshift;
 binaryfunc nb_inplace_rshift;
 binaryfunc nb_inplace_and;
 binaryfunc nb_inplace_xor;
 binaryfunc nb_inplace_or;



 binaryfunc nb_floor_divide;
 binaryfunc nb_true_divide;
 binaryfunc nb_inplace_floor_divide;
 binaryfunc nb_inplace_true_divide;


 unaryfunc nb_index;
} PyNumberMethods;
typedef void (*freefunc)(void *);
typedef void (*destructor)(PyObject *);
typedef int (*printfunc)(PyObject *, int *, int);
typedef PyObject *(*getattrfunc)(PyObject *, char *);
typedef PyObject *(*getattrofunc)(PyObject *, PyObject *);
typedef int (*setattrfunc)(PyObject *, char *, PyObject *);
typedef int (*setattrofunc)(PyObject *, PyObject *, PyObject *);
typedef int (*cmpfunc)(PyObject *, PyObject *);
typedef PyObject *(*reprfunc)(PyObject *);
typedef long (*hashfunc)(PyObject *);
typedef PyObject *(*richcmpfunc) (PyObject *, PyObject *, int);
typedef PyObject *(*getiterfunc) (PyObject *);
typedef PyObject *(*iternextfunc) (PyObject *);
typedef PyObject *(*descrgetfunc) (PyObject *, PyObject *, PyObject *);
typedef int (*descrsetfunc) (PyObject *, PyObject *, PyObject *);
typedef int (*initproc)(PyObject *, PyObject *, PyObject *);
typedef PyObject *(*newfunc)(struct _typeobject *, PyObject *, PyObject *);
typedef PyObject *(*allocfunc)(struct _typeobject *, int);
 typedef struct _typeobject {
 int ob_refcnt; struct _typeobject *ob_type; int ob_size;
 const char *tp_name;
 int tp_basicsize, tp_itemsize;
 destructor tp_dealloc;
 printfunc tp_print;
 getattrfunc tp_getattr;
 setattrfunc tp_setattr;
 cmpfunc tp_compare;
 reprfunc tp_repr;
 PyNumberMethods *tp_as_number;
 PySequenceMethods *tp_as_sequence;
 PyMappingMethods *tp_as_

[Bug middle-end/44824] [4.6 regression] internal compiler error: verify_stmts failed

[jojelino at gmail dot com]

--- Comment #13 from jojelino at gmail dot com  2010-07-12 00:48 ---
extern __attribute__((dllimport)) PyIntObject _Py_TrueStruct;
removing  __attribute__((dllimport)) or replacing __attribute__
((visibility("default"))) solves problem... 


-- 


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

[Bug middle-end/44824] [4.6 regression] internal compiler error: verify_stmts failed

[jojelino at gmail dot com]

--- Comment #14 from jojelino at gmail dot com  2010-07-12 00:50 ---
then we get more reduced testcase

typedef struct sfoo{
int ob_refcnt;
} foo;
typedef struct sbar{
int ob_refcnt;
} bar;
extern __attribute__((dllimport)) bar bar1;
foo* stub1(){
return (\
\
((foo*)(((foo *) &bar1)))->ob_refcnt++), ((foo *) &bar1);
}
int main()
{
foo* a=stub1();
return a;
}


-- 


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

[Bug tree-optimization/44900] [4.5 Regression] The variable of SSE will be broken

[hjl dot tools at gmail dot com]

--- Comment #12 from hjl dot tools at gmail dot com  2010-07-12 01:05 
---
It is caused by revision 158826. On trunk, it
is fixed/hidden by revision 158732:

http://gcc.gnu.org/ml/gcc-cvs/2010-04/msg00839.html


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu dot
   ||org
  Known to fail||4.5.1
  Known to work|4.6.0 4.4.4 |4.6.0 4.4.4 4.5.0


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

[Bug tree-optimization/44900] [4.5 Regression] The variable of SSE will be broken

[hjl dot tools at gmail dot com]

--- Comment #13 from hjl dot tools at gmail dot com  2010-07-12 02:03 
---
If you replace

---
   vec2 a;
a = vec2::load(p);
---

with

---
vec2 a = vec2::load(p);
---

the testcase will pass.


-- 


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

[Bug tree-optimization/44915] New: [4.6 Regression] ICE: SIGSEGV in walk_aliased_vdefs_1.constprop.42 (tree-ssa-alias.c:1707) with -findirect-inlining

[zsojka at seznam dot cz]

Command line:
$ g++ -findirect-inlining testcase.C

Valgrind output:
$ valgrind -q --trace-children=yes
/mnt/svn/gcc-trunk/binary-162056-lto-fortran-checking-yes-rtl-df/bin/g++
-findirect-inlining testcase.C
==4614== Invalid read of size 2
==4614==at 0xA692A8: walk_aliased_vdefs_1.constprop.42
(tree-ssa-alias.c:1707)
==4614==by 0xA6996D: walk_aliased_vdefs (tree-ssa-alias.c:1748)
==4614==by 0xBF454A: is_parm_modified_before_call (ipa-prop.c:658)
==4614==by 0xBF687B: ipa_compute_jump_functions_for_edge (ipa-prop.c:696)
==4614==by 0xBF7ABC: ipa_analyze_node (ipa-prop.c:901)
==4614==by 0xBF40C7: analyze_function (ipa-inline.c:2072)
==4614==by 0xBF4181: inline_generate_summary (ipa-inline.c:2120)
==4614==by 0x8F16D5: execute_ipa_summary_passes (passes.c:1426)
==4614==by 0xBE9B90: cgraph_optimize (cgraphunit.c:1869)
==4614==by 0xBE9E0A: cgraph_finalize_compilation_unit (cgraphunit.c:1171)
==4614==by 0x588C0C: cp_write_global_declarations (decl2.c:3924)
==4614==by 0x9DDA45: toplev_main (toplev.c:997)
==4614==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==4614== 
testcase.C: In function 'void call_dummy(f_ptr)':
testcase.C:10:1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Tested revisions:
r162056 - crash
r161659 - crash
r161170 - OK
r159696 - OK
4.5 r160526 - OK


-- 
   Summary: [4.6 Regression] ICE: SIGSEGV in
walk_aliased_vdefs_1.constprop.42 (tree-ssa-
alias.c:1707) with -findirect-inlining
   Product: gcc
   Version: 4.6.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=44915

[Bug tree-optimization/44915] [4.6 Regression] ICE: SIGSEGV in walk_aliased_vdefs_1.constprop.42 (tree-ssa-alias.c:1707) with -findirect-inlining

[zsojka at seznam dot cz]

--- Comment #1 from zsojka at seznam dot cz  2010-07-12 06:13 ---
Created an attachment (id=21182)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21182&action=view)
reduced testcase

Command line:
$ g++ -findirect-inlining pr44915.C


-- 


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

[Bug fortran/44773] [4.6 Regression] Unnecessary temporaries increase the runtime for channel.f90 by ~70%

[paul dot richard dot thomas at gmail dot com]

--- Comment #20 from paul dot richard dot thomas at gmail dot com  
2010-07-12 06:31 ---
Subject: Re:  [4.6 Regression] Unnecessary temporaries 
increase the runtime for channel.f90 by ~70%

4.3 is not so easy - it's throwing a load of regressions.  I'll spend
some time tonight to try to understand why.  If I don't see it, I will
close this PR as FIXED; after all this bug goes gack to gfortran-3.5,
so it has taken 10years for it to come up :-)

Paul

On Sun, Jul 11, 2010 at 6:07 PM, pault at gcc dot gnu dot org
 wrote:
>
>
> --- Comment #19 from pault at gcc dot gnu dot org  2010-07-11 16:07 
> ---
> Subject: Bug 44773
>
> Author: pault
> Date: Sun Jul 11 16:06:53 2010
> New Revision: 162059
>
> URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162059
> Log:
> 2010-07-11  Paul Thomas  
>
>        PR fortran/44773
>        * trans-expr.c (arrayfunc_assign_needs_temporary): No temporary
>        if the lhs has never been host associated, as well as not being
>        use associated, a pointer or a target.
>        * resolve.c (resolve_variable): Mark variables that are host
>        associated.
>        * gfortran.h: Add the host_assoc bit to the symbol_attribute
>        structure.
>
>
> Modified:
>    branches/gcc-4_5-branch/gcc/fortran/ChangeLog
>    branches/gcc-4_5-branch/gcc/fortran/gfortran.h
>    branches/gcc-4_5-branch/gcc/fortran/resolve.c
>    branches/gcc-4_5-branch/gcc/fortran/trans-expr.c
>
>
> --
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44773
>
> --- You are receiving this mail because: ---
> You are the assignee for the bug, or are watching the assignee.
>


-- 


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