[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 #15 from Hans-Werner Boschmann  2010-10-01 06:52:14 UTC ---
Thank you, now I understand the difference. The correct invocation does not
supply any new information.

Revision 20100928 compiles my code, so it's fine for me now. But I have got
huge tables of use statements in my modules and I continue to get this error
message, when I forget to explicitly "use" the whole tree of modules.

It also might has been a coincidence that the error disappeared when I renamed
kind.f90 to kinds.f03. I did the same for 20100928, and it didn't work. But
mentioning all modules works for 20100928.

[Bug c++/45853] New: Segfault while experimenting with c++-0x initializer lists

[JamesMikeDuPont at googlemail dot com]

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

   Summary: Segfault while experimenting with c++-0x initializer
lists
   Product: gcc
   Version: 4.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jamesmikedup...@googlemail.com


Created attachment 21928
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=21928
Compile Log

I have been experimenting with c++ initializer lists and refactoring binutils
to use c++. While doing so, the compiler crashed. I am reporting this in case
it might help the development of the compiler.

Compiler is :
g++ (Ubuntu 4.4.1-4ubuntu9) 4.4.1

lsb version : 9.10 karmic with lots of backports and patches

[Bug fortran/45746] [OOP] ICE in fold_convert_loc: pointer to allocatable array with select type

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org

--- Comment #4 from Tobias Burnus  2010-10-01 
05:37:29 UTC ---
(In reply to comment #3)
> I do not see the error on x86_64-unknown-linux-gnu at r164767. Can anyone
> confirm that?

Ditto for my 4.6.0 20100930 built also on x86_64-unknown-linux-gnu; I tried it
using valgrind.

[Bug c/45852] volatile structs are broken!

[regehr at cs dot utah.edu]

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

--- Comment #1 from John Regehr  2010-10-01 03:40:43 
UTC ---
This problem has been there for some time: none of 3.0.0, 3.1.0, 3.2.0, 3.3.0,
3.4.0, 4.0.0, 4.1.0, 4.2.0, 4.3.0, 4.4.0, or 4.5.0 for x86 generates the right
code.

[Bug middle-end/45406] ICE: in rename_uses, at sese.c:534

[t66667 at gmail dot com]

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

t66...@gmail.com  changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|DUPLICATE   |

--- Comment #5 from t7 at gmail dot com  
2010-10-01 03:26:34 UTC ---
bash-4.1$ xmingw-trunk-w64-sjlj/bin/x86_64-w64-mingw32-gcc  -w -O0 -lm -m32
-fgraphite-identity -c
/home/slack/gcc/gcc-trunk/gcc/testsuite/gcc.c-torture/execute/strncmp-1.c
bash-4.1$ xmingw-trunk-w64-sjlj/bin/x86_64-w64-mingw32-gcc  -w -O3 -lm -m32
-fgraphite-identity -c
/home/slack/gcc/gcc-trunk/gcc/testsuite/gcc.c-torture/execute/strncmp-1.c
bash-4.1$ xmingw-trunk-w64-sjlj/bin/x86_64-w64-mingw32-gcc  -w -Os -lm -m32
-fgraphite-identity -c
/home/slack/gcc/gcc-trunk/gcc/testsuite/gcc.c-torture/execute/strncmp-1.c
/home/slack/gcc/gcc-trunk/gcc/testsuite/gcc.c-torture/execute/strncmp-1.c: In
function 'main':
/home/slack/gcc/gcc-trunk/gcc/testsuite/gcc.c-torture/execute/strncmp-1.c:44:1:
error: Invalid first operand of MEM_REF.
&u1.buf
/home/slack/gcc/gcc-trunk/gcc/testsuite/gcc.c-torture/execute/strncmp-1.c:79:12:
note: in statement
# .MEM_120 = VDEF <.MEM_12>
MEM[(unsigned char *)&u1.buf] = 0;

/home/slack/gcc/gcc-trunk/gcc/testsuite/gcc.c-torture/execute/strncmp-1.c:44:1:
error: Invalid first operand of MEM_REF.
&u2.buf
/home/slack/gcc/gcc-trunk/gcc/testsuite/gcc.c-torture/execute/strncmp-1.c:80:12:
note: in statement
# .MEM_119 = VDEF <.MEM_120>
MEM[(unsigned char *)&u2.buf] = 0;

/home/slack/gcc/gcc-trunk/gcc/testsuite/gcc.c-torture/execute/strncmp-1.c:44:1:
internal compiler error: verify_stmts failed
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
bash-4.1$ xmingw-trunk-w64-sjlj/bin/x86_64-w64-mingw32-gcc  -w -O3 -lm -m32
-fgraphite-identity -c pr45230.c
bash-4.1$ xmingw-trunk-w64-sjlj/bin/x86_64-w64-mingw32-gcc  -w -Os -lm -m32
-fgraphite-identity -c pr45230.c
pr45230.c: In function 'foo':
pr45230.c:2:1: internal compiler error: in rename_uses, at sese.c:534
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
bash-4.1$ xmingw-trunk-w64-sjlj/bin/x86_64-w64-mingw32-g++ -r -nostdlib -Os
-fgraphite-identity -c qdrawhelper_mmx.iibash-4.1$
xmingw-trunk-w64-sjlj/bin/x86_64-w64-mingw32-g++ -r -nostdlib -O3
-fgraphite-identity -c qdrawhelper_mmx.ii
qdrawhelper_mmx.ii: In function 'void comp_func_Source(uint*, const uint*, int,
uint) [with MM = QMMXIntrinsics, uint = unsigned int]':
qdrawhelper_mmx.ii:45806:41: internal compiler error: in rename_uses, at
sese.c:534
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

gcc version 4.6.0 20100930 (experimental)
(x86_64-w64-mingw32-sjlj-x86_64-slackware-linux [164819] (3685))

[Bug middle-end/45230] gcc.c-torture/execute/strncmp-1.c ICEs with -fgraphite-identity

[t66667 at gmail dot com]

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

--- Comment #17 from t7 at gmail dot com  
2010-10-01 03:24:52 UTC ---
(In reply to comment #16)
> Fixed.

sorry you only introduced the problem into another error.
this maybe multiple problems.
what did you fix, which revision?
should i un-mark duplicate to pr45406 ?
since pr45406 and the testcase which zdenek attached in comment #2 is still
valid.

so i will reopen the problem.

do you want to fix pr45406 ?
it is not a good sign you do not say nothing.

[Bug target/45807] Lying eh_frame r2 save info causes crashes with static libgcc_eh and libstdc++

[amodra at gcc dot gnu.org]

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

--- Comment #6 from Alan Modra  2010-10-01 03:23:50 
UTC ---
Author: amodra
Date: Fri Oct  1 03:23:46 2010
New Revision: 164825

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=164825
Log:
PR target/45807
* config/rs6000/rs6000.c (rs6000_emit_prologue): Properly sign
extend toc_restore_insn.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000.c

[Bug libstdc++/45841] [4.6 Regression]: r164529 cris-elf libstdc++ 27_io/basic_filebuf/seekoff/char/2-io.cc

[hp at gcc dot gnu.org]

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

--- Comment #11 from Hans-Peter Nilsson  2010-10-01 
03:15:40 UTC ---
(In reply to comment #9)
> I somewhat doubt this will fix it, but if it's not more effort, then please 
> use
> the patch for an additional test run.

That patch made no difference to the results.

[Bug c/45852] New: volatile structs are broken!

[regehr at cs dot utah.edu]

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

   Summary: volatile structs are broken!
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: reg...@cs.utah.edu
CC: cheny...@cs.utah.edu


gcc should not be optimizing away the read from or write to this struct.

reg...@john-home:~$ current-gcc -v
Using built-in specs.
COLLECT_GCC=current-gcc
COLLECT_LTO_WRAPPER=/home/regehr/z/compiler-install/gcc-r164818-install/libexec/gcc/i686-pc-linux-gnu/4.6.0/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: ../configure --with-libelf=/usr/local --enable-lto
--prefix=/home/regehr/z/compiler-install/gcc-r164818-install
--program-prefix=r164818- --enable-languages=c,c++
Thread model: posix
gcc version 4.6.0 20100930 (experimental) (GCC) 

reg...@john-home:~$ current-gcc -S -o - -O1 small.c 

.file   "small.c"
.text
.globl  func_1
.type   func_1, @function
func_1:
.LFB0:
.cfi_startproc
rep
ret
.cfi_endproc
.LFE0:
.size   func_1, .-func_1
.globl  g_18
.data
.align 4
.type   g_18, @object
.size   g_18, 4
g_18:
.long   -6
.ident  "GCC: (GNU) 4.6.0 20100930 (experimental)"
.section.note.GNU-stack,"",@progbits

reg...@john-home:~$ cat small.c

struct S1
{
  int f0;
};

volatile struct S1 g_18 = { -6 };

void
func_1 (void)
{
  g_18 = g_18;
}

[Bug target/45807] Lying eh_frame r2 save info causes crashes with static libgcc_eh and libstdc++

[meissner at gcc dot gnu.org]

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

--- Comment #5 from Michael Meissner  2010-10-01 
01:51:43 UTC ---
This patch fixes the problem with linux ppc64 builds when the compiler is
defaulting to 64-bit cpus.

This patch is ok to check in.

[Bug testsuite/45851] FAIL: gcc.dg/lto/20090210 link test with WHOPR owing to bad -pthread option.

[davek at gcc dot gnu.org]

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

Dave Korn  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2010.10.01 01:30:26
 AssignedTo|unassigned at gcc dot   |ro at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

--- Comment #1 from Dave Korn  2010-10-01 01:30:26 
UTC ---
Hi Rainer; Cc'ing you as requested back before you went on vacation.

[Bug testsuite/45851] New: FAIL: gcc.dg/lto/20090210 link test with WHOPR owing to bad -pthread option.

[davek at gcc dot gnu.org]

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

   Summary: FAIL: gcc.dg/lto/20090210 link test with WHOPR owing
to bad -pthread option.
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: da...@gcc.gnu.org


>From original post at http://gcc.gnu.org/ml/gcc-patches/2010-09/msg01076.html:

On 15/07/2010 19:08, Rainer Orth wrote:

> > * The TLS tests in libobjc failed because they weren't linked with
> >   -pthread.  I've implemented and used dg-add-options tls to handle
> >   this.  Only gcc.dg/lto/20090210_0.c needs an explict
> >   dg-extra-ld-options "-pthread" since dg-lto-do tests don't work with
> >   dg-add-options.

> > gcc/testsuite:
> > * gcc.dg/lto/20090210_0.c: Add -pthread for *-*-solaris2.[89].

Hi Rainer,

  I have a problem on i686-pc-cygwin caused by this part of your patch:

> > diff -r c7b371acdb35 gcc/testsuite/gcc.dg/lto/20090210_0.c
> > --- a/gcc/testsuite/gcc.dg/lto/20090210_0.c Mon Jul 12 16:03:30 2010 +0200
> > +++ b/gcc/testsuite/gcc.dg/lto/20090210_0.c Thu Jul 15 18:27:58 2010 +0200
> > @@ -1,5 +1,7 @@
> >  /* { dg-lto-do run }  */
> >  /* { dg-suppress-ld-options {-fPIC} }  */
> > +/* { dg-require-effective-target tls } */
> > +/* { dg-extra-ld-options "-pthread" { target *-*-solaris2.[89] } } */
> >  int foo (int x)
> >  {
> >return x;

  As far as I can tell, dg-extra-ld-options doesn't take a target modifier in
the way you've used there, so that "-pthread" is in effect on all targets and
breaks the testcase on targets which don't support that option.  See proc
lto-get-options-main in gcc/testsuite/lto.exp.  Perhaps you could extend it to
work with a target selector?  Or maybe there's some other way you could get
the -pthread flag passed on Solaris (only)?

cheers,
  DaveK


Here's gcc.log around where the failure occurs:



Executing on host: /gnu/gcc/obj-tfmode-fenv/gcc/xgcc
-B/gnu/gcc/obj-tfmode-fenv/gcc/  -O0 -fwhopr  -c  -o c_lto_20090210_0.o
/gnu/gcc/gcc-unpatched/gcc/testsuite/gcc.dg/lto/20090210_0.c(timeout = 300)
spawn /gnu/gcc/obj-tfmode-fenv/gcc/xgcc -B/gnu/gcc/obj-tfmode-fenv/gcc/ -O0
-fwhopr -c -o c_lto_20090210_0.o
/gnu/gcc/gcc-unpatched/gcc/testsuite/gcc.dg/lto/20090210_0.c 
PASS: gcc.dg/lto/20090210 c_lto_20090210_0.o assemble, -O0 -fwhopr
Executing on host: /gnu/gcc/obj-tfmode-fenv/gcc/xgcc
-B/gnu/gcc/obj-tfmode-fenv/gcc/  -O0 -fwhopr -fPIC -c  -o c_lto_20090210_1.o
/gnu/gcc/gcc-unpatched/gcc/testsuite/gcc.dg/lto/20090210_1.c(timeout = 300)
spawn /gnu/gcc/obj-tfmode-fenv/gcc/xgcc -B/gnu/gcc/obj-tfmode-fenv/gcc/ -O0
-fwhopr -fPIC -c -o c_lto_20090210_1.o
/gnu/gcc/gcc-unpatched/gcc/testsuite/gcc.dg/lto/20090210_1.c 
/gnu/gcc/gcc-unpatched/gcc/testsuite/gcc.dg/lto/20090210_1.c:1:0: warning:
-fPIC ignored for target (all code is position independent) [enabled by
default]
output is:
/gnu/gcc/gcc-unpatched/gcc/testsuite/gcc.dg/lto/20090210_1.c:1:0: warning:
-fPIC ignored for target (all code is position independent) [enabled by
default]

PASS: gcc.dg/lto/20090210 c_lto_20090210_1.o assemble, -O0 -fwhopr
Executing on host: /gnu/gcc/obj-tfmode-fenv/gcc/xgcc
-B/gnu/gcc/obj-tfmode-fenv/gcc/ c_lto_20090210_0.o c_lto_20090210_1.o  -O0
-fwhopr -pthread  -o gcc-dg-lto-20090210-01(timeout = 300)
spawn /gnu/gcc/obj-tfmode-fenv/gcc/xgcc -B/gnu/gcc/obj-tfmode-fenv/gcc/
c_lto_20090210_0.o c_lto_20090210_1.o -O0 -fwhopr -pthread -o
gcc-dg-lto-20090210-01 
xgcc: error: unrecognized option '-pthread'
compiler exited with status 1
output is:
xgcc: error: unrecognized option '-pthread'

FAIL: gcc.dg/lto/20090210 c_lto_20090210_0.o-c_lto_20090210_1.o link, -O0
-fwhopr
UNRESOLVED: gcc.dg/lto/20090210 c_lto_20090210_0.o-c_lto_20090210_1.o execute
-O0 -fwhopr

[Bug c++/45645] pr44972.C fails with error: ‘__assert_fail’ was not declared in this scope

[howarth at nitro dot med.uc.edu]

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

Jack Howarth  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #10 from Jack Howarth  2010-10-01 
00:57:56 UTC ---
Fixed at r164479.

[Bug target/45196] ld: warning: can't add line info to anonymous symbol

[howarth at nitro dot med.uc.edu]

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

Jack Howarth  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #8 from Jack Howarth  2010-10-01 
00:52:40 UTC ---
The 'can't add line info to anonymous symbol' warning has been removed as of
Xcode 4.0 due to the excessive noise it generates. This issue should not
reappear in the main gcc testsuite since...


2010-09-10  Jack Howarth 

PR target/42070
* gcc/testsuite/lib/profopt.exp: Prune warnings on execname2 compile.
* gcc/testsuite/lib/prune.exp: Prune "can't add line info" warnings.

will prune out these bogus warnings under Xcode 3.2.x.

[Bug tree-optimization/43959] [4.6 Regression] FAIL: gcc.dg/torture/builtin-cproj-1.c -O1 (test for excess errors)

[danglin at gcc dot gnu.org]

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

John David Anglin  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #22 from John David Anglin  2010-10-01 
00:52:00 UTC ---
Fixed.

[Bug tree-optimization/43959] [4.6 Regression] FAIL: gcc.dg/torture/builtin-cproj-1.c -O1 (test for excess errors)

[danglin at gcc dot gnu.org]

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

--- Comment #21 from John David Anglin  2010-10-01 
00:47:13 UTC ---
Author: danglin
Date: Fri Oct  1 00:47:09 2010
New Revision: 164824

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=164824
Log:
PR tree-optimization/43959
* function.c (gimplify_parameters): Use create_tmp_reg instead of
create_tmp_var.


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

[Bug target/45787] r164531 breaks plugin support on x86_64-apple-darwin10

[howarth at nitro dot med.uc.edu]

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

Jack Howarth  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #7 from Jack Howarth  2010-10-01 
00:45:37 UTC ---
Fixed on gcc trunk with...

Author: mrs
Date: Wed Sep 29 17:28:19 2010
New Revision: 164726

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=164726
Log:
Joseph Myers  
Jack Howarth 

* config/darwin.opt (undefined): Add.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/darwin.opt

[Bug c/45850] New: support color diagnostics

[manu at gcc dot gnu.org]

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

   Summary: support color diagnostics
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: m...@gcc.gnu.org


Support using color output to mark warnings/errors/notes.

Basically, clang's

-f[no-]color-diagnostics:
This option, which defaults to on when a color-capable terminal is
detected, controls whether or not Clang prints diagnostics in color. When this
option is enabled, Clang will use colors to highlight specific parts of the
diagnostic.


Basis for implementation may be either diff or grep. It should be implemented
either in diagnostics.c or pretty-print.c (probably, diagnostics.c calling
pretty-print.c to enable/disable specific colors).

[Bug c++/45490] Confusing error message for local type arguments

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Target|x86_64-suse-linux   |
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.10.01 00:04:46
   Host|x86_64-suse-linux   |
 Ever Confirmed|0   |1
  Build|x86_64-suse-linux   |

--- Comment #3 from Andrew Pinski  2010-10-01 
00:04:46 UTC ---
Even though we now print out the candidates, I think we could print out that
the templates don't match local types.

[Bug target/45807] Lying eh_frame r2 save info causes crashes with static libgcc_eh and libstdc++

[amodra at gmail dot com]

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

--- Comment #4 from Alan Modra  2010-09-30 23:52:29 
UTC ---
Caught out by sign extension rules.

Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c(revision 164818)
+++ gcc/config/rs6000/rs6000.c(working copy)
@@ -20234,8 +20242,8 @@ rs6000_emit_prologue (void)
  be updated if we arrived at this function via a plt call or
  toc adjusting stub.  */
   emit_move_insn (tmp_reg_si, gen_rtx_MEM (SImode, tmp_reg));
-  toc_restore_insn = ((TARGET_32BIT ? 0x80410014 : 0xE8410028)
-  ^ 0x8000) - 0x8000;
+  toc_restore_insn = TARGET_32BIT ? 0x80410014 : 0xE8410028;
+  toc_restore_insn = (toc_restore_insn ^ 0x8000) - 0x8000;
   emit_insn (gen_xorsi3 (tmp_reg_si, tmp_reg_si,
  GEN_INT (toc_restore_insn & ~0x)));
   compare_result = gen_rtx_REG (CCUNSmode, CR0_REGNO);

[Bug debug/45849] New: [4.6 Regression] ICE: in emit_note_insn_var_location, at var-tracking.c:7336 with -O -g

[zsojka at seznam dot cz]

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

   Summary: [4.6 Regression] ICE: in emit_note_insn_var_location,
at var-tracking.c:7336 with -O -g
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz


Created attachment 21927
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=21927
reduced testcase

Compiler output:
$ gcc -O -g testcase.c
testcase.c: In function 'foo':
testcase.c:27:1: internal compiler error: in emit_note_insn_var_location, at
var-tracking.c:7336
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Tested revisions:
r164716 - crash
r163636 - crash
r161659 - OK
4.5 r163761 - OK

[Bug target/45486] throw not being caught

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  2010-09-30 
23:22:31 UTC ---
Works on linux, so I am thinking this is a target specific bug.

[Bug c/45464] Warning missing using -Wall when comparing unsigned int and sum of unsigned chars.

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.09.30 23:15:48
  Component|c++ |c
 Ever Confirmed|0   |1
  Known to fail||4.1.2, 4.3.2, 4.6.0

--- Comment #2 from Andrew Pinski  2010-09-30 
23:15:48 UTC ---
Confirmed, happens also for C (you need to add #define bool _Bool).

[Bug target/38185] -fstrict-aliasing causes wrong register usage

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED
  Known to fail||

--- Comment #5 from Andrew Pinski  2010-09-30 
23:10:04 UTC ---
Well this has been fixed for a while.

[Bug middle-end/40979] induct benchmark 60% slower when compiled with -fgraphite-identity

[spop at gcc dot gnu.org]

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

Sebastian Pop  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||spop at gcc dot gnu.org
 AssignedTo|unassigned at gcc dot   |spop at gcc dot gnu.org
   |gnu.org |

--- Comment #8 from Sebastian Pop  2010-09-30 23:02:28 
UTC ---
# FLAGS="-ffast-math -funroll-loops -msse3 -O3 -ftree-vectorizer-verbose=7"
# f951 $FLAGS induct.f90  &> foo
# f951 $FLAGS induct.f90 -fgraphite-identity &> foo.graphite
# grep "LOOP VECTORIZED" foo | wc
 8  32 320
# grep "LOOP VECTORIZED" foo.graphite | wc
 4  16 160

So we still have 4 non vectorized loops with -fgraphite-identity.

[Bug pch/45471] ICE with PCH and differening strict-aliasing settings

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.09.30 23:02:19
 Ever Confirmed|0   |1

--- Comment #3 from Andrew Pinski  2010-09-30 
23:02:19 UTC ---
305  /* Make sure abi::__type_info_pseudo has the same alias set
306 as std::type_info.  */

Simple fix:
Index: c-pch.c
===
--- c-pch.c(revision 164815)
+++ c-pch.c(working copy)
@@ -47,6 +47,7 @@ static const struct c_pch_matching
   const char *flag_name;
 } pch_matching[] = {
   { &flag_exceptions, "-fexceptions" },
+  { &flag_strict_aliasing, "-fstrict-aliasing" },
 };

 enum {

[Bug libstdc++/45841] [4.6 Regression]: r164529 cris-elf libstdc++ 27_io/basic_filebuf/seekoff/char/2-io.cc

[hp at gcc dot gnu.org]

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

--- Comment #10 from Hans-Peter Nilsson  2010-09-30 
22:55:20 UTC ---
(In reply to comment #9)
> I somewhat doubt this will fix it, but if it's not more effort, then please 
> use
> the patch for an additional test run.

Thank you, testing in progress.  The least effort was to just throw it to the
full build and test cycle, so it'll be a few hours, possibly interfered by some
Z's.

> If it is a fix, then something is wrong
> with lseek().

That seems like an important clue, thanks.

[Bug fortran/45676] Move array assignments out of loop

[tkoenig at gcc dot gnu.org]

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

--- Comment #3 from Thomas Koenig  2010-09-30 
21:28:22 UTC ---
(In reply to comment #2)
> We can't hoist invariant control flow.

Is this not possible, not desirable, or both?

In C, you could (in principle) also hoist

for (i=0; i<10; i++) {
  for (j=0; j<10; j++)
a[j] = j

/* Terms using a, no redefinition of a, no alias etc.  */

}
>  Also print *,c is surely thought
> to be an escape point for c and thus may clobber it.

Yes, PR 20165...

> I'd rate this impossible to do for the middle-end (and generally not worth
> the hassle to implement).  Better fix your sources ;)

Well, if somebody does FORmula TRANslation and doesn't think about
this, there is not reason not to help him :-)

[Bug target/45843] [4.3/4.4 Regression] __builtin_va_arg overwrites into adjacent stack location

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

  Known to work||4.5.2, 4.6.0
Summary|[4.3/4.4/4.5/4.6|[4.3/4.4 Regression]
   |Regression] |__builtin_va_arg overwrites
   |__builtin_va_arg overwrites |into adjacent stack
   |into adjacent stack |location
   |location|
  Known to fail|4.6.0   |

--- Comment #4 from Jakub Jelinek  2010-09-30 
21:27:05 UTC ---
Fixed for 4.5/4.6 for now, 4.4/4.3 needs PR44575 backport before backporting
this there.

[Bug middle-end/45758] [4.6 Regression] ICE in expr_invariant_in_loop_p

[spop at gcc dot gnu.org]

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

Sebastian Pop  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #9 from Sebastian Pop  2010-09-30 21:23:41 
UTC ---
Fixed.

[Bug middle-end/45230] gcc.c-torture/execute/strncmp-1.c ICEs with -fgraphite-identity

[spop at gcc dot gnu.org]

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

Sebastian Pop  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #16 from Sebastian Pop  2010-09-30 
21:23:29 UTC ---
Fixed.

[Bug middle-end/45758] [4.6 Regression] ICE in expr_invariant_in_loop_p

[spop at gcc dot gnu.org]

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

--- Comment #8 from Sebastian Pop  2010-09-30 21:22:13 
UTC ---
Author: spop
Date: Thu Sep 30 21:22:07 2010
New Revision: 164813

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=164813
Log:
Fix PR45758: reset scevs before Graphite.

2010-09-24  Sebastian Pop  

PR middle-end/45758
* graphite.c (graphite_initialize): Call scev_reset.

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

[Bug middle-end/45758] [4.6 Regression] ICE in expr_invariant_in_loop_p

[spop at gcc dot gnu.org]

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

--- Comment #7 from Sebastian Pop  2010-09-30 21:21:52 
UTC ---
Author: spop
Date: Thu Sep 30 21:21:46 2010
New Revision: 164811

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=164811
Log:
Add testcase for PR45758.

2010-09-23  Sebastian Pop  

PR middle-end/45758
* gfortran.dg/graphite/pr45758.f90: New.

Added:
trunk/gcc/testsuite/gfortran.dg/graphite/pr45758.f90
Modified:
trunk/gcc/ChangeLog.graphite
trunk/gcc/testsuite/ChangeLog

[Bug fortran/42954] [4.5/4.6 regression] TARGET_*_CPP_BUILDINS issues with gfortran

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

[Bug middle-end/45229] gcc.c-torture/execute/20000412-4.c ICEs with -fgraphite-identity

[spop at gcc dot gnu.org]

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

Sebastian Pop  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #5 from Sebastian Pop  2010-09-30 21:19:48 
UTC ---
Fixed.

[Bug middle-end/45230] gcc.c-torture/execute/strncmp-1.c ICEs with -fgraphite-identity

[spop at gcc dot gnu.org]

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

--- Comment #15 from Sebastian Pop  2010-09-30 
21:19:05 UTC ---
Author: spop
Date: Thu Sep 30 21:18:59 2010
New Revision: 164791

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=164791
Log:
Add testcase for PR45230.

2010-08-20  Sebastian Pop  

PR middle-end/45230
* gcc.dg/graphite/id-pr45230.c: New.

Added:
trunk/gcc/testsuite/gcc.dg/graphite/id-pr45230.c
Modified:
trunk/gcc/ChangeLog.graphite
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/45229] gcc.c-torture/execute/20000412-4.c ICEs with -fgraphite-identity

[spop at gcc dot gnu.org]

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

--- Comment #4 from Sebastian Pop  2010-09-30 21:18:06 
UTC ---
Author: spop
Date: Thu Sep 30 21:18:01 2010
New Revision: 164785

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=164785
Log:
Fix PR45229: gcc.c-torture/execute/2412-4.c ICEs with -fgraphite-identity.

2010-08-17  Sebastian Pop  

PR middle-end/45229
* graphite-sese-to-poly.c (rewrite_cross_bb_scalar_deps): Do not
handle GIMPLE_CALLs with no LHS.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/ChangeLog.graphite
trunk/gcc/graphite-sese-to-poly.c

[Bug web/45768] Input boxes overflow with low resolutions.

[LpSolit at netscape dot net]

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

Frédéric Buclin  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED
 AssignedTo|unassigned at gcc dot   |LpSolit at netscape dot net
   |gnu.org |

--- Comment #3 from Frédéric Buclin  2010-09-30 
21:10:05 UTC ---
I renamed "Last reconfirmed date" to "Last reconfirmed". This should do it.

[Bug fortran/45746] [OOP] ICE in fold_convert_loc: pointer to allocatable array with select type

[janus at gcc dot gnu.org]

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

--- Comment #3 from janus at gcc dot gnu.org 2010-09-30 21:01:13 UTC ---
I do not see the error on x86_64-unknown-linux-gnu at r164767. Can anyone
confirm that?

[Bug web/45846] Partial attachments in bugzilla

[LpSolit at netscape dot net]

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

Frédéric Buclin  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #3 from Frédéric Buclin  2010-09-30 
20:51:19 UTC ---
Done. wget is happy.

[Bug tree-optimization/31261] Missed tree optimizations: (8 - (x & 7)) & 7

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #6 from Jakub Jelinek  2010-09-30 
20:38:28 UTC ---
Fixed.

[Bug target/45843] [4.3/4.4/4.5/4.6 Regression] __builtin_va_arg overwrites into adjacent stack location

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  2010-09-30 
20:21:33 UTC ---
Author: jakub
Date: Thu Sep 30 20:21:28 2010
New Revision: 164766

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=164766
Log:
PR target/45843
* config/i386/i386.c (ix86_gimplify_va_arg): Use
INTVAL (XEXP (slot, 1)) as prev_size.

* g++.dg/torture/pr45843.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/torture/pr45843.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/testsuite/ChangeLog

--- Comment #3 from Jakub Jelinek  2010-09-30 
20:24:59 UTC ---
Author: jakub
Date: Thu Sep 30 20:24:54 2010
New Revision: 164767

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=164767
Log:
PR target/45843
* config/i386/i386.c (ix86_gimplify_va_arg): Use
INTVAL (XEXP (slot, 1)) as prev_size.

* g++.dg/torture/pr45843.C: New test.

Added:
branches/gcc-4_5-branch/gcc/testsuite/g++.dg/torture/pr45843.C
Modified:
branches/gcc-4_5-branch/gcc/ChangeLog
branches/gcc-4_5-branch/gcc/config/i386/i386.c
branches/gcc-4_5-branch/gcc/testsuite/ChangeLog

[Bug web/45846] Partial attachments in bugzilla

[LpSolit at netscape dot net]

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

Frédéric Buclin  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 AssignedTo|unassigned at gcc dot   |LpSolit at netscape dot net
   |gnu.org |

--- Comment #2 from Frédéric Buclin  2010-09-30 
20:10:39 UTC ---
mysql> select length(thedata) from attach_data where id=21915;
+-+
| length(thedata) |
+-+
| 666 |
+-+

All attachments are zipped before being inserted into the DB. 666 bytes is the
size of the compressed attachment. I have to fix $attachment->datasize to
return the size of the uncompressed data, but this means that I can no longer
do a SQL query with length(thedata). I have to get the data itself, unzip it,
and then look at length(uncompressed data), which is slower.

[Bug fortran/45848] New: [OOP] ICE on invalid code in fortran/symbol.c:2410

[anlauf at gmx dot de]

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

   Summary: [OOP] ICE on invalid code in fortran/symbol.c:2410
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: anl...@gmx.de
  Host: i686-pc-linux-gnu


Hi,

the following (invalid) code leads to an ICE:

! Compile with: gfortran -fwhole-file -c gfcbug111.f90
! The "comment line" below appears to have an effect!?

module gfcbug111
!!  use abstract_vector
  implicit none

  type, abstract :: inner_product_class
  end type inner_product_class

  type, extends(inner_product_class) :: trivial_inner_product_type
  end type trivial_inner_product_type

contains

  function my_dot_v_v (this,a,b)
class(trivial_inner_product_type), intent(in) :: this
class(vector_class),   intent(in) :: a,b
real :: my_dot_v_v

select type (a)
class is (trivial_vector_type)
   select type (b)
   class is (trivial_vector_type)
   class default
   end select
class default
end select
  end function my_dot_v_v
end module gfcbug111


I get:

gfcbug111.f90:18.23:

class(vector_class),   intent(in) :: a,b
   1
Error: Derived type 'vector_class' at (1) is being used before it is defined
gfcbug111.f90:22.33:

class is (trivial_vector_type)
 1
Error: 'trivial_vector_type' at (1) is not an accessible derived type
gfcbug111.f90:23.22: 

   select type (b)
  1
Error: Expected TYPE IS, CLASS IS or END SELECT statement following SELECT TYPE
at (1)
f951: internal compiler error: Segmentation fault   

> gdb /opt/gcc/trunk/libexec/gcc/i686-pc-linux-gnu/4.6.0/f951
GNU gdb (GDB; openSUSE 11.1) 6.8.50.20081120-cvs
Copyright (C) 2008 Free Software Foundation, Inc.   
License GPLv3+: GNU GPL version 3 or later    
This is free software: you are free to change and redistribute it.  
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"  
and "show warranty" for details.
This GDB was configured as "i586-suse-linux".   
For bug reporting instructions, please see:
...
(gdb) run gfcbug111.f90 -quiet -dumpbase gfcbug111.f90 -mtune=generic
-march=pentiumpro -auxbase gfcbug111 -version -fwhole-file
-fintrinsic-modules-path
/opt/gcc/trunk/lib/gcc/i686-pc-linux-gnu/4.6.0/finclude -o /tmp/ccnYRIzm.s
Starting program: /opt/gcc/trunk/libexec/gcc/i686-pc-linux-gnu/4.6.0/f951
gfcbug111.f90 -quiet -dumpbase gfcbug111.f90 -mtune=generic -march=pentiumpro
-auxbase gfcbug111 -version -fwhole-file -fintrinsic-modules-path
/opt/gcc/trunk/lib/gcc/i686-pc-linux-gnu/4.6.0/finclude -o /tmp/ccnYRIzm.s
GNU Fortran (GCC) version 4.6.0 20100929 (experimental) (i686-pc-linux-gnu)
compiled by GNU C version 4.6.0 20100929 (experimental), GMP version
4.2.3, MPFR version 2.3.2, MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU Fortran (GCC) version 4.6.0 20100929 (experimental) (i686-pc-linux-gnu)
compiled by GNU C version 4.6.0 20100929 (experimental), GMP version
4.2.3, MPFR version 2.3.2, MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
gfcbug111.f90:18.23:

class(vector_class),   intent(in) :: a,b
   1
Error: Derived type 'vector_class' at (1) is being used before it is defined
gfcbug111.f90:22.33:

class is (trivial_vector_type)
 1
Error: 'trivial_vector_type' at (1) is not an accessible derived type
gfcbug111.f90:23.22:

   select type (b)
  1
Error: Expected TYPE IS, CLASS IS or END SELECT statement following SELECT TYPE
at (1)

Program received signal SIGSEGV, Segmentation fault.
gfc_find_symtree (st=0x7e1, name=0xbfffe120 "class")
at ../../trunk/gcc/fortran/symbol.c:2410
2410  c = strcmp (name, st->name);
(gdb) where
#0  gfc_find_symtree (st=0x7e1, name=0xbfffe120 "class")
at ../../trunk/gcc/fortran/symbol.c:2410
#1  0x08160f8e in gfc_find_sym_tree (name=0xbfffe120 "class", ns=0x8cd9048,
parent_flag=0,
result=0xbfffe0ec) at ../../trunk/gcc/fortran/symbol.c:2631
#2  0x0816125c in gfc_get_ha_sym_tree (name=0xbfffe120 "class",
result=0xbfffe198)
at ../../trunk/gcc/fortran/symbol.c:2800
#3  0x0811cdc4 in gfc_match_sym_tree (matched_symbol=0xbfffe198, host_assoc=1)
at ../../trunk/gcc/fortran/match.c:678
#4  0xbfffe120 in

[Bug bootstrap/45801] [4.6 regression] powerpc64-linux bootstrap comparison failure

[mikpe at it dot uu.se]

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

--- Comment #3 from Mikael Pettersson  2010-09-30 
20:01:49 UTC ---
(In reply to comment #1)
> Please try with current trunk.

No joy.  Trunk as of a few hours ago, r164755, still fails with the same
bootstrap comparison failure I showed earlier.  I did run into PR45837 but
Meissner's patch cured it.

[Bug fortran/45828] [4.6 Regression] No default initialization of derived type members?

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #9 from janus at gcc dot gnu.org 2010-09-30 19:55:37 UTC ---
Fixed with r164765. Closing.

Thanks for the report!

[Bug fortran/45828] [4.6 Regression] No default initialization of derived type members?

[janus at gcc dot gnu.org]

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

--- Comment #8 from janus at gcc dot gnu.org 2010-09-30 19:54:11 UTC ---
Author: janus
Date: Thu Sep 30 19:54:08 2010
New Revision: 164765

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=164765
Log:
2010-09-30  Janus Weil  

PR fortran/45828
* resolve.c (resolve_allocate_expr): Do not use
'gfc_has_default_initializer'.

2010-09-30  Janus Weil  

PR fortran/45828
* gfortran.dg/allocate_derived_5.f90: New.

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

[Bug target/45837] [4.6 Regression] Global options changes on Sept. 29th, breaks powerpc linux64 build

[meissner at gcc dot gnu.org]

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

--- Comment #2 from Michael Meissner  2010-09-30 
19:53:01 UTC ---
Author: meissner
Date: Thu Sep 30 19:52:57 2010
New Revision: 164764

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=164764
Log:
PR target/45837: Make powerpc build again

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/aix.h
trunk/gcc/config/rs6000/option-defaults.h
trunk/gcc/config/rs6000/rs6000.h

[Bug c/45831] 0 = 10 (with -O0, 0 = 0 with -O1, but 10 = 10 expected)

[MichieldeB at aim dot com]

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

--- Comment #16 from Michiel  2010-09-30 19:38:55 
UTC ---
(In reply to comment #15)
> (In reply to comment #14)
> >
> > Is that really too hard?
>
> You are ignoring everything everybody is saying. If you think it is trivial,
> just take one single little case of the ones that bother you and fix it:
> 
> http://gcc.gnu.org/contribute.html
> 
> GCC needs more developers anyway, so you are welcome on board.

I am not ignoring everyone, since I formulated things far more concrete than
before. And I failed to formulate similar things to warnings for assigning
negative expressions to unsigned integers.

Another thing that is worth noting, is that recognizing expression as mentioned
above is also valuable for optimization, namely if you convert the result later
to a smaller integral type, and the larger integral type is larger than the
machines integral type, then you better do the computations with the smaller
integral type instead.

I have to apologize. There are already too many technically interesting things,
or just interesting things that are also technically, that I want to do.
Furthermore, I think that it will take very much time before I can make my
first contribution to the compiler, but I should browse the source to get a
better opinion on that. Some library routines would be more attainable, I will
think about that.

[Bug fortran/45828] [4.6 Regression] No default initialization of derived type members?

[janus at gcc dot gnu.org]

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

--- Comment #7 from janus at gcc dot gnu.org 2010-09-30 19:36:48 UTC ---
(In reply to comment #6)
> Here is a better patch, which avoids the use of
> 'gfc_has_default_initializer':

Forgot to mention: This one regtests cleanly. Will commit as obvious shortly.

[Bug bootstrap/45796] [4.6 regression] make targets info-gcc, dvi-gcc etc. should work from unbuilt configured tree

[rwild at gcc dot gnu.org]

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

Ralf Wildenhues  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #6 from Ralf Wildenhues  2010-09-30 
19:23:55 UTC ---
Yes, this used to work.  The difference between the 4.5 branch and trunk is
that now we have a generated gcc/doc/tm.texi from its .in file, and that
creating/updating tm.texi requires build/genhooks to be present.

Anyway, fixed.

[Bug fortran/45828] [4.6 Regression] No default initialization of derived type members?

[janus at gcc dot gnu.org]

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

--- Comment #6 from janus at gcc dot gnu.org 2010-09-30 19:23:11 UTC ---
(In reply to comment #5)
> To fix it I propose the following patch (not regtested yet):

Regtesting showed that the patch in comment #5 fails on common_10.f90 (due to
the fact that the 'initializer' field may be set also for components without
default initialization). Here is a better patch, which avoids the use of
'gfc_has_default_initializer':


Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c(revision 164755)
+++ gcc/fortran/resolve.c(working copy)
@@ -6708,6 +6708,7 @@ resolve_allocate_expr (gfc_expr *e, gfc_code *code
 {
   /* Set up default initializer if needed.  */
   gfc_typespec ts;
+  gfc_expr *init_e;

   if (code->ext.alloc.ts.type == BT_DERIVED)
 ts = code->ext.alloc.ts;
@@ -6717,9 +6718,8 @@ resolve_allocate_expr (gfc_expr *e, gfc_code *code
   if (ts.type == BT_CLASS)
 ts = ts.u.derived->components->ts;

-  if (ts.type == BT_DERIVED && gfc_has_default_initializer(ts.u.derived))
+  if (ts.type == BT_DERIVED && (init_e = gfc_default_initializer (&ts)))
 {
-  gfc_expr *init_e = gfc_default_initializer (&ts);
   gfc_code *init_st = gfc_get_code ();
   init_st->loc = code->loc;
   init_st->op = EXEC_INIT_ASSIGN;

[Bug tree-optimization/31261] Missed tree optimizations: (8 - (x & 7)) & 7

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  2010-09-30 
19:21:44 UTC ---
Author: jakub
Date: Thu Sep 30 19:21:34 2010
New Revision: 164761

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=164761
Log:
PR tree-optimization/31261
* fold-const.c (fold_binary): Optimize ((A & N) + B) & M
for constants M and N, M == (1LL << cst) - 1 && (N & M) == M.

* gcc.dg/tree-ssa/pr31261.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr31261.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/fold-const.c
trunk/gcc/testsuite/ChangeLog

[Bug target/45847] New: ICE in supportable_widening_operation

[raj.khem at gmail dot com]

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

   Summary: ICE in supportable_widening_operation
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: raj.k...@gmail.com
  Host: i686-linux-gnu
Target: arm-none-linux-gnueabi
 Build: i686-linux-gnu


The following sample causes gcc ICE on arm

int decode_subframe_lpc(int channel, int pred_order)
{
int i, j;
int qlevel;
int coeffs[pred_order];
int *decoded = channel;
long long sum;
for (i = pred_order; i < channel; i++) {
for (j = 0; j < pred_order; j++)
sum += (long long)coeffs[j] * decoded[i-j-1];
decoded[i] += sum >> qlevel;
}

return 0;
}

here is the commandline to reproduce it, it only happens at O3

arm-none-linux-gnueabi-gcc-4.6.0 -march=armv7-a -mtune=cortex-a8 -mfpu=neon
-mfloat-abi=softfp flacdec.i -c -O3


here is backtrace

Analyzing compilation unit
Performing interprocedural optimizations
 <*free_lang_data>   
 Assembling
functions:
 decode_subframe_lpc
Program received signal SIGSEGV, Segmentation fault.
0x085bfa6a in supportable_widening_operation (code=WIDEN_MULT_EXPR, 
stmt=0xb7f942d8, vectype_out=0x0, vectype_in=0xb7de8660, decl1=0xb26c, 
decl2=0xb26c, code1=0xb268, code2=0xb268, 
multi_step_cvt=0xb264, interm_types=0xb260)
at
/home/kraj/work/cross/arm-none-linux-gnueabi/../../gcc-trunk/gcc/tree-vect-stmts.c:5193
5193  if (insn_data[icode1].operand[0].mode != TYPE_MODE (wide_vectype)


here is the compiler configure

$ arm-none-linux-gnueabi-gcc-4.6.0 -v
Using built-in specs.
COLLECT_GCC=arm-none-linux-gnueabi-gcc-4.6.0
COLLECT_LTO_WRAPPER=/home/kraj/work/cross/arm-none-linux-gnueabi/tools/libexec/gcc/arm-none-linux-gnueabi/4.6.0/lto-wrapper
Target: arm-none-linux-gnueabi
Configured with:
/home/kraj/work/cross/arm-none-linux-gnueabi/../../gcc-trunk/configure
--target=arm-none-linux-gnueabi
--prefix=/home/kraj/work/cross/arm-none-linux-gnueabi/tools
--with-sysroot=/home/kraj/work/cross/arm-none-linux-gnueabi/sysroot
--enable-__cxa_atexit --disable-libssp --disable-libgomp --disable-libmudflap
--enable-languages=c,c++
Thread model: posix
gcc version 4.6.0 20100927 (experimental) (GCC)

[Bug bootstrap/45796] [4.6 regression] make targets info-gcc, dvi-gcc etc. should work from unbuilt configured tree

[rwild at gcc dot gnu.org]

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

--- Comment #5 from Ralf Wildenhues  2010-09-30 
19:16:43 UTC ---
Author: rwild
Date: Thu Sep 30 19:16:34 2010
New Revision: 164760

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=164760
Log:
build: info-gcc, dvi-gcc etc work from unbuilt configured tree.

/:
PR bootstrap/45796
* Makefile.def (info-gcc, dvi-gcc, pdf-gcc, html-gcc):
Depend on all-build-libiberty.
* Makefile.in: Regenerate.

Modified:
trunk/ChangeLog
trunk/Makefile.def
trunk/Makefile.in

[Bug bootstrap/45796] [4.6 regression] make targets info-gcc, dvi-gcc etc. should work from unbuilt configured tree

[rwild at gcc dot gnu.org]

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

--- Comment #4 from Ralf Wildenhues  2010-09-30 
19:16:25 UTC ---
Author: rwild
Date: Thu Sep 30 19:16:14 2010
New Revision: 164759

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=164759
Log:
build: more correct build rules for build/gen% programs.

gcc/:
PR bootstrap/45796
* Makefile.in (build/gen%$(build_exeext)): Move rule after all
special-casing for generators and turn into ...
((genprog:%=build/gen%$(build_exeext))): ... this static pattern
rule, for better error messages in case of toplevel dependency
errors.
(genprog): Add hooks, rename to ...
(genprogerr): ... this, and let genprog also contain check,
checksum, condmd.
((genprog:%=build/gen%$(build_exeext))): Rename to ...
((genprogerr:%=build/gen%$(build_exeext))): ... this.
(build/genhooks$(build_exeext)): Remove now-unneeded dependency.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/Makefile.in

[Bug target/45807] Lying eh_frame r2 save info causes crashes with static libgcc_eh and libstdc++

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

 CC||meissner at gcc dot gnu.org

--- Comment #3 from Michael Meissner  2010-09-30 
19:04:09 UTC ---
This breaks builds where the default is 64-bit, i.e. --with-cpu=default64

With --with-cpu=default64, it fails in building libgcc.a:
/home/meissner/fsf-install-ppc64/binutils-current/bin/ranlib libgcc.a
/home/meissner/fsf-build-ppc64/trunk/./gcc/xgcc
-B/home/meissner/fsf-build-ppc64/trunk/./gcc/
-B/home/meissner/fsf-install-ppc64/trunk/powerpc64-linux/bin/
-B/home/meissner/fsf-install-ppc64/trunk/powerpc64-linux/lib/ -isystem
/home/meissner/fsf-install-ppc64/trunk/powerpc64-linux/include -isystem
/home/meissner/fsf-install-ppc64/trunk/powerpc64-linux/sys-include-g -O2
-O2  -g -O2 -DIN_GCC   -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition  -isystem ./include  -fPIC
-mno-minimal-toc -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED 
-mlong-double-128 -I. -I. -I../.././gcc -I/home/meissner/fsf-src/trunk/libgcc
-I/home/meissner/fsf-src/trunk/libgcc/.
-I/home/meissner/fsf-src/trunk/libgcc/../gcc
-I/home/meissner/fsf-src/trunk/libgcc/../include
-I/home/meissner/fsf-src/trunk/libgcc/../libdecnumber/dpd
-I/home/meissner/fsf-src/trunk/libgcc/../libdecnumber -DHAVE_CC_TLS  -o
unwind-dw2.o -MT unwind-dw2.o -MD -MP -MF unwind-dw2.dep -fexceptions -c
/home/meissner/fsf-src/trunk/libgcc/../gcc/unwind-dw2.c -fvisibility=hidden
-DHIDE_EXPORTS
In file included from
/home/meissner/fsf-src/trunk/libgcc/../gcc/unwind-dw2.c:1582:0:
/home/meissner/fsf-src/trunk/libgcc/../gcc/unwind.inc: In function
‘_Unwind_RaiseException’:
/home/meissner/fsf-src/trunk/libgcc/../gcc/unwind.inc:136:1: error: insn does
not satisfy its constraints:
(insn 217 216 218 2 (set (reg:SI 11 11)
(xor:SI (reg:SI 11 11)
(const_int 3896573952 [0xe841])))
/home/meissner/fsf-src/trunk/libgcc/../gcc/unwind.inc:83 158
{*boolsi3_internal1}
 (nil))
/home/meissner/fsf-src/trunk/libgcc/../gcc/unwind.inc:136:1: internal compiler
error: in copyprop_hardreg_forward_1, at regcprop.c:768
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[2]: *** [unwind-dw2.o] Error 1
make[2]: Leaving directory
`/home/meissner/fsf-build-ppc64/trunk/powerpc64-linux/libgcc'
make[1]: *** [all-target-libgcc] Error 2
make[1]: Leaving directory `/home/meissner/fsf-build-ppc64/trunk'
make: *** [all] Error 2

[Bug c/45831] 0 = 10 (with -O0, 0 = 0 with -O1, but 10 = 10 expected)

[manu at gcc dot gnu.org]

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

--- Comment #15 from Manuel López-Ibáñez  2010-09-30 
18:51:33 UTC ---
(In reply to comment #14)
>
> Is that really too hard?

You are ignoring everything everybody is saying. If you think it is trivial,
just take one single little case of the ones that bother you and fix it:

http://gcc.gnu.org/contribute.html

GCC needs more developers anyway, so you are welcome on board.

[Bug fortran/42954] [4.5/4.6 regression] TARGET_*_CPP_BUILDINS issues with gfortran

[nightstrike at gmail dot com]

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

--- Comment #8 from nightstrike  2010-09-30 
18:47:04 UTC ---
This bug is listed as NEW, not ASSIGNED, but it's set to be assigned to FX. 
Can the status be updated to ASSIGNED?

[Bug bootstrap/45760] GCC build fails: can't find MPC

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #9 from Jonathan Wakely  2010-09-30 
18:39:44 UTC ---
fixed by http://gcc.gnu.org/ml/gcc-patches/2010-09/msg02135.html

the online docs should update overnight

[Bug c/45831] 0 = 10 (with -O0, 0 = 0 with -O1, but 10 = 10 expected)

[MichieldeB at aim dot com]

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

--- Comment #14 from Michiel  2010-09-30 18:30:16 
UTC ---
Remove signed/unsigned warnings, or even overflow warnings, for constants that
are used in an expression with the following operations only:

casts to integral type of smaller or equal size,
casts to boolean, !, == and !=,
casts from boolean to integral type, ? :,
+ - * << & | ^.

Probably I missed some, but I hope you see what I mean. Then you will
understand that /, %, >> and casts to larger integral type (or float, double)
do not belong to this list.

Is that really too hard?

[Bug tree-optimization/45781] [4.6 Regression] GCC incorrectly puts function in .text.unlikely

[hubicka at gcc dot gnu.org]

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

--- Comment #6 from Jan Hubicka  2010-09-30 
18:21:29 UTC ---
I think I am hitting instance of PR45846.  I get just part of the testcase:
typedef union tree_node *tree;
struct tree_exp { tree operands[1]; };
union tree_node { struct tree_exp exp; };
static unsigned char init_target_chars (void);
static unsigned long long target_newline;



tree rewrite_call_expr()
{
return 0;
}

tree fold_builtin_snprintf_chk (tree exp)
{
tree len, fmt;
if (exp->exp.operands[0] < 5)

[Bug bootstrap/45658] [4.6 regression] Comparison failure in gcc/ada/ali.o on Solaris 2/SPARC

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||FIXED

--- Comment #8 from Rainer Orth  2010-09-30 17:50:18 UTC 
---
Works again as of rev. 164749.

[Bug tree-optimization/45781] [4.6 Regression] GCC incorrectly puts function in .text.unlikely

[hubicka at ucw dot cz]

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

--- Comment #4 from Jan Hubicka  2010-09-30 17:47:39 UTC 
---
Hi, please, can you add the testcase to PR?  I guess problem might be that as
the function is split and then
inlined back together the profile gets confused...

Honza

Re: [Bug tree-optimization/45781] [4.6 Regression] GCC incorrectly puts function in .text.unlikely

[Jan Hubicka]

Hi, please, can you add the testcase to PR?  I guess problem might be that as 
the function is split and then
inlined back together the profile gets confused...

Honza

[Bug bootstrap/45700] [4.5/4.6 Regression] --enable-checking=fold bootstrap failures

[aldyh at gcc dot gnu.org]

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

--- Comment #1 from Aldy Hernandez  2010-09-30 
17:47:19 UTC ---
If we call build[1-5] just to call protected_set_expr_location next, then by
all means, use build[1-5]_loc and be done with it.

Ideally we should strive to set location information if we know it, so I think
Jakub's second approach of setting the locus if different (with a copy_node) is
a good one.  However, if memory usage goes up too much, perhaps we should
re-think this, or ignore the locus as suggested.

[Bug tree-optimization/45781] [4.6 Regression] GCC incorrectly puts function in .text.unlikely

[sje at cup dot hp.com]

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

--- Comment #3 from Steve Ellcey  2010-09-30 17:41:36 
UTC ---
(In reply to comment #1)
> The decision is reasonable (I suppose partial inlining will inline the
> if (!init) case) as the function is called exactly once then and thus
> should be optimized for size and put into a separate section.

But when I compile with -O2, partial inlining doesn't inline anything.
All the calls still exist as they are in the code.  Actually, the only
reason I can see for moving init_target_chars to .text.unlikely is that
there are 3 'early returns' in fold_builtin_snprintf_chk that could prevent
the execution from ever getting to the init_target_chars call.  Maybe that is
why GCC put it in .text.unlikely.

Very strange, I added:

tree rewrite_call_expr() { return 0; }

to my test case and recompiled to see if this new code went into .text.unlikely
but for some reason that caused everything (including init_target_chars)
to be put into .text.

> 
> The question is thus, why does that break IA64 bootstrap?
> 
> If IA64 doesn't support .text.unlikely it should define
> UNLIKELY_EXECUTED_TEXT_SECTION_NAME appropriately.

Yes, I think I need to define this for IA64 HP-UX.

[Bug web/45846] Partial attachments in bugzilla

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.09.30 17:38:57
   date||
 Ever Confirmed|0   |1

--- Comment #1 from Andrew Pinski  2010-09-30 
17:38:57 UTC ---
I have been noticing this too.

[Bug web/45846] New: Partial attachments in bugzilla

[jakub at gcc dot gnu.org]

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

   Summary: Partial attachments in bugzilla
   Product: gcc
   Version: 4.3.6
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: web
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ja...@gcc.gnu.org


When downloading
http://gcc.gnu.org/bugzilla/attachment.cgi?id=21915
with wget or elinks, only 666 bytes are downloaded, while when viewing the same
in mozilla, it has 1710 bytes.
When doing
telnet gcc.gnu.org 80
GET /bugzilla/attachment.cgi?id=21915 HTTP/1.1
Host: gcc.gnu.org

I get:
HTTP/1.1 200 OK
Date: Thu, 30 Sep 2010 17:35:13 GMT
Server: Apache/2.0.52 (Red Hat)
Content-disposition: inline; filename="bug-45837.patch01"
Content-length: 666
Vary: Accept-Encoding
Content-Type: text/plain; name="bug-45837.patch01"; charset=

and then 1710 bytes of the file, so it seems to be a bugzilla bug.

[Bug lto/45810] 40% slowdown when using LTO for a single-file program

[dominiq at lps dot ens.fr]

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

--- Comment #10 from Dominique d'Humieres  
2010-09-30 17:28:19 UTC ---
(In reply to comment #8)
> Using -fno-inline-functions, the program recovers the speed of the no-LTO
> version.

This does not work on powerpc-apple-darwin9:

[karma] lin/test% gfc -Ofast -funroll-loops -fwhole-program -g fatigue.f90
[karma] lin/test% time a.out > /dev/null
15.942u 0.052s 0:16.54 96.6%0+0k 2+1io 40pf+0w
[karma] lin/test% gfc -Ofast -funroll-loops -fwhole-program -g -flto
fatigue.f90
[karma] lin/test% time a.out > /dev/null
20.330u 0.063s 0:21.06 96.8%0+0k 0+2io 0pf+0w
[karma] lin/test% gfc -Ofast -funroll-loops -fwhole-program -g -flto
-fno-inline-functions fatigue.f90
[karma] lin/test% time a.out > /dev/null
20.678u 0.063s 0:21.33 97.1%0+0k 0+2io 0pf+0w
[karma] lin/test% gfc -Ofast -funroll-loops -fwhole-program -g -flto
-finline-limit=600 fatigue.f90
[karma] lin/test% time a.out > /dev/null
10.903u 0.036s 0:11.30 96.7%0+0k 0+2io 0pf+0w

[Bug bootstrap/45801] [4.6 regression] powerpc64-linux bootstrap comparison failure

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Depends on||45837

--- Comment #2 from Andrew Pinski  2010-09-30 
17:09:35 UTC ---
(In reply to comment #1)
> Please try with current trunk.

Well PR 45837 shows a different failure instead.

[Bug target/45837] [4.6 Regression] Global options changes on Sept. 29th, breaks powerpc linux64 build

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |4.6.0
Summary|Global options changes on   |[4.6 Regression] Global
   |Sept. 29th, breaks powerpc  |options changes on Sept.
   |linux64 build   |29th, breaks powerpc
   ||linux64 build

[Bug c++/45845] g++.dg/pubtypes.C scan-assembler "A\\\\\\\\0"+[ \\t]+[#;@]+[\\t]+external name

[howarth at nitro dot med.uc.edu]

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

--- Comment #4 from Jack Howarth  2010-09-30 
17:02:29 UTC ---
The failing testcase was introduced with the proposed patch...

http://gcc.gnu.org/ml/gcc-patches/2006-11/msg00438.html

that added the ability to generate the DWARF pubtypes section on Darwin
architectures (or any other architecture that defines DEBUG_PUBTYPES_SECTION).

[Bug tree-optimization/45781] [4.6 Regression] GCC incorrectly puts function in .text.unlikely

[hubicka at gcc dot gnu.org]

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

--- Comment #2 from Jan Hubicka  2010-09-30 
16:44:17 UTC ---
IA-64 seems to be fine with unlikely section at least at our periodic tester
setup, otherwise SPEC2000 FDO testing would break. So it might be specific for
ia64 HP-UX and in that case indeed correct fix is to simply define cold and hot
sections to be .text sections (or fix it at binutils side) for HP-UX IA-64 (and
possibly PA target too).

What I am confused about is how partial inlining affect placement of
init_target_chars. If it was because function got partially inlined, the wrong
call would be named init_target_chars.part.XXX and it is not.

It is possible that partial inlining affect profile in some of the callers and
then it might be some bug in profile updating, so I would like to see a
testcase.
x.c in the PR is truncated and when i compile builtins.c from my GCC tree
(x86-64) I do not get init_target_chars in unlikely function.
For some funny reason I however get gimple_rewrite_call_expr. All uses of it
are preceeded by very many exists from the function that makes them appear
cold. Funny but probably not harmful.

Honza

[Bug bootstrap/42628] ICE during bootstrap when compiling several libsupc++ files: original tree changed by fold

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #11 from Jakub Jelinek  2010-09-30 
16:42:41 UTC ---
That's PR45700.

[Bug bootstrap/42628] ICE during bootstrap when compiling several libsupc++ files: original tree changed by fold

[aanisimov at inbox dot ru]

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

Artem Anisimov  changed:

   What|Removed |Added

 CC||aanisimov at inbox dot ru

--- Comment #10 from Artem Anisimov  2010-09-30 
16:35:06 UTC ---
  4.6 trunk fails too. Building rev. 164569 fails with the following error:

../../../../gcc-current/libstdc++-v3/libsupc++/dyncast.cc: In function 'void*
__cxxabiv1::__dynamic_cast(const void*, const __cxxabiv1::__class_type_info*,
const __cxxabiv1::__class_type_info*, ptrdiff_t)':
../../../../gcc-current/libstdc++-v3/libsupc++/dyncast.cc:86:1: internal
compiler error: fold check: original tree changed by fold
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

  GCC was configured with these options:

../gcc-current/configure --prefix=/home/artem/testing/gcc46 --enable-shared
--enable-bootstrap --enable-languages=c,c++ --enable-threads=posix
--enable-checking=release --with-system-zlib --disable-libunwind-exceptions
--enable-__cxa_atexit --enable-libssp --with-gnu-ld --with-lto --disable-nls
--verbose --with-arch=athlon64 --target=x86_64-slackware-linux
--build=x86_64-slackware-linux --host=x86_64-slackware-linux --disable-multilib
--enable-checking=all

[Bug c/32511] [4.4/4.5/4.6 regression] GCC rejects inline+weak function

[jason at gcc dot gnu.org]

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

--- Comment #11 from Jason Merrill  2010-09-30 
16:01:01 UTC ---
I don't see it as different at all; I am arguing that the initial bug report
was not actually a bug, and that the patch should be reverted.

[Bug fortran/39427] F2003: Procedures with same name as types/type constructors

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org

--- Comment #20 from Tobias Burnus  2010-09-30 
15:49:37 UTC ---
(In reply to comment #19)
> Could someone please comment on the relevance (or lack thereof) of the
> component being public in the example I submitted?

This issue was solved off list/PR. The question was how to interpret the
following, where [F2008's] R455 defines a "structure-constructor":

"C496 (R455) If derived-type-spec is a type name that is the same as a generic
name, the component-spec-list shall not be a valid actual-arg-spec-list for a
function reference that is resolvable as a generic reference to that name
(12.5.5.2)."

My interpretation is that this only disallows structure constructors, i.e.,
that generic functions have a higher precedence than structure constructors.
Thus, one can always override a constructor by a generic function. (And I do
not see how private components could alter the interpretation of C496 - even if
one reads it differently.)

F2008 also has the following note, which supports the overriding
interpretation:

"NOTE 4.58   The form 'name(...)' is interpreted as a generic
function-reference if possible; it is interpreted as a structure-constructor
only if it cannot be interpreted as a generic function-reference."

[Bug rtl-optimization/38644] [4.3/4.4/4.5/4.6 Regression] Optimization flag -O1 -fschedule-insns2 causes wrong code

[sebastian.hu...@embedded-brains.de]

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

--- Comment #32 from Sebastian Huber  
2010-09-30 15:36:02 UTC ---
Which target milestone do you intend for a fix?  It is still present in 4.6.0
20100925.

[Bug fortran/45828] [4.6 Regression] No default initialization of derived type members?

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 AssignedTo|unassigned at gcc dot   |janus at gcc dot gnu.org
   |gnu.org |

--- Comment #5 from janus at gcc dot gnu.org 2010-09-30 14:48:17 UTC ---
(In reply to comment #3)
> the problem seems to be in expr.c (called from resolve.c:
> resolve_allocate_expr())
> 
> [...]
> 
> if a derived type has a derived type component it only checks whether
> that components components have default initializers, not the component
> itself.

Right. To fix it I propose the following patch (not regtested yet):

Index: gcc/fortran/expr.c
===
--- gcc/fortran/expr.c(revision 164461)
+++ gcc/fortran/expr.c(working copy)
@@ -3662,21 +3662,18 @@ gfc_has_default_initializer (gfc_symbol *der)

   gcc_assert (der->attr.flavor == FL_DERIVED);
   for (c = der->components; c; c = c->next)
-if (c->ts.type == BT_DERIVED)
-  {
-if (!c->attr.pointer
- && gfc_has_default_initializer (c->ts.u.derived))
-  return true;
-  }
-else
-  {
-if (c->initializer)
-  return true;
-  }
+{
+  if (c->ts.type == BT_DERIVED && !c->attr.pointer
+  && gfc_has_default_initializer (c->ts.u.derived))
+return true;
+  if (c->initializer)
+return true;
+}

   return false;
 }

+
 /* Get an expression for a default initializer.  */

 gfc_expr *

[Bug tree-optimization/45704] [4.5 Regression] load byte instruction is used for volatile int

[rguenther at suse dot de]

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

--- Comment #9 from rguenther at suse dot de  
2010-09-30 14:14:13 UTC ---
On Thu, 30 Sep 2010, anemo at mba dot ocn.ne.jp wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45704
> 
> --- Comment #8 from Atsushi Nemoto  2010-09-30 
> 13:59:34 UTC ---
> (In reply to comment #0)
> > The PR 42956 bugzilla shows same fix was applied to both 4.5.0 and 4.4.4,
> > but they behave differently on this test case.
> > 
> > Comparing patches for 4.4 branch and 4.5, I see the latter contains two more
> > changes for gimplify.c:
> > A STRIP_NOP line and lines starting with "/* *(foo *)&complexfoo => __real__
> > complexfoo */" comment.
> 
> In the first place, why PR 42956 fixes are different for 4.4 and 4.5?
> The commit logs are same, but actual changes for gimplify.c were differ.
> 
> Is that "two more changes" are not bugfix but improvement?

Yes.

[Bug tree-optimization/45704] [4.5 Regression] load byte instruction is used for volatile int

[anemo at mba dot ocn.ne.jp]

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

--- Comment #8 from Atsushi Nemoto  2010-09-30 
13:59:34 UTC ---
(In reply to comment #0)
> The PR 42956 bugzilla shows same fix was applied to both 4.5.0 and 4.4.4,
> but they behave differently on this test case.
> 
> Comparing patches for 4.4 branch and 4.5, I see the latter contains two more
> changes for gimplify.c:
> A STRIP_NOP line and lines starting with "/* *(foo *)&complexfoo => __real__
> complexfoo */" comment.

In the first place, why PR 42956 fixes are different for 4.4 and 4.5?
The commit logs are same, but actual changes for gimplify.c were differ.

Is that "two more changes" are not bugfix but improvement?

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

[burnus at gcc dot gnu.org]

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

--- Comment #14 from Tobias Burnus  2010-09-30 
13:48:15 UTC ---
(In reply to comment #13)
> But I have run valgrind now. It was the first time, so I don't understand the
> result. Is it somehow the fault of my hardware/OS? Here is the output:

> valgrind --leak-check=full /opt/gcc-trunk/bin/gfortran -ffree-form
> -ffree-line-length-0 -I. -L.  -c common.f03 -o common.o

You did not do what I wrote. I wrote:

  valgrind `gfortran -v 2>&1  | grep f951`

you did

  valgrind gfortran ...

Thus you are testing a completely different program! "gcc", "gfortran" etc. are
only "drivers" which call the actual compiler, which is named "cc1", "f951",
... (That is also the reason why C programs can be compiled with "gfortran
foo.c" as this then calls "cc1" rather than "f951".)

To find out the command line arguments to the real compiler 'f951', one can
compile using the option "-v" which shows the parts which are called. The line
of interest is the one which is calling "f951".


> ==31832== 1 bytes in 1 blocks are definitely lost in loss record 2 of 70   
> ==31832== 4 bytes in 1 blocks are possibly lost in loss record 4 of 
etc.

That only tells that some memory has not been freed and is possibly/definitely
lost. That should not happen, but usually just means that gfortran uses more
memory as it should (and which is then only freed by the operating system if
one returns). -- In some cases  (cf. e.g. Bug 45793) those indicate a true
error which have to be fixed. (But one usually should also try to fix normal
memory issues.)

I was more looking for warnings such as:
  ==27731== Invalid read of size 8
which indicate that there is an error (e.g. uninitialized variable or pointer).

[Bug c++/45845] g++.dg/ext/visibility/anon6.C scan-assembler 1BIiE1cE regressed on darwin

[howarth at nitro dot med.uc.edu]

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

--- Comment #3 from Jack Howarth  2010-09-30 
13:47:26 UTC ---
Caused by...

Author: rguenth
Date: Wed Sep 29 13:59:08 2010
New Revision: 164719

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=164719
Log:
2010-09-29  Richard Guenther  

* tree.h (SCOPE_FILE_SCOPE_P): New macro.
(DECL_FILE_SCOPE_P): Use it.
(TYPE_FILE_SCOPE_P): New macro.

cp/
* cp-tree.h (CP_DECL_CONTEXT): Check DECL_FILE_SCOPE_P.
(CP_TYPE_CONTEXT): Similar.
(FROB_CONTEXT): Frob global_namespace to the global
TRANSLATION_UNIT_DECL.
* decl.c (cxx_init_decl_processing): Build a TRANSLATION_UNIT_DECL,
set DECL_CONTEXT of global_namespace to it.
(start_decl): Use CP_DECL_CONTEXT and test TYPE_P
instead of zeroing context.
(cp_finish_decl): Use DECL_FILE_SCOPE_P.
(grokfndecl): Likewise.
(start_preparsed_function): Likewise.
* name-lookup.c (maybe_push_decl): Use DECL_NAMESPACE_SCOPE_P.
(namespace_binding): Use SCOPE_FILE_SCOPE_P.
* pt.c (template_class_depth): Use CP_TYPE_CONTEXT.
(is_specialization_of_friend): Use CP_DECL_CONTEXT.
(push_template_decl_real): Likewise.
(tsubst_friend_class): Likewise.  Adjust context comparisons.
(instantiate_class_template): Use CP_TYPE_CONTEXT.
(tsubst): Do not substitute into TRANSLATION_UNIT_DECL.
* cxx-pretty-print.c (pp_cxx_nested_name_specifier): Use
SCOPE_FILE_SCOPE_P.

[Bug c++/45845] New: g++.dg/ext/visibility/anon6.C scan-assembler 1BIiE1cE regressed on darwin

[howarth at nitro dot med.uc.edu]

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

   Summary: g++.dg/ext/visibility/anon6.C scan-assembler 1BIiE1cE
regressed on darwin
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: howa...@nitro.med.uc.edu


Between r164716 and r164731, a regression in the g++ test suite appeared on
both powerpc-apple-darwin9 and x86_64-apple-darwin10.

FAIL: g++.dg/pubtypes.C scan-assembler "A0"+[ \\t]+[#;@]+[
\\t]+external name

[Bug tree-optimization/43959] [4.6 Regression] FAIL: gcc.dg/torture/builtin-cproj-1.c -O1 (test for excess errors)

[dave at hiauly1 dot hia.nrc.ca]

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

--- Comment #20 from dave at hiauly1 dot hia.nrc.ca 2010-09-30 13:13:05 UTC ---
> > > Ah.  The following fixes it for me on a cross.  Can you bootstrap & 
> > > regtest and
> > > install it?  It's pre-approved if it works for you.
> > 
> > Will test and install if successful.
> 
> Ping?

It works.  Tested on hppa2.0w-hp-hpux11.11 and hppa64-hp-hpux11.11.
I was going to install it  when I get a chance, but I got side tracked
on other problems.

Dave

[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 #13 from Hans-Werner Boschmann  2010-09-30 13:03:09 UTC ---
(In reply to comment #12)
> Actually, I am confused: From that comment it sounds as if 20100921 does not
> have the bug 45746 - but it has been reported using 20100921 and a comment by
> Dominique indicates that it never worked with GCC 4.5/4.6 but it only worked
> for a while on the fortran-dev branch.

You are right about this, I'm switching back and forth in the version of gcc
and got lost.


But I have run valgrind now. It was the first time, so I don't understand the
result. Is it somehow the fault of my hardware/OS? Here is the output:


valgrind --leak-check=full /opt/gcc-trunk/bin/gfortran -ffree-form
-ffree-line-length-0 -I. -L.  -c common.f03 -o common.o
==31832== Memcheck, a memory error detector 
==31832== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.   
==31832== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info 
==31832== Command: /opt/gcc-trunk/bin/gfortran -ffree-form -ffree-line-length-0
-I. -L. -c common.f03 -o common.o  
==31832==   
common.f03:27.22:   

  use arguments_module
  1
Interner Fehler bei (1):
mio_component_ref(): Component not found
==31832==   
==31832== HEAP SUMMARY: 
==31832== in use at exit: 32,209 bytes in 82 blocks
==31832==   total heap usage: 268 allocs, 186 frees, 49,388 bytes allocated
==31832==  
==31832== 1 bytes in 1 blocks are definitely lost in loss record 2 of 70   
==31832==at 0x4C234E7: calloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==31832==by 0x41FC38: xcalloc (xmalloc.c:162)   
==31832==by 0x40DE7F: main (gcc.c:6993) 
==31832==   
==31832== 4 bytes in 1 blocks are possibly lost in loss record 4 of 70  
==31832==at 0x4C241C3: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==31832==by 0x41FBF7: xmalloc (xmalloc.c:147)   
==31832==by 0x41DA2D: concat (concat.c:159) 
==31832==by 0x407090: driver_handle_option (gcc.c:3729) 
==31832==by 0x410A37: handle_option (opts-common.c:673) 
==31832==by 0x410B7C: read_cmdline_option (opts-common.c:812)   
==31832==by 0x40580E: process_command (gcc.c:4177)  
==31832==by 0x40C63C: main (gcc.c:6593) 
==31832==   
==31832== 15 bytes in 1 blocks are definitely lost in loss record 10 of 70  
==31832==at 0x4C241C3: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==31832==by 0x41FBF7: xmalloc (xmalloc.c:147)   
==31832==by 0x4025D5: save_string (gcc.c:7322)  
==31832==by 0x40B3AB: handle_braces (gcc.c:6093)
==31832==by 0x409303: do_spec_1 (gcc.c:5485)
==31832==by 0x40B455: handle_braces (gcc.c:6096)
==31832==by 0x409303: do_spec_1 (gcc.c:5485)
==31832==by 0x40B455: handle_braces (gcc.c:6096)
==31832==by 0x409303: do_spec_1 (gcc.c:5485)
==31832==by 0x40A25A: do_spec_2 (gcc.c:4554)
==31832==by 0x40A282: do_self_spec (gcc.c:4619) 
==31832==by 0x40ABCE: do_option_spec (gcc.c:4608)   
==31832==   
==31832== 18 bytes in 1 blocks are definitely lost in loss record 16 of 70  
==31832==at 0x4C241C3: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==31832==by 0x41FBF7: xmalloc (xmalloc.c:147)   
==31832==by 0x4025D5: save_string (gcc.c:7322)  
==31832==by 0x40B3AB: handle_braces (gcc.c:6093)
==31832==by 0x409303: do_spec_1 (gcc.c:5485)
==31832==by 0x40B455: handle_braces (gcc.c:6096)
==31832==by 0x409303: do_spec_1 (gcc.c:5485)
==31832==by 0x40B455: handle_braces (gcc.c:6096)
==31832==by 0x409303: do_spec_1 (gcc.c:5485)
==31832==by 0x4097A4: do_spec_1 

[Bug rtl-optimization/45394] [4.6 regression] gnat fails to build on s390, trunk 20100918

[ebotcazou at gcc dot gnu.org]

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

--- Comment #7 from Eric Botcazou  2010-09-30 
13:00:38 UTC ---
For the records, I have a reduced testcase and a patch.  ETA is next week.

[Bug lto/45702] [4.6 Regression] New LTO test failures

[rguenth at gcc dot gnu.org]

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

--- Comment #20 from Richard Guenther  2010-09-30 
12:22:41 UTC ---
Author: rguenth
Date: Thu Sep 30 12:22:33 2010
New Revision: 164749

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=164749
Log:
2010-09-30  Richard Guenther  

PR testsuite/45702
* gcc.dg/debug/pr41893-1.c: Adjust.
* gcc.dg/pr30762-1.c: Likewise.
* gcc.dg/pr31529-1.c: Likewise.
* gcc.dg/pr34457-1.c: Likewise.
* gcc.dg/pr34668-1.c: Likewise.
* gcc.dg/pr43557-1.c: Likewise.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/debug/pr41893-1.c
trunk/gcc/testsuite/gcc.dg/pr30762-1.c
trunk/gcc/testsuite/gcc.dg/pr31529-1.c
trunk/gcc/testsuite/gcc.dg/pr34457-1.c
trunk/gcc/testsuite/gcc.dg/pr34668-1.c
trunk/gcc/testsuite/gcc.dg/pr43557-1.c

[Bug libstdc++/45841] [4.6 Regression]: r164529 cris-elf libstdc++ 27_io/basic_filebuf/seekoff/char/2-io.cc

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Priority|P3  |P4

[Bug tree-optimization/45743] [4.6 Regression] gfortran.dg/whole_file_3.f90 ICE: verify_stmts failed: invalid conversion in gimple call with -finline-small-functions

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Keywords||ice-checking
   Priority|P3  |P1

[Bug tree-optimization/45732] [4.6 Regression] ICE: in bit_value_unop, at tree-ssa-ccp.c:1861 at -O1

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug lto/45721] [4.6 Regression] ICE: in function_and_variable_visibility, at ipa.c:673 with -flto

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug c/45831] 0 = 10 (with -O0, 0 = 0 with -O1, but 10 = 10 expected)

[manu at gcc dot gnu.org]

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

--- Comment #13 from Manuel López-Ibáñez  2010-09-30 
12:12:17 UTC ---
(In reply to comment #10)
> To get to know what a formula does, I usually compute some examples. When 
> doing
> so, I was warned, but ignored them and that was stupid.
> 
> There are however also warnings that are stupid. I now think of setting an
> integer to -2147483648. 2147483648 is too large for an integer and it is good
> that the compiler warns you. Unfortunately, the compiler ignores the context 
> of
> 2147483648 and thus warns for -2147483648 as well. A similar argument applies
> for setting an unsigned to a value in the range 2147483648 to 4294967295. 
> 
> On the other hand, setting an unsigned to a negative value does not give any
> warning. Setting an unsigned to e.g. -1 is totally unnecessary, since you can
> write ~0 instead, which is also preferable.

See: http://gcc.gnu.org/wiki/NewWconversion#Frequently_Asked_Questions

Please search also the C FAQs, your answers are there. We cannot change how C
works, even if it seems counter-intuitive at first glance.

If you find another specific problem, please open a new PR with a complete
testcase and expected/obtained output.

[Bug target/45701] [4.6 Regression] Fail to prefer using r3 for padding a push/pop multiple to 8-byte alignment

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug target/45693] [4.6 regression] All Tru64 UNIX EH tests fail

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Priority|P3  |P4

[Bug lto/45667] [4.6 Regression] ICE: verify_stmts failed: type mismatch in address expression with -flto

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Keywords||ice-checking
 AssignedTo|unassigned at gcc dot   |rguenth at gcc dot gnu.org
   |gnu.org |

--- Comment #2 from Richard Guenther  2010-09-30 
11:58:51 UTC ---
Mine.

[Bug c/45831] 0 = 10 (with -O0, 0 = 0 with -O1, but 10 = 10 expected)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #12 from Jakub Jelinek  2010-09-30 
11:56:41 UTC ---
And the warnings you mention are of course reasonable, -2147483648 in C/C++
is the integer constant 2147483648 (which doesn't fit into int), which is
afterwards negated, you should write -2147483647-1, and you should be using
4294967295U if you want an unsigned int constant.

[Bug tree-optimization/45844] New: FAIL: gfortran.dg/vect/pr45714-b.f -O (internal compiler error)

[dominiq at lps dot ens.fr]

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

   Summary: FAIL: gfortran.dg/vect/pr45714-b.f  -O  (internal
compiler error)
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: domi...@lps.ens.fr
CC: i...@il.ibm.com
  Host: powerpc-apple-darwin9
Target: powerpc-apple-darwin9
 Build: powerpc-apple-darwin9


When compiled with -O3 -m64 -mcpu=power7 -ffast-math -mveclibabi=mass the test
gfortran.dg/vect/pr45714-b.f gives the following ICE:

[karma] f90/bug% gfc -c -O3 -m64 -mcpu=power7 -ffast-math -mveclibabi=mass
/opt/gcc/_gcc_clean/gcc/testsuite/gfortran.dg/vect/pr45714-b.f
/opt/gcc/_gcc_clean/gcc/testsuite/gfortran.dg/vect/pr45714-b.f: In function
'MAIN__':
/opt/gcc/_gcc_clean/gcc/testsuite/gfortran.dg/vect/pr45714-b.f:25:0: error:
insn does not satisfy its constraints:
(insn 39 141 33 2 (set (reg:V2DF 108 v31 [orig:162 vect_cst_.14 ] [162])
(vec_duplicate:V2DF (mem/u/c/i:DF (lo_sum:DI (reg:DI 2 r2)
(const:DI (unspec:DI [
(symbol_ref/u:DI ("*LC1") [flags 0x2])
] 50))) [2 S8 A64])))
/opt/gcc/_gcc_clean/gcc/testsuite/gfortran.dg/vect/pr45714-b.f:14 873
{vsx_splat_v2df}
 (nil))
/opt/gcc/_gcc_clean/gcc/testsuite/gfortran.dg/vect/pr45714-b.f:25:0: internal
compiler error: in reload_cse_simplify_operands, at postreload.c:402

The test has been introduced at revision 164420.

[Bug bootstrap/45658] [4.6 regression] Comparison failure in gcc/ada/ali.o on Solaris 2/SPARC

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|NEW |WAITING

--- Comment #7 from Richard Guenther  2010-09-30 
11:52:13 UTC ---
Please try to re-confirm or close as fixed.