[Bug c++/46188] -fipa-cp removes destructor call

[jens.maurer at gmx dot net]

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

--- Comment #4 from Jens Maurer  2010-10-27 
07:55:37 UTC ---
Created attachment 22171
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22171
two "if" conditions removed from the testcase

Two "if" conditions increase the complexity of the assembler code.  Removing
them doesn't change anything in reproducibility.  So I removed them.

[Bug target/46191] Non-absolute names in libgcc_s.so

[sch...@linux-m68k.org]

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

--- Comment #2 from Andreas Schwab  2010-10-27 08:33:07 
UTC ---
The parts may not be installed in the same directory and relative names may
break in the presence of symbolic links.

[Bug target/46179] Codegen/TLS: invalid assembler syntax

[sch...@linux-m68k.org]

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

--- Comment #4 from Andreas Schwab  2010-10-27 08:41:05 
UTC ---
The invalid address is generated by output_move_double.

[Bug fortran/46196] New: [OOP] gfortran compiles invalid generic TBP: dummy arguments are type compatible

[boschmann at tp1 dot physik.uni-siegen.de]

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

   Summary: [OOP] gfortran compiles invalid generic TBP: dummy
arguments are type compatible
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: boschm...@tp1.physik.uni-siegen.de


module generic
  type :: a_type
   contains
 procedure :: a_subroutine
  end type a_type
  type,extends(a_type) :: b_type
   contains
 procedure :: b_subroutine
 generic :: g_sub => a_subroutine,b_subroutine
  end type b_type
contains
  subroutine a_subroutine(this)
class(a_type)::this
  end subroutine a_subroutine
  subroutine b_subroutine(this)
class(b_type)::this
  end subroutine b_subroutine
end module generic

GNU Fortran (GCC) 4.6.0 20101022 (experimental)

This code is invalid, because the dummy arguments in a_subroutine and
b_subroutine are type compatible. Therefore they must not share a generic
interface.

[Bug fortran/45827] mio_component_ref(): Component not found when mixing f90 and f03 in large projects

[boschmann at tp1 dot physik.uni-siegen.de]

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

--- Comment #31 from Hans-Werner Boschmann  2010-10-27 09:35:07 UTC ---
I've posted the generic issue as Bug 46196

[Bug web/45818] Missing message-ids in Bugzilla messages

[LpSolit at netscape dot net]

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

Frédéric Buclin  changed:

   What|Removed |Added

 Status|NEW |WAITING

--- Comment #2 from Frédéric Buclin  2010-10-27 
09:47:14 UTC ---
This bug has been fixed upstream. We can take the fix next time we upgrade.

[Bug web/45785] Bugzilla search sometimes fails with an internal error

[LpSolit at netscape dot net]

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

--- Comment #5 from Frédéric Buclin  2010-10-27 
09:52:17 UTC ---
Could you try:

http://gcc.gnu.org/bugzilla/buglist.cgi?quicksearch=ALL+comment%3Alto_symtab_merge_decls_1

[Bug tree-optimization/46194] [4.5/4.6 Regression] gcc.dg/graphite/block-0.c FAILs with -ftree-parallelize-loops

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.10.27 10:19:03
 CC||hubicka at gcc dot gnu.org
 Ever Confirmed|0   |1

--- Comment #1 from H.J. Lu  2010-10-27 10:19:03 
UTC ---
It is caused by revision 153457:

http://gcc.gnu.org/ml/gcc-cvs/2009-10/msg01110.html

[Bug c++/46188] -fipa-cp removes destructor call

[zsojka at seznam dot cz]

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

--- Comment #5 from Zdenek Sojka  2010-10-27 10:30:35 
UTC ---
Created attachment 22172
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22172
the second part of testcase

I used this file to complete your testcase. It defines remaining functions and
prints some debug output. (x86_86-pc-linux-gnu target)

gcc-4.5.2 (r165781)
$ g++ -O2 playground4.cxx playground_main.cxx && ./a.out 
pre-f()
Array::do_something()
h(0x602030)
h((nil))
post-f()
h((nil))
h(0x602010)
h((nil))

$ g++ -O2 -fno-ipa-cp playground4.cxx playground_main.cxx && ./a.out 
pre-f()
Array::do_something()
h((nil))
h(0x602030)
h((nil))
post-f()
h((nil))
h(0x602010)
h((nil))

gcc 4.6.0 (r165985)
$ g++ -O2 playground4.cxx playground_main.cxx && ./a.out 
pre-f()
Array::do_something()
h((nil))
h(0x602030)
h((nil))
post-f()
h((nil))
h(0x602010)
h((nil))

For 4.5 -fipa-cp the output is different. I don't see anything obviously wrong
with the testcase, and valgrind doesn't anyreport any errors. But I am
certainly not an expert.

Apart from this:
#pragma interface
#pragma interface "subdir/objects.h"
Use this directive in header files that define object classes, to save
space in most of the object files that use those classes.

It's not a header file and #pragma implementation is nowhere... I suppose the
testcase was reduced from preprocessed files.

[Bug web/45785] Bugzilla search sometimes fails with an internal error

[zsojka at seznam dot cz]

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

--- Comment #6 from Zdenek Sojka  2010-10-27 10:48:13 
UTC ---
That is indeed much faster

[Bug middle-end/46195] r165965 regresses i386 darwin

[hjl.tools at gmail dot com]

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

--- Comment #6 from H.J. Lu  2010-10-27 10:51:06 
UTC ---
Created attachment 22173
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22173
A patch

Please try this patch.

[Bug target/46195] r165965 regresses i386 darwin

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

  Component|middle-end  |target
   Target Milestone|--- |4.6.0

[Bug target/46191] Non-absolute names in libgcc_s.so

[ibolton at gcc dot gnu.org]

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

Ian Bolton  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.10.27 11:06:55
 CC||ibolton at gcc dot gnu.org
 Ever Confirmed|0   |1

--- Comment #3 from Ian Bolton  2010-10-27 11:06:55 
UTC ---
Setting status to NEW.

How do other linker scripts do it?

[Bug target/46191] Non-absolute names in libgcc_s.so

[ibolton at gcc dot gnu.org]

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

Ian Bolton  changed:

   What|Removed |Added

 Status|NEW |WAITING

--- Comment #4 from Ian Bolton  2010-10-27 11:09:30 
UTC ---
On second thought, I have set this to WAITING, because the "Known to work" and
"Known to fail" have not been complete.  The Version is set to "4.5.0" - does
trunk have a sensible solution?

[Bug target/46195] r165965 regresses i386 darwin

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

  Attachment #22173|0   |1
is obsolete||
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2010.10.27 11:26:53
 AssignedTo|unassigned at gcc dot   |hjl.tools at gmail dot com
   |gnu.org |
 Ever Confirmed|0   |1

--- Comment #7 from H.J. Lu  2010-10-27 11:26:53 
UTC ---
Created attachment 22174
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22174
An updated patch

Please try this one.

[Bug fortran/46196] [OOP] gfortran compiles invalid generic TBP: dummy arguments are type compatible

[janus at gcc dot gnu.org]

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

--- Comment #1 from janus at gcc dot gnu.org 2010-10-27 11:58:15 UTC ---
Yes. Apparently a duplicate of PR 44917/44926.

[Bug target/46191] [4.5/4.6 regression] Non-absolute names in libgcc_s.so

[joseph at codesourcery dot com]

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

--- Comment #5 from joseph at codesourcery dot com  2010-10-27 12:02:35 UTC ---
On Wed, 27 Oct 2010, jakub at gcc dot gnu.org wrote:

> Using absolute names is undesirable too, because then gcc is not actually
> relocatable.  Guess we want something like $ORIGIN relative path if $ORIGIN or
> something similar expands to the directory the linker script was found in.

Absolute paths work in linker scripts in sysrooted compilers, in that they 
are interpreted relative to the (relocatable) sysroot for a linker script 
(typically libc.so) found in the sysroot.  But GCC itself never installs 
anything in a sysroot, meaning that if you put a linker script there 
(after GCC's own installation) you also need to update paths in it 
accordingly - and so to have a relative path from the sysroot to libgcc.a 
outside the sysroot.

Perhaps what's actually wanted is a way to have the linker search for 
libgcc.a in its normal search path (the compiler should have passed -L 
options that include the libgcc.a installation directory) rather than in 
"."?

[Bug target/46195] r165965 regresses i386 darwin

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|ASSIGNED|UNCONFIRMED
 Ever Confirmed|1   |0

[Bug target/46191] [4.5/4.6 regression] Non-absolute names in libgcc_s.so

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  2010-10-27 
12:44:16 UTC ---
Linker does that if -lfoo instead of libfoo.a form is used in the linker
script.
So perhaps we could just use that.  As libgcc_s linker script name is different
and -lgcc is only a library, it might DTRT.

[Bug target/46128] There is no mechanism for detecting VFP revisions in ARM GCC.

[ibolton at gcc dot gnu.org]

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

Ian Bolton  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2010.10.27 12:59:21
 CC||ibolton at gcc dot gnu.org
 Ever Confirmed|0   |1

--- Comment #3 from Ian Bolton  2010-10-27 12:59:21 
UTC ---
Please complete the "Known to work", "Known to fail", "Version" and "Target
Milestone" and any other useful details you can add.  I can then move this onto
the NEW status.

[Bug target/46197] New: Bad split_stack_return pattern in i386.md

[hjl.tools at gmail dot com]

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

   Summary: Bad split_stack_return pattern in i386.md
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com
CC: ubiz...@gmail.com


On Linux/x86, revision 166000 gave

FAIL: gcc.target/i386/avx-vzeroupper-10.c scan-assembler-times avx_vzeroupper 3
FAIL: gcc.target/i386/avx-vzeroupper-11.c scan-assembler-times avx_vzeroupper 3
FAIL: gcc.target/i386/avx-vzeroupper-12.c scan-assembler-times avx_vzeroupper 1
FAIL: gcc.target/i386/avx-vzeroupper-14.c scan-assembler-times avx_vzeroupper 1
FAIL: gcc.target/i386/avx-vzeroupper-7.c scan-assembler-times avx_vzeroupper 1
FAIL: gcc.target/i386/avx-vzeroupper-9.c scan-assembler-times avx_vzeroupper 1

The problem is

(define_insn "split_stack_return"
 [(unspec_volatile [(match_operand:SI 0 "const_int_operand" "")]
   UNSPEC_STACK_CHECK)]


vs.

(define_insn "avx_vzeroupper"
 [(unspec_volatile [(match_operand 0 "const_int_operand" "")]
   UNSPECV_VZEROUPPER)]

I generate avx_zeroupper.  But it matches split_stack_return
since (int) UNSPEC_STACK_CHECK == (int) UNSPECV_VZEROUPPER.

[Bug c++/46188] -fipa-cp removes destructor call

[jens.maurer at gmx dot net]

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

--- Comment #6 from Jens Maurer  2010-10-27 
13:15:19 UTC ---
Thanks.  Yes, the testcase was reduced from preprocessed files.  Unfortunately,
you can't remove the "#pragma interface" without breaking the testcase.  But
the only documented effect that "#pragma interface" should have is that I get
linker errors, i.e. undefined symbols.

[Bug c++/46188] -fipa-cp removes destructor call

[jens.maurer at gmx dot net]

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

--- Comment #6 from Jens Maurer  2010-10-27 
13:15:19 UTC ---
Thanks.  Yes, the testcase was reduced from preprocessed files.  Unfortunately,
you can't remove the "#pragma interface" without breaking the testcase.  But
the only documented effect that "#pragma interface" should have is that I get
linker errors, i.e. undefined symbols.

[Bug target/46197] Bad split_stack_return pattern in i386.md

[ubizjak at gmail dot com]

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

Uros Bizjak  changed:

   What|Removed |Added

URL||http://gcc.gnu.org/ml/gcc-p
   ||atches/2010-10/msg02296.htm
   ||l

--- Comment #1 from Uros Bizjak  2010-10-27 13:17:37 
UTC ---
Patch at [1].

[1] http://gcc.gnu.org/ml/gcc-patches/2010-10/msg02296.html

[Bug target/46195] r165965 regresses i386 darwin

[howarth at nitro dot med.uc.edu]

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

--- Comment #8 from Jack Howarth  2010-10-27 
13:22:42 UTC ---
(In reply to comment #7)
> Created attachment 22174 [details]
> An updated patch
> 
> Please try this one.

A quick manual test of only those test cases listed in the original report
shows they are all fixed by this patch except for
gcc.c-torture/execute/20040709-1.c which still fails at all optimizations.
These failures are of the form...

Executing on host: /Users/howarth/darwin_objdir/gcc/xgcc
-B/Users/howarth/darwin_objdir/gcc/
/Users/howarth/gcc/gcc/testsuite/gcc.c-torture/execute/20040709-1.c  -w  -O0  
-lm   -m32 -o /Users/howarth/darwin_objdir/gcc/testsuite/gcc/20040709-1.x0   
(timeout = 300)
/Users/howarth/gcc/gcc/testsuite/gcc.c-torture/execute/20040709-1.c: In
function ‘retmeW’:
/Users/howarth/gcc/gcc/testsuite/gcc.c-torture/execute/20040709-1.c:112:1:
note: The ABI of passing parameter with 16byte alignment has changed in GCC 4.6

[Bug target/46179] Codegen/TLS: invalid assembler syntax

[fthain at telegraphics dot com.au]

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

--- Comment #5 from Finn Thain  2010-10-27 
13:28:01 UTC ---
> The invalid address is generated by output_move_double.

I have to say it, the .md files I looked at are hands-down the most complex and
baroque code I've ever seen. So I don't understand them. But, that's where
output_move_double gets called.

And apparently, somehow, ColdFire (and 68000) avoid this issue... What's the
solution? Should I somehow find a test case that breaks on ColdFire so that
Maxim gets to fix this? (Just kidding ;-)

Or maybe have output_move_double call a new routine that does the same
reshuffling that m68k_final_prescan_insn does -- a wrapper around the
*handle_movsi invocation. Or is that going to be too expensive?

[Bug target/46195] r165965 regresses i386 darwin

[howarth at nitro dot med.uc.edu]

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

--- Comment #9 from Jack Howarth  2010-10-27 
13:31:18 UTC ---
Created attachment 22175
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22175
assembly file for gcc.c-torture/execute/20040709-1.c -O0 at -m32 using r165964

[Bug target/46195] r165965 regresses i386 darwin

[howarth at nitro dot med.uc.edu]

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

--- Comment #10 from Jack Howarth  2010-10-27 
13:32:44 UTC ---
Created attachment 22176
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22176
assembly file for gcc.c-torture/execute/20040709-1.c -O0 at -m32 using r165965
with patch 22174

[Bug target/46197] Bad split_stack_return pattern in i386.md

[hjl at gcc dot gnu.org]

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

--- Comment #2 from hjl at gcc dot gnu.org  2010-10-27 
13:32:58 UTC ---
Author: hjl
Date: Wed Oct 27 13:32:54 2010
New Revision: 166001

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=166001
Log:
Replace UNSPEC_STACK_CHECK with UNSPECV_SPLIT_STACK_RETURN.

2010-10-27  Ian Lance Taylor  

PR target/46197
* config/i386/i386.md (UNSPECV_SPLIT_STACK_RETURN): New.
(split_stack_return): Replace UNSPEC_STACK_CHECK with
UNSPECV_SPLIT_STACK_RETURN.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.md

[Bug target/46195] r165965 regresses i386 darwin

[howarth at nitro dot med.uc.edu]

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

--- Comment #11 from Jack Howarth  2010-10-27 
13:35:26 UTC ---
Created attachment 22177
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22177
diff between assembly for gcc.c-torture/execute/20040709-1.c at -m32 using
r165964 vs r165965+22174

[Bug target/46197] Bad split_stack_return pattern in i386.md

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #3 from H.J. Lu  2010-10-27 13:35:49 
UTC ---
Fixed.

[Bug c++/2288] Variable declared in for-loop-header is in wrong scope

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

URL||http://gcc.gnu.org/ml/gcc-p
   ||atches/2010-03/msg00838.htm
   ||l
 CC||bergner at gcc dot gnu.org
  Known to fail||

--- Comment #12 from Peter Bergner  2010-10-27 
14:34:30 UTC ---
Janis, I noticed your patch:

  http://gcc.gnu.org/ml/gcc-patches/2010-03/msg00838.html

to fix this PR and PR18770 was approved by Jason here:

  http://gcc.gnu.org/ml/gcc-patches/2010-05/msg00264.html

Now that we're in 4.6 stage1, can we commit this patch to mainline?

[Bug target/46198] New: movd xmm, r (xmm -> GPR) may hit the stack

[tbptbp at gmail dot com]

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

   Summary: movd xmm, r (xmm -> GPR) may hit the stack
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: tbp...@gmail.com
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu


Under somewhat elusive (target) conditions...
$ cat movd.c
#include 
int foo(__m128i x) { return _mm_cvtsi128_si32(x); }
$ gcc -O3 movd.c -S -o -
foo:
.LFB521:
.cfi_startproc
movd%xmm0, -12(%rsp)
movl-12(%rsp), %eax
ret
$ gcc -Os movd.c -S -o -
foo:
.LFB514:
.cfi_startproc
movd%xmm0, -12(%rsp)
movl-12(%rsp), %eax
ret
$ gcc -O3 -march=native movd.c -S -o -
foo:
.LFB521:
.cfi_startproc
movd%xmm0, %eax
ret

... movd may or may not pay a trip to the stack, apparently depending on some
target cpu+SSE level condition (here native is a corei7).
I can't see any good reason for that (and certainly not for size).

Known to happen from gcc 4.4.4 to 
$ /usr/local/gcc-4.6-20101026/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/usr/local/gcc-4.6-20101026/bin/gcc
COLLECT_LTO_WRAPPER=/usr/local/gcc-4.6-20101026/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --prefix=/usr/local/gcc-4.6.0
--enable-languages=c,c++ --enable-threads=posix --disable-nls
--with-system-zlib --disable-bootstrap --enable-mpfr --enable-gold --enable-lto
--with-ppl --with-cloog --with-arch=native --enable-checking=release
Thread model: posix
gcc version 4.6.0 20101026 (experimental) (GCC)

[Bug c++/2288] Variable declared in for-loop-header is in wrong scope

[janis at gcc dot gnu.org]

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

--- Comment #15 from Janis Johnson  2010-10-27 
17:38:36 UTC ---
Peter, I don't know what address you should use for me; ask on #gcc if you
should use the IBM one, otherwise it's janis.marie.john...@gmail.com.

[Bug target/46198] movd xmm, r (xmm -> GPR) may hit the stack

[ubizjak at gmail dot com]

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

Uros Bizjak  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #1 from Uros Bizjak  2010-10-27 18:00:13 
UTC ---
This is all what TARGET_INTER_UNIT_MOVES is for. On AMD (and generic) targets,
TARGET_INTER_UNIT_MOVES is disabled, for -march=core2 is enabled.

The situation is thus totally under control ;)

I recommend that you read [1], especially:

Part 2: Optimizing subroutines in assembly language: An optimization guide for
x86 platforms
Part 3: The microarchitecture of Intel, AMD and VIA CPUs: An optimization guide
for assembly programmers and compiler makers
Part 4: Instruction tables: Lists of instruction latencies, throughputs and
micro-operation breakdowns for Intel, AMD and VIA CPUs

[1] http://www.agner.org/optimize/

[Bug target/46198] movd xmm, r (xmm -> GPR) may hit the stack

[tbptbp at gmail dot com]

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

--- Comment #2 from tbp  2010-10-27 18:10:21 UTC ---
(In reply to comment #1)
> The situation is thus totally under control ;)
I concede you may have a point :)
Yet, for size builds, it really can't possibly make sense, ever (and that's
what lead me to investigate).

[Bug target/46195] r165965 regresses i386 darwin

[howarth at nitro dot med.uc.edu]

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

--- Comment #14 from Jack Howarth  2010-10-27 
19:04:25 UTC ---
Latest patch still leaves the regressions...

FAIL: gcc.dg/compat/struct-by-value-18 c_compat_x_tst.o compile
FAIL: gcc.dg/compat/struct-by-value-18 c_compat_y_tst.o compile
FAIL: gcc.dg/compat/struct-by-value-18a c_compat_x_tst.o compile
FAIL: gcc.dg/compat/struct-by-value-18a c_compat_y_tst.o compile

These failures are of the form...

Executing on host: /Users/howarth/darwin_objdir/gcc/xgcc
-B/Users/howarth/darwin_objdir/gcc/   -DSKIP_DECIMAL_FLOAT -c  -m32 -o
c_compat_x_tst.o
/Users/howarth/gcc/gcc/testsuite/gcc.dg/compat//struct-by-value-18_x.c   
(timeout = 300)
/Users/howarth/gcc/gcc/testsuite/gcc.dg/compat//struct-by-value-18_x.c: In
function 'checkScld2':
/Users/howarth/gcc/gcc/testsuite/gcc.dg/compat//struct-by-value-18_x.c:9:1:
note: The ABI of passing parameter with 16byte alignment has changed in GCC 4.6
output is:
/Users/howarth/gcc/gcc/testsuite/gcc.dg/compat//struct-by-value-18_x.c: In
function 'checkScld2':
/Users/howarth/gcc/gcc/testsuite/gcc.dg/compat//struct-by-value-18_x.c:9:1:
note: The ABI of passing parameter with 16byte alignment has changed in GCC 4.6

FAIL: gcc.dg/compat/struct-by-value-18 c_compat_x_tst.o compile

[Bug fortran/46196] [OOP] gfortran compiles invalid generic TBP: dummy arguments are type compatible

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2010.10.27 20:32:13
 AssignedTo|unassigned at gcc dot   |janus at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

--- Comment #2 from janus at gcc dot gnu.org 2010-10-27 20:32:13 UTC ---
Draft patch. It seems to fix this PR as well as all of PR44917 and PR44926. Not
tested for regressions yet.


Index: gcc/fortran/interface.c
===
--- gcc/fortran/interface.c (revision 165975)
+++ gcc/fortran/interface.c (working copy)
@@ -872,7 +872,8 @@ count_types_test (gfc_formal_arglist *f1, gfc_form
   /* Find other nonoptional arguments of the same type/rank.  */
   for (j = i + 1; j < n1; j++)
if ((arg[j].sym == NULL || !arg[j].sym->attr.optional)
-   && compare_type_rank_if (arg[i].sym, arg[j].sym))
+   && (compare_type_rank_if (arg[i].sym, arg[j].sym)
+   || compare_type_rank_if (arg[j].sym, arg[i].sym)))
  arg[j].flag = k;

   k++;
@@ -897,7 +898,8 @@ count_types_test (gfc_formal_arglist *f1, gfc_form
   ac2 = 0;

   for (f = f2; f; f = f->next)
-   if (compare_type_rank_if (arg[i].sym, f->sym))
+   if (compare_type_rank_if (arg[i].sym, f->sym)
+   || compare_type_rank_if (f->sym, arg[i].sym))
  ac2++;

   if (ac1 > ac2)
@@ -948,7 +950,8 @@ generic_correspondence (gfc_formal_arglist *f1, gf
   if (f1->sym->attr.optional)
goto next;

-  if (f2 != NULL && compare_type_rank (f1->sym, f2->sym))
+  if (f2 != NULL && (compare_type_rank (f1->sym, f2->sym)
+|| compare_type_rank (f2->sym, f1->sym)))
goto next;

   /* Now search for a disambiguating keyword argument starting at

[Bug target/46091] missed optimization: x86 bt/btc/bts instructions

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
   Severity|normal  |enhancement

[Bug c++/46170] [4.4/4.5/4.6 Regression] g++ wrongly rejects pointer-to-member in template arguments

[dodji at gcc dot gnu.org]

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

Dodji Seketeli  changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot   |dodji at gcc dot gnu.org
   |gnu.org |

--- Comment #4 from Dodji Seketeli  2010-10-27 
20:36:46 UTC ---
Created attachment 22180
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22180
Fix candidate

This looks like another case of us missing an SFINAE spot.

I am about to start testing the attached patchlet.

[Bug other/46125] -mcmodel=large doesn't work

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords|ABI |
   Severity|critical|normal

--- Comment #1 from Andrew Pinski  2010-10-27 
20:37:54 UTC ---
As mentioned in the thread to the list you need to compile crtstuff.c with
-mcmodel=large also.

[Bug c++/46124] ICE: tree check: expected var_decl or function_decl, have error_mark in cp_parser_lambda_declarator_opt, at cp/parser.c:7817 on invalid lambda function

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||error-recovery
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.10.27 20:39:32
 Ever Confirmed|0   |1

--- Comment #1 from Andrew Pinski  2010-10-27 
20:39:32 UTC ---
Confirmed.

[Bug tree-optimization/46190] [4.6 Regression] ICE in vect_enhance_data_refs_alignment when building fma3d

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.6.0
Summary|ICE in  |[4.6 Regression] ICE in
   |vect_enhance_data_refs_alig |vect_enhance_data_refs_alig
   |nment when building fma3d   |nment when building fma3d

[Bug fortran/46201] New: ICE using procedure pointer...

[sjbespa at comcast dot net]

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

   Summary: ICE using procedure pointer...
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: sjbe...@comcast.net


Created attachment 22181
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22181
module which generates the compiler crash described in PR

Compiler crash using attached example...

et: sjbespa$ /volumes/dev/gfortran-4.6-trunk/bin/gfortran -o test test_4.f90
test_4.f90: In function ‘test_subroutine’:
test_4.f90:24:0: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

==
et: sjbespa$ /volumes/dev/gfortran-4.6-trunk/bin/gfortran -v
Using built-in specs.
COLLECT_GCC=/volumes/dev/gfortran-4.6-trunk/bin/gfortran
COLLECT_LTO_WRAPPER=/Volumes/dev/gfortran-4.6-trunk/bin/../libexec/gcc/x86_64-apple-darwin10.4.0/4.6.0/lto-wrapper
Target: x86_64-apple-darwin10.4.0
Configured with: ../gfortran-4.6-src/configure
--prefix=/volumes/dev/gfortran-4.6-trunk --enable-languages=fortran
--disable-bootstrap
Thread model: posix
gcc version 4.6.0 20101027 (experimental) (GCC)

[Bug tree-optimization/46194] [4.5/4.6 Regression] gcc.dg/graphite/block-0.c FAILs with -ftree-parallelize-loops

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.5.2

[Bug c++/46105] Ordering failure among partial specializations with non-deduced context

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski  2010-10-27 
20:53:14 UTC ---
The error message that GCC gives is:
t.cc:25:22: error: ambiguous class template instantiation for ‘struct
element’
t.cc:12:8: error: candidates are: struct element::type>
t.cc:17:8: error: struct element::type>
t.cc:25:1: error: ‘type’ in class ‘element’ does not name a type


T is "const has_et" for the first candidate and T is has_et for the second. 
Maybe I am missing something here but both T's have an element_type.

[Bug c/46112] internal compiler error

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.10.27 20:58:43
 Ever Confirmed|0   |1
  Known to fail||4.1.2, 4.3.2, 4.6.0

--- Comment #2 from Andrew Pinski  2010-10-27 
20:58:43 UTC ---
Confirmed.

[Bug c++/46159] [4.5/4.6 Regression] Bogus warning about lambdas

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.10.27 21:02:56
   Target Milestone|--- |4.5.2
 Ever Confirmed|0   |1

--- Comment #1 from Andrew Pinski  2010-10-27 
21:02:56 UTC ---
Confirmed.  Looks like there might be some ambiguous in the parsing with
lambda's.

[Bug c++/46105] Ordering failure among partial specializations with non-deduced context

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  2010-10-27 
21:03:50 UTC ---
I think the point is that the element partial specialization should be
preferred, but GCC considers them ambiguous, and uses the primary template.

[Bug other/46202] New: Makefile doesn't support install-strip

[nightstrike at gmail dot com]

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

   Summary: Makefile doesn't support install-strip
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: other
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: nightstr...@gmail.com


The GNU Standards list install-strip as a required makefile target.  This
target isn't present, however.  See discussion here:

http://www.sourceware.org/ml/binutils/2010-10/msg00377.html

[Bug middle-end/46164] Local variables in specified registers don't work correctly with inline asm operands

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ra, wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.10.27 21:13:00
 Ever Confirmed|0   |1
  Known to fail||4.1.2, 4.3.2, 4.6.0

--- Comment #3 from Andrew Pinski  2010-10-27 
21:13:00 UTC ---
Confirmed, The register allocator is causing it.  I think it does not take into
account the "&" so reload will correct it.  (this was true at least in the old
RA in 4.3 and before).

[Bug debug/46132] ICE: in force_decl_die, at dwarf2out.c:20525 with -fenable-icf-debug

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.10.27 21:25:57
 Ever Confirmed|0   |1

--- Comment #1 from Andrew Pinski  2010-10-27 
21:25:57 UTC ---
Confirmed.

[Bug debug/46135] ICE: in splice_child_die, at dwarf2out.c:7627 with -g1 -femit-class-debug-always -fenable-icf-debug

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.10.27 21:27:24
 Ever Confirmed|0   |1

--- Comment #1 from Andrew Pinski  2010-10-27 
21:27:24 UTC ---
Confirmed.

[Bug c++/46203] New: constexpr weirdness w/ default ctors

[bkoz at gcc dot gnu.org]

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

   Summary: constexpr weirdness w/ default ctors
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: b...@gcc.gnu.org


From trunk, get these additional fails.

FAIL: 23_containers/vector/ext_pointer/citerators.cc (test for excess errors)
FAIL: 29_atomics/atomic_address/cons/assign_neg.cc (test for excess errors)
FAIL: 29_atomics/atomic_address/cons/copy_neg.cc (test for excess errors)
FAIL: 29_atomics/atomic_address/cons/default.cc (test for excess errors)
FAIL: 29_atomics/atomic_flag/cons/assign_neg.cc (test for excess errors)
FAIL: 29_atomics/atomic_flag/cons/copy_neg.cc (test for excess errors)
FAIL: 29_atomics/atomic_flag/cons/default.cc (test for excess errors)

=== libstdc++ Summary ===

# of expected passes7977
# of unexpected failures7
# of expected failures84
# of unsupported tests100

Looking at 

FAIL: 29_atomics/atomic_address/cons/default.cc, 

I see:

In file included from
/mnt/share/bld/gcc.git-trunk/x86_64-unknown-linux-gnu/libstdc++-v3/include/atomic:42:0,
 from
/mnt/share/src/gcc.git-trunk/libstdc++-v3/testsuite/29_atomics/atomic_flag/cons/default.cc:20:
/mnt/share/bld/gcc.git-trunk/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/atomic_base.h:
In constructor ‘constexpr std::__atomic_flag_base::__atomic_flag_base()’:
/mnt/share/bld/gcc.git-trunk/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/atomic_base.h:58:18:
error: uninitialized member ‘std::__atomic_flag_base::_M_i’ in ‘constexpr’
constructor
In file included from
/mnt/share/bld/gcc.git-trunk/x86_64-unknown-linux-gnu/libstdc++-v3/include/atomic:81:0,
 from
/mnt/share/src/gcc.git-trunk/libstdc++-v3/testsuite/29_atomics/atomic_flag/cons/default.cc:20:
/mnt/share/bld/gcc.git-trunk/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/atomic_2.h:
In constructor ‘constexpr std::__atomic2::atomic_flag::atomic_flag()’:
/mnt/share/bld/gcc.git-trunk/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/atomic_2.h:49:5:
note: synthesized method ‘std::__atomic_flag_base::__atomic_flag_base()’ first
required here 
/mnt/share/src/gcc.git-trunk/libstdc++-v3/testsuite/29_atomics/atomic_flag/cons/default.cc:
In function ‘int main()’:
/mnt/share/src/gcc.git-trunk/libstdc++-v3/testsuite/29_atomics/atomic_flag/cons/default.cc:25:44:
note: synthesized method ‘constexpr std::__atomic2::atomic_flag::atomic_flag()’
first required here


These default ctors are not constexpr.

[Bug c++/46203] constexpr weirdness w/ default ctors

[bkoz at gcc dot gnu.org]

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

--- Comment #1 from Benjamin Kosnik  2010-10-27 
21:30:29 UTC ---
Created attachment 22182
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22182
pre-processed sources

[Bug c++/42121] g++ should warn or error on internal 0 size array in struct

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.10.27 21:31:30
 Ever Confirmed|0   |1

--- Comment #8 from Jonathan Wakely  2010-10-27 
21:31:30 UTC ---
The C++ front end is far too permissive, the comments below show what should
change for compatibility with the C front end:

struct bogus
{
int a;
char b[];   // should be rejected, b[0] is ok
int c;
};

struct bogus2 {
  int x[];  // should be rejected, x[0] is ok
};

struct ok {
  int a;
  int x[];
};

struct gnu_extension
{
  struct ok a;
};

If bogus::b and bogus2::x are declared as zero-length arrays, rather than
flexible array members, then they are accepted by the C front end.

[Bug debug/46136] ICE: in size_of_dcall_table, at dwarf2out.c:12387 with -fenable-icf-debug

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.10.27 21:33:52
 Ever Confirmed|0   |1

--- Comment #1 from Andrew Pinski  2010-10-27 
21:33:52 UTC ---
Confirmed.

[Bug middle-end/46169] [4.4 Regression] ICE: internal compiler error: in convert_move, at expr.c:371

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.10.27 21:35:06
  Known to work||4.5.0
   Target Milestone|--- |4.4.6
Summary|ICE: internal compiler  |[4.4 Regression] ICE:
   |error: in convert_move, at  |internal compiler error: in
   |expr.c:371  |convert_move, at expr.c:371
 Ever Confirmed|0   |1

--- Comment #3 from Andrew Pinski  2010-10-27 
21:35:06 UTC ---
Confirmed.

[Bug bootstrap/46173] [4.4 Regression] gcc/gencheck.c:30:24: error: all-tree.def: No such file or directory

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Keywords||build
   Last reconfirmed||2010.10.27 21:35:46
 Ever Confirmed|0   |1
Summary|gcc/gencheck.c:30:24:   |[4.4 Regression]
   |error: all-tree.def: No |gcc/gencheck.c:30:24:
   |such file or directory  |error: all-tree.def: No
   ||such file or directory
   Target Milestone|--- |4.4.6

--- Comment #1 from Andrew Pinski  2010-10-27 
21:35:46 UTC ---
Confirmed.

[Bug fortran/46161] [OOP] Invalid: Passing non-polymorphic to allocatable polymorphic dummy

[janus at gcc dot gnu.org]

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

--- Comment #2 from janus at gcc dot gnu.org 2010-10-27 21:41:56 UTC ---
Author: janus
Date: Wed Oct 27 21:41:52 2010
New Revision: 166018

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=166018
Log:
2010-10-27  Janus Weil  

PR fortran/46161
* interface.c (compare_allocatable): Handle polymorphic allocatables.
(compare_parameter): Add two error messages for polymorphic dummies.

2010-10-27  Janus Weil  

PR fortran/46161
* gfortran.dg/class_dummy_3.f03: New.

Added:
trunk/gcc/testsuite/gfortran.dg/class_dummy_3.f03
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/interface.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/46161] [OOP] Invalid: Passing non-polymorphic to allocatable polymorphic dummy

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #3 from janus at gcc dot gnu.org 2010-10-27 21:42:43 UTC ---
Fixed with r166018. Closing.

[Bug rtl-optimization/46175] ICE: in rtl_verify_flow_info_1, at cfgrtl.c:2037: flow control insn inside a basic block with -O -fgcse -fno-guess-branch-probability -freorder-blocks and asm goto

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.10.27 21:43:28
 Ever Confirmed|0   |1

--- Comment #1 from Andrew Pinski  2010-10-27 
21:43:28 UTC ---
Even just -O1 -da will cause a crash.

Confirmed.

[Bug target/46153] [4.5/4.6 Regression] ICE: in extract_insn, at recog.c:2110 (unrecognizable insn) with -ffloat-store and __builtin_ia32_movlhps

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.10.27 21:48:02
 Ever Confirmed|0   |1

--- Comment #1 from Andrew Pinski  2010-10-27 
21:48:02 UTC ---
I wonder if -ffloat-store should touch the vector types.

We have a store to the stack but the pattern does not accept a store; only a
register.

Confirmed.

[Bug fortran/46201] ICE using procedure pointer...

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 CC||burnus at gcc dot gnu.org,
   ||janus at gcc dot gnu.org

--- Comment #1 from Tobias Burnus  2010-10-27 
21:48:17 UTC ---
The ICE happens for:
   nam = vars(ivar)%name(1)

where "name" is the PPC. It fails with 4.5 and 4.6. (4.4 does not support PPC.)

ICEs at:

==7160== Invalid read of size 8
==7160==at 0x57365F: gfc_conv_procedure_call (trans-expr.c:3539)
==7160==by 0x5742C1: gfc_conv_function_expr (trans-expr.c:3937)
==7160==by 0x56DD39: gfc_trans_assignment_1 (trans-expr.c:5675)
==7160==by 0x574AF9: gfc_trans_assignment (trans-expr.c:5847)

That's the line:  se->expr = info->descriptor;

[Bug fortran/46196] [OOP] gfortran compiles invalid generic TBP: dummy arguments are type compatible

[dominiq at lps dot ens.fr]

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

--- Comment #3 from Dominique d'Humieres  2010-10-27 
21:51:23 UTC ---
With the patch in comment #2, several of my codelets are rejected: for instance
the test in comment #24 of pr42274 is rejected with:

[macbook] f90/bug% gfc pr42274_5.f90
pr42274_5.f90:14.33:

generic, public :: extract => make_integer_2
 1
Error: 'make_integer_2' and 'make_integer' for GENERIC 'extract' at (1) are
ambiguous
pr42274_5.f90:33.7:

  use m
   1
Fatal Error: Can't open module file 'm.mod' for reading at (1): No such file or
directory

If you need I can sort out the other similar new errors tomorrow.

[Bug fortran/32049] Support on x86_64 also kind=16

[burnus at gcc dot gnu.org]

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

--- Comment #9 from Tobias Burnus  2010-10-27 
21:53:14 UTC ---
Last patch: http://gcc.gnu.org/ml/fortran/2010-10/msg00262.html

[Bug c++/46001] [4.6 Regression] diagnostic refers to type '__java_boolean'

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.10.27 22:00:45
 Ever Confirmed|0   |1

--- Comment #1 from Andrew Pinski  2010-10-27 
22:00:45 UTC ---
Confirmed.

[Bug fortran/46201] [F03] ICE on procedure pointer component call

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.10.27 22:03:01
Summary|ICE using procedure |[F03] ICE on procedure
   |pointer...  |pointer component call
 Ever Confirmed|0   |1

--- Comment #2 from janus at gcc dot gnu.org 2010-10-27 22:03:01 UTC ---
Here is a slightly reduced/modified test case:


implicit none

abstract interface
   character function name_func (ivar) result (res)
  integer, intent(in) :: ivar
   end function
end interface

type var_type
   procedure(name_func), nopass, pointer :: name
end type

type(var_type), dimension(1) :: vars

print *,vars(1)%name(1)

end

[Bug c++/35688] template visibility botch

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.10.27 22:10:38
 Ever Confirmed|0   |1

--- Comment #1 from Andrew Pinski  2010-10-27 
22:10:38 UTC ---
Confirmed.  The reason why they should be hidden is because the template
argument is hidden.

[Bug c++/46043] attribute to mark virtual methods that can't be further overriden so they can be devirtualized

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.10.27 22:12:08
 Ever Confirmed|0   |1

--- Comment #4 from Andrew Pinski  2010-10-27 
22:12:08 UTC ---
Confirmed, I thought I had say a bug asking for this previously.  MS Visual
Studio has such a method and IIRC it was rejected for GCC but I don't remember
why anymore.

[Bug rtl-optimization/46034] [4.6 regression] internal compiler error: Segmentation fault

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.10.27 22:14:25
  Component|middle-end  |rtl-optimization
 Ever Confirmed|0   |1

--- Comment #3 from Andrew Pinski  2010-10-27 
22:14:25 UTC ---
#0  if_then_else_cond (x=0x7f4d072f7b10, ptrue=0x7fff4c5ea078,
pfalse=0x7fff4c5ea068)
at /home/apinski/src/gcc-fsf/local//gcc/gcc/combine.c:8468


Confirmed.

[Bug rtl-optimization/46034] [4.6 regression] internal compiler error: Segmentation fault

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |4.6.0

[Bug rtl-optimization/46034] [4.6 regression] internal compiler error: Segmentation fault

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski  2010-10-27 
22:16:55 UTC ---
We are going into an infinite loop in  if_then_else_cond.

[Bug rtl-optimization/46034] [4.6 regression] internal compiler error: Segmentation fault

[pinskia at gcc dot gnu.org]

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

--- Comment #5 from Andrew Pinski  2010-10-27 
22:19:13 UTC ---
But that is because we have something like XOR (ASHIFTRT) Where the operand of
the ASHIFTRT is the same XOR again.

[Bug rtl-optimization/46034] [4.6 regression] internal compiler error: Segmentation fault

[pinskia at gcc dot gnu.org]

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

--- Comment #6 from Andrew Pinski  2010-10-27 
22:34:40 UTC ---
The most reduced testcase I could get:
intersect_al(int n, int k)
{
  int i;
  for (i = 0; i < n; i++)
  {
k = __builtin_abs(k);
set_x_next(k / 2);
  }
}

[Bug target/46195] r165965 regresses i386 darwin

[howarth at nitro dot med.uc.edu]

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

--- Comment #15 from Jack Howarth  2010-10-27 
22:34:46 UTC ---
Created attachment 22183
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22183
assembly for gcc.dg/compat/struct-by-value-18_x.c at -m32 using r165964

Created with...

/Users/howarth/darwin_objdir/gcc/xgcc -B/Users/howarth/darwin_objdir/gcc/
-DSKIP_DECIMAL_FLOAT -c -m32 --save-temps -o c_compat_x_tst.o
/Users/howarth/gcc/gcc/testsuite/gcc.dg/compat/struct-by-value-18_x.c

[Bug target/46195] r165965 regresses i386 darwin

[howarth at nitro dot med.uc.edu]

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

--- Comment #16 from Jack Howarth  2010-10-27 
22:36:12 UTC ---
Created attachment 22184
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22184
assembly for gcc.dg/compat/struct-by-value-18_x.c at -m32 using r165965 and
patch 22178

[Bug target/46195] r165965 regresses i386 darwin

[howarth at nitro dot med.uc.edu]

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

--- Comment #17 from Jack Howarth  2010-10-27 
22:37:36 UTC ---
Created attachment 22185
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22185
diff between assembly for gcc.dg/compat/struct-by-value-18_x.c at -m32 using
r165964 and r165965/patch 22178

[Bug rtl-optimization/46034] [4.6 regression] internal compiler error: Segmentation fault

[pinskia at gcc dot gnu.org]

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

--- Comment #7 from Andrew Pinski  2010-10-27 
22:38:26 UTC ---
Fails also with revision 164656.

[Bug c++/46058] [4.5/4.6 Regression] gcc crashes with lvalue error on the following Code

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.10.27 22:55:58
   Target Milestone|--- |4.5.2
Summary|gcc crashes with lvalue |[4.5/4.6 Regression] gcc
   |error on the following Code |crashes with lvalue error
   ||on the following Code
 Ever Confirmed|0   |1

--- Comment #2 from Andrew Pinski  2010-10-27 
22:55:58 UTC ---
<<< Unknown tree: scope_ref
  struct StringLiterals
  dec >>>


StringLiterals is not dependent so the scope_ref should have been resolved.

4.3.2 gave:
t.cc:12: error: ‘StringLiterals::dec’ cannot appear in a constant-expression
t.cc:12: error: template argument 3 is invalid


But I think that is incorrect as that is a static field.

Note 4.5.0 20100401 (experimental) [trunk revision 157933]  accepted the code
though.

[Bug c++/46001] [4.6 Regression] diagnostic refers to type '__java_boolean'

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |4.6.0

[Bug rtl-optimization/46034] [4.6 regression] internal compiler error: Segmentation fault

[zsojka at seznam dot cz]

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

--- Comment #8 from Zdenek Sojka  2010-10-27 22:59:53 
UTC ---
Created attachment 22186
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22186
reduced testcase

Needs only "-O -fexpensive-optimizations" to reproduce

Relevant valgrind output:
$ gcc -O -fexpensive-optimizations testcase2.c
==10818== 
==10818== Stack overflow in thread 1: can't grow stack to 0x7fe801fd8
==10818== Can't extend stack to 0x7fe801450 during signal delivery for thread
1:
==10818==   no stack segment
==10818== 
==10818== Process terminating with default action of signal 11 (SIGSEGV)
==10818==  Access not within mapped region at address 0x7FE801450
==10818==at 0xF1C9BB: if_then_else_cond (combine.c:8504)
==10818==  If you believe this happened as a result of a stack
==10818==  overflow in your program's main thread (unlikely but
==10818==  possible), you can try to increase the size of the
==10818==  main thread stack using the --main-stacksize= flag.
==10818==  The main thread stack size used in this run was 8388608.
==10818== Stack overflow in thread 1: can't grow stack to 0x7fe801f50
gcc: internal compiler error: Segmentation fault (program cc1)
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Tested revisions:
r165985 - crash
r163636 - crash
r161659 - OK

[Bug debug/45997] [4.6 Regression] __unknown__ type name for typedef'd int

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.10.27 23:00:32
Version|unknown |4.6.0
   Target Milestone|--- |4.6.0
Summary|__unknown__ type name for   |[4.6 Regression]
   |typedef'd int   |__unknown__ type name for
   ||typedef'd int
 Ever Confirmed|0   |1

--- Comment #1 from Andrew Pinski  2010-10-27 
23:00:32 UTC ---
4.5.0 20100401 (experimental) [trunk revision 157933] did not do it either.

[Bug middle-end/46204] New: g++.dg/torture/stackalign/throw-1.C fails to compile on IA64

[sje at cup dot hp.com]

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

   Summary: g++.dg/torture/stackalign/throw-1.C fails to compile
on IA64
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Keywords: link-failure
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: s...@cup.hp.com
  Host: ia64-*-*
Target: ia64-*-*
 Build: ia64-*-*


I am not sure exactly where this is going wrong but when
g++.dg/torture/stackalign/throw-1.C is compiled with -O3 -funroll-loops on IA64
I get an undefined label.

Here is a cutdown test case based on that test:

int global, global2;
int main()
{
int i,j,k,l,m,n;
   for (i=0; i < global; i++)
   for (k=0; k < j; k++)
   for (l=0; l < k; l++)
   for (m=0; m < l; m++)
   global2 = k;
 throw 0;
}

When I compile it I get:

g++ -O3 -funroll-loops x.C
/tmp/ccVWUtRi.o: In function `main':
x.C:(.text+0xc2): undefined reference to `.L34'
collect2: ld returned 1 exit status

[Bug fortran/46205] New: Invalid FORALL fails to compile

[jstottsj at gmail dot com]

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

   Summary: Invalid FORALL fails to compile
   Product: gcc
   Version: 4.5.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jstot...@gmail.com


Created attachment 22187
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22187
A very short program that illustrates the problem.

Compiler information:
  Using built-in specs.
  COLLECT_GCC=gfortran
 
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-apple-darwin10.4.0/4.5.1/lto-wrapper
  Target: x86_64-apple-darwin10.4.0
  Configured with: ./configure --enable-languages=c,c++,fortran,lto
  Thread model: posix
  gcc version 4.5.1 (GCC) 

Error message displayed:
  bugtest.f90: In function ‘forallbug’:
  bugtest.f90:1:0: internal compiler error: Segmentation fault
  Please submit a full bug report,
  with preprocessed source if appropriate.
  See  for instructions.

Description:
  An illegal FORALL statement consistently causes the compiler to crash instead
of generating an error message.  To trigger it, pass a vector (of type logical)
as the mask of the FORALL instead of the required scalar logial.

The bug does not depend on the complier flags; "gfortran -c bugtest.f90" is
sufficient.

I've attached a simple program that demonstrates the problem.

-JS

[Bug target/46195] r165965 regresses i386 darwin

[howarth at nitro dot med.uc.edu]

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

--- Comment #18 from Jack Howarth  2010-10-28 
00:43:00 UTC ---
Full regression results for patch in comment 12...

http://gcc.gnu.org/ml/gcc-testresults/2010-10/msg02196.html

show that the four failures in comment 14 are the only remaining regressions
from r165965 on x86_64-apple-darwin10.

[Bug fortran/46205] Invalid FORALL fails to compile

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.10.28 01:27:01
 CC||jvdelisle at gcc dot
   ||gnu.org
 Ever Confirmed|0   |1

--- Comment #1 from Jerry DeLisle  2010-10-28 
01:27:01 UTC ---
Confirmed. I don't get a segfault, but we should catch this in the matchers I
would think.

$ gfc bugtest.f90 
bugtest.f90: In function ‘forallbug’:
bugtest.f90:23:0: internal compiler error: Unexpected type in
truthvalue_conversion
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug c++/46206] New: using typedef-name error with typedef name hiding struct name

[nathan.keynes at oracle dot com]

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

   Summary: using typedef-name error with typedef name hiding
struct name
   Product: gcc
   Version: 4.1.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: nathan.key...@oracle.com


G++ rejects the following code:

class Foo
{
bool a, b, c, d;
typedef struct Bar { } Bar;
virtual void foo(void) {
struct Bar bar;
}
};

example.cc: In member function ‘virtual void Foo::foo()’:
example.cc:6: error: using typedef-name ‘Foo::Bar’ after ‘struct’
example.cc:4: error: ‘Foo::Bar’ has a previous declaration here
example.cc:6: error: invalid type in declaration before ‘;’ token

but accepts many similar examples, including:
class Foo
{
bool a, b, c;
typedef struct Bar { } Bar;
virtual void foo(void) {
struct Bar bar;
}
};

This behaviour is reproducible on x86_64-redhat-linux (4.1.2 and 4.4.0) and
i386-pc-solaris2.11 (4.2.4, 4.3.4 and 4.5.1)

I'm uncertain if this is strictly legal or not per the standard, but it doesn't
seem to make sense to accept one of these cases but not the other.

[Bug c++/46206] using typedef-name error with typedef name hiding struct name

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.10.28 02:16:05
 Ever Confirmed|0   |1

--- Comment #1 from Paolo Carlini  2010-10-28 
02:16:05 UTC ---
Crazy.

[Bug libstdc++/46207] New: std::atomic::store(...) fails to compile

[miles at gnu dot org]

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

   Summary: std::atomic::store(...) fails to compile
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mi...@gnu.org


The following program:


#include 

std::atomic non_const_int_pointer;
void non_const_set (int *value)
{
  non_const_int_pointer.store (value, std::memory_order_release);
}

#ifndef SUPPRESS_CONST
std::atomic const_int_pointer;
void const_set (const int *value)
{
  const_int_pointer.store (value, std::memory_order_release);
}
#endif


compiled with options "-O2 -march=native -std=c++0x", gives an error and fails
to compile because of the call to "const_int_pointer.store" (see error log
below).

However, the program compiles successfully if I add "-DSUPPRESS_CONST" to the
compiler options -- the call of "non_const_int_pointer.store" does not seem to
cause any problems.


Error log:

$ g++-snapshot --version
g++ (Debian 20101016-1) 4.6.0 20101016 (experimental) [trunk revision 165538]
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ g++-snapshot -O2 -march=native -std=c++0x  -S al.cc
In file included from al.cc:1:0:
/usr/lib/gcc-snapshot/lib/gcc/x86_64-linux-gnu/4.6.0/../../../../include/c++/4.6.0/atomic:
In member function 'void std::atomic<_Tp*>::store(_Tp*, std::memory_order)
[with _Tp = const int, std::memory_order = std::memory_order]':
al.cc:13:60:   instantiated from here
/usr/lib/gcc-snapshot/lib/gcc/x86_64-linux-gnu/4.6.0/../../../../include/c++/4.6.0/atomic:145:9:
error: invalid conversion from 'const void*' to 'void*' [-fpermissive]
/usr/lib/gcc-snapshot/lib/gcc/x86_64-linux-gnu/4.6.0/../../../../include/c++/4.6.0/bits/atomic_2.h:99:5:
error:   initializing argument 1 of 'void
std::__atomic2::atomic_address::store(void*, std::memory_order)' [-fpermissive]

$ g++-snapshot -DSUPPRESS_CONST -O2 -march=native -std=c++0x  -S al.cc
$

[Bug target/46195] r165965 regresses i386 darwin

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed|2010-10-27 11:26:53 |2010.10.28 05:46:35
 Ever Confirmed|0   |1

--- Comment #19 from H.J. Lu  2010-10-28 05:46:35 
UTC ---
(In reply to comment #14)
> Latest patch still leaves the regressions...
> 
> FAIL: gcc.dg/compat/struct-by-value-18 c_compat_x_tst.o compile
> FAIL: gcc.dg/compat/struct-by-value-18 c_compat_y_tst.o compile
> FAIL: gcc.dg/compat/struct-by-value-18a c_compat_x_tst.o compile
> FAIL: gcc.dg/compat/struct-by-value-18a c_compat_y_tst.o compile
> 

Please provide preprocessed file which triggers the warning.

[Bug other/46125] -mcmodel=large doesn't work

[liwei79 at gmail dot com]

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

Wei Li  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #2 from Wei Li  2010-10-28 06:22:59 UTC 
---
Thanks a lot.

I recompiled crtstuff.c with -mcmodel=large and the issue is solved.