[Bug c++/45897] ZNC. make

[risech at pochta dot ru]

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

--- Comment #3 from buddhabrot  2010-10-06 05:57:20 
UTC ---
The problem is solved! On the virtual server  was not enough physical memory. 
Andrew Pinski, thanks for the help.

[Bug c++/45908] New: ICE involving decltype: in tree_low_cst, at tree.h:4114

[tom.prince at ualberta dot net]

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

   Summary: ICE involving decltype: in tree_low_cst, at
tree.h:4114
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: tom.pri...@ualberta.net


Created attachment 21968
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=21968
failing file

g++-4.6.0-alpha20100925 -std=c++0x -c test.cc
test.cc:7:50: internal compiler error: in tree_low_cst, at tree.h:4114

also:

g++-4.6.0-alpha20100925 -std=c++0x -c test2.cc
test.cc:6:33: error: 'statements' was not declared in this scope
test.cc:6:33: error: 'statements' was not declared in this scope

[Bug debug/45865] [4.6 regression] Failed to build 403.gcc in SPEC CPU 2006

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #4 from H.J. Lu  2010-10-06 02:49:56 
UTC ---
A patch is posted at

http://gcc.gnu.org/ml/gcc-patches/2010-10/msg00417.html

[Bug middle-end/37770] static structures initialization, undefined reference to `_0'

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.3.3

--- Comment #6 from Andrew Pinski  2010-10-06 
02:49:05 UTC ---
So fixed for 4.3.x, 4.2 branch is closed so closing.

[Bug tree-optimization/45902] CPU2006 benchmark sphinx3 fails with vectorization

[pthaugen at gcc dot gnu.org]

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

--- Comment #3 from Pat Haugen  2010-10-06 
02:29:35 UTC ---
Just checked current trunk, rev 165011, still fails.  Started failing a while
ago actually, have it narrowed down to 159910(ok) - 159980(fail). Unfortunately
159920-159970 result in GCC build errors for me.

[Bug middle-end/37770] static structures initialization, undefined reference to `_0'

[amdmi3 at amdmi3 dot ru]

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

Dmitry Marakasov  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|WORKSFORME  |

--- Comment #5 from Dmitry Marakasov  2010-10-06 
02:22:50 UTC ---
Sorry, forgot to finish this one.

Yes, the bug is present with gcc 4.2 compiled by hand (tried last revision from
gcc-4_2-branch). I've also found a commit that fixed this bug in gcc-4_3-branch
with using git repository at git://gcc.gnu.org/git/gcc.git and git bisect:

---
2008-03-25  Richard Guenther  

Backport from mainline:
2008-03-19  Richard Guenther  

PR middle-end/35609
* tree-ssa.c (walk_data): New structure.
(warn_uninitialized_var): If not always_executed warn with "maybe"
instead of "is".
(execute_early_warn_uninitialized): Compute post-dominators.
Initialize always_executed before processing each basic block.

* gcc.dg/testsuite/uninit-15.c: New testcase.
* gcc.dg/testsuite/uninit-16.c: Likewise.


git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/branches/gcc-4_3-bra...@133507
138bc75d-0d04-0410-961f-82ee72b054a4
---

[Bug c++/45894] [4.5/4.6 Regression] [C++0x] ICE: segmentation fault with -Wall

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #3 from H.J. Lu  2010-10-06 02:05:14 
UTC ---
It is caused by revision 146472:

http://gcc.gnu.org/ml/gcc-cvs/2009-04/msg01112.html

[Bug lto/45907] New: [4.6 Regression] Revision 164995 failed gcc.dg/torture/fp-int-convert-*.c

[hjl.tools at gmail dot com]

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

   Summary: [4.6 Regression] Revision 164995 failed
gcc.dg/torture/fp-int-convert-*.c
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com
CC: hubi...@gcc.gnu.org


On Linux/x86, revision 164995:

http://gcc.gnu.org/ml/gcc-cvs/2010-10/msg00177.html

caused:

FAIL: gcc.dg/torture/fp-int-convert-double.c  -O2 -fwhopr  (internal compiler
error)
FAIL: gcc.dg/torture/fp-int-convert-double.c  -O2 -fwhopr  (test for excess
errors)
FAIL: gcc.dg/torture/fp-int-convert-float.c  -O2 -fwhopr  (internal compiler
error)
FAIL: gcc.dg/torture/fp-int-convert-float.c  -O2 -fwhopr  (test for excess
errors)
FAIL: gcc.dg/torture/fp-int-convert-float128.c  -O2 -fwhopr  (internal compiler
error)
FAIL: gcc.dg/torture/fp-int-convert-float128.c  -O2 -fwhopr  (test for excess
errors)
FAIL: gcc.dg/torture/fp-int-convert-float80.c  -O2 -fwhopr  (internal compiler
error)
FAIL: gcc.dg/torture/fp-int-convert-float80.c  -O2 -fwhopr  (test for excess
errors)
FAIL: gcc.dg/torture/fp-int-convert-long-double.c  -O2 -fwhopr  (internal
compiler error)
FAIL: gcc.dg/torture/fp-int-convert-long-double.c  -O2 -fwhopr  (test for
excess errors)
FAIL: gcc.dg/torture/fp-int-convert-timode.c  -O2 -fwhopr  (internal compiler
error)
FAIL: gcc.dg/torture/fp-int-convert-timode.c  -O2 -fwhopr  (test for excess
errors)

[Bug web/45904] Email addresses used by Bugzilla

[fche at redhat dot com]

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

Frank Ch. Eigler  changed:

   What|Removed |Added

 CC||LpSolit at netscape dot net

--- Comment #1 from Frank Ch. Eigler  2010-10-06 
01:25:33 UTC ---
I set the 'mailfrom' config options back to {gcc,sourceware}-bugzi...@foo.
There appears to be no setting to override the envelope-from / Return-Path:
fields, nor to append a Reply-To:, each of which may help fix the problem
of bugs getting bounces recorded in them.

[Bug libstdc++/45893] [C++0x] [DR 817] Finish updating std::bind to rvalue refs

[paolo.carlini at oracle dot com]

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

--- Comment #4 from Paolo Carlini  2010-10-06 
01:13:27 UTC ---
Jon, can I have your help, here?

I'm pretty sure that fixing / implementing this (+ properly forwarding from the
30_threads facilities using bind) would also allow enabling the commented out
overloads for volatile and const volatile. A huge win everywhere.

[Bug debug/45865] [4.6 regression] Failed to build 403.gcc in SPEC CPU 2006

[hjl.tools at gmail dot com]

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

--- Comment #3 from H.J. Lu  2010-10-06 01:11:30 
UTC ---
A simple testcase:

[...@gnu-32 rrs]$ cat pr45865.c
typedef struct rtx_def *rtx;
enum machine_mode {
  VOIDmode,
  CCFPmode,
  CCFPUmode,
  MAX_MACHINE_MODE
};
enum mode_class {
  MODE_CC,
  MODE_FLOAT,
  MODE_COMPLEX_FLOAT,
  MODE_VECTOR_FLOAT
};
extern const enum mode_class mode_class[(int) MAX_MACHINE_MODE];
enum rtx_code {
  UNKNOWN,
  GEU,
  ORDERED,
  CONST_INT
};
struct rtx_def {
  unsigned int code: 16;
  unsigned int mode : 8;
};
extern enum rtx_code reverse_condition (enum rtx_code);
enum rtx_code
reversed_comparison_code_parts (enum rtx_code code, rtx insn, rtx arg0,
rtx arg1)
{
  enum machine_mode mode;
  mode = (enum machine_mode) (arg0)->mode;
  if (mode == VOIDmode)
mode = (enum machine_mode) (arg1)->mode;
  if ((mode_class[(int) (mode)]) == MODE_CC)
return (mode != CCFPmode && mode != CCFPUmode
? reverse_condition (code)
: reverse_condition_maybe_unordered (code));
  switch (code) 
{
case GEU:
  return reverse_condition (code);
case ORDERED:
  return UNKNOWN;
}
  if (((enum rtx_code) (arg0)->code) == CONST_INT
  || (((enum machine_mode) (arg0)->mode) != VOIDmode
  && ! ((mode_class[(int) (mode)]) == MODE_FLOAT
|| (mode_class[(int) (mode)]) == MODE_COMPLEX_FLOAT
|| (mode_class[(int) (mode)]) == MODE_VECTOR_FLOAT)))
return reverse_condition (code);
  return UNKNOWN;
}
[...@gnu-32 rrs]$ /export/gnu/import/rrs/164914/usr/bin/gcc -O2 -S -m32
pr45865.c
pr45865.c: In function \u2018reversed_comparison_code_parts\u2019:
pr45865.c:52:1: internal compiler error: in dwarf2out_cfi_begin_epilogue, at
dwarf2out.c:2930
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
[...@gnu-32 rrs]$

[Bug libstdc++/45906] Cross build gcc 4.5.1 failed but same options success on 4.4.1

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||paolo.carlini at oracle dot
   ||com

--- Comment #1 from Paolo Carlini  2010-10-06 
01:09:08 UTC ---
(In reply to comment #0)
> /home/samson/src/gccB451/arm-none-linux-gnueabi/libstdc++-v3/include/type_traits:179:
> error: a function call cannot appear in a constant-expression
> /home/samson/src/gccB451/arm-none-linux-gnueabi/libstdc++-v3/include/type_traits:179:
> error: template argument 2 is invalid

I know very little about cross-compilation, but something seems badly wrong
with the setup you are using: the 4.5.1 C++ front-end definitely implements the
__is_trivial "builtin".

[Bug libstdc++/45893] [C++0x] [DR 817] Finish updating std::bind to rvalue refs

[paolo.carlini at oracle dot com]

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

--- Comment #3 from Paolo Carlini  2010-10-06 
01:00:27 UTC ---
In fact, if I enable again the volatile and const volatile overloads *and*
fiddle a bit (incompletely) with bind(_Functor __f, _ArgTypes... __args)
changing it to bind(_Functor __f, _ArgTypes&&... __args) and also with
thread(_Callable&& __f, _Args&&... __args) to forward the __args to bind, the
packaged_task/members/invoke5.cc regression caused by the former overloads goes
away. Thus there are definitely interactionss between these issues.

[Bug libstdc++/45906] New: Corss build gcc 4.5.1 failed but same options success on 4.4.1

[samsonluk at gmail dot com]

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

   Summary: Corss build gcc 4.5.1 failed but same options success
on 4.4.1
   Product: gcc
   Version: 4.5.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: samson...@gmail.com


GCC version: 4.5.1 final
System type: i686 Ubuntu 10.04
Cross Toolchain: GNU C (Sourcery G++ Lite 2010q1-202) version 4.4.1
(arm-none-linux-gnueabi)compiled by GNU C version 4.3.2, GMP version 4.3.1,
MPFR version 2.4.2.
build systm type: i686-pc-linux-gnu
host system type: arm-none-linux-gnueabi
target system type: arm-none-linux-gnueabi
gcc source folder: /home/samson/src/gcc-4.5.1
gcc build folder: /home/samson/src/gccB451

gmp-5.0.1, mpc-0.8.2, mpfr-3.0.0 unpack to /home/samson/src/gcc-4.5.1 and
folder renamed gmp, mpc and mpfr respectively.

Options given when GCC was configured/built:
/home/samson/src/gcc-4.4.1/configure --prefix=/opt \
--host=arm-none-linux-gnueabi \
--target=arm-none-linux-gnueabi \
--disable-bootstrap \
--enable-languages=c,c++ \
--enable-threads=posix \
--disable-multilib \
--disable-libstdcxx-pch \
--enable-__cxa_atexit \
--disable-libgomp \
--without-ppl \
--without-cloog \
--enable-clocale=gnu


Compiler error output (using the same options to compile gcc 4.4.1 without any
error and compiler successful build):
make[4]: Entering directory
`/home/samson/src/gccB451/arm-none-linux-gnueabi/libstdc++-v3/src'
/bin/sh ../libtool --tag CXX   --mode=compile arm-none-linux-gnueabi-c++ 
-I/home/samson/src/gccB451/arm-none-linux-gnueabi/libstdc++-v3/include/arm-none-linux-gnueabi
-I/home/samson/src/gccB451/arm-none-linux-gnueabi/libstdc++-v3/include
-I/home/samson/src/gcc-4.5.1/libstdc++-v3/libsupc++  -fno-implicit-templates
-Wall -Wextra -Wwrite-strings -Wcast-qual  -fdiagnostics-show-location=once 
-ffunction-sections -fdata-sections  -g -O2 -D_GNU_SOURCE -std=gnu++0x -c
/home/samson/src/gcc-4.5.1/libstdc++-v3/src/atomic.cc
libtool: compile:  arm-none-linux-gnueabi-c++
-I/home/samson/src/gccB451/arm-none-linux-gnueabi/libstdc++-v3/include/arm-none-linux-gnueabi
-I/home/samson/src/gccB451/arm-none-linux-gnueabi/libstdc++-v3/include
-I/home/samson/src/gcc-4.5.1/libstdc++-v3/libsupc++ -fno-implicit-templates
-Wall -Wextra -Wwrite-strings -Wcast-qual -fdiagnostics-show-location=once
-ffunction-sections -fdata-sections -g -O2 -D_GNU_SOURCE -std=gnu++0x -c
/home/samson/src/gcc-4.5.1/libstdc++-v3/src/atomic.cc  -fPIC -DPIC -o
.libs/atomic.o
In file included from
/home/samson/src/gccB451/arm-none-linux-gnueabi/libstdc++-v3/include/bits/move.h:38,
 from
/home/samson/src/gccB451/arm-none-linux-gnueabi/libstdc++-v3/include/bits/stl_pair.h:60,
 from
/home/samson/src/gccB451/arm-none-linux-gnueabi/libstdc++-v3/include/utility:71,
 from
/home/samson/src/gccB451/arm-none-linux-gnueabi/libstdc++-v3/include/tuple:38,
 from
/home/samson/src/gccB451/arm-none-linux-gnueabi/libstdc++-v3/include/mutex:39,
 from /home/samson/src/gcc-4.5.1/libstdc++-v3/src/atomic.cc:28:
/home/samson/src/gccB451/arm-none-linux-gnueabi/libstdc++-v3/include/type_traits:179:
error: a function call cannot appear in a constant-expression
/home/samson/src/gccB451/arm-none-linux-gnueabi/libstdc++-v3/include/type_traits:179:
error: template argument 2 is invalid
/home/samson/src/gccB451/arm-none-linux-gnueabi/libstdc++-v3/include/type_traits:185:
error: a function call cannot appear in a constant-expression
/home/samson/src/gccB451/arm-none-linux-gnueabi/libstdc++-v3/include/type_traits:185:
error: template argument 2 is invalid
In file included from
/home/samson/src/gccB451/arm-none-linux-gnueabi/libstdc++-v3/include/mutex:44,
 from /home/samson/src/gcc-4.5.1/libstdc++-v3/src/atomic.cc:28:
/home/samson/src/gccB451/arm-none-linux-gnueabi/libstdc++-v3/include/functional:2023:
error: only declarations of constructors can be 'explicit'
In file included from
/home/samson/src/gccB451/arm-none-linux-gnueabi/libstdc++-v3/include/mutex:45,
 from /home/samson/src/gcc-4.5.1/libstdc++-v3/src/atomic.cc:28:
/home/samson/src/gccB451/arm-none-linux-gnueabi/libstdc++-v3/include/system_error:160:
error: only declarations of constructors can be 'explicit'
/home/samson/src/gccB451/arm-none-linux-gnueabi/libstdc++-v3/include/system_error:236:
error: only declarations of constructors can be 'explicit'
In file included from /home/samson/src/gcc-4.5.1/libstdc++-v3/src/atomic.cc:28:
/home/samson/src/gccB451/arm-none-linux-gnueabi/libstdc++-v3/include/mutex:577:
error: only declarations of constructors can be 'explicit'
make[4]: *** [atomic.lo] Error 1
make[4]: Leaving directory
`/home/samson/src/gccB451/arm-none-linux-gnueabi/libstdc++-v3/src'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory
`/home/samson/src/gccB451/arm-none-linux-gnueab

[Bug bootstrap/45905] Cross Build GCC 4.5.1 for arm failed to located gmp header files

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|other   |bootstrap

--- Comment #2 from Andrew Pinski  2010-10-06 
00:48:05 UTC ---
http://gcc.gnu.org/ml/gcc/2010-06/msg00280.html

[Bug other/45905] Cross Build GCC 4.5.1 for arm failed to located gmp header files

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  2010-10-06 
00:47:23 UTC ---
I think this is an issue with the newer versions of MPRF and GMP where you need
to copy a header before being able to build.

[Bug other/45905] New: Cross Build GCC 4.5.1 for arm failed to located gmp header files

[samsonluk at gmail dot com]

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

   Summary: Cross Build GCC 4.5.1 for arm failed to located gmp
header files
   Product: gcc
   Version: 4.5.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: samson...@gmail.com


GCC version: 4.5.1 final
System type: i686 Ubuntu 10.04
Cross Toolchain: GNU C (Sourcery G++ Lite 2010q1-202) version 4.4.1
(arm-none-linux-gnueabi)compiled by GNU C version 4.3.2, GMP version 4.3.1,
MPFR version 2.4.2.
build systm type: i686-pc-linux-gnu
host system type: arm-none-linux-gnueabi
target system type: arm-none-linux-gnueabi
gcc source folder: /home/samson/src/gcc-4.5.1
gcc build folder: /home/samson/src/gccB451

gmp-5.0.1, mpc-0.8.2, mpfr-3.0.0 unpack to /home/samson/src/gcc-4.5.1 and
folder renamed gmp, mpc and mpfr respectively.

Options given when GCC was configured/built:
/home/samson/src/gcc-4.4.1/configure --prefix=/opt \
--host=arm-none-linux-gnueabi \
--target=arm-none-linux-gnueabi \
--disable-bootstrap \
--enable-languages=c,c++ \
--enable-threads=posix \
--disable-multilib \
--disable-libstdcxx-pch \
--enable-__cxa_atexit \
--disable-libgomp \
--without-ppl \
--without-cloog \
--enable-clocale=gnu


Compiler error output:
checking for gmp internal files... configure: error: header files gmp-impl.h
and longlong.h not found
make[1]: *** [configure-mpfr] Error 1
make[1]: Leaving directory `/home/samson/src/gccB451'
make: *** [all] Error 2


Problem fixed by making symlinks of gmp header file uder gcc source folder/gmp
to gcc build folder/gmp :
~/src/gccB451$ ll
total 3848
drwxr-xr-x  8 samson samson4096 2010-10-06 07:53 ./
drwxr-xr-x 15 samson samson4096 2010-10-06 07:11 ../
-rw-r--r--  1 samson samson  139860 2010-10-06 07:41 config.log
-rwxr-xr-x  1 samson samson   35569 2010-10-06 07:41 config.status*
-rw-r--r--  1 samson samson   12765 2010-10-06 07:41 configure451.out
drwxr-xr-x  2 samson samson4096 2010-10-06 07:43 fixincludes/
drwxr-xr-x 11 samson samson4096 2010-10-06 07:47 gcc/
drwxr-xr-x 15 samson samson4096 2010-10-06 07:53 gmp/
drwxr-xr-x  2 samson samson4096 2010-10-06 07:44 intl/
drwxr-xr-x  3 samson samson4096 2010-10-06 07:43 libiberty/
-rw-r--r--  1 samson samson 3214786 2010-10-06 07:53 make451.log
-rw-r--r--  1 samson samson  488822 2010-10-06 07:41 Makefile
drwxr-xr-x  2 samson samson4096 2010-10-06 07:53 mpfr/
-rw-r--r--  1 samson samson  13 2010-10-06 07:41 serdep.tmp
~/src/gccB451$
~/src/gccB451$ cd gmp
~/src/gccB451/gmp$ ll
total 2280
drwxr-xr-x 15 samson samson4096 2010-10-06 07:53 ./
drwxr-xr-x  8 samson samson4096 2010-10-06 07:53 ../
-rw-r--r--  1 samson samson 261 2010-10-06 07:52 assert.lo
-rw-r--r--  1 samson samson1776 2010-10-06 07:52 assert.o
-rw-r--r--  1 samson samson 261 2010-10-06 07:52 compat.lo
-rw-r--r--  1 samson samson1644 2010-10-06 07:52 compat.o
-rw-r--r--  1 samson samson   11714 2010-10-06 07:48 config.cache
-rw-r--r--  1 samson samson   19070 2010-10-06 07:48 config.h
-rw-r--r--  1 samson samson 1166648 2010-10-06 07:49 config.log
-rw-r--r--  1 samson samson 700 2010-10-06 07:48 config.m4
-rwxr-xr-x  1 samson samson   98883 2010-10-06 07:48 config.status*
drwxr-xr-x  2 samson samson4096 2010-10-06 07:48 cxx/
drwxr-xr-x  4 samson samson4096 2010-10-06 07:48 demos/
drwxr-xr-x  2 samson samson4096 2010-10-06 07:48 doc/
-rw-r--r--  1 samson samson 259 2010-10-06 07:52 errno.lo
-rw-r--r--  1 samson samson1660 2010-10-06 07:52 errno.o
-rw-r--r--  1 samson samson 271 2010-10-06 07:52 extract-dbl.lo
-rw-r--r--  1 samson samson1736 2010-10-06 07:52 extract-dbl.o
-rw-r--r--  1 samson samson 196 2010-10-06 07:49 fib_table.h
-rwxr-xr-x  1 samson samson   17577 2010-10-06 07:49 gen-bases*
-rwxr-xr-x  1 samson samson   17248 2010-10-06 07:49 gen-fac_ui*
-rwxr-xr-x  1 samson samson   17427 2010-10-06 07:49 gen-fib*
-rwxr-xr-x  1 samson samson   22198 2010-10-06 07:49 gen-psqr*
-rwxr-xr-x  1 samson samson   21461 2010-10-06 07:49 gen-trialdivtab*
-rw-r--r--  1 samson samson   86217 2010-10-06 07:48 gmp.h
lrwxrwxrwx  1 samson samson  55 2010-10-06 07:49 gmp-mparam.h ->
/home/samson/src/gcc-4.5.1/gmp/mpn/generic/gmp-mparam.h
-rw-r--r--  1 samson samson 263 2010-10-06 07:52 invalid.lo
-rw-r--r--  1 samson samson1244 2010-10-06 07:52 invalid.o
-rw-r--r--  1 samson samson 859 2010-10-06 07:53 libgmp.la
drwxr-xr-x  2 samson samson4096 2010-10-06 07:53 .libs/
-rwxr-xr-x  1 samson samson  269041 2010-10-06 07:49 libtool*
-rw-r--r--  1 samson samson   79975 2010-10-06 07:48 Makefile
-rw-r--r--  1 samson samson 261 2010-10-06 07:52 memory.lo
-rw-r--r--  1 samson samson2248 2010-10-06 07:52 memory.o
-rw-r--r--  1 samson samson 379 2010-10-06 07:49 mp_bases.h
-rw-r--r--  1 samson samson 261 2010-10-06 07:52 mp_bpl.lo
-rw-r--r--  1 samson samso

[Bug tree-optimization/45902] CPU2006 benchmark sphinx3 fails with vectorization

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 CC||hjl.tools at gmail dot com

--- Comment #2 from H.J. Lu  2010-10-06 00:37:39 
UTC ---
Please check if revision 164914 is OK.

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

[paolo at gcc dot gnu.org]

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

--- Comment #44 from paolo at gcc dot gnu.org  
2010-10-06 00:17:38 UTC ---
Author: paolo
Date: Wed Oct  6 00:17:28 2010
New Revision: 165009

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=165009
Log:
2010-10-05  David Krauss  

PR libstdc++/45841
* include/bits/fstream.h (basic_filebuf::underflow): Overflow
success does not preclude returning failure.
(basic_filebuf::pbackfail): Likewise.
(basic_filebuf::xsputn): Fix indentation problem.
(basic_filebuf::xsgetn): Likewise. Also, add similar overflow
call to enable optimized case from write mode.
* testsuite/27_io/basic_filebuf/underflow/char/45841.cc: New.
* testsuite/27_io/basic_filebuf/underflow/wchar_t/45841.cc: Likewise.

Added:
trunk/libstdc++-v3/testsuite/27_io/basic_filebuf/underflow/char/45841.cc
trunk/libstdc++-v3/testsuite/27_io/basic_filebuf/underflow/wchar_t/45841.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/fstream.tcc

[Bug bootstrap/45888] tm.texi generation is not portable, rule is broken

[joseph at codesourcery dot com]

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

--- Comment #3 from joseph at codesourcery dot com  2010-10-05 23:59:16 UTC ---
[resending manually to gcc-bugzilla while Bugzilla is broken and sending 
emails with a header From: address that bounces incoming comments]

On Tue, 5 Oct 2010, amylaar at gcc dot gnu.org wrote:

> I've found a problem with a circular dependency, but the patch for that didn't
> get reviewed:
> http://gcc.gnu.org/ml/gcc-patches/2010-06/msg03046.html

I don't see any patch pings.  The usual rules apply: ping an unreviewed 
patch about weekly, CC to relevant maintainers if necessary, until it is 
reviewed.

[Bug web/45904] New: Email addresses used by Bugzilla

[jsm28 at gcc dot gnu.org]

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

   Summary: Email addresses used by Bugzilla
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: web
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: js...@gcc.gnu.org
CC: f...@redhat.com


GCC Bugzilla is currently sending emails with From: address
gcc-bugzilla-nore...@gcc.gnu.org.  This is very bad because it means email
replies get a bounce:

Hi! This is the ezmlm program. I'm managing the
g...@gcc.gnu.org mailing list.

This is a generic help message. The message I received wasn't sent to
any of my command addresses.

We need to use a valid address here.  Since people may reply to the messages
sent to gcc-bugzilla-noreply at any time in the future, it would be a good idea
to make that address into a valid address for some period of time after the
messages revert back to coming from gcc-bugzilla, and to contact people who
sent messages during the time it bounced to ask them to resend them.

The *envelope* sender can be an invalid address, and should be to avoid bounces
getting filed in bugs, but the header From: address must not be.  The critical
problem is the header address which will lose contributions to bug reports
while it remains as is.

[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 #43 from Hans-Peter Nilsson  2010-10-05 
23:52:03 UTC ---
(In reply to comment #37)
> (In reply to comment #35)
> > Yes and no.  By fixing one of the two (known :) simulator bugs and running 
> > the
> > test-suite for r164529, the result of that test regressed from PASS to FAIL.
> 
> Is it ever a regression (using the proper sense of the word ;v) ) vs my patch?

I think we draw the line at committed revisions, so: no.
I just mentioned them as to clarify what I meant by issue #3 above.

(I haven't committed any of the mentioned simulator fixes yet; I haven't run
the simulator test-suite.  At least now I've written two separate regression
tests for those bugs and verified "manually", i.e. outside the test framework
for src/sim, that they individually fail. ;-)

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

[paolo.carlini at oracle dot com]

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

--- Comment #42 from Paolo Carlini  2010-10-05 
23:48:52 UTC ---
No problem for this time. But the general rule stays: do not hide substantive
changes in the middle of large cosmetic changes. Just send separate patches.

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

[potswa at mac dot com]

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

--- Comment #41 from David Krauss  2010-10-05 23:47:00 
UTC ---
(In reply to comment #40)
> Ok, no problem. While we are at it, I would recommend not including large
> formatting / indentation fixes, are hising too much the substance of the work.
> For a later patch...

D'oh, I just sent you another one including that. My thinking is that it's not
good to include substantive changes inside an indentation correction, because
you can't see them. That code could use a few more changes eventually, so the
indentation really does need to be fixed or it will keep getting less
consistent with every patch.

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

[paolo.carlini at oracle dot com]

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

--- Comment #40 from Paolo Carlini  2010-10-05 
23:40:56 UTC ---
Ok, no problem. While we are at it, I would recommend not including large
formatting / indentation fixes, are hising too much the substance of the work.
For a later patch...

[Bug bootstrap/45888] tm.texi generation is not portable, rule is broken

[amylaar at gcc dot gnu.org]

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

--- Comment #2 from Jorn Wolfgang Rennecke  
2010-10-05 23:39:37 UTC ---
(In reply to comment #0)
> The thread starting at:
> 
> lists a number of issues around tm.texi:
> 
> The output produced by genhooks is not portable (newline encoding), so it
> should either produce binary output, or diff should be used to compare for
> changes.

Sigh.  What was supposed to give C programs more portability works against
us here.

Using diff to ignore line-end space change would not really be satisfactory,
because then you'd get gratuitous changes in the checked in tm.texi whenever
there is a change in the newline encoding in effect when autogenerating a
changed tm.texi.
Unless we make the copy step do newline translation, that is.
So, what is the lesser evil in maintainability and portability?
Generating binary output with unix-style newlines (as we generally have
in our repository), or compare ignoring newline style and translating
while copying?

If we go for translating copying, do we make autoconf fail if no suitable
tool is found?  Would that be specific to --enable-maintainer-mode?  Or do
we postpone the failure till the tool is actually needed?

> The tm.texi rule is broken because it references non-existing
> $(srcdir)/doc/target.def.

Mea culpa.  That should be just a plain $(srcdir)/taget.def .

>  Also, it seems references to source and build tree
> are a bit messed up.  The logic to trigger a warning for updating the wrong
> file could need a look-over, too.

I've found a problem with a circular dependency, but the patch for that didn't
get reviewed:
http://gcc.gnu.org/ml/gcc-patches/2010-06/msg03046.html

If references to source / build trees are 'messed up' in other ways too,
could you please be a bit more specific?

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

[potswa at mac dot com]

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

--- Comment #39 from David Krauss  2010-10-05 23:37:55 
UTC ---
> Good, I'm going to apply it here, give it a spin and commit it if everything
> looks fine.

Please hold off for a minute. I screwed that patch up about as much as it's
possible for something so simple; although there's nothing damaging in there I
might as well include the *intended* change set, fix the logfile, and properly
implement the regression test.

I'll get the hang soon, it's been a while since I did any collaborative
development.

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

[paolo.carlini at oracle dot com]

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

--- Comment #38 from Paolo Carlini  2010-10-05 
23:34:37 UTC ---
> To summarize the comments above, the real issues I know of at r164529 are:
> 1) an extra lseek (compared to r164529) for
> 27_io/basic_filebuf/seekoff/char/2-io.cc
> 2) erroneous behavior that David found, when reading past the end-of-file

Ok, thanks for the summary. Thus it looks like we are in good shape (David said
in a previous message that 1) isn't really worth optimizing for, if I remember
correctly).

> (In reply to comment #34)
> > Posted a patch to fix my end of this, and a regression to verify that fix on
> > working systems.
> > 
> > http://gcc.gnu.org/ml/libstdc++/2010-10/msg00015.html

Good, I'm going to apply it here, give it a spin and commit it if everything
looks fine.

> 
> David, regarding contracting the expression "regression test" into
> "regression": Don't.  It changes the meaning in a bad way: you add a
> "regression *test*" not a "regression".  I hope; at least eventually. :)

I must say I totally agree. More substantively, please, at your ease, figure
out a more complete and independent testcase. The normal rule is: one bug
report, one testcase.

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

[potswa at mac dot com]

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

--- Comment #37 from David Krauss  2010-10-05 23:31:34 
UTC ---
(In reply to comment #35)
> Yes and no.  By fixing one of the two (known :) simulator bugs and running the
> test-suite for r164529, the result of that test regressed from PASS to FAIL.

Is it ever a regression (using the proper sense of the word ;v) ) vs my patch?

[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 #36 from Hans-Peter Nilsson  2010-10-05 
23:29:32 UTC ---
(In reply to comment #33)
> (In reply to comment #32)
> > Thanks for caring but FWIW, my work would not be helped by backing out any
> > changes; I do all the work at a fix set of revisions, followed up if needed
> > (rarely) at a later revision.  I certainly did not have zero fails before, 
> > but
> > they will be much much fewer after this PR is closed!
> 
> Good, I see you are doing an excellent work for your target. Thus, just let me
> know when / if you come to the conclusion that there are real issues in the
> generic library code, because this is an extremely crucial facility, and we
> want to be 100% sure we are not regressing for 4.6.0, even if that means not
> making progress.

To summarize the comments above, the real issues I know of at r164529 are:
1) an extra lseek (compared to r164529) for
27_io/basic_filebuf/seekoff/char/2-io.cc
2) erroneous behavior that David found, when reading past the end-of-file

(In reply to comment #34)
> Posted a patch to fix my end of this, and a regression to verify that fix on
> working systems.
> 
> http://gcc.gnu.org/ml/libstdc++/2010-10/msg00015.html


David, regarding contracting the expression "regression test" into
"regression": Don't.  It changes the meaning in a bad way: you add a
"regression *test*" not a "regression".  I hope; at least eventually. :)

"Hey guys, I just committed a regression."
"Revert immediately and investigate in your local tree."

[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 #35 from Hans-Peter Nilsson  2010-10-05 
23:16:37 UTC ---
(In reply to comment #30)
> Also, I think we need to clarify whether 9425.cc is a regression. That was an
> expected failure before my revision, right?

Yes and no.  By fixing one of the two (known :) simulator bugs and running the
test-suite for r164529, the result of that test regressed from PASS to FAIL.

[Bug tree-optimization/45903] New: unnecessary load of 32/64bit variable when only 8 bits are needed

[zsojka at seznam dot cz]

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

   Summary: unnecessary load of 32/64bit variable when only 8 bits
are needed
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz


Created attachment 21967
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=21967
testcase for both cases

For the following testcase:

uint8_t f64(uint64_t a, uint64_t b)
{
return (a >> 8) + (b >> 8);
}

gcc (r164716) generates this code:

$ gcc -O3 -S -m32 tst10.s tst10.c -masm=intel

f64:
pushebx
mov ecx, DWORD PTR [esp+8]
mov ebx, DWORD PTR [esp+12]
mov eax, DWORD PTR [esp+16]
mov edx, DWORD PTR [esp+20]
shrdecx, ebx, 8
pop ebx
shrdeax, edx, 8
add eax, ecx
ret

while it could use just something like:
f64:
mov al, DWORD PTR [esp+5]
add al, DWORD PTR [esp+9]
ret


The situation is better for 32bit case:

uint8_t f32(uint32_t a, uint32_t b)
{
return (a >> 8) + (b >> 8);
}

where gcc generates:
$ gcc -O3 -S -m32 tst10.s tst10.c -masm=intel

f32:
mov eax, DWORD PTR [esp+4]
mov edx, DWORD PTR [esp+8]
shr eax, 8
shr edx, 8
add eax, edx
ret

while it could generate the same code as for f64:
f32:
mov al, DWORD PTR [esp+5]
add al, DWORD PTR [esp+9]
ret

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

[potswa at mac dot com]

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

--- Comment #34 from David Krauss  2010-10-05 22:47:14 
UTC ---
Posted a patch to fix my end of this, and a regression to verify that fix on
working systems.

http://gcc.gnu.org/ml/libstdc++/2010-10/msg00015.html

[Bug fortran/45889] Regression with I/O of element of allocatable array in derived type

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2010.10.05 22:41:07
 AssignedTo|unassigned at gcc dot   |jvdelisle at gcc dot
   |gnu.org |gnu.org
 Ever Confirmed|0   |1

--- Comment #8 from Jerry DeLisle  2010-10-05 
22:41:07 UTC ---
Keith: Good point, I will add this to my list.  That parens make a difference
is an issue.

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

[paolo.carlini at oracle dot com]

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

--- Comment #33 from Paolo Carlini  2010-10-05 
21:57:26 UTC ---
(In reply to comment #32)
> Thanks for caring but FWIW, my work would not be helped by backing out any
> changes; I do all the work at a fix set of revisions, followed up if needed
> (rarely) at a later revision.  I certainly did not have zero fails before, but
> they will be much much fewer after this PR is closed!

Good, I see you are doing an excellent work for your target. Thus, just let me
know when / if you come to the conclusion that there are real issues in the
generic library code, because this is an extremely crucial facility, and we
want to be 100% sure we are not regressing for 4.6.0, even if that means not
making progress.

[Bug fortran/45900] [OOP] Static TBP resolved incorrectly

[ortp21 at gmail dot com]

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

--- Comment #3 from ortp21 at gmail dot com 2010-10-05 22:01:08 UTC ---
(In reply to comment #2)
> (In reply to comment #1)
> > Confirmed. This is basically a duplicate of PR45836.
> 
> Both are also related to PR42769.

The reason I posted this bug report as well is that PR45836 returned a compiler
error (type mismatch), while this case does not, and actually lets an incorrect
result through. I hope it was worth another report.

Thanks.

[Bug fortran/45900] [OOP] Static TBP resolved incorrectly

[janus at gcc dot gnu.org]

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

--- Comment #2 from janus at gcc dot gnu.org 2010-10-05 21:42:15 UTC ---
(In reply to comment #1)
> Confirmed. This is basically a duplicate of PR45836.

Both are also related to PR42769. I'm currently not sure how to fix this. The
obvious workaround is to use different names for the procedures.

[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 #32 from Hans-Peter Nilsson  2010-10-05 
21:40:39 UTC ---
(In reply to comment #29)
> Otherwise, if the situation is too confused maybe we have to humbly take out
> the improvements to filebuf, allow HP to fix the other issues on the target,
> get back to zero fails there, and on top of that clean status reapply the
> filebuf changes.

Thanks for caring but FWIW, my work would not be helped by backing out any
changes; I do all the work at a fix set of revisions, followed up if needed
(rarely) at a later revision.  I certainly did not have zero fails before, but
they will be much much fewer after this PR is closed!

before, at r164528:
=== libstdc++ Summary ===

# of expected passes6518
# of unexpected failures18
# of unexpected successes   1
# of expected failures  80
# of unsupported tests  496

at r164529, with one of the two found simulator bugs fixed and still with the
one mentioned spurious fail due to "svn diff" failing (i.e. really down to 4):
 === libstdc++ Summary ===

# of expected passes6532
# of unexpected failures6
# of unexpected successes   1
# of expected failures  80
# of unsupported tests  496

[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 #31 from Hans-Peter Nilsson  2010-10-05 
21:26:23 UTC ---
(In reply to comment #28)
> I'm a little confused. Is that supposed to be a sticky state?

Nope.  Don't worry.  The patch I quoted just fixes a bug on the return path
from the host file i/o call, which messed up the return value so the lseek
syscall (as seen from the simulated syscall) returns -0 (just the expression,
no sign-magnitude machine here :) instead of -EINVAL in Linux syscall parlance.

[Bug tree-optimization/45902] CPU2006 benchmark sphinx3 fails with vectorization

[pthaugen at gcc dot gnu.org]

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

Pat Haugen  changed:

   What|Removed |Added

 CC||bergner at gcc dot gnu.org,
   ||meissner at gcc dot gnu.org

--- Comment #1 from Pat Haugen  2010-10-05 
21:24:01 UTC ---
Hmmm, apparently bug got filed before entering all the text.  Anyway, here goes
again...


482.sphinx3 miscompares when built with a recent mainline and the options -O3
-mcpu=power7. The error message seen is:

*** Miscompare of an4.log

Recompiling bencmark source file lm.c with -mno-vsx -mno-altivec or
-fno-tree-vectorize results in a successful execution.

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

[potswa at mac dot com]

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

--- Comment #30 from David Krauss  2010-10-05 21:16:01 
UTC ---
Also, I think we need to clarify whether 9425.cc is a regression. That was an
expected failure before my revision, right?

[Bug tree-optimization/45902] New: CPU2006 benchmark sphinx3 fails with vectorization

[pthaugen at gcc dot gnu.org]

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

   Summary: CPU2006 benchmark sphinx3 fails with vectorization
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: pthau...@gcc.gnu.org
CC: i...@il.ibm.com
  Host: powerpc64-linux
Target: powerpc64-linux
 Build: powerpc64-linux

[Bug fortran/45900] [OOP] Static TBP resolved incorrectly

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.10.05 21:00:31
 CC||janus at gcc dot gnu.org
Summary|[OOP] Polymorphic method|[OOP] Static TBP resolved
   |not called  |incorrectly
 Ever Confirmed|0   |1

--- Comment #1 from janus at gcc dot gnu.org 2010-10-05 21:00:31 UTC ---
Confirmed. This is basically a duplicate of PR45836. The TBP call here is
non-polymorphic, since the type of the passed object is fixed at compile time.
The problem is that it is resolved to the wrong procedure (due to the
procedures having the same name).

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

[paolo.carlini at oracle dot com]

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

--- Comment #29 from Paolo Carlini  2010-10-05 
20:39:11 UTC ---
Can I ask a simple question? At this point in the analysis, do we have a
testcase failing on Linux or Darwin, thus showing a clear regression in the
generic code? If the answer is yes, do we believe a fix is reasonably simple?
Otherwise, if the situation is too confused maybe we have to humbly take out
the improvements to filebuf, allow HP to fix the other issues on the target,
get back to zero fails there, and on top of that clean status reapply the
filebuf changes.

[Bug target/45901] New: alpha-gnu target-specific CPP macros are broken

[fxcoudert at gcc dot gnu.org]

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

   Summary: alpha-gnu target-specific CPP macros are broken
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: fxcoud...@gcc.gnu.org


gcc/config/alpha/gnu.h has:


#define TARGET_OS_CPP_BUILTINS()\
do {\
HURD_TARGET_OS_CPP_BUILTINS();  \
builtin_define ("_LONGLONG");   \
} while (0)

but HURD_TARGET_OS_CPP_BUILTINS is not defined anywhere in the sources. Seems
to have been forgotten by:


2008-11-13  Thomas Schwinge  

PR target/28102
* config.gcc (*-*-gnu*): Move Alpha parts into the `alpha*-*-gnu*',
x86 parts into the `i[34567]86-*-linux*' and parts that are
independent of the processor architecture into the `*-*-linux*' cases.
(*-*-linux*): Consider `linux.opt' only for Linux-based configurations.
* config/i386/gnu.h (GLIBC_DYNAMIC_LINKER): Redefine.
(TARGET_OS_CPP_BUILTINS, LINK_SPEC): Don't redefine.
[TARGET_LIBC_PROVIDES_SSP] (TARGET_THREAD_SSP_OFFSET): Undefine.
* config/gnu.h (NO_IMPLICIT_EXTERN_C): Don't redefine.
(HURD_TARGET_OS_CPP_BUILTINS): Don't define, but instead...
(LINUX_TARGET_OS_CPP_BUILTINS): Redefine.

[Bug fortran/45900] New: [OOP] Polymorphic method not called

[ortp21 at gmail dot com]

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

   Summary: [OOP] Polymorphic method not called
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ort...@gmail.com


The following example code provides an incorrect result using gfortran 4.6.0
20100925. I believe the code is valid and I have tested the same code with the
Intel Fortran compiler (ifort) 11.1 on Linux and the results returned are
correct. See the below example:

types.f90
-
module A
implicit none
type :: aType
contains
procedure :: callback
end type aType
contains
subroutine callback( callback_ )
implicit none
class(aType) :: callback_

print *, "Error: aType method called."
end subroutine callback

subroutine solver( callback_ )
implicit none
class(aType) :: callback_

call callback_%callback()
end subroutine solver
end module A

module B
use A, only: aType
implicit none
type, extends(aType) :: bType
integer :: i
contains
procedure :: callback
end type bType
contains
subroutine callback( callback_ )
implicit none
class(bType) :: callback_

print *, "Made it."
end subroutine callback
end module B

program main
use A
use B
implicit none
type(bType) :: bTypeInstance
integer :: iflag

bTypeInstance%i = 4

call bTypeInstance%callback()
call solver( bTypeInstance )
end program main
-

The result produced running this code are found to be:
$ gfortran -o t types.f90
$ ./t
 Error: aType method called.
 Made it.

While ifort correctly produces the result:
 Made it.
 Made it.

A workaround is to do change "use A" in the main to:

use A, only: solver


Using built-in specs.
COLLECT_GCC=gfortran
Target: x86_64-apple-darwin10.4.0
Configured with: ../gcc-4.6-20100925/configure --prefix=~$HOME/gcc-trunk
--enable-languages=fortran --enable-checking=release --disable-bootstrap
Thread model: posix
gcc version 4.6.0 20100925 (experimental) (GCC)

[Bug fortran/45451] [OOP] Inconsistent status of ALLOCATABLE components inside CLASS variables.

[sfilippone at uniroma2 dot it]

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

--- Comment #11 from Salvatore Filippone  
2010-10-05 19:39:44 UTC ---
(In reply to comment #4)
> Ok, I could reduce this quite a bit:
> 

> 
>1   3   4   5
>1   3   4   5
>0   0   4   5
> 
> The last line here should be the same as the first two. Changing the CLASS
> variable into a TYPE makes it work. Running through valgrind shows:
> 

Strange thing is that guarding with a SELECT TYPE statement as in 
===
 allocate(a,source=acsr)

  write(*,*) acsr%irp(:)

  select type(aa=>a) 
  type is (psb_base_sparse_mat)
call move_alloc(acsr%irp, aa%irp)

write(*,*) aa%irp(:)
  class default
write(*,*) 'Wrong class default'
  end select
 
still gives the wrong answer
[sfili...@localhost bug23]$ ./bug23_janus 
   1   3   4   5
   1   3   4   5
   0   0   4   5

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

[potswa at mac dot com]

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

--- Comment #28 from David Krauss  2010-10-05 19:35:17 
UTC ---
(In reply to comment #26)

> lseek(4, -1, SEEK_CUR)  = -1 EINVAL (Invalid argument)
> read(4, "// 990117 bkoz\n// test functiona"..., 1023) = 1023
> 
> So, it's (error/EOF) file state state that's lost; looks like I have to amend
> the check_v3_target_fileio some more and fix another simulator bug.  Film at
> 11.

I'm a little confused. Is that supposed to be a sticky state? The file is
trying to seek past the beginning, not past the end, so the read should
succeed, right?

The program should terminate immediately without reading after the seek fails. 

We have basic_file_stdio.cc

return lseek(this->fd(), __off, __way);

returns to seekoff in fstream.tcc

   off_type __file_off = _M_file.seekoff(0, ios_base::cur);
   if (__file_off != off_type(-1))
... escape scopes
  return __ret; // only ever assigned pos_type(off_type(-1))

returns to pbackfail in fstream.tcc

  else if (this->seekoff(-1, ios_base::cur) != pos_type(off_type(-1)))
{
  __tmp = this->underflow(); // read 1024, SHOULDN'T GET HERE
  else return __ret; // equal to EOF

So the code path looks sterling to me, yet it reads 1024.

Perhaps the fixed simulator is now reporting a 32-bit return value from lseek
but the the program is actually using a 64-bit, zero-extended value that
doesn't indicate failure?

[Bug objc++/31126] Infinite loop on missing @end

[nicola at gcc dot gnu.org]

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

Nicola Pero  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #2 from Nicola Pero  2010-10-05 19:27:36 
UTC ---
Fixed in trunk.

Thanks

[Bug objc++/23707] ICE on invalid code after error

[nicola at gcc dot gnu.org]

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

Nicola Pero  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||nicola at gcc dot gnu.org
 Resolution||FIXED

--- Comment #3 from Nicola Pero  2010-10-05 19:28:54 
UTC ---
Fixed in trunk.

Thanks

[Bug objc++/31126] Infinite loop on missing @end

[nicola at gcc dot gnu.org]

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

--- Comment #1 from Nicola Pero  2010-10-05 19:23:39 
UTC ---
Author: nicola
Date: Tue Oct  5 19:23:33 2010
New Revision: 164997

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=164997
Log:
In gcc/:
2010-10-05  Nicola Pero  

* c-parser.c (c_parser_objc_method_definition): Updated comment.

In gcc/cp/:
2010-10-05  Nicola Pero  

PR objc++/31125
* parser.c (cp_parser_objc_class_interface): If no identifier
follows an @interface token, stop parsing the interface after
printing an error.
(cp_parser_objc_class_implementation): If no identifier follows an
@implementation token, stop parsing the implementation after
printing an error.

2010-10-05  Nicola Pero  

PR objc++/23707
* parser.c (cp_parser_objc_method_keyword_params): If the required
colon is not found while parsing parameters, stop parsing them.

2010-10-05  Nicola Pero  

PR objc++/31126
* parser.c (cp_parser_objc_class_ivars): Do not eat the EOF or
@end after detecting it.  Print an error if @end is found without
a '}'.
(cp_parser_objc_method_prototype_list): Do not eat the EOF after
detecting it.  Fixed reading the next token when continuing
because of an error in a method signature.  Print an error if EOF
is found without an '@end'.
(cp_parser_objc_method_definition_list): Same change.

2010-10-05  Nicola Pero  

Merge from apple/trunk branch on FSF servers:

2005-10-17  Fariborz Jahanian 

Radar 4290840
* parser.c (cp_parser_objc_method_keyword_params): Check for valid
method parameters and issue error.
(cp_parser_objc_method_definition_list): Check for invalid tokens
which cannot start a function definition.

2005-10-14  Fariborz Jahanian 

Radar 4294425
* parser.c (cp_parser_objc_message_args): Check for missing message
arguments and syntax error.

2005-10-13  Fariborz Jahanian 

Radar 4261146
* parser.c (cp_parser_objc_class_ivars): Check for @end/eof while
looking for '}'.

2005-08-15  Ziemowit Laski  

Radar 4093475
* parser.c (cp_parser_objc_interstitial_code): Catch stray
'{' and '}' tokens and issue appropriate errors.

2005-08-02  Ziemowit Laski  

Radar 4185810
(cp_parser_statement_seq_opt): In addition to '}' and
end-of-file, a statement sequence may also be terminated
by a stray '@end'.

In gcc/objc/:
2010-10-05  Nicola Pero  

Merge from 'apple/trunk' branch on FSF servers.

2005-10-17  Fariborz Jahanian 

Radar 4290840
* objc-act.c (objc_start_method_definition): Check for error_mark_node
for
the selector name and make a quick exit.

In gcc/testsuite/:
2010-10-05  Nicola Pero  

PR objc++/28050
* obj-c++.dg/syntax-error-10.mm: New.

2010-10-05  Nicola Pero  

PR objc++/23707
* obj-c++.dg/syntax-error-9.mm: New.

2010-10-05  Nicola Pero  

PR objc++/31126
* obj-c++.dg/syntax-error-8.mm: New.

2010-10-05  Nicola Pero  

Merge from 'apple/trunk' branch on FSF servers.

2005-10-17  Fariborz Jahanian 

Radar 4290840
* obj-c++.dg/syntax-error-7.mm: New

2005-10-14  Fariborz Jahanian 

Radar 4294425
* obj-c++.dg/syntax-error-6.mm: New

2005-10-13  Fariborz Jahanian 

Radar 4261146
* obj-c++.dg/syntax-error-5.mm: New

2005-08-15  Ziemowit Laski  

Radar 4093475
* obj-c++.dg/syntax-error-[3-4].mm: New.

2005-08-02  Ziemowit Laski  

Radar 4185810
* obj-c++.dg/syntax-error-[1-2].mm: New.

Added:
trunk/gcc/testsuite/obj-c++.dg/syntax-error-1.mm
trunk/gcc/testsuite/obj-c++.dg/syntax-error-10.mm
trunk/gcc/testsuite/obj-c++.dg/syntax-error-2.mm
trunk/gcc/testsuite/obj-c++.dg/syntax-error-3.mm
trunk/gcc/testsuite/obj-c++.dg/syntax-error-4.mm
trunk/gcc/testsuite/obj-c++.dg/syntax-error-5.mm
trunk/gcc/testsuite/obj-c++.dg/syntax-error-6.mm
trunk/gcc/testsuite/obj-c++.dg/syntax-error-7.mm
trunk/gcc/testsuite/obj-c++.dg/syntax-error-8.mm
trunk/gcc/testsuite/obj-c++.dg/syntax-error-9.mm
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-parser.c
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c
trunk/gcc/objc/ChangeLog
trunk/gcc/objc/objc-act.c
trunk/gcc/testsuite/ChangeLog

[Bug objc++/23707] ICE on invalid code after error

[nicola at gcc dot gnu.org]

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

--- Comment #2 from Nicola Pero  2010-10-05 19:23:39 
UTC ---
Author: nicola
Date: Tue Oct  5 19:23:33 2010
New Revision: 164997

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=164997
Log:
In gcc/:
2010-10-05  Nicola Pero  

* c-parser.c (c_parser_objc_method_definition): Updated comment.

In gcc/cp/:
2010-10-05  Nicola Pero  

PR objc++/31125
* parser.c (cp_parser_objc_class_interface): If no identifier
follows an @interface token, stop parsing the interface after
printing an error.
(cp_parser_objc_class_implementation): If no identifier follows an
@implementation token, stop parsing the implementation after
printing an error.

2010-10-05  Nicola Pero  

PR objc++/23707
* parser.c (cp_parser_objc_method_keyword_params): If the required
colon is not found while parsing parameters, stop parsing them.

2010-10-05  Nicola Pero  

PR objc++/31126
* parser.c (cp_parser_objc_class_ivars): Do not eat the EOF or
@end after detecting it.  Print an error if @end is found without
a '}'.
(cp_parser_objc_method_prototype_list): Do not eat the EOF after
detecting it.  Fixed reading the next token when continuing
because of an error in a method signature.  Print an error if EOF
is found without an '@end'.
(cp_parser_objc_method_definition_list): Same change.

2010-10-05  Nicola Pero  

Merge from apple/trunk branch on FSF servers:

2005-10-17  Fariborz Jahanian 

Radar 4290840
* parser.c (cp_parser_objc_method_keyword_params): Check for valid
method parameters and issue error.
(cp_parser_objc_method_definition_list): Check for invalid tokens
which cannot start a function definition.

2005-10-14  Fariborz Jahanian 

Radar 4294425
* parser.c (cp_parser_objc_message_args): Check for missing message
arguments and syntax error.

2005-10-13  Fariborz Jahanian 

Radar 4261146
* parser.c (cp_parser_objc_class_ivars): Check for @end/eof while
looking for '}'.

2005-08-15  Ziemowit Laski  

Radar 4093475
* parser.c (cp_parser_objc_interstitial_code): Catch stray
'{' and '}' tokens and issue appropriate errors.

2005-08-02  Ziemowit Laski  

Radar 4185810
(cp_parser_statement_seq_opt): In addition to '}' and
end-of-file, a statement sequence may also be terminated
by a stray '@end'.

In gcc/objc/:
2010-10-05  Nicola Pero  

Merge from 'apple/trunk' branch on FSF servers.

2005-10-17  Fariborz Jahanian 

Radar 4290840
* objc-act.c (objc_start_method_definition): Check for error_mark_node
for
the selector name and make a quick exit.

In gcc/testsuite/:
2010-10-05  Nicola Pero  

PR objc++/28050
* obj-c++.dg/syntax-error-10.mm: New.

2010-10-05  Nicola Pero  

PR objc++/23707
* obj-c++.dg/syntax-error-9.mm: New.

2010-10-05  Nicola Pero  

PR objc++/31126
* obj-c++.dg/syntax-error-8.mm: New.

2010-10-05  Nicola Pero  

Merge from 'apple/trunk' branch on FSF servers.

2005-10-17  Fariborz Jahanian 

Radar 4290840
* obj-c++.dg/syntax-error-7.mm: New

2005-10-14  Fariborz Jahanian 

Radar 4294425
* obj-c++.dg/syntax-error-6.mm: New

2005-10-13  Fariborz Jahanian 

Radar 4261146
* obj-c++.dg/syntax-error-5.mm: New

2005-08-15  Ziemowit Laski  

Radar 4093475
* obj-c++.dg/syntax-error-[3-4].mm: New.

2005-08-02  Ziemowit Laski  

Radar 4185810
* obj-c++.dg/syntax-error-[1-2].mm: New.

Added:
trunk/gcc/testsuite/obj-c++.dg/syntax-error-1.mm
trunk/gcc/testsuite/obj-c++.dg/syntax-error-10.mm
trunk/gcc/testsuite/obj-c++.dg/syntax-error-2.mm
trunk/gcc/testsuite/obj-c++.dg/syntax-error-3.mm
trunk/gcc/testsuite/obj-c++.dg/syntax-error-4.mm
trunk/gcc/testsuite/obj-c++.dg/syntax-error-5.mm
trunk/gcc/testsuite/obj-c++.dg/syntax-error-6.mm
trunk/gcc/testsuite/obj-c++.dg/syntax-error-7.mm
trunk/gcc/testsuite/obj-c++.dg/syntax-error-8.mm
trunk/gcc/testsuite/obj-c++.dg/syntax-error-9.mm
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-parser.c
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c
trunk/gcc/objc/ChangeLog
trunk/gcc/objc/objc-act.c
trunk/gcc/testsuite/ChangeLog

[Bug objc++/31125] ICE on @interface without identifier

[nicola at gcc dot gnu.org]

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

Nicola Pero  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #3 from Nicola Pero  2010-10-05 19:26:52 
UTC ---
Fixed in trunk.

Thanks

[Bug objc++/28050] ICE on invalid initializer

[nicola at gcc dot gnu.org]

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

Nicola Pero  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #16 from Nicola Pero  2010-10-05 
19:25:32 UTC ---
Fixed in trunk.

Thanks

[Bug other/32998] -frecord-gcc-switches issues

[roland at redhat dot com]

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

--- Comment #12 from Roland McGrath  2010-10-05 
19:24:56 UTC ---
Preprocessing stuff is probably best left to the -g3 info instead.  cc1*
options make sense for DW_AT_producer.

[Bug objc++/28050] ICE on invalid initializer

[nicola at gcc dot gnu.org]

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

--- Comment #15 from Nicola Pero  2010-10-05 
19:23:40 UTC ---
Author: nicola
Date: Tue Oct  5 19:23:33 2010
New Revision: 164997

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=164997
Log:
In gcc/:
2010-10-05  Nicola Pero  

* c-parser.c (c_parser_objc_method_definition): Updated comment.

In gcc/cp/:
2010-10-05  Nicola Pero  

PR objc++/31125
* parser.c (cp_parser_objc_class_interface): If no identifier
follows an @interface token, stop parsing the interface after
printing an error.
(cp_parser_objc_class_implementation): If no identifier follows an
@implementation token, stop parsing the implementation after
printing an error.

2010-10-05  Nicola Pero  

PR objc++/23707
* parser.c (cp_parser_objc_method_keyword_params): If the required
colon is not found while parsing parameters, stop parsing them.

2010-10-05  Nicola Pero  

PR objc++/31126
* parser.c (cp_parser_objc_class_ivars): Do not eat the EOF or
@end after detecting it.  Print an error if @end is found without
a '}'.
(cp_parser_objc_method_prototype_list): Do not eat the EOF after
detecting it.  Fixed reading the next token when continuing
because of an error in a method signature.  Print an error if EOF
is found without an '@end'.
(cp_parser_objc_method_definition_list): Same change.

2010-10-05  Nicola Pero  

Merge from apple/trunk branch on FSF servers:

2005-10-17  Fariborz Jahanian 

Radar 4290840
* parser.c (cp_parser_objc_method_keyword_params): Check for valid
method parameters and issue error.
(cp_parser_objc_method_definition_list): Check for invalid tokens
which cannot start a function definition.

2005-10-14  Fariborz Jahanian 

Radar 4294425
* parser.c (cp_parser_objc_message_args): Check for missing message
arguments and syntax error.

2005-10-13  Fariborz Jahanian 

Radar 4261146
* parser.c (cp_parser_objc_class_ivars): Check for @end/eof while
looking for '}'.

2005-08-15  Ziemowit Laski  

Radar 4093475
* parser.c (cp_parser_objc_interstitial_code): Catch stray
'{' and '}' tokens and issue appropriate errors.

2005-08-02  Ziemowit Laski  

Radar 4185810
(cp_parser_statement_seq_opt): In addition to '}' and
end-of-file, a statement sequence may also be terminated
by a stray '@end'.

In gcc/objc/:
2010-10-05  Nicola Pero  

Merge from 'apple/trunk' branch on FSF servers.

2005-10-17  Fariborz Jahanian 

Radar 4290840
* objc-act.c (objc_start_method_definition): Check for error_mark_node
for
the selector name and make a quick exit.

In gcc/testsuite/:
2010-10-05  Nicola Pero  

PR objc++/28050
* obj-c++.dg/syntax-error-10.mm: New.

2010-10-05  Nicola Pero  

PR objc++/23707
* obj-c++.dg/syntax-error-9.mm: New.

2010-10-05  Nicola Pero  

PR objc++/31126
* obj-c++.dg/syntax-error-8.mm: New.

2010-10-05  Nicola Pero  

Merge from 'apple/trunk' branch on FSF servers.

2005-10-17  Fariborz Jahanian 

Radar 4290840
* obj-c++.dg/syntax-error-7.mm: New

2005-10-14  Fariborz Jahanian 

Radar 4294425
* obj-c++.dg/syntax-error-6.mm: New

2005-10-13  Fariborz Jahanian 

Radar 4261146
* obj-c++.dg/syntax-error-5.mm: New

2005-08-15  Ziemowit Laski  

Radar 4093475
* obj-c++.dg/syntax-error-[3-4].mm: New.

2005-08-02  Ziemowit Laski  

Radar 4185810
* obj-c++.dg/syntax-error-[1-2].mm: New.

Added:
trunk/gcc/testsuite/obj-c++.dg/syntax-error-1.mm
trunk/gcc/testsuite/obj-c++.dg/syntax-error-10.mm
trunk/gcc/testsuite/obj-c++.dg/syntax-error-2.mm
trunk/gcc/testsuite/obj-c++.dg/syntax-error-3.mm
trunk/gcc/testsuite/obj-c++.dg/syntax-error-4.mm
trunk/gcc/testsuite/obj-c++.dg/syntax-error-5.mm
trunk/gcc/testsuite/obj-c++.dg/syntax-error-6.mm
trunk/gcc/testsuite/obj-c++.dg/syntax-error-7.mm
trunk/gcc/testsuite/obj-c++.dg/syntax-error-8.mm
trunk/gcc/testsuite/obj-c++.dg/syntax-error-9.mm
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-parser.c
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c
trunk/gcc/objc/ChangeLog
trunk/gcc/objc/objc-act.c
trunk/gcc/testsuite/ChangeLog

[Bug objc++/31125] ICE on @interface without identifier

[nicola at gcc dot gnu.org]

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

--- Comment #2 from Nicola Pero  2010-10-05 19:23:38 
UTC ---
Author: nicola
Date: Tue Oct  5 19:23:33 2010
New Revision: 164997

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=164997
Log:
In gcc/:
2010-10-05  Nicola Pero  

* c-parser.c (c_parser_objc_method_definition): Updated comment.

In gcc/cp/:
2010-10-05  Nicola Pero  

PR objc++/31125
* parser.c (cp_parser_objc_class_interface): If no identifier
follows an @interface token, stop parsing the interface after
printing an error.
(cp_parser_objc_class_implementation): If no identifier follows an
@implementation token, stop parsing the implementation after
printing an error.

2010-10-05  Nicola Pero  

PR objc++/23707
* parser.c (cp_parser_objc_method_keyword_params): If the required
colon is not found while parsing parameters, stop parsing them.

2010-10-05  Nicola Pero  

PR objc++/31126
* parser.c (cp_parser_objc_class_ivars): Do not eat the EOF or
@end after detecting it.  Print an error if @end is found without
a '}'.
(cp_parser_objc_method_prototype_list): Do not eat the EOF after
detecting it.  Fixed reading the next token when continuing
because of an error in a method signature.  Print an error if EOF
is found without an '@end'.
(cp_parser_objc_method_definition_list): Same change.

2010-10-05  Nicola Pero  

Merge from apple/trunk branch on FSF servers:

2005-10-17  Fariborz Jahanian 

Radar 4290840
* parser.c (cp_parser_objc_method_keyword_params): Check for valid
method parameters and issue error.
(cp_parser_objc_method_definition_list): Check for invalid tokens
which cannot start a function definition.

2005-10-14  Fariborz Jahanian 

Radar 4294425
* parser.c (cp_parser_objc_message_args): Check for missing message
arguments and syntax error.

2005-10-13  Fariborz Jahanian 

Radar 4261146
* parser.c (cp_parser_objc_class_ivars): Check for @end/eof while
looking for '}'.

2005-08-15  Ziemowit Laski  

Radar 4093475
* parser.c (cp_parser_objc_interstitial_code): Catch stray
'{' and '}' tokens and issue appropriate errors.

2005-08-02  Ziemowit Laski  

Radar 4185810
(cp_parser_statement_seq_opt): In addition to '}' and
end-of-file, a statement sequence may also be terminated
by a stray '@end'.

In gcc/objc/:
2010-10-05  Nicola Pero  

Merge from 'apple/trunk' branch on FSF servers.

2005-10-17  Fariborz Jahanian 

Radar 4290840
* objc-act.c (objc_start_method_definition): Check for error_mark_node
for
the selector name and make a quick exit.

In gcc/testsuite/:
2010-10-05  Nicola Pero  

PR objc++/28050
* obj-c++.dg/syntax-error-10.mm: New.

2010-10-05  Nicola Pero  

PR objc++/23707
* obj-c++.dg/syntax-error-9.mm: New.

2010-10-05  Nicola Pero  

PR objc++/31126
* obj-c++.dg/syntax-error-8.mm: New.

2010-10-05  Nicola Pero  

Merge from 'apple/trunk' branch on FSF servers.

2005-10-17  Fariborz Jahanian 

Radar 4290840
* obj-c++.dg/syntax-error-7.mm: New

2005-10-14  Fariborz Jahanian 

Radar 4294425
* obj-c++.dg/syntax-error-6.mm: New

2005-10-13  Fariborz Jahanian 

Radar 4261146
* obj-c++.dg/syntax-error-5.mm: New

2005-08-15  Ziemowit Laski  

Radar 4093475
* obj-c++.dg/syntax-error-[3-4].mm: New.

2005-08-02  Ziemowit Laski  

Radar 4185810
* obj-c++.dg/syntax-error-[1-2].mm: New.

Added:
trunk/gcc/testsuite/obj-c++.dg/syntax-error-1.mm
trunk/gcc/testsuite/obj-c++.dg/syntax-error-10.mm
trunk/gcc/testsuite/obj-c++.dg/syntax-error-2.mm
trunk/gcc/testsuite/obj-c++.dg/syntax-error-3.mm
trunk/gcc/testsuite/obj-c++.dg/syntax-error-4.mm
trunk/gcc/testsuite/obj-c++.dg/syntax-error-5.mm
trunk/gcc/testsuite/obj-c++.dg/syntax-error-6.mm
trunk/gcc/testsuite/obj-c++.dg/syntax-error-7.mm
trunk/gcc/testsuite/obj-c++.dg/syntax-error-8.mm
trunk/gcc/testsuite/obj-c++.dg/syntax-error-9.mm
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-parser.c
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c
trunk/gcc/objc/ChangeLog
trunk/gcc/objc/objc-act.c
trunk/gcc/testsuite/ChangeLog

[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 #27 from Hans-Peter Nilsson  2010-10-05 
18:59:00 UTC ---
(In reply to comment #26)
> looks like I have to amend
> the check_v3_target_fileio some more and fix another simulator bug.  Film at
> 11.

JFTR, the simulator part (the wrap function records errno for passing on to the
target):

--- sim/common/callback.c.origWed Jan 14 12:09:55 2009
+++ sim/common/callback.cTue Oct  5 20:56:21 2010
@@ -278,7 +278,7 @@ os_lseek (p, fd, off, way)
   result = fdbad (p, fd);
   if (result)
 return result;
-  result = lseek (fdmap (p, fd), off, way);
+  result = wrap (p, lseek (fdmap (p, fd), off, way));
   return result;
 }

[Bug middle-end/323] optimized code gives strange floating point results

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu.org

--- Comment #140 from Andrew Pinski  2010-10-05 
18:45:34 UTC ---
*** Bug 45899 has been marked as a duplicate of this bug. ***

[Bug middle-end/45899] New: testing

[pinskia at gcc dot gnu.org]

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

   Summary: testing
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: pins...@gcc.gnu.org


Testing email

[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 #26 from Hans-Peter Nilsson  2010-10-05 
18:45:52 UTC ---
(In reply to comment #24)
> Did I follow the wrong process for deleting the file?

No, the commit was fine, it's the "svn diff" that fails.

(In reply to comment #25)
> A putback at the beginning will attempt a backwards seek, though, which is
> exactly what you're looking at fixing.

But... again, this is with the *fixed* simulator.
Whatever: I had a look and the difference is:

(unfixed simulator)
open("filebuf_virtuals-1.txt", O_RDONLY|O_NONBLOCK) = 4
lseek(4, 4294967295, SEEK_CUR)  = 4294967295
read(4, "", 1023)   = 0
close(4)= 0
(return with 0)

(fixed simulator)
open("filebuf_virtuals-1.txt", O_RDONLY|O_NONBLOCK) = 4
lseek(4, -1, SEEK_CUR)  = -1 EINVAL (Invalid argument)
read(4, "// 990117 bkoz\n// test functiona"..., 1023) = 1023
close(4)= 0
write(2, "assertion \"", 11assertion ")= 11
(failed assertion)

On a host (using gcc-4.4.3 and library), I don't get to the "read":
open("filebuf_virtuals-1.txt", O_RDONLY) = 3
lseek(3, -1, SEEK_CUR)  = -1 EINVAL (Invalid argument)
close(3)= 0

So, it's (error/EOF) file state state that's lost; looks like I have to amend
the check_v3_target_fileio some more and fix another simulator bug.  Film at
11.

[Bug middle-end/45899] testing

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE

--- Comment #1 from Andrew Pinski  2010-10-05 
18:45:34 UTC ---
Just doing it for a test.

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

[Bug target/27682] float to int conversion doesn't raise invalid exception

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||geoffk at gcc dot gnu.org

--- Comment #11 from Andrew Pinski  2010-10-05 
18:30:07 UTC ---
*** Bug 30580 has been marked as a duplicate of this bug. ***

[Bug c/30580] GCC doesn't set floating-point exceptions when performing fp<->int conversions

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE

--- Comment #7 from Andrew Pinski  2010-10-05 
18:30:07 UTC ---
Yes I agree this is a dup of bug 27682.

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

[Bug c/30580] GCC doesn't set floating-point exceptions when performing fp<->int conversions

[tydeman at tybor dot com]

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

Fred J. Tydeman  changed:

   What|Removed |Added

 CC||tydeman at tybor dot com

--- Comment #6 from Fred J. Tydeman  2010-10-05 
18:28:05 UTC ---
I believe that this is a dup of bug 27682.
It still is failing in 4.5.1 on Intel Pentium 4 under Linux.

[Bug libstdc++/45896] [C++0x] Facet time_get not reading dates according to the IEEE 1003 standard.

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW
 CC||paolo.carlini at oracle dot
   ||com
  Component|c++ |libstdc++

--- Comment #4 from Paolo Carlini  2010-10-05 
18:24:44 UTC ---
Actually, adding this sort of flexibility then hits
http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#461. Better
dealing with this as part of a more general review of time_get for C++0x.

[Bug bootstrap/45888] tm.texi generation is not portable, rule is broken

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.10.05 18:19:43
 CC||fxcoudert at gcc dot
   ||gnu.org
 Ever Confirmed|0   |1

[Bug middle-end/45838] [4.6 Regression] FAIL: libgomp.c/pr34513.c execution test

[dave at hiauly1 dot hia.nrc.ca]

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

--- Comment #5 from dave at hiauly1 dot hia.nrc.ca 2010-10-05 18:14:57 UTC ---
> Untested patch.  Several of the GOMP_* builtins are certainly not leaf.

I did a quick test.  Unfortunately, libgomp.c/pr34513.c still fails.

[Bug middle-end/40893] ARM and PPC truncate intermediate operations unnecessarily

[paul at pwsan dot com]

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

paul walmsley  changed:

   What|Removed |Added

 CC||paul at pwsan dot com

--- Comment #2 from paul walmsley  2010-10-05 18:14:35 
UTC ---
Here's a minimal test case:

void foo(unsigned int v)
{
  *(volatile unsigned short *)0xabcdefab = (v);
}

arm-linux-gcc  -O2 -march=armv7-a -c test.c; arm-linux-objdump -DS test.o 
| less


 :
   0:   e30e3fffmovwr3, #61439  ; 0xefff
   4:   e34a3bcdmovtr3, #43981  ; 0xabcd
   8:   e6ff0070uxthr0, r0
   c:   e14305b4strhr0, [r3, #-84]
  10:   e12fff1ebx  lr


As David notes, the expected behavior is that the uxth should not be generated
for >= armv6 targets, and the two shifts should not be generated on < armv6
targets, as they should be superfluous.

http://marc.info/?l=linux-omap&m=128630215909798&w=2

[Bug c++/45897] ZNC. make

[risech at pochta dot ru]

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

--- Comment #2 from buddhabrot  2010-10-05 18:01:24 
UTC ---
buddhabrot# gcc -v
Using built-in specs.
Target: amd64-undermydesk-freebsd
Configured with: FreeBSD/amd64 system compiler
Thread model: posix
gcc version 4.2.1 20070719  [FreeBSD]
buddhabrot#

[Bug c++/45896] [C++0x] Facet time_get not reading dates according to the IEEE 1003 standard.

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2010.10.05 17:57:04
 Ever Confirmed|0   |1

--- Comment #3 from Paolo Carlini  2010-10-05 
17:57:04 UTC ---
Can fix pretty quickly.

[Bug c++/45897] ZNC. make

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  2010-10-05 
17:30:30 UTC ---
>  c++: Internal error: Killed: 9 (program cc1plus)

This almost always means cc1plus ran out of memory.

Can you provide the output of "gcc -v"?

[Bug c++/45897] New: ZNC. make

[risech at pochta dot ru]

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

   Summary: ZNC. make
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ris...@pochta.ru


1.
  buddhabrot# make install clean
   2.
  ===>  Building for znc-0.094
   3.
  Building znc.o...
   4.
  Csocket.h: In member function 'void
TSocketManager::Select(std::map::EMessages,
std::less, std::allocator::EMessages>
> >&) [with T = CZNCSock]':
   5.
  Csocket.h:1487:   instantiated from 'void TSocketManager::Loop() [with
T = CZNCSock]'
   6.
  Csocket.h:1621:   instantiated from 'void
TSocketManager::DynamicSelectLoop(u_long, u_long, time_t) [with T =
CZNCSock]'
   7.
  znc.cpp:252:   instantiated from here
   8.
  Csocket.h:2010: warning: comparison between signed and unsigned integer
expressions
   9.
  Csocket.h:2010: warning: comparison between signed and unsigned integer
expressions
  10.
  {standard input}: Assembler messages:
  11.
  {standard input}:30267: Warning: end of file not at end of a line;
newline inserted
  12.
  c++: Internal error: Killed: 9 (program cc1plus)
  13.
  Please submit a full bug report.
  14.
  See http://gcc.gnu.org/bugs.html> for instructions.
  15.
  gmake: *** [znc.o] Error 1
  16.
  *** Error code 1
  17.

  18.
  Stop in /usr/ports/irc/znc.
  19.
  *** Error code 1
  20.

  21.
  Stop in /usr/ports/irc/znc.
  22.
  buddhabrot#

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

[potswa at mac dot com]

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

--- Comment #25 from David Krauss  2010-10-05 17:26:18 
UTC ---
> The required sequence is a write up to EOF followed by a read. 9425 is a
> putback at the beginning of the file, which is neither.

A putback at the beginning will attempt a backwards seek, though, which is
exactly what you're looking at fixing.

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

[potswa at mac dot com]

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

--- Comment #24 from David Krauss  2010-10-05 17:24:22 
UTC ---
(In reply to comment #22)
> Just a heads-up regarding issue #3.
> 
> (In reply to comment #19)
> > Apparently
> > reading after a write at EOF is not in the tests.
> 
> Hm, doesn't
> 27_io/basic_filebuf/sputbackc/char/9425.cc
> test something like that, or at leas EOF after?  It doesn't fail for you?

The required sequence is a write up to EOF followed by a read. 9425 is a
putback at the beginning of the file, which is neither.

> It does for me (cris-axis-elf), seen as a regression with a fixed simulator.
> Or maybe that's not the reason?  Ok, I'll look closer.
> 
> FWIW, due to 
> I also saw 27_io/basic_filebuf/sync/wchar_t/1.cc (a file removed in r164529) 
> as
> regressing, which had me confused until I STFW and found that svn up to 1.7.0
> (version according to the bug report, but I can confirm it includes 1.6.9) did
> not include (files in) deleted directories in diffs, like "svn diff -c164529".
> Note that sync/char/1.cc is included.

Did I follow the wrong process for deleting the file? Hmm, I'm using svn 1.6.5.
The reason it was removed was that it verified the very behavior the patch was
designed to eliminate. And no way to adapt it to do something useful. We will,
presumably, re-add that directory with some other kind of test though.

> Looks like lots of libstdc++ file I/O test-cases are missing "// {
> dg-require-fileio "" }" lines.  I'll add them as obvious.

Good to know, thanks!

[Bug objc++/31125] ICE on @interface without identifier

[nicola at gcc dot gnu.org]

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

Nicola Pero  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.10.05 17:10:11
 CC||nicola at gcc dot gnu.org
 AssignedTo|unassigned at gcc dot   |nicola at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

--- Comment #1 from Nicola Pero  2010-10-05 17:10:11 
UTC ---
I have a patch waiting for approval which fixes this.

Thanks

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

[paolo.carlini at oracle dot com]

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

--- Comment #23 from Paolo Carlini  2010-10-05 
17:06:27 UTC ---
(In reply to comment #22)
> Hm, doesn't
> 27_io/basic_filebuf/sputbackc/char/9425.cc
> test something like that, or at leas EOF after?  It doesn't fail for you?

Just have a look to testresults: clean testsuite at least for x86_64-linux,
both -m32 and -m64. I understand Darwin too.

[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 #22 from Hans-Peter Nilsson  2010-10-05 
17:03:09 UTC ---
Just a heads-up regarding issue #3.

(In reply to comment #19)
> Apparently
> reading after a write at EOF is not in the tests.

Hm, doesn't
27_io/basic_filebuf/sputbackc/char/9425.cc
test something like that, or at leas EOF after?  It doesn't fail for you?

It does for me (cris-axis-elf), seen as a regression with a fixed simulator.
Or maybe that's not the reason?  Ok, I'll look closer.

FWIW, due to 
I also saw 27_io/basic_filebuf/sync/wchar_t/1.cc (a file removed in r164529) as
regressing, which had me confused until I STFW and found that svn up to 1.7.0
(version according to the bug report, but I can confirm it includes 1.6.9) did
not include (files in) deleted directories in diffs, like "svn diff -c164529".
Note that sync/char/1.cc is included.

Looks like lots of libstdc++ file I/O test-cases are missing "// {
dg-require-fileio "" }" lines.  I'll add them as obvious.

[Bug objc++/28050] ICE on invalid initializer

[nicola at gcc dot gnu.org]

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

Nicola Pero  changed:

   What|Removed |Added

 CC||nicola at gcc dot gnu.org
 AssignedTo|unassigned at gcc dot   |nicola at gcc dot gnu.org
   |gnu.org |
  Known to fail||

--- Comment #14 from Nicola Pero  2010-10-05 
16:48:47 UTC ---
ObjC is already fixed; I have a patch (pending approval) that fixes this for
ObjC++ as well.

Thanks

[Bug c++/45896] [C++0x] Facet time_get not reading dates according to the IEEE 1003 standard.

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

   Priority|P3  |P4
Summary|Facet time_get not reading  |[C++0x] Facet time_get not
   |dates according to the  |reading dates according to
   |standard.   |the IEEE 1003 standard.
   Severity|normal  |enhancement

--- Comment #2 from Paolo Carlini  2010-10-05 
16:46:41 UTC ---
I suppose you are referring to the sentences "leading zeros shall be permitted
but shall not be required", right? Because they do *not* exist in the C(99) ISO
Standard, which is the normative reference for C++98, in this area. In general,
ISO 8601, in turn, is pretty strict about those formats.

Only C++0x references explicitly "the ISO/IEC 9945 function strptime" (ISO/IEC
9945 is the same as IEEE 1003), which is more flexible about leading zeros.
Thus, C++0x work, in due course...

[Bug fortran/45889] Regression with I/O of element of allocatable array in derived type

[krefson at googlemail dot com]

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

--- Comment #7 from Keith Refson  2010-10-05 
16:19:50 UTC ---
Steve - thanks for the workaround (In fact I had already discovered this).

Jerry: As Steve pointed out explicitly, the statement that fails to
compile is simply printing a character expression, and NOT attempting
to do anything like derived type I/O.  It is correct F95+TR15581.

The allocatable or other attributes of the variable ought to be utterly
irrelevant. It would be pretty wierd (and a considerable feat of code analysis)
if the allocation status - a run-time property - were able to generate a
compile-time error.

[Bug c++/45896] New: Facet time_get not reading dates according to the standard.

[alexander.rojas at gmail dot com]

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

   Summary: Facet time_get not reading dates according to the
standard.
   Product: gcc
   Version: 4.4.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: alexander.ro...@gmail.com


I just create a simple program to exchange dates formats based in locales.
According to the standard (
http://www.opengroup.org/onlinepubs/9699919799/functions/strptime.html ) a date
like 2/2/2005 would be a valid date. However the program fails with that input.
It requires 02/02/2005 to work.

The compiler options where set to:
g++ -v -save-temps -odate date.cpp

the program compiles without errors or warnings.

This is the dump of my system information:


Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.4.3-4ubuntu5'
--with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--enable-multiarch --enable-linker-build-id --with-system-zlib
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.4 --program-suffix=-4.4 --enable-nls
--enable-clocale=gnu --enable-libstdcxx-debug --enable-plugin --enable-objc-gc
--disable-werror --with-arch-32=i486 --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-odate' '-shared-libgcc'
'-mtune=generic'
 /usr/lib/gcc/x86_64-linux-gnu/4.4.3/cc1plus -E -quiet -v -D_GNU_SOURCE
date.cpp -D_FORTIFY_SOURCE=2 -mtune=generic -fpch-preprocess -fstack-protector
-o date.ii
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-linux-gnu/4.4.3/../../../../x86_64-linux-gnu/include"
ignoring nonexistent directory "/usr/include/x86_64-linux-gnu"
#include "..." search starts here:
#include <...> search starts here:
 /usr/include/c++/4.4
 /usr/include/c++/4.4/x86_64-linux-gnu
 /usr/include/c++/4.4/backward
 /usr/local/include
 /usr/lib/gcc/x86_64-linux-gnu/4.4.3/include
 /usr/lib/gcc/x86_64-linux-gnu/4.4.3/include-fixed
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-odate' '-shared-libgcc'
'-mtune=generic'
 /usr/lib/gcc/x86_64-linux-gnu/4.4.3/cc1plus -fpreprocessed date.ii -quiet
-dumpbase date.cpp -mtune=generic -auxbase date -version -fstack-protector -o
date.s
GNU C++ (Ubuntu 4.4.3-4ubuntu5) version 4.4.3 (x86_64-linux-gnu)
compiled by GNU C version 4.4.3, GMP version 4.3.2, MPFR version
2.4.2-p1.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++ (Ubuntu 4.4.3-4ubuntu5) version 4.4.3 (x86_64-linux-gnu)
compiled by GNU C version 4.4.3, GMP version 4.3.2, MPFR version
2.4.2-p1.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 88858f45841827736473e527a4e9ab10
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-odate' '-shared-libgcc'
'-mtune=generic'
 as -V -Qy -o date.o date.s
GNU assembler version 2.20.1 (x86_64-linux-gnu) using BFD version (GNU Binutils
for Ubuntu) 2.20.1-system.20100303
COMPILER_PATH=/usr/lib/gcc/x86_64-linux-gnu/4.4.3/:/usr/lib/gcc/x86_64-linux-gnu/4.4.3/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/4.4.3/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/4.4.3/:/usr/lib/gcc/x86_64-linux-gnu/
LIBRARY_PATH=/usr/lib/gcc/x86_64-linux-gnu/4.4.3/:/usr/lib/gcc/x86_64-linux-gnu/4.4.3/:/usr/lib/gcc/x86_64-linux-gnu/4.4.3/../../../../lib/:/lib/../lib/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-linux-gnu/4.4.3/../../../:/lib/:/usr/lib/:/usr/lib/x86_64-linux-gnu/
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-odate' '-shared-libgcc'
'-mtune=generic'
 /usr/lib/gcc/x86_64-linux-gnu/4.4.3/collect2 --build-id --eh-frame-hdr -m
elf_x86_64 --hash-style=both -dynamic-linker /lib64/ld-linux-x86-64.so.2 -odate
-z relro /usr/lib/gcc/x86_64-linux-gnu/4.4.3/../../../../lib/crt1.o
/usr/lib/gcc/x86_64-linux-gnu/4.4.3/../../../../lib/crti.o
/usr/lib/gcc/x86_64-linux-gnu/4.4.3/crtbegin.o
-L/usr/lib/gcc/x86_64-linux-gnu/4.4.3 -L/usr/lib/gcc/x86_64-linux-gnu/4.4.3
-L/usr/lib/gcc/x86_64-linux-gnu/4.4.3/../../../../lib -L/lib/../lib
-L/usr/lib/../lib -L/usr/lib/gcc/x86_64-linux-gnu/4.4.3/../../..
-L/usr/lib/x86_64-linux-gnu date.o -lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc
/usr/lib/gcc/x86_64-linux-gnu/4.4.3/crtend.o
/usr/lib/gcc/x86_64-linux-gnu/4.4.3/../../../../lib/crtn.o

[Bug fortran/45889] Regression with I/O of element of allocatable array in derived type

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #6 from kargl at gcc dot gnu.org 2010-10-05 15:33:02 UTC ---
If you remove the parentheses then code compiles.
That is, change 


do i = 1, current_cell%num_species
   write(*,*) (current_cell%species_symbol(i))
end do

to

do i = 1, current_cell%num_species
   write(*,*) current_cell%species_symbol(i)
end do

You can also change the expression (yes, it is an expression
in your transfer) to

do i = 1, current_cell%num_species
   write(*,*) (current_cell%species_symbol(i)//'')
end do

if you are dead set on using the superfluous parenthesis.

[Bug libfortran/45165] unix.c:fallback_access() leaks file descriptors

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

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

[Bug middle-end/45838] [4.6 Regression] FAIL: libgomp.c/pr34513.c execution test

[dave at hiauly1 dot hia.nrc.ca]

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

--- Comment #4 from dave at hiauly1 dot hia.nrc.ca 2010-10-05 15:19:09 UTC ---
> Untested patch.  Several of the GOMP_* builtins are certainly not leaf.

Another issue may be that the sync builtins on hppa-unknown-linux-gnu are
implemented in a library.  This is also the case for some arm targets.
There are no sync builtins on hppa-hpux.

Will try patch.

[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 #7 from Mikael Pettersson  2010-10-05 
14:35:37 UTC ---
(In reply to comment #6)
> Thanks for the testcase.
>   http://gcc.gnu.org/ml/gcc-patches/2010-10/msg00059.html
> seems to help with the testcase.  Does it also fix bootstrap?

Yes it unbreaks bootstrap.

[Bug fortran/45889] Regression with I/O of element of allocatable array in derived type

[jvdelisle at gcc dot gnu.org]

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

--- Comment #5 from Jerry DeLisle  2010-10-05 
14:28:55 UTC ---
Looks like we are being too conservative on this check.  If we can give an
error if unallocated but not give an error if allocated, then it would be
better.

[Bug fortran/45889] Regression with I/O of element of allocatable array in derived type

[krefson at googlemail dot com]

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

--- Comment #4 from Keith Refson  2010-10-05 
13:51:09 UTC ---
(In reply to comment #3)
> In the test case, does the SAVE automatically allocate?  Where does the 
> derived
> type get allocated ?.  If it has not been allocated and set to some value the
> component must be undefined.

The allocation was lost in stripping down to a minimal test case,
which is intended only to demonstrate the compile-time diagnostic.
It is not intended to link or run.

[Bug fortran/45889] Regression with I/O of element of allocatable array in derived type

[jvdelisle at gcc dot gnu.org]

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

--- Comment #3 from Jerry DeLisle  2010-10-05 
13:44:02 UTC ---
In the test case, does the SAVE automatically allocate?  Where does the derived
type get allocated ?.  If it has not been allocated and set to some value the
component must be undefined.

??

[Bug c++/45894] [4.5/4.6 Regression] [C++0x] ICE: segmentation fault with -Wall

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords|error-recovery, |
   |ice-on-invalid-code |

--- Comment #2 from Jonathan Wakely  2010-10-05 
13:41:38 UTC ---
Good point, I'm not sure this is invalid, thanks Paolo.
I got confused by the fact it's rejected in 4.4, but I guess the change from an
error to a warning is probably intentional.  I've removed the keywords.

[Bug target/45847] ICE in supportable_widening_operation

[belagod at gcc dot gnu.org]

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

belagod at gcc dot gnu.org changed:

   What|Removed |Added

 CC||belagod at gcc dot gnu.org

--- Comment #1 from belagod at gcc dot gnu.org 2010-10-05 13:36:16 UTC ---
(In reply to comment #0)
> 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)

I've just posted a patch that fixes this. See
http://gcc.gnu.org/ml/gcc-patches/2010-10/msg00323.html

[Bug fortran/45889] Regression with I/O of element of allocatable array in derived type

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot
   ||gnu.org

--- Comment #2 from Jerry DeLisle  2010-10-05 
13:34:21 UTC ---
this is in resolve.c. We will have to check the standard on this.

  if (ts->type == BT_DERIVED)
{
  /* Check that transferred derived type doesn't contain POINTER
 components.  */
  if (ts->u.derived->attr.pointer_comp)
{
  gfc_error ("Data transfer element at %L cannot have "
 "POINTER components", &code->loc);
  return;
}

  if (ts->u.derived->attr.alloc_comp)
{
  gfc_error ("Data transfer element at %L cannot have "
 "ALLOCATABLE components", &code->loc);
  return;
}

  if (derived_inaccessible (ts->u.derived))
{
  gfc_error ("Data transfer element at %L cannot have "
 "PRIVATE components",&code->loc);
  return;
}
}

[Bug c++/45894] [4.5/4.6 Regression] [C++0x] ICE: segmentation fault with -Wall

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||paolo.carlini at oracle dot
   ||com

--- Comment #1 from Paolo Carlini  2010-10-05 
13:33:51 UTC ---
What about the no -Wall case? Is it also an accepts invalid?

[Bug middle-end/45838] [4.6 Regression] FAIL: libgomp.c/pr34513.c execution test

[danglin at gcc dot gnu.org]

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

John David Anglin  changed:

   What|Removed |Added

  Component|libgomp |middle-end

--- Comment #2 from John David Anglin  2010-10-05 
13:29:02 UTC ---
Introduced in revision 164689.

2010-09-28  Jan Hubicka  

* builtin-attrs.def (ATTR_LEAF): New attribute.
(ATTR_NOVOPS_LEAF_LIST, ATTR_LEAF_LIST, ATTR_NOTHROW_LEAF_LIST,
ATTR_CONST_NOTHROW_LEAF_LIST, ATTR_PURE_NOTHROW_LEAF_LIST,
ATTR_PURE_NOTHROW_NOVOPS_LEAF_LIST, ATTR_NORETURN_NOTHROW_LEAF_LIST,
ATTR_MALLOC_NOTHROW_LEAF_LIST, ATTR_SENTINEL_NOTHROW_LEAF_LIST,
ATTR_NOTHROW_NONNULL_LEAF, ATTR_CONST_NOTHROW_NONNULL_LEAF,
ATTR_CONST_NOTHROW_TYPEGENERIC_LEAF, ATTR_PURE_NOTHROW_NONNULL_LEAF,
ATTR_MALLOC_NOTHROW_NONNULL_LEAF): New attribute lists.
* sync-builtins.def: Annotate all builtins by leaf.
* omp-builtins.def: Annotate all builtins by leaf.
* builtins.def: Annotate relevant builtins with leaf attribute.
(ATTR_MATHFN_ERRNO, ATTR_MATHFN_FPROUNDING,
ATTR_MATHFN_FPROUNDING_ERRNO, ATTR_MATHFN_FPROUNDING_STORE): Make
leaf.

[Bug objc/45895] -Wunused-but-set-variable complains for almost all Objective-C objects

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  2010-10-05 
13:27:34 UTC ---
That means some mark_exp_read calls need to be added, supposedly in objc-act.c,
on the right spots.  I'm not familiar enough with ObjC to know where exactly,
please CC me on any fixes you write though.

[Bug libstdc++/45893] [C++0x] [DR 817] Finish updating std::bind to rvalue refs

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

Summary|[C++0x] Finish updating |[C++0x] [DR 817] Finish
   |std::bind to rvalue refs|updating std::bind to
   ||rvalue refs

--- Comment #2 from Paolo Carlini  2010-10-05 
13:27:18 UTC ---
I see. By the way, when std::bind is fixed, it should become possible to remove
the thread::thread(_Callable) constructor (alternately, we should not use there
std::bind as an implementation detail).

[Bug c++/45894] [4.5/4.6 Regression] [C++0x] ICE: segmentation fault with -Wall

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||error-recovery,
   ||ice-on-invalid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.10.05 13:08:41
Summary|ICE: segmentation fault |[4.5/4.6 Regression]
   |with -Wall  |[C++0x] ICE: segmentation
   ||fault with -Wall
 Ever Confirmed|0   |1

[Bug objc++/31126] Infinite loop on missing @end

[nicola at gcc dot gnu.org]

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

Nicola Pero  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.10.05 12:54:20
 CC||nicola at gcc dot gnu.org
 AssignedTo|unassigned at gcc dot   |nicola at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

[Bug objc/45895] New: -Wunused-but-set-variable complains for almost all Objective-C objects

[nicola at gcc dot gnu.org]

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

   Summary: -Wunused-but-set-variable complains for almost all
Objective-C objects
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: objc
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: nic...@gcc.gnu.org


It seems that -Wunused-but-set-variable complains any time an Objective-C
object variable is set, and only used to invoke methods.  This is incorrect;
when a variable is used to invoke a method, it is used. :-)

(hence, compiling any Objective-C with -Wall generates lots of wrong warnings).

Here is a testcase --

#include 
#include 

int main (void)
{
  id o = nil;

  [o hash];

  return 0;
}

Here are what happens when you compile:

[nic...@lampone ~]$ gcc -Wall bug.m -lobjc -c
bug.m: In function ‘main’:
bug.m:6:6: warning: variable ‘o’ set but not used [-Wunused-but-set-variable]
[nic...@lampone ~]$ 

The warning is obviously incorrect because 'o' *is* used.  This is on a
i686-pc-linux-gnu.

Thanks

[Bug c++/45894] New: ICE: segmentation fault with -Wall

[gcc at abeckmann dot de]

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

   Summary: ICE: segmentation fault with -Wall
   Product: gcc
   Version: 4.5.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: g...@abeckmann.de


I get an "internal compiler error: Segmentation fault" when compiling this code
with 4.5.2/4.6.0 and -Wall. The problem disappears if I remove -Wall.
4.4.5 and 4.3.x report "error: statement cannot resolve address of overloaded
function"

== 8< ===
struct FOO
{
template < typename = void >
void Bar () ;
} ;
template < typename = void >
struct V
{
V ( const V &)
{
FOO :: Bar < > ;
}
} ;
struct C
{
V < > v ;
} ;
struct B
{
C f () ;
} ;
struct A
{
C c ;
B b ;
A () : c ( b . f () )
{ }
} ;
== >8 ===

$ g++-4.5.x -v -std=c++0x -Wall -c segfault-ice.min.cpp
Using built-in specs.
COLLECT_GCC=/opt/software/x86_64/gcc-4.5.x/bin/g++-4.5.x
COLLECT_LTO_WRAPPER=/opt/software/x86_64/gcc-4.5.x/libexec/gcc/x86_64-unknown-linux-gnu/4.5.2/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4_5-branch/configure
--prefix=/opt/software/x86_64/gcc-4.5.x --program-suffix=-4.5.x
--enable-languages=c,c++ --enable-checking
Thread model: posix
gcc version 4.5.2 20101004 (prerelease) (GCC)
COLLECT_GCC_OPTIONS='-v' '-std=c++0x' '-Wall' '-c' '-shared-libgcc'
'-mtune=generic' '-march=x86-64'

/opt/software/x86_64/gcc-4.5.x/libexec/gcc/x86_64-unknown-linux-gnu/4.5.2/cc1plus
-quiet -v -D_GNU_SOURCE segfault-ice.min.cpp -quiet -dumpbase
segfault-ice.min.cpp -mtune=generic -march=x86-64 -auxbase segfault-ice.min
-Wall -std=c++0x -version -o /tmp/cco6qHiQ.s
GNU C++ (GCC) version 4.5.2 20101004 (prerelease) (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.5.2 20101004 (prerelease), GMP version
4.3.2, MPFR version 3.0.0-p3, MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
ignoring nonexistent directory
"/opt/software/x86_64/gcc-4.5.x/lib/gcc/x86_64-unknown-linux-gnu/4.5.2/../../../../x86_64-unknown-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:

/opt/software/x86_64/gcc-4.5.x/lib/gcc/x86_64-unknown-linux-gnu/4.5.2/../../../../include/c++/4.5.2

/opt/software/x86_64/gcc-4.5.x/lib/gcc/x86_64-unknown-linux-gnu/4.5.2/../../../../include/c++/4.5.2/x86_64-unknown-linux-gnu

/opt/software/x86_64/gcc-4.5.x/lib/gcc/x86_64-unknown-linux-gnu/4.5.2/../../../../include/c++/4.5.2/backward
 /usr/local/include
 /opt/software/x86_64/gcc-4.5.x/include
 /opt/software/x86_64/gcc-4.5.x/lib/gcc/x86_64-unknown-linux-gnu/4.5.2/include

/opt/software/x86_64/gcc-4.5.x/lib/gcc/x86_64-unknown-linux-gnu/4.5.2/include-fixed
 /usr/include
End of search list.
GNU C++ (GCC) version 4.5.2 20101004 (prerelease) (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.5.2 20101004 (prerelease), GMP version
4.3.2, MPFR version 3.0.0-p3, MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 8c3e00fe3cfb9293e6e3b31a6f7f6d80
segfault-ice.min.cpp: In copy constructor ‘V< 
>::V(const V<  >&)’:
segfault-ice.min.cpp:11:18: warning: statement is a reference, not call, to
function ‘FOO::Bar [with  = void]’
segfault-ice.min.cpp: In copy constructor ‘V< 
>::V(const V<  >&) [with  =
void, V<  > = V<>]’:
segfault-ice.min.cpp:15:1:   instantiated from here
segfault-ice.min.cpp:11:3: internal compiler error: Segmentation fault
Please submit a full bug report,