[Bug libstdc++/40038] [4.4/4.5 regression] symbols ce...@glibcxx_3.4.3 not exported

[doko at gcc dot gnu dot org]

--- Comment #7 from doko at gcc dot gnu dot org  2009-05-07 06:55 ---
Subject: Bug 40038

Author: doko
Date: Thu May  7 06:55:15 2009
New Revision: 147217

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147217
Log:
2009-05-07  Matthias Klose  

PR libstdc++/40038
* src/math_stubs_long_double.cc: Add ceill.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/src/math_stubs_long_double.cc


-- 


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

[Bug rtl-optimization/33928] [4.3/4.4/4.5 Regression] 30% performance slowdown in floating-point code caused by r118475

[lucier at math dot purdue dot edu]

--- Comment #66 from lucier at math dot purdue dot edu  2009-05-07 05:27 
---
Adding -frename-registers gives a significant speedup (sometimes as fast as
4.1.2 on this shared machine, i.e., it somtimes hits 108 ms instead of
132-140ms), the command line with -fforward-propagate -fno-move-loop-invariants
-frename-registers  is

/pkgs/gcc-mainline/bin/gcc -save-temps -I../include -I. -Wall -W -Wno-unused
-O1 -fno-math-errno -fschedule-insns2 -fno-trapping-math -fno-strict-aliasing
-fwrapv -fomit-frame-pointer -fPIC -fno-common -mieee-fp -fforward-propagate
-fno-move-loop-invariants -frename-registers -DHAVE_CONFIG_H -D___PRIMAL
-D___LIBRARY -D___GAMBCDIR="\"/usr/local/Gambit-C/v4.1.2\""
-D___SYS_TYPE_CPU="\"x86_64\"" -D___SYS_TYPE_VENDOR="\"unknown\""
-D___SYS_TYPE_OS="\"linux-gnu\"" -c _num.c

and the loop is

.L2752:
movq%rcx, %r12
addq8(%rax), %r12
leaq4(%rcx), %rdi
movq%r12, -8(%rax)
leaq4(%r12), %r8
addq8(%rax), %r12
movq%r8, -16(%rax)
movq-8(%rax), %r8
movq-16(%rax), %rdx
movq%r12, -24(%rax)
leaq4(%r12), %rbx
addq8(%rax), %r12
movq-24(%rax), %r9
movq%rbx, -32(%rax)
movq24(%rax), %rbx
movq-32(%rax), %r10
leaq4(%r12), %r11
movq%r12, -40(%rax)
movq40(%rax), %r12
movq-40(%rax), %r14
movq%r11, -48(%rax)
movsd   15(%rbx), %xmm1
movsd   7(%rbx), %xmm2
movsd   7(%r12,%r11,2), %xmm9
movapd  %xmm1, %xmm3
movsd   7(%r12,%r14,2), %xmm11
leaq7(%r12,%rcx,2), %r11
movapd  %xmm2, %xmm10
leaq(%rdi,%rdi), %r14
mulsd   %xmm11, %xmm3
movapd  %xmm2, %xmm12
mulsd   %xmm9, %xmm10
addq$8, %rcx
mulsd   %xmm1, %xmm9
cmpq%rcx, %r13
mulsd   %xmm2, %xmm11
movsd   7(%r12,%r10,2), %xmm5
movsd   7(%r12,%r9,2), %xmm7
addsd   %xmm10, %xmm3
movsd   7(%r12,%r8,2), %xmm6
subsd   %xmm9, %xmm11
mulsd   %xmm7, %xmm2
movapd  %xmm1, %xmm9
mulsd   %xmm5, %xmm1
movapd  %xmm6, %xmm13
movsd   7(%r12,%rdx,2), %xmm14
mulsd   %xmm5, %xmm12
mulsd   %xmm7, %xmm9
subsd   %xmm11, %xmm13
movsd   31(%rbx), %xmm0
addsd   %xmm6, %xmm11
movsd   .LC5(%rip), %xmm6
subsd   %xmm1, %xmm2
movsd   (%r11), %xmm4
movapd  %xmm14, %xmm10
xorpd   %xmm0, %xmm6
addsd   %xmm12, %xmm9
movsd   7(%r14,%r12), %xmm8
subsd   %xmm3, %xmm10
movapd  %xmm4, %xmm7
addsd   %xmm14, %xmm3
movsd   23(%rbx), %xmm15
subsd   %xmm2, %xmm7
movapd  %xmm8, %xmm5
addsd   %xmm4, %xmm2
movapd  %xmm6, %xmm4
subsd   %xmm9, %xmm5
movapd  %xmm15, %xmm14
addsd   %xmm8, %xmm9
mulsd   %xmm10, %xmm4
movapd  %xmm15, %xmm8
mulsd   %xmm15, %xmm10
movapd  %xmm0, %xmm12
mulsd   %xmm11, %xmm15
mulsd   %xmm3, %xmm0
movapd  %xmm7, %xmm1
mulsd   %xmm13, %xmm6
mulsd   %xmm3, %xmm8
movapd  %xmm9, %xmm3
mulsd   %xmm11, %xmm12
subsd   %xmm0, %xmm15
mulsd   %xmm13, %xmm14
subsd   %xmm10, %xmm6
movapd  %xmm2, %xmm10
movapd  %xmm5, %xmm0
addsd   %xmm12, %xmm8
addsd   %xmm15, %xmm10
subsd   %xmm15, %xmm2
addsd   %xmm14, %xmm4
addsd   %xmm8, %xmm3
movsd   %xmm10, (%r11)
movq40(%rax), %r10
subsd   %xmm8, %xmm9
addsd   %xmm6, %xmm1
addsd   %xmm4, %xmm0
movsd   %xmm3, 7(%r14,%r10)
movq-8(%rax), %r9
movq40(%rax), %rdx
subsd   %xmm6, %xmm7
subsd   %xmm4, %xmm5
movsd   %xmm2, 7(%rdx,%r9,2)
movq-16(%rax), %r8
movq40(%rax), %r12
movsd   %xmm9, 7(%r12,%r8,2)
movq-24(%rax), %rbx
movq40(%rax), %r11
movsd   %xmm1, 7(%r11,%rbx,2)
movq-32(%rax), %r14
movq40(%rax), %r10
movsd   %xmm0, 7(%r10,%r14,2)
movq-40(%rax), %r9
movq40(%rax), %rdx
movsd   %xmm7, 7(%rdx,%r9,2)
movq-48(%rax), %r8
movq40(%rax), %r12
movsd   %xmm5, 7(%r12,%r8,2)
jg  .L2752

Adding -fforward-propagate -fno-move-loop-invariants -fweb instead of
-fforward-propagate -fno-move-loop-invariants -frename-registers, so the
compile line is

/pkgs/gcc-mainline/bin/gcc -save-temps -I../include -I. -Wall -W -Wno-unused
-O1 -fno-math-errno -fschedule-insns2 -fno-trapping-math -fno-strict-aliasing
-fwrapv -fomit-frame-pointer -fPIC -fno-common -mieee-fp -fforward-propagate
-fno-move-loop-invariants -fweb -DHAVE_CONFIG_H -D___PRIMAL -D___LIBRARY
-D___GAMBCDIR="\"/usr/local/Gambit-C/v4.1.2\"" -D___SYS_TYPE

[Bug rtl-optimization/33928] [4.3/4.4/4.5 Regression] 30% performance slowdown in floating-point code caused by r118475

[bonzini at gnu dot org]

--- Comment #65 from bonzini at gnu dot org  2009-05-07 05:03 ---
Subject: Re:  [4.3/4.4/4.5 Regression] 30% performance
 slowdown in floating-point code caused by  r118475

lucier at math dot purdue dot edu wrote:
> --- Comment #64 from lucier at math dot purdue dot edu  2009-05-06 20:43 
> ---
> In answer to comment 60, here's the command line where I added
> -fforward-propagate -fno-move-loop-invariants:

Hmm, can you try adding -frename-registers *or* -fweb (i.e. together
they get no benefit) too?

> and the loop looks pretty much just as bad (it's 117 instructions long, by my
> count):

116 actually: the movq here is outside the loop (that's how I made all
the instruction counts).

> movsd   %xmm5, 7(%rdx,%rbx,2)
> jg  .L2752
> movq%rdi, %r13
> .L2751:


-- 


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

[Bug fortran/40018] [4.4/4.5 Regression] ICE in output_constructor

[pault at gcc dot gnu dot org]

--- Comment #6 from pault at gcc dot gnu dot org  2009-05-07 04:44 ---
(In reply to comment #5)
> The patch in comment #4 fixes this pr, but gives:
> 
> .*: internal compiler error: in fold_convert, at fold-const.c:2551

Yes... I went to bed when the regression test started spewing out the errors. 
The fix is easy... I think :-)  The type must be checked for not being a
character type before doing the fold_convert.

It's regtesting right now.

Cheers

Paul


-- 


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

[Bug tree-optimization/40052] New: missed optimizations on logical types: (x | 1) --> 1

[matz at gcc dot gnu dot org]

The testcase from PR40021:
 http://gcc.gnu.org/bugzilla/attachment.cgi?id=17800&action=view
shows a current problem in optimizing away logical operations on logical
(boolean) types, like "x | 1" --> "1".  This folding is done in some contexts,
and not in others.  In particular the testcase
 (with -m32 -O2 -ftree-vectorize -msse2 -mfpmath=sse -ffast-math )
leaves this until expand (it's generated quite early already, so there
are multiple possibilities to fold it):

  D.1650_109 = D.1648_107 | 1;
  if (D.1650_109 != 0)
goto ;
  else
goto ;

Richi already fiddled a bit with this, so CCing him.


-- 
   Summary: missed optimizations on logical types: (x | 1) --> 1
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: matz at gcc dot gnu dot org
  GCC host triplet: x86_64-unknown-linux-gnu


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

[Bug target/40051] [4.3, 4.4, 4.5] regression member variable of a C++ class is read to a register for future use before it is written

[jack2 at cantab dot net]

--- Comment #5 from jack2 at cantab dot net  2009-05-06 22:31 ---
> No, from the sound of it there is an alias violation in the code.

You're right, I had thought of that but had read that Mozilla code was compiled
with -fno-strict-aliasing because of this. Looking more closely the code in
this extension isn't and so fails.

Now that I've added -fno-strict-aliasing it works.

Sorry for the noise.


-- 

jack2 at cantab dot net changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug target/40051] [4.3, 4.4, 4.5] regression member variable of a C++ class is read to a register for future use before it is written

[hjl dot tools at gmail dot com]

--- Comment #4 from hjl dot tools at gmail dot com  2009-05-06 22:29 ---
Revision 138953:

http://gcc.gnu.org/ml/gcc-cvs/2008-08/msg00512.html
http://gcc.gnu.org/ml/gcc-patches/2008-08/msg00524.html

fixed a real bug.


-- 


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

[Bug other/40051] [4.3, 4.4, 4.5] regression member variable of a C++ class is read to a register for future use before it is written

[jack2 at cantab dot net]

--- Comment #3 from jack2 at cantab dot net  2009-05-06 22:00 ---
Created an attachment (id=17815)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17815&action=view)
Patch against trunk 147188 to revert commit 138953


-- 


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

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

[janus at gcc dot gnu dot org]

--- Comment #4 from janus at gcc dot gnu dot org  2009-05-06 22:07 ---

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

I don't see any reason why 'erfc' should get the EXTERNAL attribute here at
all. In any case this happens in gfc_is_intrinsic:

  /* See if this intrinsic is allowed in the current standard.  */
  if (gfc_check_intrinsic_standard (isym, &symstd, false, loc) == FAILURE)
{
  if (gfc_option.warn_intrinsics_std)
gfc_warning_now ("The intrinsic '%s' at %L is not included in the"
 " selected standard but %s and '%s' will be treated
as"
 " if declared EXTERNAL.  Use an appropriate -std=*"
 " option or define -fall-intrinsics to allow this"
 " intrinsic.", sym->name, &loc, symstd, sym->name);
  sym->attr.external = 1;

  return false;
}

This code was committed as r138122 by Daniel K. as a fix for PR33141, but it
doesn't seem quite right to me. Either one should avoid setting the EXTERNAL
attribute here at all, or at least only do it if the symbol is not specified by
the user as a module procedure.


-- 

janus at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||janus at gcc dot gnu dot org


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

[Bug other/40051] [4.3, 4.4, 4.5] regression member variable of a C++ class is read to a register for future use before it is written

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2009-05-06 21:59 ---
>SVN commit 138953 introduced a bug where code compiled at -O2 and above reads a
value into a register before it is written in a function called by the
optimized code.

No, from the sound of it there is an alias violation in the code.


-- 


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

[Bug other/40051] [4.3, 4.4, 4.5] regression member variable of a C++ class is read to a register for future use before it is written

[jack2 at cantab dot net]

--- Comment #1 from jack2 at cantab dot net  2009-05-06 21:56 ---
Created an attachment (id=17814)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17814&action=view)
*.i file with which the bug is demonstrated


-- 


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

[Bug middle-end/39954] [4.5 Regression] Revision 146817 caused unaligned access in gcc.dg/torture/pr26565.c

[matz at gcc dot gnu dot org]

--- Comment #23 from matz at gcc dot gnu dot org  2009-05-06 21:56 ---
No regressions on x86_64-linux.  I'm baffled.


-- 


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

[Bug middle-end/39954] [4.5 Regression] Revision 146817 caused unaligned access in gcc.dg/torture/pr26565.c

[rguenther at suse dot de]

--- Comment #22 from rguenther at suse dot de  2009-05-06 21:55 ---
Subject: Re:  [4.5 Regression] Revision 146817 caused
 unaligned access in gcc.dg/torture/pr26565.c

On Wed, 6 May 2009, matz at suse dot de wrote:

> --- Comment #21 from matz at suse dot de  2009-05-06 21:39 ---
> Subject: Re:  [4.5 Regression] Revision 146817 caused
>  unaligned access in gcc.dg/torture/pr26565.c
> 
> On Wed, 6 May 2009, rguenther at suse dot de wrote:
> 
> > > +  tree ret;
> > > +  if (TYPE_PACKED (t))
> > > +return t;
> > 
> > Walking the type variants and searching for what we now build would
> > fix the inefficiency.  And of course this function needs a comment ;)
> 
> I anyway am unsure about using variants of types for this.  E.g. some 
> other lookup functions when searching for a qualified type simply walk the 
> list and take the first one with matching qualifiers.  Now if there 
> suddenly are multiple variants with same qualifiers but different 
> alignment in there it might chose an overly aligned type accidentally.  
> Or maybe I'm confused, hmm...  (but yes, that's the obvious fix for the 
> inefficiency).  Can qualified types themself be a new base 
> (TYPE_MAIN_VARIANT) for a new chain?  In that case it would work just 
> fine.

Well, build_variant_type_copy already inserts the variant in the
list ... but yes, existing walkers would need to be changed to
also verify matching alignment to the main variant.  OTOH we
may end up creating regular variants for the different align
variants.  Ugh.

Maybe instead using build_distinct_type_copy on the main
variant and using type_hash_canon for efficiency and setting
TYPE_CANONICAL to the type with the natural alignment is better.
This may pose problems with C frontend internal compatibility
and diagnostics.

> 
> > > +  ret = build_variant_type_copy (t);
> > > +  TYPE_ALIGN (ret) = align * BITS_PER_UNIT;
> > > +  TYPE_USER_ALIGN (ret) = 1;
> > 
> > It seems that only ever place_field looks at this flag.
> 
> TYPE_USER_ALIGN?  By place_field and update_alignment_for_field, and it's 
> copied into DECL_USER_ALIGN (which is used in more places).
> 
> TYPE_USER_ALIGN only ever seems to guard calls to ADJUST_FIELD_ALIGN when 
> PCC_BITFIELD_TYPE_MATTERS or BITFIELD_NBYTES_LIMITED.  But I have no idea 
> why a user specified alignment should not also be affected by 
> ADJUST_FIELD_ALIGN.  It all seems to have to do with the general theme of 
> not overriding user-specified alignment in any way that the compiler 
> normally takes to derive alignments.
> 
> In any case it seems better to leave this alone, stor-layout.c is filled 
> with sometimes quite arcane conditions and special cases and probably 
> nobody in the world can test all combinations of strange ABIs and funny 
> requirements or backward compatibilities.
> 
> > How is the effect of setting it here?
> 
> Well, the user explicitely put "attribute((packed))" there so it seems 
> reasonable to deal with this as if he also specified an explicit 
> alignment.

Ok.

> > Overall I like this patch.
> 
> Much to my surprise it even seems to work up to now, bootstrap was okay 
> testsuite still running.

Probably making the type a variant at least makes the FE happy ;)

Richard.


-- 


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

[Bug other/40051] New: [4.3, 4.4, 4.5] regression member variable of a C++ class is read to a register for future use before it is written

[jack2 at cantab dot net]

SVN commit 138953 introduced a bug where code compiled at -O2 and above reads a
value into a register before it is written in a function called by the
optimized code.

This is demonstrated in the code for the Enigmail plugin to Mozilla Thunderbird
as discussed at https://bugs.gentoo.org/show_bug.cgi?id=246421 I haven't been
able to produce a more minimal test case - it seems to need a significant
portion of the surrounding infrastructure to trigger this.

I've reversed commit 138953 on a recent trunk snapshot and it fixes this bug
but I don't know if this introduces a regression on other bugs.


-- 
   Summary: [4.3, 4.4, 4.5] regression member variable of a C++
class is read to a register for future use before it is
written
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jack2 at cantab dot net
 GCC build triplet: x86_64-pc-linux-gnu
  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=40051

[Bug fortran/40018] [4.4/4.5 Regression] ICE in output_constructor

[dominiq at lps dot ens dot fr]

--- Comment #5 from dominiq at lps dot ens dot fr  2009-05-06 21:43 ---
The patch in comment #4 fixes this pr, but gives:

.*: internal compiler error: in fold_convert, at fold-const.c:2551

in 83 of my tests, for instance

[ibook-dhum] f90/bug% cat pr36257.f90
  implicit none
  character(len=5), dimension(3,3), parameter :: &
p = reshape(["", "", "", "", "", "", "", "", ""], [3,3])
  character(len=5), dimension(3,3) :: m1

  m1 = p
  if (any (spread (p, 1, 2) /= spread (m1, 1, 2))) call abort

end

I did not review all the cases, but all those I have looked at deal with
constructor+strings.


-- 


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

[Bug middle-end/39954] [4.5 Regression] Revision 146817 caused unaligned access in gcc.dg/torture/pr26565.c

[matz at suse dot de]

--- Comment #21 from matz at suse dot de  2009-05-06 21:39 ---
Subject: Re:  [4.5 Regression] Revision 146817 caused
 unaligned access in gcc.dg/torture/pr26565.c

On Wed, 6 May 2009, rguenther at suse dot de wrote:

> > +  tree ret;
> > +  if (TYPE_PACKED (t))
> > +return t;
> 
> Walking the type variants and searching for what we now build would
> fix the inefficiency.  And of course this function needs a comment ;)

I anyway am unsure about using variants of types for this.  E.g. some 
other lookup functions when searching for a qualified type simply walk the 
list and take the first one with matching qualifiers.  Now if there 
suddenly are multiple variants with same qualifiers but different 
alignment in there it might chose an overly aligned type accidentally.  
Or maybe I'm confused, hmm...  (but yes, that's the obvious fix for the 
inefficiency).  Can qualified types themself be a new base 
(TYPE_MAIN_VARIANT) for a new chain?  In that case it would work just 
fine.

> > +  ret = build_variant_type_copy (t);
> > +  TYPE_ALIGN (ret) = align * BITS_PER_UNIT;
> > +  TYPE_USER_ALIGN (ret) = 1;
> 
> It seems that only ever place_field looks at this flag.

TYPE_USER_ALIGN?  By place_field and update_alignment_for_field, and it's 
copied into DECL_USER_ALIGN (which is used in more places).

TYPE_USER_ALIGN only ever seems to guard calls to ADJUST_FIELD_ALIGN when 
PCC_BITFIELD_TYPE_MATTERS or BITFIELD_NBYTES_LIMITED.  But I have no idea 
why a user specified alignment should not also be affected by 
ADJUST_FIELD_ALIGN.  It all seems to have to do with the general theme of 
not overriding user-specified alignment in any way that the compiler 
normally takes to derive alignments.

In any case it seems better to leave this alone, stor-layout.c is filled 
with sometimes quite arcane conditions and special cases and probably 
nobody in the world can test all combinations of strange ABIs and funny 
requirements or backward compatibilities.

> How is the effect of setting it here?

Well, the user explicitely put "attribute((packed))" there so it seems 
reasonable to deal with this as if he also specified an explicit 
alignment.

> Overall I like this patch.

Much to my surprise it even seems to work up to now, bootstrap was okay 
testsuite still running.


-- 


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

[Bug testsuite/40050] plugin tests don't work with multilib

[hjl at gcc dot gnu dot org]

--- Comment #3 from hjl at gcc dot gnu dot org  2009-05-06 21:33 ---
Subject: Bug 40050

Author: hjl
Date: Wed May  6 21:31:56 2009
New Revision: 147208

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147208
Log:
2009-05-06  H.J. Lu  

PR testsuite/40050
* lib/plugin-support.exp (plugin-test-execute): Use HOSTCC to
build plugin.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/lib/plugin-support.exp


-- 


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

[Bug fortran/39630] Fortran 2003: Procedure Pointer Components

[janus at gcc dot gnu dot org]

--- Comment #4 from janus at gcc dot gnu dot org  2009-05-06 21:23 ---
Status: r147206 implements PPCs with NOPASS, but PASS is still missing ...


-- 


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

[Bug fortran/39630] Fortran 2003: Procedure Pointer Components

[janus at gcc dot gnu dot org]

--- Comment #3 from janus at gcc dot gnu dot org  2009-05-06 21:17 ---
Subject: Bug 39630

Author: janus
Date: Wed May  6 21:17:16 2009
New Revision: 147206

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147206
Log:
2009-05-06  Janus Weil  
Paul Thomas  

PR fortran/39630
* decl.c (match_procedure_interface): New function to match the
interface for a PROCEDURE statement.
(match_procedure_decl): Call match_procedure_interface.
(match_ppc_decl): New function to match the declaration of a
procedure pointer component.
(gfc_match_procedure):  Call match_ppc_decl.
(match_binding_attributes): Add new argument 'ppc' and handle the
POINTER attribute for procedure pointer components.
(match_procedure_in_type,gfc_match_generic): Added new argument to
match_binding_attributes.
* dump-parse-tree.c (show_expr,show_components,show_code_node): Handle
procedure pointer components.
* expr.c (free_expr0,gfc_copy_expr,gfc_simplify_expr): Handle EXPR_PPC.
(gfc_check_pointer_assign): Handle procedure pointer components, but no
full checking yet.
(is_proc_ptr_comp): New function to determine if an expression is a
procedure pointer component.
* gfortran.h (expr_t): Add EXPR_PPC.
(symbol_attribute): Add new member 'proc_pointer_comp'.
(gfc_component): Add new member 'formal'.
(gfc_exec_op): Add EXEC_CALL_PPC.
(gfc_get_default_type): Changed first argument.
(is_proc_ptr_comp): Add prototype.
(gfc_match_varspec): Add new argument.
* interface.c (compare_actual_formal): Handle procedure pointer
components.
* match.c (gfc_match_pointer_assignment,match_typebound_call): Handle
procedure pointer components.
* module.c (mio_expr): Handle EXPR_PPC.
* parse.c (parse_derived): Handle procedure pointer components.
* primary.c (gfc_match_varspec): Add new argument 'ppc_arg' and handle
procedure pointer components.
(gfc_variable_attr): Handle procedure pointer components.
(gfc_match_rvalue): Added new argument to gfc_match_varspec and changed
first argument of gfc_get_default_type.
(match_variable): Added new argument to gfc_match_varspec.
* resolve.c (resolve_entries,set_type,resolve_fl_parameter): Changed
first argument of gfc_get_default_type.
(resolve_structure_cons,resolve_actual_arglist): Handle procedure
pointer components.
(resolve_ppc_call): New function to resolve a call to a procedure
pointer component (subroutine).
(resolve_expr_ppc): New function to resolve a call to a procedure
pointer component (function).
(gfc_resolve_expr): Handle EXPR_PPC.
(resolve_code): Handle EXEC_CALL_PPC.
(resolve_fl_derived): Copy the interface for a procedure pointer
component.
(resolve_symbol): Fix overlong line.
* st.c (gfc_free_statement): Handle EXEC_CALL_PPC.
* symbol.c (gfc_get_default_type): Changed first argument.
(gfc_set_default_type): Changed first argument of gfc_get_default_type.
(gfc_add_component): Initialize ts.type to BT_UNKNOWN.
* trans.h (gfc_conv_function_call): Renamed.
* trans.c (gfc_trans_code): Handle EXEC_CALL_PPC.
* trans-expr.c (gfc_conv_component_ref): Ditto.
(gfc_conv_function_val): Rename to 'conv_function_val', add new
argument 'expr' and handle procedure pointer components.
(gfc_conv_operator_assign): Renamed gfc_conv_function_val.
(gfc_apply_interface_mapping_to_expr): Handle EXPR_PPC.
(gfc_conv_function_call): Rename to 'gfc_conv_procedure_call', add new
argument 'expr' and handle procedure pointer components.
(gfc_get_proc_ptr_comp): New function to get the backend decl for a
procedure pointer component.
(gfc_conv_function_expr): Renamed gfc_conv_function_call.
(gfc_conv_structure): Handle procedure pointer components.
* trans-intrinsic.c (gfc_conv_intrinsic_funcall,
conv_generic_with_optional_char_arg): Renamed gfc_conv_function_call.
* trans-stmt.h (gfc_get_proc_ptr_comp): Add prototype.
* trans-stmt.c (gfc_trans_call): Renamed gfc_conv_function_call.
* trans-types.h (gfc_get_ppc_type): Add prototype.
* trans-types.c (gfc_get_ppc_type): New function to build a tree node
for a procedure pointer component.
(gfc_get_derived_type): Handle procedure pointer components.


2009-05-06  Janus Weil  

PR fortran/39630
* gfortran.dg/proc_decl_1.f90: Modified.
* gfortran.dg/proc_ptr_comp_1.f90: New.
* gfortran.dg/proc_ptr_comp_2.f90: New.
* gfortran.dg/proc_ptr_comp_3.f90: New.
* gfortran.dg/proc_ptr_comp_4.f90: New.
* gfortran.dg/proc_ptr_comp_5.f90: New

[Bug testsuite/40050] plugin tests don't work with multilib

[hjl dot tools at gmail dot com]

--- Comment #2 from hjl dot tools at gmail dot com  2009-05-06 21:03 ---
Here is a patch:

http://gcc.gnu.org/ml/gcc-patches/2009-05/msg00280.html


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

URL||http://gcc.gnu.org/ml/gcc-
   ||patches/2009-
   ||05/msg00280.html


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

[Bug middle-end/39954] [4.5 Regression] Revision 146817 caused unaligned access in gcc.dg/torture/pr26565.c

[rguenther at suse dot de]

--- Comment #20 from rguenther at suse dot de  2009-05-06 21:02 ---
Subject: Re:  [4.5 Regression] Revision 146817 caused
 unaligned access in gcc.dg/torture/pr26565.c

On Wed, 6 May 2009, matz at gcc dot gnu dot org wrote:

> --- Comment #19 from matz at gcc dot gnu dot org  2009-05-06 20:39 ---
> Something like this implements option 1.  It's probably hopelessly inefficient
> (always generating a new type for each packed field), and wrong, and generally
> just a bad idea, but it does fix the testcase, execute.exp still works and
> bootstrap is already in the target libs :)
> And it only deals with packed fields, not those having an aligned() attribute.
> 
> Index: c-common.c
> ===
> --- c-common.c  (Revision 147187)
> +++ c-common.c  (Arbeitskopie)
> @@ -5813,6 +5813,18 @@ c_init_attributes (void)
>  #undef DEF_ATTR_TREE_LIST
>  }
> 
> +static tree
> +get_aligned_type (tree t, int align)
> +{
> +  tree ret;
> +  if (TYPE_PACKED (t))
> +return t;

Walking the type variants and searching for what we now build would
fix the inefficiency.  And of course this function needs a comment ;)

> +  ret = build_variant_type_copy (t);
> +  TYPE_ALIGN (ret) = align * BITS_PER_UNIT;
> +  TYPE_USER_ALIGN (ret) = 1;

It seems that only ever place_field looks at this flag.  How
is the effect of setting it here?

Overall I like this patch.

Richard.

> +  return ret;
> +}
> +
>  /* Attribute handlers common to C front ends.  */
> 
>  /* Handle a "packed" attribute; arguments as in
> @@ -5837,7 +5849,10 @@ handle_packed_attribute (tree *node, tre
>  "%qE attribute ignored for field of type %qT",
>  name, TREE_TYPE (*node));
>else
> -   DECL_PACKED (*node) = 1;
> +   {
> + DECL_PACKED (*node) = 1;
> + TREE_TYPE (*node) = get_aligned_type (TREE_TYPE (*node), 1);
> +   }
>  }
>/* We can't set DECL_PACKED for a VAR_DECL, because the bit is
>   used for DECL_REGISTER.  It wouldn't mean anything anyway.
> 
> 
> 


-- 


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

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

[dodji at gcc dot gnu dot org]

--- Comment #12 from dodji at gcc dot gnu dot org  2009-05-06 20:47 ---
Fixed in 4.4 and 4.5. The patch won't apply to 4.3 as the code base has
diverged.


-- 

dodji at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug fortran/40018] [4.4/4.5 Regression] ICE in output_constructor

[pault at gcc dot gnu dot org]

--- Comment #4 from pault at gcc dot gnu dot org  2009-05-06 20:46 ---
This fixes it and is regtesting right now.

Index: gcc/fortran/trans-array.c
===
--- gcc/fortran/trans-array.c   (revision 147128)
+++ gcc/fortran/trans-array.c   (working copy)
@@ -1620,6 +1620,7 @@
 {
   gfc_init_se (&se, NULL);
   gfc_conv_constant (&se, c->expr);
+  se.expr = fold_convert (type, se.expr);
   if (c->expr->ts.type == BT_CHARACTER && POINTER_TYPE_P (type))
se.expr = gfc_build_addr_expr (gfc_get_pchar_type (c->expr->ts.kind),
   se.expr);

I am looking to see if this cannot be done in the front-end.

Note the enormous difference in the code produced in 4.3, compared with 4.4 and
trunk.  Fixing assignments exposed this little gem!

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|NEW |ASSIGNED
   Last reconfirmed|2009-05-05 08:00:19 |2009-05-06 20:46:37
   date||


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

[Bug rtl-optimization/33928] [4.3/4.4/4.5 Regression] 30% performance slowdown in floating-point code caused by r118475

[lucier at math dot purdue dot edu]

--- Comment #64 from lucier at math dot purdue dot edu  2009-05-06 20:43 
---
In answer to comment 60, here's the command line where I added
-fforward-propagate -fno-move-loop-invariants:

/pkgs/gcc-mainline/bin/gcc -save-temps -I../include -I. -Wall -W -Wno-unused
-O1 -fno-math-errno -fschedule-insns2 -fno-trapping-math -fno-strict-aliasing
-fwrapv -fomit-frame-pointer -fPIC -fno-common -mieee-fp -fforward-propagate
-fno-move-loop-invariants -DHAVE_CONFIG_H -D___PRIMAL -D___LIBRARY
-D___GAMBCDIR="\"/usr/local/Gambit-C/v4.1.2\"" -D___SYS_TYPE_CPU="\"x86_64\""
-D___SYS_TYPE_VENDOR="\"unknown\"" -D___SYS_TYPE_OS="\"linux-gnu\"" -c _num.c

here's the compiler:

/pkgs/gcc-mainline/bin/gcc -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: /tmp/lucier/gcc/mainline/configure --enable-checking=release
--prefix=/pkgs/gcc-mainline --enable-languages=c
Thread model: posix
gcc version 4.5.0 20090506 (experimental) [trunk revision 147199] (GCC) 

and the runtime didn't change (substantially)

132 ms cpu time (132 user, 0 system)

and the loop looks pretty much just as bad (it's 117 instructions long, by my
count):

.L2752:
movq%rcx, %rdx
addq8(%rax), %rdx
leaq4(%rcx), %rdi
movq%rdx, -8(%rax)
leaq4(%rdx), %rbx
addq8(%rax), %rdx
movq%rbx, -16(%rax)
movq%rdx, -24(%rax)
leaq4(%rdx), %rbx
addq8(%rax), %rdx
movq%rbx, -32(%rax)
movq%rdx, -40(%rax)
leaq4(%rdx), %rbx
movq40(%rax), %rdx
movq%rbx, -48(%rax)
movsd   7(%rdx,%rbx,2), %xmm9
movq-40(%rax), %rbx
leaq7(%rdx,%rcx,2), %r8
addq$8, %rcx
movsd   (%r8), %xmm4
cmpq%rcx, %r13
movsd   7(%rdx,%rbx,2), %xmm11
movq-32(%rax), %rbx
movsd   7(%rdx,%rbx,2), %xmm5
movq-24(%rax), %rbx
movsd   7(%rdx,%rbx,2), %xmm7
movq-16(%rax), %rbx
movsd   7(%rdx,%rbx,2), %xmm14
movq-8(%rax), %rbx
movsd   7(%rdx,%rbx,2), %xmm6
leaq(%rdi,%rdi), %rbx
movsd   7(%rbx,%rdx), %xmm8
movq24(%rax), %rdx
movapd  %xmm6, %xmm13
movsd   15(%rdx), %xmm1
movsd   7(%rdx), %xmm2
movapd  %xmm1, %xmm10
movsd   31(%rdx), %xmm3
movapd  %xmm2, %xmm12
mulsd   %xmm11, %xmm10
mulsd   %xmm9, %xmm12
mulsd   %xmm2, %xmm11
mulsd   %xmm1, %xmm9
movsd   23(%rdx), %xmm0
addsd   %xmm12, %xmm10
movapd  %xmm2, %xmm12
mulsd   %xmm7, %xmm2
subsd   %xmm9, %xmm11
movapd  %xmm1, %xmm9
mulsd   %xmm5, %xmm12
mulsd   %xmm5, %xmm1
movapd  %xmm8, %xmm5
mulsd   %xmm7, %xmm9
movapd  %xmm4, %xmm7
subsd   %xmm11, %xmm13
addsd   %xmm6, %xmm11
movsd   .LC5(%rip), %xmm6
subsd   %xmm1, %xmm2
movapd  %xmm0, %xmm1
addsd   %xmm12, %xmm9
movapd  %xmm14, %xmm12
xorpd   %xmm3, %xmm6
subsd   %xmm10, %xmm12
mulsd   %xmm13, %xmm1
subsd   %xmm2, %xmm7
addsd   %xmm4, %xmm2
movapd  %xmm6, %xmm4
addsd   %xmm14, %xmm10
mulsd   %xmm13, %xmm6
mulsd   %xmm12, %xmm4
subsd   %xmm9, %xmm5
mulsd   %xmm0, %xmm12
addsd   %xmm8, %xmm9
movapd  %xmm0, %xmm8
mulsd   %xmm11, %xmm0
addsd   %xmm1, %xmm4
movapd  %xmm3, %xmm1
mulsd   %xmm10, %xmm3
subsd   %xmm12, %xmm6
mulsd   %xmm11, %xmm1
mulsd   %xmm10, %xmm8
subsd   %xmm3, %xmm0
addsd   %xmm1, %xmm8
movapd  %xmm2, %xmm1
addsd   %xmm0, %xmm1
subsd   %xmm0, %xmm2
movapd  %xmm7, %xmm0
subsd   %xmm6, %xmm7
addsd   %xmm6, %xmm0
movsd   %xmm1, (%r8)
movapd  %xmm9, %xmm1
movq40(%rax), %rdx
subsd   %xmm8, %xmm9
addsd   %xmm8, %xmm1
movsd   %xmm1, 7(%rbx,%rdx)
movq-8(%rax), %rbx
movq40(%rax), %rdx
movsd   %xmm2, 7(%rdx,%rbx,2)
movq-16(%rax), %rbx
movq40(%rax), %rdx
movsd   %xmm9, 7(%rdx,%rbx,2)
movq-24(%rax), %rbx
movq40(%rax), %rdx
movsd   %xmm0, 7(%rdx,%rbx,2)
movapd  %xmm5, %xmm0
movq-32(%rax), %rbx
movq40(%rax), %rdx
subsd   %xmm4, %xmm5
addsd   %xmm4, %xmm0
movsd   %xmm0, 7(%rdx,%rbx,2)
movq-40(%rax), %rbx
movq40(%rax), %rdx
movsd   %xmm7, 7(%rdx,%rbx,2)
movq-48(%rax), %rbx
movq40(%rax), %rdx
movsd   %xmm5, 7(%rdx,%rbx,2)
jg  .L2752
movq%rdi, %r13
.L2751:


-- 

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

[dodji at gcc dot gnu dot org]

--- Comment #11 from dodji at gcc dot gnu dot org  2009-05-06 20:43 ---
Subject: Bug 17395

Author: dodji
Date: Wed May  6 20:43:41 2009
New Revision: 147202

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147202
Log:
2009-05-06  Dodji Seketeli  

gcc/cp/ChangeLog:
PR c++/17395
* pt.c (tsubst_copy) : We don't want to tsubst the
whole list of PARM_DECLs, just the current one.

gcc/testsuite/ChangeLog:
PR c++/17395
* g++.dg/template/call7.C: New test.


Added:
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/template/call7.C
Modified:
branches/gcc-4_4-branch/gcc/cp/ChangeLog
branches/gcc-4_4-branch/gcc/cp/pt.c
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog


-- 


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

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

[dodji at gcc dot gnu dot org]

--- Comment #10 from dodji at gcc dot gnu dot org  2009-05-06 20:42 ---
Subject: Bug 17395

Author: dodji
Date: Wed May  6 20:41:52 2009
New Revision: 147201

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147201
Log:
2009-05-06  Dodji Seketeli  

gcc/cp/ChangeLog:
PR c++/17395
* pt.c (tsubst_copy) : We don't want to tsubst the
whole list of PARM_DECLs, just the current one.

gcc/testsuite/ChangeLog:
PR c++/17395
* g++.dg/template/call7.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/template/call7.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug middle-end/39954] [4.5 Regression] Revision 146817 caused unaligned access in gcc.dg/torture/pr26565.c

[matz at gcc dot gnu dot org]

--- Comment #19 from matz at gcc dot gnu dot org  2009-05-06 20:39 ---
Something like this implements option 1.  It's probably hopelessly inefficient
(always generating a new type for each packed field), and wrong, and generally
just a bad idea, but it does fix the testcase, execute.exp still works and
bootstrap is already in the target libs :)
And it only deals with packed fields, not those having an aligned() attribute.

Index: c-common.c
===
--- c-common.c  (Revision 147187)
+++ c-common.c  (Arbeitskopie)
@@ -5813,6 +5813,18 @@ c_init_attributes (void)
 #undef DEF_ATTR_TREE_LIST
 }

+static tree
+get_aligned_type (tree t, int align)
+{
+  tree ret;
+  if (TYPE_PACKED (t))
+return t;
+  ret = build_variant_type_copy (t);
+  TYPE_ALIGN (ret) = align * BITS_PER_UNIT;
+  TYPE_USER_ALIGN (ret) = 1;
+  return ret;
+}
+
 /* Attribute handlers common to C front ends.  */

 /* Handle a "packed" attribute; arguments as in
@@ -5837,7 +5849,10 @@ handle_packed_attribute (tree *node, tre
 "%qE attribute ignored for field of type %qT",
 name, TREE_TYPE (*node));
   else
-   DECL_PACKED (*node) = 1;
+   {
+ DECL_PACKED (*node) = 1;
+ TREE_TYPE (*node) = get_aligned_type (TREE_TYPE (*node), 1);
+   }
 }
   /* We can't set DECL_PACKED for a VAR_DECL, because the bit is
  used for DECL_REGISTER.  It wouldn't mean anything anyway.


-- 


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

[Bug testsuite/40050] plugin tests don't work with multilib

[joseph at codesourcery dot com]

--- Comment #1 from joseph at codesourcery dot com  2009-05-06 20:16 ---
Subject: Re:   New: plugin tests don't work with multilib

On Wed, 6 May 2009, hjl dot tools at gmail dot com wrote:

> On Linux/Intel64, 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/ -I.
> -I/net/gnu-13/export/gnu/src/gcc/gcc/gcc/testsuite
> -I/net/gnu-13/export/gnu/src/gcc/gcc/gcc/testsuite/../../gcc
> -I/export/build/gnu/gcc/build-x86_64-linux/gcc/testsuite/gcc/../../../gcc 
> -I/net/gnu-13/export/gnu/src/gcc/gcc/gcc/testsuite/../../include
> -I/net/gnu-13/export/gnu/src/gcc/gcc/gcc/testsuite/../../libcpp/include  -I -O
> -DIN_GCC -fPIC -shared
> /net/gnu-13/export/gnu/src/gcc/gcc/gcc/testsuite/gcc.dg/plugin/selfassign.c  
> -lm   -m32 -o selfassign.so(timeout = 300)
> Executing on host: /export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
> -B/export/build/gnu/gcc/build-x86_64-linux/gcc/
> /net/gnu-13/export/gnu/src/gcc/gcc/gcc/testsuite/gcc.dg/plugin/self-assign-test-1.c
>  -fplugin=./selfassign.so -O -S  -m32 -o self-assign-test-1.s(timeout =
> 300)
> cc1: error: Cannot load plugin ./selfassign.so^M
> ./selfassign.so: cannot open shared object file: No such file or directory^M
> 
> I think LD_LIBRARY_PATH was set to multilib path. But for this case,
> it should be set to the current dir.

I read the problem differently.  I presume -m32 are your multilib flags.  
It looks like both the plugin and the code being built with a compiler 
loading the plugin have been built with the multilib flags, and the error 
is because a 64-bit compiler ignores a 32-bit plugin.

Plugins must never be built with multilib flags; they must be built with 
the *host* compiler, and while that's the same compiler as the target 
compiler in the native case, they must still not use the multilib flags 
because those won't generally be compatible with the compiler binary.  The 
second compilation, the only loading the plugin, is the one that should 
keep using the multilib flags.


-- 


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

[Bug tree-optimization/40049] Incorrect tree made for vector shifted by constant on powerpc, spu

[rguenth at gcc dot gnu dot org]

--- Comment #7 from rguenth at gcc dot gnu dot org  2009-05-06 20:15 ---
Yep, that patch makes more sense.  Please make sure to also test x86_64. 
Thanks.


-- 


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

[Bug debug/40040] gfortran invalid DW_AT_location for overridable variables

[jan dot kratochvil at redhat dot com]

--- Comment #5 from jan dot kratochvil at redhat dot com  2009-05-06 20:12 
---
(In reply to comment #4)
> I don't know how ready GDB et al are to cope with this,

(For GDB the local definitions containing an address expression are even less
problematic than the current declarations requiring mangled symbols resolving.)


-- 


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

[Bug testsuite/40050] New: plugin tests don't work with multilib

[hjl dot tools at gmail dot com]

On Linux/Intel64, 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/ -I.
-I/net/gnu-13/export/gnu/src/gcc/gcc/gcc/testsuite
-I/net/gnu-13/export/gnu/src/gcc/gcc/gcc/testsuite/../../gcc
-I/export/build/gnu/gcc/build-x86_64-linux/gcc/testsuite/gcc/../../../gcc 
-I/net/gnu-13/export/gnu/src/gcc/gcc/gcc/testsuite/../../include
-I/net/gnu-13/export/gnu/src/gcc/gcc/gcc/testsuite/../../libcpp/include  -I -O
-DIN_GCC -fPIC -shared
/net/gnu-13/export/gnu/src/gcc/gcc/gcc/testsuite/gcc.dg/plugin/selfassign.c  
-lm   -m32 -o selfassign.so(timeout = 300)
Executing on host: /export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/
/net/gnu-13/export/gnu/src/gcc/gcc/gcc/testsuite/gcc.dg/plugin/self-assign-test-1.c
 -fplugin=./selfassign.so -O -S  -m32 -o self-assign-test-1.s(timeout =
300)
cc1: error: Cannot load plugin ./selfassign.so^M
./selfassign.so: cannot open shared object file: No such file or directory^M

I think LD_LIBRARY_PATH was set to multilib path. But for this case,
it should be set to the current dir.


-- 
   Summary: plugin tests don't work with multilib
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com


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

[Bug tree-optimization/40049] Incorrect tree made for vector shifted by constant on powerpc, spu

[meissner at linux dot vnet dot ibm dot com]

--- Comment #6 from meissner at linux dot vnet dot ibm dot com  2009-05-06 
20:00 ---
Created an attachment (id=17813)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17813&action=view)
More targetted patch to fix the problem

This patch is much more targeted to just make sure vector shifts by constant or
loop invarients have the correct type on machines with vector/vector shifts,
and not vector/scalar shifts.


-- 

meissner at linux dot vnet dot ibm dot com changed:

   What|Removed |Added

  Attachment #17811|0   |1
is obsolete||


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

[Bug rtl-optimization/33928] [4.3/4.4/4.5 Regression] 30% performance slowdown in floating-point code caused by r118475

[lucier at math dot purdue dot edu]

--- Comment #63 from lucier at math dot purdue dot edu  2009-05-06 19:57 
---
Was the patch in comment 55 meant for me to bootstrap and test with today's
mainline?  It crashes at the gcc_assert at

/* Subroutine of canon_reg.  Pass *XLOC through canon_reg, and validate
   the result if necessary.  INSN is as for canon_reg.  */

static void
validate_canon_reg (rtx *xloc, rtx insn)
{
  if (*xloc)
{
  rtx new_rtx = canon_reg (*xloc, insn);

  /* If replacing pseudo with hard reg or vice versa, ensure the
 insn remains valid.  Likewise if the insn has MATCH_DUPs.  */
  gcc_assert (insn && new_rtx);
  validate_change (insn, xloc, new_rtx, 1);
}
}

when building libgcc:

/tmp/lucier/gcc/objdirs/mainline/./gcc/xgcc
-B/tmp/lucier/gcc/objdirs/mainline/./gcc/
-B/pkgs/gcc-mainline/x86_64-unknown-linux-gnu/bin/
-B/pkgs/gcc-mainline/x86_64-unknown-linux-gnu/lib/ -isystem
/pkgs/gcc-mainline/x86_64-unknown-linux-gnu/include -isystem
/pkgs/gcc-mainline/x86_64-unknown-linux-gnu/sys-include -g -O2 -m32 -O2  -g -O2
-DIN_GCC   -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-Wcast-qual -Wold-style-definition  -isystem ./include  -fPIC -g
-DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED   -I. -I.
-I../../.././gcc -I../../../../../mainline/libgcc
-I../../../../../mainline/libgcc/. -I../../../../../mainline/libgcc/../gcc
-I../../../../../mainline/libgcc/../include
-I../../../../../mainline/libgcc/config/libbid -DENABLE_DECIMAL_BID_FORMAT
-DHAVE_CC_TLS -DUSE_TLS -o _moddi3.o -MT _moddi3.o -MD -MP -MF _moddi3.dep
-DL_moddi3 -c ../../../../../mainline/libgcc/../gcc/libgcc2.c \
  -fexceptions -fnon-call-exceptions -fvisibility=hidden -DHIDE_EXPORTS
../../../../../mainline/libgcc/../gcc/libgcc2.c: In function â:
../../../../../mainline/libgcc/../gcc/libgcc2.c:1121: internal compiler error:
in validate_canon_reg, at cse.c:2730


-- 


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

[Bug debug/40040] gfortran invalid DW_AT_location for overridable variables

[roland at redhat dot com]

--- Comment #4 from roland at redhat dot com  2009-05-06 19:45 ---
Hmm.  I am concerned by the idea of relocs for DWARF sections in final-linked
objects.  That is a hassle that consumers have not had to handle before. 
(AFAIK only consumers that handle ET_REL pseudo-final objects such as Linux
kernel .ko modules cope with reloc sections at all.)

I think what's ideal in the abstract is that the location expression indicates
how the variable is really accessed, i.e. loading the address from the GOT or
whatever it really does.

That might not always be possible in the defining declaration.  e.g., when the
definition is in a CU where there are no accesses, perhaps it can't tell
whether other CUs will be using direct addressing (e.g. @GOTOFF) or
GOT-indirect.

I read DWARF 3 section 4.1 item 4 to suggest that there should be a defining
DW_TAG_variable whose DW_AT_location can be the "base" one, i.e. direct address
in the definer, plus non-defining DW_TAG_variable (with DW_AT_declaration) DIEs
whose DW_AT_location expressions indicate how the variable is accessed in each
scope using it.  So, in the "main program" CU the DW_TAG_variable should have
DW_AT_declaration, DW_AT_external, and a DW_AT_location describing the main
program's copy (or its GOT lookup if PIC).  In the non-defining accessing CUs
in a DSO, there should be a similar DIE whose DW_AT_location describes that
DSO's GOT lookup, etc.  If the defining CU also contains accesses, then the
defining DW_TAG_variable's DW_AT_location would describe the GOT access if
that's what that CU uses, and then no DIE anywhere would have the direct
address location expression for the DSO initializer/copy.

I don't know how ready GDB et al are to cope with this, but it seems like the
"correct" route to me.  They'd have to find the right DIE for the scope of the
access, so it has the appropriate location expression.  For "blind" global
lookups, it would have to be sure to use the "dominating" DIE, i.e. choose one
somewhere in the main program before the defining definition in the DSO.


-- 


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

[Bug tree-optimization/40049] Incorrect tree made for vector shifted by constant on powerpc, spu

[meissner at linux dot vnet dot ibm dot com]

--- Comment #5 from meissner at linux dot vnet dot ibm dot com  2009-05-06 
19:35 ---
Subject: Re:  Incorrect tree made for vector shifted by constant on powerpc,
spu

On Wed, May 06, 2009 at 07:22:25PM -, rguenth at gcc dot gnu dot org wrote:
> 
> 
> --- Comment #4 from rguenth at gcc dot gnu dot org  2009-05-06 19:22 
> ---
> See http://gcc.gnu.org/ml/gcc-cvs/2009-04/msg01532.html
> 
> 
> -- 
> 
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40049
> 
> --- You are receiving this mail because: ---
> You reported the bug, or are watching the reporter.

The integer constants might have the correct types elsewhere, but in the
specific case of vector shifts, the type is SImode and not HImode.  Perphaps, I
need to make the patch more specific for just shifts.

Powerpc and spu would be the only machines that this shows up on.  X86_64 has
vector/vector shifts for SSE5 mode, but it is unlikely many people would notice
at this stage (also, the x86 has vector shift by constant, in addition to the
vector/vector shift of SSE5).


-- 


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

[Bug tree-optimization/40049] Incorrect tree made for vector shifted by constant on powerpc, spu

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2009-05-06 19:22 ---
See http://gcc.gnu.org/ml/gcc-cvs/2009-04/msg01532.html


-- 


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

[Bug tree-optimization/40049] Incorrect tree made for vector shifted by constant on powerpc, spu

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2009-05-06 19:20 ---
Wait - I patched this area exactly to avoid type verification issues on x86_64
...

(what do you mean by integer constants do not have a type?  They definitely
do on the tree level)


-- 


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

[Bug tree-optimization/40049] Incorrect tree made for vector shifted by constant on powerpc, spu

[meissner at linux dot vnet dot ibm dot com]

--- Comment #2 from meissner at linux dot vnet dot ibm dot com  2009-05-06 
19:19 ---
Created an attachment (id=17812)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17812&action=view)
Simplified test case

This testcase shows the problem.  Without the patch, it generates a vspltiw
(vector splat immediate word) when it should generate vspltish.  Using vsplitw
means that every other vector element will be shifted by 0 instead of 2.


-- 


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

[Bug tree-optimization/40049] Incorrect tree made for vector shifted by constant on powerpc, spu

[meissner at linux dot vnet dot ibm dot com]

--- Comment #1 from meissner at linux dot vnet dot ibm dot com  2009-05-06 
19:08 ---
Created an attachment (id=17811)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17811&action=view)
Patch to fix vector shift by constant on machines with vector/vector shift

This patch fixes the problem in the small case.  While there, I fixed the FIXME
in the next section to use build_constructor instead of
build_constructor_from_list.


-- 


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

[Bug tree-optimization/40049] New: Incorrect tree made for vector shifted by constant on powerpc, spu

[meissner at linux dot vnet dot ibm dot com]

On machines with only a vector/vector shift like the powerpc and spu, the wrong
type is generated for the tree vector that is created with the constant
splat'ed to fill the vector.  The problem is the code uses
get_vectype_for_scalar_type, and integer constants don't have a type.  So
get_vectype_for_scalar_type returns V4SI, even if the vector in question is
V8HI or V16QI.  Before the added type validation was added on April 27th, this
appeared to work because nothing looked at the type field.  With the current
code, this can lead to incorrect code being generated, and for larger programs
the compiler will die due to garbage collection failure.


-- 
   Summary: Incorrect tree made for vector shifted by constant on
powerpc, spu
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: meissner at linux dot vnet dot ibm dot com
 GCC build triplet: powerpc64-unknown-linux-gnu
  GCC host triplet: powerpc64-unknown-linux-gnu
GCC target triplet: powerpc64-unknown-linux-gnu


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

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

[dodji at gcc dot gnu dot org]

--- Comment #9 from dodji at gcc dot gnu dot org  2009-05-06 18:56 ---
I have submitted a patch for this at
http://gcc.gnu.org/ml/gcc-patches/2009-05/msg00270.html.


-- 


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

[Bug middle-end/40021] [4.5 Regression] Revision 146817 miscompiled DAXPY in BLAS

[hjl at gcc dot gnu dot org]

--- Comment #15 from hjl at gcc dot gnu dot org  2009-05-06 17:47 ---
Subject: Bug 40021

Author: hjl
Date: Wed May  6 17:45:40 2009
New Revision: 147195

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147195
Log:
2009-05-06  H.J. Lu  

Backport from mainline:
2009-05-06  H.J. Lu  

PR middle-end/40021
* gfortran.fortran-torture/execute/pr40021.f: New.

2009-05-05  Richard Guenther  

PR middle-end/40023
* gcc.c-torture/compile/pr40023.c: New testcase.

2009-05-03  Richard Guenther  

PR c/39983
* gcc.c-torture/compile/pr39983.c: New testcase.

Added:
branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/compile/pr39983.c
  - copied unchanged from r147193,
trunk/gcc/testsuite/gcc.c-torture/compile/pr39983.c
branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/compile/pr40023.c
  - copied unchanged from r147194,
trunk/gcc/testsuite/gcc.c-torture/compile/pr40023.c
   
branches/gcc-4_4-branch/gcc/testsuite/gfortran.fortran-torture/execute/pr40021.f
  - copied unchanged from r147193,
trunk/gcc/testsuite/gfortran.fortran-torture/execute/pr40021.f
Modified:
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug c/39983] ICE: type mismatch in address expression

[hjl at gcc dot gnu dot org]

--- Comment #6 from hjl at gcc dot gnu dot org  2009-05-06 17:47 ---
Subject: Bug 39983

Author: hjl
Date: Wed May  6 17:45:40 2009
New Revision: 147195

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147195
Log:
2009-05-06  H.J. Lu  

Backport from mainline:
2009-05-06  H.J. Lu  

PR middle-end/40021
* gfortran.fortran-torture/execute/pr40021.f: New.

2009-05-05  Richard Guenther  

PR middle-end/40023
* gcc.c-torture/compile/pr40023.c: New testcase.

2009-05-03  Richard Guenther  

PR c/39983
* gcc.c-torture/compile/pr39983.c: New testcase.

Added:
branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/compile/pr39983.c
  - copied unchanged from r147193,
trunk/gcc/testsuite/gcc.c-torture/compile/pr39983.c
branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/compile/pr40023.c
  - copied unchanged from r147194,
trunk/gcc/testsuite/gcc.c-torture/compile/pr40023.c
   
branches/gcc-4_4-branch/gcc/testsuite/gfortran.fortran-torture/execute/pr40021.f
  - copied unchanged from r147193,
trunk/gcc/testsuite/gfortran.fortran-torture/execute/pr40021.f
Modified:
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug middle-end/40023] type mismatch in address expression

[hjl at gcc dot gnu dot org]

--- Comment #8 from hjl at gcc dot gnu dot org  2009-05-06 17:47 ---
Subject: Bug 40023

Author: hjl
Date: Wed May  6 17:45:40 2009
New Revision: 147195

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147195
Log:
2009-05-06  H.J. Lu  

Backport from mainline:
2009-05-06  H.J. Lu  

PR middle-end/40021
* gfortran.fortran-torture/execute/pr40021.f: New.

2009-05-05  Richard Guenther  

PR middle-end/40023
* gcc.c-torture/compile/pr40023.c: New testcase.

2009-05-03  Richard Guenther  

PR c/39983
* gcc.c-torture/compile/pr39983.c: New testcase.

Added:
branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/compile/pr39983.c
  - copied unchanged from r147193,
trunk/gcc/testsuite/gcc.c-torture/compile/pr39983.c
branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/compile/pr40023.c
  - copied unchanged from r147194,
trunk/gcc/testsuite/gcc.c-torture/compile/pr40023.c
   
branches/gcc-4_4-branch/gcc/testsuite/gfortran.fortran-torture/execute/pr40021.f
  - copied unchanged from r147193,
trunk/gcc/testsuite/gfortran.fortran-torture/execute/pr40021.f
Modified:
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug fortran/40037] gfortran -O3 optimization generates code that seg faults on unaligned array data

[hjl dot tools at gmail dot com]

--- Comment #4 from hjl dot tools at gmail dot com  2009-05-06 17:39 ---
(In reply to comment #3)
> The code generated for SMALL is correct, any caller that passes argument not
> aligned on 8 byte boundary (you are mistaken that it requires 16 byte
> alignment,
> try calling it with c(3) which is 8 byte aligned, but not 16 byte aligned and
> it will work too) is invalid.  All DOUBLE PRECISION variables/arrays must be
> properly aligned on 8 byte boundaries.
> 

I believe x86-64 psABI requires that all arrays >= 16byte must be aligned
at 16byte.


-- 


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

[Bug middle-end/39986] decimal float constant is incorrect when cc1 is a 64-bit binary

[janis at gcc dot gnu dot org]

--- Comment #5 from janis at gcc dot gnu dot org  2009-05-06 17:18 ---
This was a regression after all, release branches do not have the bug.  I added
the new test case to the 4.4 and 4.3 branches.


-- 

janis at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug middle-end/39986] decimal float constant is incorrect when cc1 is a 64-bit binary

[janis at gcc dot gnu dot org]

--- Comment #4 from janis at gcc dot gnu dot org  2009-05-06 17:01 ---
Subject: Bug 39986

Author: janis
Date: Wed May  6 16:59:53 2009
New Revision: 147188

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147188
Log:
PR middle-end/39986
* dfp.c (encode_decimal32, decode_decimal32, encode_decimal64,
decode_decimal64, encode_decimal128, decode_decimal128): Avoid
32-bit memcpy into long.

* gcc.dg/dfp/pr39986.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/dfp/pr39986.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/dfp.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug middle-end/40021] [4.5 Regression] Revision 146817 miscompiled DAXPY in BLAS

[matz at gcc dot gnu dot org]

--- Comment #14 from matz at gcc dot gnu dot org  2009-05-06 16:54 ---
Hence, fixed.


-- 

matz at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug middle-end/40021] [4.5 Regression] Revision 146817 miscompiled DAXPY in BLAS

[matz at gcc dot gnu dot org]

--- Comment #13 from matz at gcc dot gnu dot org  2009-05-06 16:50 ---
Subject: Bug 40021

Author: matz
Date: Wed May  6 16:49:13 2009
New Revision: 147186

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147186
Log:
PR middle-end/40021
* cfgexpand.c (maybe_cleanup_end_of_block): New static function.
(expand_gimple_cond): Use it to cleanup CFG and superfluous jumps.

* gfortran.dg/pr40021.f: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/pr40021.f
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cfgexpand.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug debug/40040] gfortran invalid DW_AT_location for overridable variables

[burnus at gcc dot gnu dot org]

--- Comment #3 from burnus at gcc dot gnu dot org  2009-05-06 16:40 ---
(In reply to comment #2)
> The GDB patch now assembles the symbol name from its parent DW_TAG_module as
> `__modulename_MOD_varname'.  As GDB also has to know the C++ mangling rules I
> believe this Fortran mangling is can be also used from GDB.

Note: The Fortran mangling is highly compiler dependent. Intel's ifort uses
"modulename_mp_varname_", sunf95 uses "modulename.varname_", and g95 and NAG
f95 use "modulename_MP_varname" (however,  the latter two don't create
DW_TAG_module - g95 is based on gcc 4.0.x and NAG f95 uses the system's C
compiler).


-- 


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

[Bug middle-end/32667] builtin operator= generates memcpy with overlapping memory regions

[ppluzhnikov at google dot com]

--- Comment #5 from ppluzhnikov at google dot com  2009-05-06 16:36 ---
(In reply to comment #3)

> Note that this is likely not a problem in practice as 
>  memcpy (p, p, sizeof (*p)) is difficult to implement
> in a way that would make it not work.

>From Julian Seward:

JS> AIUI, POSIX says the src==dst case is not allowed (along with all other
JS> overlapping cases) because (eg) on PowerPC, it is possible to make a high
JS> performance memcpy that preallocates the destination area in D1 using
JS> dcbz instructions, which create the line in D1 and fill it full of
JS> zeroes.  This avoids dragging the destination line up the memory
JS> hierarchy only to completely overwrite it with stuff from the source.
JS>
JS> Result is however that if the src and dst overlap, in any way, including
JS> completely, then this causes zeroes to be written into the src area (!)
JS> which is certainly not what you want.

This bug is likely fixed by:
http://gcc.gnu.org/ml/gcc-patches/2009-04/msg00932.html


-- 


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

[Bug c++/40048] Compiler crash possibly related to --std=c++0x

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2009-05-06 16:18 ---
Works for me on the branch head.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Known to work||4.4.1 4.5.0
 Resolution||WORKSFORME
Summary|Compiler crash  |Compiler crash possibly
   ||related to --std=c++0x


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

[Bug c++/40048] Compiler crash

[bgalehouse at spamcop dot net]

--- Comment #2 from bgalehouse at spamcop dot net  2009-05-06 16:04 ---
Just found that it seems unrelated to c++0x features. I configured the library
to not require them, and found the 4.4.0 crashes but the system compiler works.
(both running same options, without the -std=c++0x, but otherwise as
previously)

I'm happy to provide additional .ii files and so on if necessary.


-- 

bgalehouse at spamcop dot net changed:

   What|Removed |Added

Summary|Compiler crash possibly |Compiler crash
   |related to --std=c++0x  |


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

[Bug middle-end/39958] [4.5 Regression] OMP tasking creates invalid gimple

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2009-05-06 15:56 ---
*** Bug 40047 has been marked as a duplicate of this bug. ***


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu dot
   ||org


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

[Bug libgomp/40047] [4.5 Regression] ICE for libgomp.c++/task-4.C: type mismatch in indirect reference

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2009-05-06 15:56 ---


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


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug c++/40048] Compiler crash possibly related to --std=c++0x

[bgalehouse at spamcop dot net]

--- Comment #1 from bgalehouse at spamcop dot net  2009-05-06 15:53 ---
Created an attachment (id=17810)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17810&action=view)
Compressed preprocessed source to recreate.

Attached proprocessed source file, compressed to fit under bugtraq size limit.


-- 


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

[Bug bootstrap/39929] [4.5 Regression] Bootstrapping fails at stage 1 on powerpc-ibm-aix

[matz at gcc dot gnu dot org]

--- Comment #20 from matz at gcc dot gnu dot org  2009-05-06 15:48 ---
Bootstrap on AIX was already working on April 29:
http://gcc.gnu.org/ml/gcc-patches/2009-04/msg02342.html

I just left this open for the other (ARM/Mips) problem.  As that now moved
somewhere else, this here is fixed.


-- 

matz at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||FIXED


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

[Bug middle-end/40021] [4.5 Regression] Revision 146817 miscompiled DAXPY in BLAS

[hjl dot tools at gmail dot com]

--- Comment #12 from hjl dot tools at gmail dot com  2009-05-06 15:48 
---
(In reply to comment #11)
> (In reply to comment #10)
> > Yes, I'll clean this up before submission.  Did it help?
> > 
> 
> I tried it on revision 147173 and it works on test input for
> 416.gamess and 465.tonto. I am running reference input now. Thanks.
> 

It fixed 416.gamess and 465.tonto with reference input.


-- 


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

[Bug c++/40048] New: Compiler crash possibly related to --std=c++0x

[bgalehouse at spamcop dot net]

The following was produced on a gentoo x86 linux system with a pentium-m
processor, the system compiler is Gentoo 4.3.3-r2 and kernel is
linux-2.6.28-gentoo-r5. 

Last night, I built gcc 4.4.0 and installed it into /home/bgalehouse/installs. 
I then reconfigured a library (CGAL) to make use of c++0x features, and tried
to compile a program. This program worked fine under the system compiler when
the library is configured to avoid c++0x features. I might have time to compile
and try a recent snapshot over the next few days, if so I'll try to amend this
bug report accordingly.

g++ -v --save-temps -c --std=c++0x -g -O0 -Wall -D_GLIBCXX_DEBUG
-I/home/bgalehouse/installs/include -Isubdivision_trees -I.  meshTangleCube.cpp
-o meshTangleCube.o
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ./configure --prefix=/home/bgalehouse/installs/
--enable-languages=c,c++ --with-ppl=/home/bgalehouse/install
--with-cloog=/home/bgalehouse/install --with-gmp=/home/bgalehouse/install
Thread model: posix
gcc version 4.4.0 (GCC) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-c' '-std=c++0x' '-g' '-O0' '-Wall'
'-D_GLIBCXX_DEBUG' '-I/home/bgalehouse/installs/include' '-Isubdivision_trees'
'-I.' '-o' 'meshTangleCube.o' '-shared-libgcc' '-mtune=generic'
 /home/bgalehouse/installs/bin/../libexec/gcc/i686-pc-linux-gnu/4.4.0/cc1plus
-E -quiet -v -I/home/bgalehouse/installs/include -Isubdivision_trees -I.
-iprefix /home/bgalehouse/installs/bin/../lib/gcc/i686-pc-linux-gnu/4.4.0/
-D_GNU_SOURCE -D_GLIBCXX_DEBUG m
eshTangleCube.cpp -mtune=generic -std=c++0x -Wall -g -fworking-directory -O0
-fpch-preprocess -o meshTangleCube.ii
ignoring nonexistent directory
"/home/bgalehouse/installs/bin/../lib/gcc/i686-pc-linux-gnu/4.4.0/../../../../i686-pc-linux-gnu/include"
ignoring duplicate directory
"/home/bgalehouse/installs/bin/../lib/gcc/../../lib/gcc/i686-pc-linux-gnu/4.4.0/../../../../include/c++/4.4.0"
ignoring duplicate directory
"/home/bgalehouse/installs/bin/../lib/gcc/../../lib/gcc/i686-pc-linux-gnu/4.4.0/../../../../include/c++/4.4.0/i686-pc-linux-gnu"
ignoring duplicate directory
"/home/bgalehouse/installs/bin/../lib/gcc/../../lib/gcc/i686-pc-linux-gnu/4.4.0/../../../../include/c++/4.4.0/backward"
ignoring nonexistent directory "/usr/local/include"
ignoring duplicate directory
"/home/bgalehouse/installs/bin/../lib/gcc/../../include"
ignoring duplicate directory
"/home/bgalehouse/installs/bin/../lib/gcc/../../lib/gcc/i686-pc-linux-gnu/4.4.0/include"
ignoring duplicate directory
"/home/bgalehouse/installs/bin/../lib/gcc/../../lib/gcc/i686-pc-linux-gnu/4.4.0/include-fixed"
ignoring nonexistent directory
"/home/bgalehouse/installs/bin/../lib/gcc/../../lib/gcc/i686-pc-linux-gnu/4.4.0/../../../../i686-pc-linux-gnu/include"
ignoring duplicate directory "/home/bgalehouse/installs/include"
  as it is a non-system directory that duplicates a system directory
ignoring duplicate directory "/home/bgalehouse/installs/include/"
  as it is a non-system directory that duplicates a system directory
#include "..." search starts here:
#include <...> search starts here:
 subdivision_trees
 .
 /home/bgalehouse/installs/include/

/home/bgalehouse/installs/bin/../lib/gcc/i686-pc-linux-gnu/4.4.0/../../../../include/c++/4.4.0

/home/bgalehouse/installs/bin/../lib/gcc/i686-pc-linux-gnu/4.4.0/../../../../include/c++/4.4.0/i686-pc-linux-gnu

/home/bgalehouse/installs/bin/../lib/gcc/i686-pc-linux-gnu/4.4.0/../../../../include/c++/4.4.0/backward
 /home/bgalehouse/installs/bin/../lib/gcc/i686-pc-linux-gnu/4.4.0/include
 /home/bgalehouse/installs/bin/../lib/gcc/i686-pc-linux-gnu/4.4.0/include-fixed
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-c' '-std=c++0x' '-g' '-O0' '-Wall'
'-D_GLIBCXX_DEBUG' '-I/home/bgalehouse/installs/include' '-Isubdivision_trees'
'-I.' '-o' 'meshTangleCube.o' '-shared-libgcc' '-mtune=generic'
 /home/bgalehouse/installs/bin/../libexec/gcc/i686-pc-linux-gnu/4.4.0/cc1plus
-fpreprocessed meshTangleCube.ii -quiet -dumpbase meshTangleCube.cpp
-mtune=generic -auxbase-strip meshTangleCube.o -g -O0 -Wall -std=c++0x -version
-o meshTangleCube.s
GNU C++ (GCC) version 4.4.0 (i686-pc-linux-gnu)
compiled by GNU C version 4.4.0, GMP version 4.3, MPFR version
2.4.1-p1.
warning: GMP header version 4.3 differs from library version 4.3.0.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: a06cae60c4bc667b19bd2a267478aeb7
In file included from FunctionInfo.h++:5,
 from SimpleHull.h++:11,
 from CGALHullFinder.h++:4,
 from meshTangleCube.cpp:10:
subdivision_trees/CGAL/Spatial_subdivision_tree.h: In member function
'CGAL::Spatial_subdivision_tree::rect_reference
CGAL::Spatial_subdivision_tree::root_reference() [with unsigned int
a_dim = 3u, D_ = CGALHullFinder,
CGAL::Linear_algebraCd<__gmp_expr<__mpq_struct [1], __mpq_struct [1]>,
std::allocator<__gmp_expr<__mpq_struct [1], __mpq_struct [1]> > > >,
tangleCubeFunction<3

[Bug fortran/40041] spurious warning with INTRINSIC statement

[burnus at gcc dot gnu dot org]

--- Comment #5 from burnus at gcc dot gnu dot org  2009-05-06 15:46 ---
FIXED on the trunk (4.5). Thanks for reporting it.

Crossref: The warning was added by Daniel Franke with Rev. 126153 for PR 20373.


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug fortran/40041] spurious warning with INTRINSIC statement

[burnus at gcc dot gnu dot org]

--- Comment #4 from burnus at gcc dot gnu dot org  2009-05-06 15:45 ---
Subject: Bug 40041

Author: burnus
Date: Wed May  6 15:44:18 2009
New Revision: 147183

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147183
Log:
2009-05-06  Tobias Burnus  

PR fortran/40041
* resolve.c (resolve_symbol): Print no warning for implicitly
typed intrinsic functions.

2009-05-06  Tobias Burnus  

PR fortran/40041
* gfortran.dg/intrinsic_2.f90: New test.
* gfortran.dg/intrinsic.f90: Add old and this PR as comment.


Added:
trunk/gcc/testsuite/gfortran.dg/intrinsic_2.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/intrinsic.f90


-- 


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

[Bug middle-end/39978] [4.5 Regression] SEGV compiling libiberty/regex.c in stage2

[bonzini at gnu dot org]

--- Comment #7 from bonzini at gnu dot org  2009-05-06 15:35 ---
Is this reproducible with a crosscompiler and with --enable-checking=all,gcac? 
You can try valgrind too.


-- 

bonzini at gnu dot org changed:

   What|Removed |Added

 CC||bonzini at gnu dot org


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

[Bug bootstrap/39929] [4.5 Regression] Bootstrapping fails at stage 1 on powerpc-ibm-aix

[bonzini at gnu dot org]

--- Comment #19 from bonzini at gnu dot org  2009-05-06 15:33 ---
ARM moved to PR40031 (and PR39978?).

What about AIX?


-- 

bonzini at gnu dot org changed:

   What|Removed |Added

 Status|NEW |WAITING


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

[Bug tree-optimization/39999] [4.4/4.5 Regression] gcc 4.4.0 compiles in infinite loop

[mmitchel at gcc dot gnu dot org]

-- 

mmitchel at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P1


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

[Bug libgomp/40047] [4.5 Regression] ICE for libgomp.c++/task-4.C: type mismatch in indirect reference

[burnus at gcc dot gnu dot org]

-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.5.0
Version|unknown |4.5.0


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

[Bug libgomp/40047] New: [4.5 Regression] ICE for libgomp.c++/task-4.C: type mismatch in indirect reference

[burnus at gcc dot gnu dot org]

Compiling "libgomp.c++/task-4.C" with "g++" is successful, but compiling it
with "g++ -fopenmp" gives:

libgomp.c++/task-4.C: In function 'void foo(int, int)':
libgomp.c++/task-4.C:37: error: type mismatch in indirect reference
int[0:D.2193]

int[0:<<< error >>>]

D.2218 = &(*q.1)[0];

libgomp.c++/task-4.C:37: error: type mismatch in indirect reference
int[0:D.2173]

int[0:<<< error >>>]

D.2219 = &(*p.0)[0];

libgomp.c++/task-4.C:37: internal compiler error: verify_stmts failed


(It might be not a true regression but a side effect of stricter type checking
in 4.5.)


-- 
   Summary: [4.5 Regression] ICE for libgomp.c++/task-4.C: type
mismatch in indirect reference
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: libgomp
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org


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

[Bug rtl-optimization/33928] [4.3/4.4/4.5 Regression] 30% performance slowdown in floating-point code caused by r118475

[bonzini at gnu dot org]

--- Comment #62 from bonzini at gnu dot org  2009-05-06 15:07 ---
No, totally unrelated to PR39871


-- 


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

[Bug rtl-optimization/39871] [4.3/4.4/4.5 regression] Code size increase on ARM due to inferior CSE

[bonzini at gnu dot org]

--- Comment #1 from bonzini at gnu dot org  2009-05-06 15:06 ---
With 4.5 I see
With 4.5.0 I see:

push{lr}
sub sp, sp, #12
ldr r2, [r0]
ldr r1, [r0, #4]
mov r0, sp
str r2, [sp, #4]
bl  func
add sp, sp, #12
pop {pc}

Can you bisect which revision fixed this?


-- 

bonzini at gnu dot org changed:

   What|Removed |Added

 CC||bonzini at gnu dot org
  Known to work||4.5.0


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

[Bug fortran/40045] ICE with type extension and -fdump-parse-tree

[domob at gcc dot gnu dot org]

--- Comment #4 from domob at gcc dot gnu dot org  2009-05-06 15:01 ---
Yes, that sounds like a problem caused by my patch; it did change the structure
of storing the type-bounds, so maybe simply changing the if to the one shown by
Tobias was wrong.

I will look into this!


-- 

domob at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |domob at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-05-06 15:01:04
   date||


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

[Bug fortran/40045] ICE with type extension and -fdump-parse-tree

[janus at gcc dot gnu dot org]

--- Comment #3 from janus at gcc dot gnu dot org  2009-05-06 14:58 ---
(In reply to comment #2)
> and the interesting question is: Why is it called? There are no type-bound
> procedures (and also no components [except of t2%t]. 

If it's a regression it may be caused by Daniel's r146733 ("reworking
type-bound procedures")?!?



> Related problem: The following gives: show_code_node(): Bad statement code

I will handle this in my PPC patch before committing.


-- 

janus at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||domob at gcc dot gnu dot org


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

[Bug bootstrap/40027] [4.4/4.5 regression] i686-pc-solaris2.10 bootstrap fails using Sun ld

[hjl dot tools at gmail dot com]

--- Comment #2 from hjl dot tools at gmail dot com  2009-05-06 14:51 ---
(In reply to comment #1)
> I've just confirmed the bug on i686-pc-solaris2.10.  It doesn't occur on
> i686-pc-solaris2.11, though, so this is indeed a Sun ld bug.
> 
> I've got a few questions to resolve, though:
> 
> * Why does generating code for i686 instead of i386 change gcc's assembler
> output
>   so significantly?
> 

The difference is in how to get PC for -fPIC:

bash-3.2$ cat p.c
void
foo ()
{
  bar ();
}
bash-3.2$ gcc -m32 -fPIC p.c -S -O3 -mtune=i386
bash-3.2$ cat p.s
.file   "p.c"
.text
.p2align 2,,3
.globl foo
.type   foo, @function
foo:
pushl   %ebp
movl%esp, %ebp
pushl   %ebx
subl$4, %esp
call.L3
.L3:
popl%ebx
addl$_GLOBAL_OFFSET_TABLE_+[.-.L3], %ebx
callb...@plt
popl%eax
popl%ebx
leave
ret
.size   foo, .-foo
.ident  "GCC: (GNU) 4.3.2 20081105 (Red Hat 4.3.2-7)"
.section.note.GNU-stack,"",@progbits
bash-3.2$ gcc -m32 -fPIC p.c -S -O3 -mtune=i686
bash-3.2$ cat p.s
.file   "p.c"
.text
.p2align 4,,15
.globl foo
.type   foo, @function
foo:
pushl   %ebp
movl%esp, %ebp
pushl   %ebx
call__i686.get_pc_thunk.bx
addl$_GLOBAL_OFFSET_TABLE_, %ebx
subl$4, %esp
callb...@plt
addl$4, %esp
popl%ebx
popl%ebp
ret
.size   foo, .-foo
.ident  "GCC: (GNU) 4.3.2 20081105 (Red Hat 4.3.2-7)"
.section   
.text.__i686.get_pc_thunk.bx,"axG",@progbits,__i686.get_pc_thunk.bx,comdat
.globl __i686.get_pc_thunk.bx
.hidden __i686.get_pc_thunk.bx
.type   __i686.get_pc_thunk.bx, @function
__i686.get_pc_thunk.bx:
movl(%esp), %ebx
ret
.section.note.GNU-stack,"",@progbits
bash-3.2$ 


-- 


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

[Bug fortran/40045] ICE with type extension and -fdump-parse-tree

[burnus at gcc dot gnu dot org]

--- Comment #2 from burnus at gcc dot gnu dot org  2009-05-06 14:39 ---
Regarding the segfault, valgrind shows:

==14376== Invalid read of size 1
==14376==by 0x616A4F7: fprintf (in /lib64/libc-2.9.so)
==14376==by 0x4B4BF1: show_typebound (dump-parse-tree.c:693)

The line is:
fprintf (dumpfile, "PASS(%s)", st->n.tb->pass_arg);
and the interesting question is: Why is it called? There are no type-bound
procedures (and also no components [except of t2%t]. Thus why is
  if (!st->n.tb)
return;
not working?

 * * *

Related problem: The following gives: show_code_node(): Bad statement code

type t
  procedure(), nopass, pointer :: p
end type t
type(t) m
!external bar
!m%p => bar
call m%p()
end


-- 


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

[Bug fortran/40045] ICE with type extension and -fdump-parse-tree

[dominiq at lps dot ens dot fr]

--- Comment #1 from dominiq at lps dot ens dot fr  2009-05-06 14:31 ---
Confirmed and this is regression with repect to 4.4.0:

[karma] f90/bug% gfc -fdump-parse-tree pr40045.f90

Namespace: A-H: (REAL 4) I-N: (INTEGER 4) O-Z: (REAL 4)
procedure name = MAIN__
symtree: MAIN__  Ambig 0
symbol MAIN__ (UNKNOWN 0)(PROGRAM UNKNOWN-INTENT PUBLIC UNKNOWN-PROC
UNKNOWN SUBROUTINE)

symtree: t  Ambig 0
symbol t (UNKNOWN 0)(DERIVED UNKNOWN-INTENT UNKNOWN-ACCESS UNKNOWN-PROC
UNKNOWN)
Procedure bindings:

f951: internal compiler error: Bus error
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
  PROCEDURE, [karma] f90/bug% 
[karma] f90/bug% gfc44 -fdump-parse-tree pr40045.f90

Namespace: A-H: (REAL 4) I-N: (INTEGER 4) O-Z: (REAL 4)
procedure name = MAIN__
symtree: MAIN__  Ambig 0
symbol MAIN__ (UNKNOWN 0)(PROGRAM UNKNOWN-INTENT PUBLIC UNKNOWN-PROC
UNKNOWN SUBROUTINE)

symtree: t  Ambig 0
symbol t (UNKNOWN 0)(DERIVED UNKNOWN-INTENT UNKNOWN-ACCESS UNKNOWN-PROC
UNKNOWN)
Procedure bindings:


symtree: t2  Ambig 0
symbol t2 (UNKNOWN 0)(DERIVED UNKNOWN-INTENT UNKNOWN-ACCESS
UNKNOWN-PROC UNKNOWN)
components: (t (DERIVED t) ())
Procedure bindings:


-- 


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

[Bug fortran/40041] spurious warning with INTRINSIC statement

[burnus at gcc dot gnu dot org]

--- Comment #3 from burnus at gcc dot gnu dot org  2009-05-06 14:28 ---
> Btw, adding "REAL ABS,MAX" doesn't help either, so it's not related to the
> function's types.

Well, exactly that should trigger the warning! Thus it shall not help silencing
the warning!

Some light testing - now that bootstrapping finished - shows that the patch
seems to work correctly. -> Assign to myself


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |burnus at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-05-06 14:28:48
   date||


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

[Bug middle-end/40021] [4.5 Regression] Revision 146817 miscompiled DAXPY in BLAS

[hjl dot tools at gmail dot com]

--- Comment #11 from hjl dot tools at gmail dot com  2009-05-06 14:27 
---
(In reply to comment #10)
> Yes, I'll clean this up before submission.  Did it help?
> 

I tried it on revision 147173 and it works on test input for
416.gamess and 465.tonto. I am running reference input now. Thanks.


-- 


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

[Bug other/40046] New: GCC build fails due to host_address variable is empty

[roman dot marchenko at mail dot ru]

There is the following line in configure script:

eval `${CC-cc} -E conftest.c | grep host_address=`

Since I have GREP_OPTIONS variable in my environment which looks like
"GREP_OPTIONS=--color=always", some color codes are generated in grep's output.
The issue is the "eval ..." does not work properly in this case and the
host_address variable is empty.

I have repaired the build by replacing the line with the following:

eval `${CC-cc} -E conftest.c | grep --color=auto host_address=`


-- 
   Summary: GCC build fails due to host_address variable is empty
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: roman dot marchenko at mail dot ru
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


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

[Bug tree-optimization/39999] [4.4/4.5 Regression] gcc 4.4.0 compiles in infinite loop

[rguenth at gcc dot gnu dot org]

--- Comment #5 from rguenth at gcc dot gnu dot org  2009-05-06 13:52 ---
Ok, I know what happens.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rguenth at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2009-05-02 10:19:57 |2009-05-06 13:52:20
   date||


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

[Bug fortran/40045] New: ICE with type extension and -fdump-parse-tree

[janus at gcc dot gnu dot org]

Segfault with -fdump-parse-tree:

type t
end type
type, extends(t) :: t2
end type t2
end


-- 
   Summary: ICE with type extension and -fdump-parse-tree
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: janus at gcc dot gnu dot org


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

[Bug tree-optimization/39999] [4.4/4.5 Regression] gcc 4.4.0 compiles in infinite loop

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2009-05-06 13:24 ---
Reduced testcase:

void foo(void *);
void
MMAPGCD (int *A1, int *A2)
{
  int *t; 

  do
{
  t = A1;
  A1 = A2;
  A2 = t;
}
  while (A2[-1]);

  foo (A1-1);
  foo (A2-1);
}   

if you make foo take int * the issue goes away.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to fail||4.4.0
  Known to work||4.3.3
Summary|gcc 4.4.0 compiles in   |[4.4/4.5 Regression] gcc
   |infinite loop   |4.4.0 compiles in infinite
   ||loop
   Target Milestone|--- |4.4.1


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

[Bug libstdc++/40038] [4.4/4.5 regression] symbols ce...@glibcxx_3.4.3 not exported

[paolo dot carlini at oracle dot com]

--- Comment #6 from paolo dot carlini at oracle dot com  2009-05-06 13:20 
---
Excellent. Then Matthias' suggested fix makes sense to me. Better if Benjamin
could also review it, however (lately, he touched this code, IIRC).


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-05-06 13:20:29
   date||


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

[Bug rtl-optimization/33928] [4.3/4.4/4.5 Regression] 30% performance slowdown in floating-point code caused by r118475

[jakub at gcc dot gnu dot org]

--- Comment #61 from jakub at gcc dot gnu dot org  2009-05-06 13:05 ---
Also see PR39871, maybe that's related (though on ARM).


-- 


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

[Bug c/40032] [4.5 regression] ICE with incomplete type in struct

[jsm28 at gcc dot gnu dot org]

--- Comment #2 from jsm28 at gcc dot gnu dot org  2009-05-06 13:04 ---
Fixed for 4.5.


-- 

jsm28 at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Known to work||4.5.0
 Resolution||FIXED


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

[Bug c/40032] [4.5 regression] ICE with incomplete type in struct

[jsm28 at gcc dot gnu dot org]

--- Comment #1 from jsm28 at gcc dot gnu dot org  2009-05-06 13:03 ---
Subject: Bug 40032

Author: jsm28
Date: Wed May  6 13:02:48 2009
New Revision: 147174

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147174
Log:
PR c/40032
* c-decl.c (grokdeclarator): Handle incomplete type of unnamed
field.

testsuite:
* gcc.dg/noncompile/incomplete-5.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/noncompile/incomplete-5.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-decl.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug libstdc++/40038] [4.4/4.5 regression] symbols ce...@glibcxx_3.4.3 not exported

[jakub at gcc dot gnu dot org]

--- Comment #5 from jakub at gcc dot gnu dot org  2009-05-06 13:02 ---
Only ceill is actually missing in SVN.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|[4.4/4.5 regression] symbols|[4.4/4.5 regression] symbols
   |ce...@glibcxx_3.4.3 and |ce...@glibcxx_3.4.3 not
   |ta...@glibcxx_3.4 not   |exported
   |exported|


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

[Bug bootstrap/40027] [4.4/4.5 regression] i686-pc-solaris2.10 bootstrap fails using Sun ld

[ro at gcc dot gnu dot org]

--- Comment #1 from ro at gcc dot gnu dot org  2009-05-06 13:01 ---
I've just confirmed the bug on i686-pc-solaris2.10.  It doesn't occur on
i686-pc-solaris2.11, though, so this is indeed a Sun ld bug.

I've got a few questions to resolve, though:

* Why does generating code for i686 instead of i386 change gcc's assembler
output
  so significantly?

* Is it possible to get the relevant CRs backported to Solaris 10 (or are fixes
  already included in recent linker/kernel patches)?

* How to handle this in gcc/configure.ac?  I'd like to avoid completely
  disabling hidden support on Solaris 10 (and even early versions of Solaris 11
  before the linker bug got fixed).


-- 

ro at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||ro at gcc dot gnu dot org
 AssignedTo|unassigned at gcc dot gnu   |ro at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-05-06 13:01:30
   date||


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

[Bug c++/40044] New: ICE when resolves overloaded functions

[vbvan at 163 dot com]

The following code will ICE:

template
void f(T*);

template
struct A {};

template
void g(A > *);

int main()
{
g((A >*)0);
}


-- 
   Summary: ICE when resolves overloaded functions
   Product: gcc
   Version: 4.3.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vbvan at 163 dot com


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

[Bug libstdc++/40042] delete doesn't always delete

[jakub at gcc dot gnu dot org]

--- Comment #5 from jakub at gcc dot gnu dot org  2009-05-06 12:14 ---
That just means you have no idea how a memory allocator works.
Returning all just freed pages immediately to the system is of course possible,
but terribly expensive performance wise, since often on the following malloc
call you'll need the memory again and mmapping it is very expensive.
glibc malloc has many options which allow you to fine tune things to the
behavior of your application, see mallopt or corresponding env variables, plus
recent glibcs (last year or two, don't remember) use madvise syscall in certain
cases to allow the kernel to reuse the pages for other process if needed, but
if not immediately needed for other process can be fairly cheaply used by the
current process for malloc again.


-- 


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

[Bug libstdc++/40042] delete doesn't always delete

[paolo dot carlini at oracle dot com]

--- Comment #4 from paolo dot carlini at oracle dot com  2009-05-06 12:07 
---
Oh well, if valgrind is happy, definitely not a libstdc++ maintainers job.


-- 


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

[Bug libstdc++/40042] delete doesn't always delete

[simonracz at gmail dot com]

--- Comment #3 from simonracz at gmail dot com  2009-05-06 12:03 ---
(In reply to comment #2)
> By the way, valgrind, correctly, doesn't report anything, at least together
> with glibc 2.9:

You can see the difference in memory usage (after deleting) with top.


-- 


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

[Bug middle-end/39954] [4.5 Regression] Revision 146817 caused unaligned access in gcc.dg/torture/pr26565.c

[matz at gcc dot gnu dot org]

--- Comment #18 from matz at gcc dot gnu dot org  2009-05-06 11:57 ---
The structure in this testcase is not packed.  One member is.  Or are you
talking about some different case?

Let's suppose you are and you mean something like this:
  struct S {T1 m1; T2 m2; ...} __attribute__((packed));
then IMO all members should also have DECL_PACKED set.  I don't think this
is currently the case (only TYPE_PACKED is set on the whole struct type), but
conceptually that is the ultimate meaning.

If we don't do that we still can create such unaligned types when building
COMPONENT_REFs, when the base datum has TYPE_PACKED set, i.e. option (2).
But let's deal with one case after the other, I'm currently concerned with
only packed members.


-- 


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

[Bug fortran/40041] spurious warning with INTRINSIC statement

[dfranke at gcc dot gnu dot org]

--- Comment #2 from dfranke at gcc dot gnu dot org  2009-05-06 11:57 ---
(In reply to comment #1)
> > The same warnings are given if the arguments of ABS/MAX are of default-real
> > kind, so this not related to implicit typing.
> 
> I have to admit that I don't fully understand that sentence, but I don't get
> the warning with IMPLICIT NONE. I also don't see the relation to the arguments
> of ABS/MAX -- I think it is about implicit typing of the result value of
> ABS/MAX itself.

IIRC, typing of 'a' and 'n' is enough to avoid the warnings as well. 

In above statement I assumed some interaction between INTEGER actual arguments
to an implicitly typed REAL ABS-function - and REAL-typed arguments to the
implicitly INTEGER-typed MAX-function. Thus, converting all the arguments to
REAL as in

  a(n) = MAX(ABS(2.0),ABS(3.0),REAL(n))

one could think that the warnings should vanish - they don't. So, I concluded,
that it's not related to the argument types.

Btw, adding "REAL ABS,MAX" doesn't help either, so it's not related to the
function's types.

I'll give your patch a try later today.


-- 


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

[Bug middle-end/39954] [4.5 Regression] Revision 146817 caused unaligned access in gcc.dg/torture/pr26565.c

[rguenther at suse dot de]

--- Comment #17 from rguenther at suse dot de  2009-05-06 11:45 ---
Subject: Re:  [4.5 Regression] Revision 146817 caused
 unaligned access in gcc.dg/torture/pr26565.c

On Wed, 6 May 2009, matz at gcc dot gnu dot org wrote:

> --- Comment #16 from matz at gcc dot gnu dot org  2009-05-06 11:20 ---
> Option (2) lies somewhere in between, although it should be nearly equivalent
> to option 1, as there aren't many other contexts than COMPONENT_REF where
> a pure FIELD_DECL could be used.  But option (2) has the advantage that the
> structure type is completely laid out already, not so for option (1).  That
> might be important for performance sometimes, e.g. when the user declares
> a field as packed (or aligned(1)), but it so happens (due to other members)
> that it got it's natural alignment in the end.  In that case we don't _have_
> to construct unaligned types.

I'm all for option (1), but concering (2) - a packed structure does
have alignment 1, so how can we derive anything but alignment 1 from
(the sizes of, supposedly) other members?  That is, we would have
to build an explicitly aligned _decl_ of the packed type to be able
to derive more than 1 alignment.  No?

Richard.


-- 


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

[Bug c/40026] [4.5 Regression] ICE during gimplify_init_constructor

[rguenther at suse dot de]

--- Comment #3 from rguenther at suse dot de  2009-05-06 11:41 ---
Subject: Re:  [4.5 Regression] ICE during
 gimplify_init_constructor

On Wed, 6 May 2009, joseph at codesourcery dot com wrote:

> Subject: Re:  [4.5 Regression] ICE during gimplify_init_constructor
> 
> On Tue, 5 May 2009, rguenth at gcc dot gnu dot org wrote:
> 
> > Reduced testcase, maybe due to the C const expression changes(?)
> 
> I see nothing in the reported information about this bug to suggest this 
> (rather than, say, the move of COMPOUND_LITERAL_EXPR handling to 
> language-independent code).  What do you think is wrong about the trees 
> being passed by the C front end to the gimplifier?

It was just wild guessing - the COMPOUND_LITERAL_EXPR changes may be
indeed a better guess.

Richard.


-- 


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

[Bug libstdc++/40042] delete doesn't always delete

[paolo dot carlini at oracle dot com]

--- Comment #2 from paolo dot carlini at oracle dot com  2009-05-06 11:39 
---
By the way, valgrind, correctly, doesn't report anything, at least together
with glibc 2.9:

==5250== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 3 from 1)
==5250== malloc/free: in use at exit: 0 bytes in 0 blocks.
==5250== malloc/free: 10,000,001 allocs, 10,000,001 frees, 280,000,000 bytes
allocated.


-- 


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

[Bug libstdc++/40038] [4.4/4.5 regression] symbols ce...@glibcxx_3.4.3 and ta...@glibcxx_3.4 not exported

[paolo dot carlini at oracle dot com]

--- Comment #4 from paolo dot carlini at oracle dot com  2009-05-06 11:25 
---
Benjamin, can you have a look?


-- 


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

[Bug libstdc++/40038] [4.4/4.5 regression] symbols ce...@glibcxx_3.4.3 and ta...@glibcxx_3.4 not exported

[paolo dot carlini at oracle dot com]

-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

   Target Milestone|--- |4.4.1


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

[Bug libstdc++/39546] parallel mode doesn't support implicit string conversion

[singler at gcc dot gnu dot org]

--- Comment #19 from singler at gcc dot gnu dot org  2009-05-06 11:21 
---
Subject: Bug 39546

Author: singler
Date: Wed May  6 11:20:35 2009
New Revision: 147169

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147169
Log:
2009-05-06  Johannes Singler  

PR libstdc++/39546
* include/parallel/algo.h (find_switch):
Parametrize binder2nd with const T& instead of T.
* testsuite/25_algorithms/find/39546.cc: new test case


Added:
trunk/libstdc++-v3/testsuite/25_algorithms/find/39546.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/parallel/algo.h


-- 


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

[Bug middle-end/39954] [4.5 Regression] Revision 146817 caused unaligned access in gcc.dg/torture/pr26565.c

[matz at gcc dot gnu dot org]

--- Comment #16 from matz at gcc dot gnu dot org  2009-05-06 11:20 ---
Joseph: I'd need some advise where best starting to fix this.  I see some
options, when we want to deal with such construct:

struct S { T member __attribute__((packed)); };
... struct S s; ... &s->member ...

(1) make the type of the FIELD_DECL not be T but an aligned(1) variant
of it.  Currently simply DECL_PACKED is set on the FIELD_DECL, but
that's ignored in some contextes, which results in the other options:
(2) make the type of the COMPONENT_REF "s->member" not be T but an aligned(1)
variant of it, and
(3) make the type of the ADDR_EXPR "&s->member" not be T* but (T-aligned1)*.

It seems that option (1) would be the most thorough one as then surely no
other code can accidentally construct an aligned access to it.  I think
amending handle_packed_attribute to retroactively patch TREE_TYPE if called
on a FIELD_DECL might do it.

Option (3) I think is the least appealing one, as I'd always fear that there
might be other usages of the COMPONENT_REF than the ADDR_EXPR where the
alignment might matter.  It would also mean constructing the pointer type
not from the RHS but using some variant, which seems to introduce a conceptual
inconsistency.

Option (2) lies somewhere in between, although it should be nearly equivalent
to option 1, as there aren't many other contexts than COMPONENT_REF where
a pure FIELD_DECL could be used.  But option (2) has the advantage that the
structure type is completely laid out already, not so for option (1).  That
might be important for performance sometimes, e.g. when the user declares
a field as packed (or aligned(1)), but it so happens (due to other members)
that it got it's natural alignment in the end.  In that case we don't _have_
to construct unaligned types.


-- 

matz at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||joseph at codesourcery dot
   ||com


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

[Bug middle-end/40043] [4.5 Regression] ICE with nested try/catch

[reichelt at gcc dot gnu dot org]

-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.5.0
Version|unknown |4.5.0


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

[Bug middle-end/40043] New: [4.5 Regression] ICE with nested try/catch

[reichelt at gcc dot gnu dot org]

The following valid testcase triggers an ICE on trunk when compiled with "-O":

===
struct A
{
  ~A();
  void foo();
};

void bar()
{
  A a;

  try
  {
A b;

try
{
  b.foo();
}
catch (int) {}
  }
  catch (int) {}
}
===

bug.cc: In function 'void bar()':
bug.cc:7: error: EH edge 2->21 is missing
bug.cc:7: error: unnecessary EH edge 2->10
bug.cc:7: internal compiler error: verify_flow_info failed
Please submit a full bug report, [etc.]

The bug might be related to PR39862.


-- 
   Summary: [4.5 Regression] ICE with nested try/catch
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org


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