[Bug ada/49084] [4.7 regression] bootstrap failure with Ada enabled

[ktietz at gcc dot gnu.org]

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

Kai Tietz  changed:

   What|Removed |Added

 CC||ktietz at gcc dot gnu.org

--- Comment #7 from Kai Tietz  2011-11-13 06:00:35 
UTC ---
Hmm, this is due usage of "%lld" in printf-formatter.  Does following patch fix
your issue?

Index: implicit-zee.c
===
--- implicit-zee.c  (revision 180840)
+++ implicit-zee.c  (working copy)
@@ -944,10 +944,12 @@
   VEC_free (rtx, heap, zeinsn_del_list);

   if (dump_file && num_ze_opportunities > 0)
-fprintf (dump_file, "\n %s : num_zee_opportunities = %lld "
-"num_realized = %lld \n",
+fprintf (dump_file, "\n %s : num_zee_opportunities = "
+   HOST_WIDEST_INT_PRINT_DEC
+" num_realized = "HOST_WIDEST_INT_PRINT_DEC "\n",
 current_function_name (),
-num_ze_opportunities, num_realized);
+(HOST_WIDEST_INT) num_ze_opportunities,
+(HOST_WIDEST_INT) num_realized);

   df_finish_pass (false);
   return 0;

[Bug c++/50372] [C++0x] pointers to static functions should be valid template parameters

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||jason at gcc dot gnu.org
 Resolution||FIXED
   Target Milestone|--- |4.7.0

--- Comment #2 from Jason Merrill  2011-11-13 
05:54:16 UTC ---
Fixed for 4.7.

[Bug middle-end/51116] [4.7 Regression] configure: error: cannot compute suffix of object files: cannot compile

[jimis at gmx dot net]

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

jimis  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #4 from jimis  2011-11-13 05:27:54 UTC ---
Does the following simple patch solve it? This undoes an optimisation, and
there is an ongoing discussion about it so I expect it soon to be resolved one
way on another: http://gcc.gnu.org/ml/gcc-patches/2011-11/msg01602.html

I'm curious though: in pa64-hpux.h I can see that this part is in the
GAS-specific part. Why are we emmiting HP-style labels?

apinski, any pointers to that email about mips?


=== modified file 'gcc/config/elfos.h'
--- gcc/config/elfos.h2011-10-30 01:45:46 +
+++ gcc/config/elfos.h2011-11-12 02:51:39 +
@@ -125,9 +125,6 @@ see the files COPYING3 and COPYING.RUNTI
 }\
   while (0)

-#undef TARGET_ASM_INTERNAL_LABEL
-#define TARGET_ASM_INTERNAL_LABEL default_elf_internal_label
-
 /* Output the label which precedes a jumptable.  Note that for all svr4
systems where we actually generate jumptables (which is to say every
svr4 target except i386, where we use casesi instead) we put the jump-

[Bug c++/986] g++ misses warning for reference on temporary that invokes undefined behaviour

[jason at gcc dot gnu.org]

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

--- Comment #32 from Jason Merrill  2011-11-13 
05:09:43 UTC ---
Author: jason
Date: Sun Nov 13 05:09:36 2011
New Revision: 181334

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=181334
Log:
PR c++/986
* call.c (set_up_extended_ref_temp): Warn about references
bound to non-static reference members.
* init.c (perform_member_init): Pass in the member.

Added:
trunk/gcc/testsuite/g++.dg/warn/ref-temp1.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c
trunk/gcc/cp/init.c
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/51116] [4.7 Regression] configure: error: cannot compute suffix of object files: cannot compile

[pinskia at gmail dot com]

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

--- Comment #3 from pinskia at gmail dot com  
2011-11-13 04:32:06 UTC ---
According to another email mips is broken the same way.



Sent from my Palm Pre on AT&T
On Nov 12, 2011 20:18, danglin at gcc dot gnu.org
 wrote: 

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



 Bug #: 51116

   Summary: [4.7 Regression] configure: error: cannot compute

suffix of object files: cannot compile

Classification: Unclassified

   Product: gcc

   Version: 4.7.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: middle-end

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: dang...@gcc.gnu.org

  Host: hppa64-hp-hpux11.11

Target: hppa64-hp-hpux11.11

 Build: hppa64-hp-hpux11.11





In stage1,



checking for hppa64-hp-hpux11.11-gcc... /test/gnu/gcc/objdir/./gcc/xgcc

-B/test/gnu/gcc/objdir/./gcc/ -B/opt/gnu64/gcc/gcc-4.7/hppa64-hp-hpux11.11/bin/

-B/opt/gnu64/gcc/gcc-4.7/hppa64-hp-hpux11.11/lib/ -isystem

/opt/gnu64/gcc/gcc-4.7/hppa64-hp-hpux11.11/include -isystem

/opt/gnu64/gcc/gcc-4.7/hppa64-hp-hpux11.11/sys-include   

checking for suffix of object files... configure: error: in

`/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libgcc':

configure: error: cannot compute suffix of object files: cannot compile

See `config.log' for more details.



In config.log,



configure:3650: /test/gnu/gcc/objdir/./gcc/xgcc -B/test/gnu/gcc/objdir/./gcc/

-B

/opt/gnu64/gcc/gcc-4.7/hppa64-hp-hpux11.11/bin/

-B/opt/gnu64/gcc/gcc-4.7/hppa64-

hp-hpux11.11/lib/ -isystem /opt/gnu64/gcc/gcc-4.7/hppa64-hp-hpux11.11/include

-i

system /opt/gnu64/gcc/gcc-4.7/hppa64-hp-hpux11.11/sys-include-c -g -O2

conf

test.c >&5

/var/tmp//ccjq1spX.s: Assembler messages:

/var/tmp//ccjq1spX.s:44: Error: can't resolve `.text.startup' {.text.startup

sec

tion} - `L$FB' {*UND* section}

/var/tmp//ccjq1spX.s:148: Error: can't resolve `.text.startup' {.text.startup

se

ction} - `L$FB' {*UND* section}

configure:3654: $? = 1

configure: failed program was:

| /* confdefs.h */

| #define PACKAGE_NAME "GNU C Runtime Library"

| #define PACKAGE_TARNAME "libgcc"

| #define PACKAGE_VERSION "1.0"

| #define PACKAGE_STRING "GNU C Runtime Library 1.0"

| #define PACKAGE_BUGREPORT ""

| #define PACKAGE_URL "http://www.gnu.org/software/libgcc/";

| /* end confdefs.h.  */

| 

| int

| main ()

| 

|   ;

|   return 0;

| }

[Bug middle-end/51116] [4.7 Regression] configure: error: cannot compute suffix of object files: cannot compile

[danglin at gcc dot gnu.org]

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

--- Comment #2 from John David Anglin  2011-11-13 
04:22:16 UTC ---
Created attachment 25812
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25812
Assembler file

[Bug middle-end/51116] [4.7 Regression] configure: error: cannot compute suffix of object files: cannot compile

[danglin at gcc dot gnu.org]

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

--- Comment #1 from John David Anglin  2011-11-13 
04:19:34 UTC ---
Forgot to say, this was introduced in revision 181279.

-bash-3.2$ ./xgcc -B./ -v
Reading specs from ./specs
COLLECT_GCC=./xgcc
COLLECT_LTO_WRAPPER=./lto-wrapper
Target: hppa64-hp-hpux11.11
Configured with: ../gcc/configure --with-gnu-as --with-as=/opt/gnu64/bin/as
--with-ld=/usr/ccs/bin/ld --enable-shared --with-local-prefix=/opt/gnu64
--prefix=/opt/gnu64/gcc/gcc-4.7 --build=hppa64-hp-hpux11.11
--enable-threads=posix --disable-nls --with-gmp=/opt/gnu64/gcc/gmp
--with-libelf=/opt/gnu64 --enable-languages=c,c++,objc,obj-c++,fortran
Thread model: posix
gcc version 4.7.0 2011 (experimental) [trunk revision 181279] (GCC)

[Bug middle-end/51116] New: [4.7 Regression] configure: error: cannot compute suffix of object files: cannot compile

[danglin at gcc dot gnu.org]

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

 Bug #: 51116
   Summary: [4.7 Regression] configure: error: cannot compute
suffix of object files: cannot compile
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dang...@gcc.gnu.org
  Host: hppa64-hp-hpux11.11
Target: hppa64-hp-hpux11.11
 Build: hppa64-hp-hpux11.11


In stage1,

checking for hppa64-hp-hpux11.11-gcc... /test/gnu/gcc/objdir/./gcc/xgcc
-B/test/gnu/gcc/objdir/./gcc/ -B/opt/gnu64/gcc/gcc-4.7/hppa64-hp-hpux11.11/bin/
-B/opt/gnu64/gcc/gcc-4.7/hppa64-hp-hpux11.11/lib/ -isystem
/opt/gnu64/gcc/gcc-4.7/hppa64-hp-hpux11.11/include -isystem
/opt/gnu64/gcc/gcc-4.7/hppa64-hp-hpux11.11/sys-include   
checking for suffix of object files... configure: error: in
`/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libgcc':
configure: error: cannot compute suffix of object files: cannot compile
See `config.log' for more details.

In config.log,

configure:3650: /test/gnu/gcc/objdir/./gcc/xgcc -B/test/gnu/gcc/objdir/./gcc/
-B
/opt/gnu64/gcc/gcc-4.7/hppa64-hp-hpux11.11/bin/
-B/opt/gnu64/gcc/gcc-4.7/hppa64-
hp-hpux11.11/lib/ -isystem /opt/gnu64/gcc/gcc-4.7/hppa64-hp-hpux11.11/include
-i
system /opt/gnu64/gcc/gcc-4.7/hppa64-hp-hpux11.11/sys-include-c -g -O2 
conf
test.c >&5
/var/tmp//ccjq1spX.s: Assembler messages:
/var/tmp//ccjq1spX.s:44: Error: can't resolve `.text.startup' {.text.startup
sec
tion} - `L$FB' {*UND* section}
/var/tmp//ccjq1spX.s:148: Error: can't resolve `.text.startup' {.text.startup
se
ction} - `L$FB' {*UND* section}
configure:3654: $? = 1
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "GNU C Runtime Library"
| #define PACKAGE_TARNAME "libgcc"
| #define PACKAGE_VERSION "1.0"
| #define PACKAGE_STRING "GNU C Runtime Library 1.0"
| #define PACKAGE_BUGREPORT ""
| #define PACKAGE_URL "http://www.gnu.org/software/libgcc/";
| /* end confdefs.h.  */
| 
| int
| main ()
| 
|   ;
|   return 0;
| }

[Bug other/19563] Makefiles don't handle configure --program-suffix

[gerald at pfeifer dot com]

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

Gerald Pfeifer  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||gerald at pfeifer dot com
 Resolution||WORKSFORME

--- Comment #3 from Gerald Pfeifer  2011-11-13 
02:09:06 UTC ---
Hmm, this has been working for me just fine (except for Ada) for the last
couple of years, in the context of that very usecase: installing several
instances of GCC into the same prefix.

Let's track the Ada issue in PR #51095 specifically, for apart from that
It Seems To Work[TM] for tens of thousands of users of FreeBSD who use my
ports, for example.  Please advise if I missed something!

[Bug ada/51095] "make install" with --program-suffix does not install the bin/gnat* binaries with that suffix

[gerald at pfeifer dot com]

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

Gerald Pfeifer  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011-11-13
 CC||gerald at pfeifer dot com,
   ||rguenth at gcc dot gnu.org
 Ever Confirmed|0   |1

--- Comment #2 from Gerald Pfeifer  2011-11-13 
02:06:29 UTC ---
Richi, in PR 864 you shared the patch you use for the SUSE flavors of GCC;
now one of our users on the FreeBSD side ran into the very same issue.

Instead of just addressing this locally at a distro level, any chance I
could talk you into submitting that patch for inclusion in GCC HEAD?

[Bug c++/51115] New: "-Wstrict-prototypes" is rejected for C++ (ok) but accepted for Ada (meaningless)

[Keith.S.Thompson at gmail dot com]

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

 Bug #: 51115
   Summary: "-Wstrict-prototypes" is rejected for C++ (ok) but
accepted for Ada (meaningless)
Classification: Unclassified
   Product: gcc
   Version: 4.5.2
Status: UNCONFIRMED
  Severity: trivial
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: keith.s.thomp...@gmail.com


Created attachment 25811
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25811
Demo script

When the "-Wstrict-prototypes" option is used when compiling C++, the following
warning appears:

cc1plus: warning: command line option "-Wstrict-prototypes" is valid for
Ada/C/ObjC but not for C++

The warning option doesn't make sense for C++, since the language doesn't
permit old-style non-prototype function declarations, but it makes even less
sense for Ada.  Further experiment shows that the option is quietly accepted
when compiling Ada.

Suggested solution:

1. Make the Ada front end complain about "-Wstrict-prototypes" (unless there's
a general policy of having it quietly accept options that don't make sense).

2. Drop "Ada/" from the cc1plus warning message.

The attached sh script demonstrates the problem.  The output on my system is:


% gcc --version
gcc (Ubuntu/Linaro 4.5.2-8ubuntu4) 4.5.2
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

% gnatmake --version
GNATMAKE 4.4.5
Copyright (C) 1995-2008, Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.

% uname -a
Linux kvetch 2.6.38-12-generic #51-Ubuntu SMP Wed Sep 28 14:25:20 UTC 2011 i686
i686 i386 GNU/Linux

=== C ===
% gcc -c -Wstrict-prototypes foo.c

=== C++ ===
% g++ -c -Wstrict-prototypes foo.cpp
cc1plus: warning: command line option "-Wstrict-prototypes" is valid for
Ada/C/ObjC but not for C++
% gcc -c -Wstrict-prototypes foo.cpp
cc1plus: warning: command line option "-Wstrict-prototypes" is valid for
Ada/C/ObjC but not for C++

=== Objective-C
% gcc -c -Wstrict-prototypes foo.m

=== Ada ===
% gnatmake foo.adb -cargs -Wstrict-prototypes
gcc-4.4 -c -Wstrict-prototypes foo.adb
gnatbind -x foo.ali
gnatlink foo.ali

[Bug c++/51060] Temporary object stack space is not re-used

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.7.0

--- Comment #4 from Jason Merrill  2011-11-13 
00:47:26 UTC ---
Indeed, pretty simple now that we have that infrastructure.

[Bug c++/51060] Temporary object stack space is not re-used

[jason at gcc dot gnu.org]

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

--- Comment #3 from Jason Merrill  2011-11-13 
00:44:43 UTC ---
Author: jason
Date: Sun Nov 13 00:44:39 2011
New Revision: 181332

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=181332
Log:
PR c++/51060
* gimplify.c (gimplify_target_expr): Add a clobber to the cleanup.
(gimplify_modify_expr): Don't try to simplify it.
* cp/cp-gimplify.c (cp_gimplify_expr): Leave clobbers alone.

Added:
trunk/gcc/testsuite/g++.dg/opt/stack2.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-gimplify.c
trunk/gcc/gimplify.c
trunk/gcc/testsuite/ChangeLog
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/testsuite/25_algorithms/max/1.cc
trunk/libstdc++-v3/testsuite/25_algorithms/min/1.cc
trunk/libstdc++-v3/testsuite/25_algorithms/minmax/1.cc

[Bug fortran/51103] configure: error: GNU Fortran is not working

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

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

--- Comment #14 from Francois-Xavier Coudert  
2011-11-12 23:55:29 UTC ---
So, you get twice a segfault running the compiler:

configure:15421: /Users/rlewis/src/gcc-4.6.2/build/./gcc/gfortran
-B/Users/rlewis/src/gcc-4.6.2/build/./gcc/
-B/usr/local/x86_64-apple-darwin11.2.0/bin/
-B/usr/local/x86_64-apple-darwin11.2.0/lib/ -isystem
/usr/local/x86_64-apple-darwin11.2.0/include -isystem
/usr/local/x86_64-apple-darwin11.2.0/sys-include-c -g -O2  conftest.f >&5
f951: internal compiler error: Segmentation fault: 11
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
configure:15421: $? = 1
configure: failed program was:
| 
|   program foo
|   real, parameter :: bar = sin (12.34 / 2.5)
|   end program foo
configure:15425: result: no


Now, can you try to run this:

/Users/rlewis/src/gcc-4.6.2/build/gcc/f951 -quiet test.f

where test.f contains:

   program foo
   real, parameter :: bar = sin (12.34 / 2.5)
   end program foo

If it segfaults, please run it again inside gdb and try to get us a backtrace.

[Bug rtl-optimization/51051] [4.7 Regression]: build fails on cris-elf building libstdc++-v3

[hp at gcc dot gnu.org]

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

Hans-Peter Nilsson  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011-11-12
 Ever Confirmed|0   |1

[Bug ada/51114] New: Got compiler error when creating a private subtype

[frederic.praca at free dot fr]

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

 Bug #: 51114
   Summary: Got compiler error when creating a private subtype
Classification: Unclassified
   Product: gcc
   Version: 4.4.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: frederic.pr...@free.fr


Created attachment 25810
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25810
The source files which can trigger the bug

When creating a private subtype through a function caused a compiler error.
Output was :
gnatmake -Wall -Wextra gnat_bug.adb 
gcc-4.4 -c -Wall -Wextra gnat_bug.adb
+===GNAT BUG DETECTED==+
| 4.4.3 (i486-pc-linux-gnu) GCC error: |
| in gnat_to_gnu_entity, at ada/gcc-interface/decl.c:545   |
| Error detected at gnat_bug.adb:9:30  |
| Please submit a bug report; see http://gcc.gnu.org/bugs.html.|
| Use a subject line meaningful to you and us to track the bug.|
| Include the entire contents of this bug box in the report.   |
| Include the exact gcc-4.4 or gnatmake command that you entered.  |
| Also include sources listed below in gnatchop format |
| (concatenated together with no headers between files).   |
+==+

Please include these source files with error report
Note that list may not be accurate in some cases,
so please double check that the problem can still
be reproduced with the set of files listed.

gnat_bug.adb
chords.ads
namedstructures.ads
notes.ads
intervals.ads

gnat_bug.adb:9:04: warning: "Failling_Chord" is not modified, could be declared
constant
compilation abandoned
gnatmake: "gnat_bug.adb" compilation error

Appeared also on FreeBSD on a 4.6.1 version with the following message:
gnatmake -Wall -Wextra gnat_bug.adb
gnatgcc -c -Wall -Wextra gnat_bug.adb
+===GNAT BUG DETECTED==+
| 4.6.1 20110627 (release) -=> GNAT AUX [FreeBSD] (i386-aux-freebsd8.2) GCC
error:|
| in gnat_to_gnu_entity, at ada/gcc-interface/decl.c:599   |
| Error detected at gnat_bug.adb:9:30  |
| Please submit a bug report; see http://gcc.gnu.org/bugs.html.|
| Use a subject line meaningful to you and us to track the bug.|
| Include the entire contents of this bug box in the report.   |
| Include the exact gcc or gnatmake command that you entered.  |
| Also include sources listed below in gnatchop format |
| (concatenated together with no headers between files).   |
+==+

Please include these source files with error report
Note that list may not be accurate in some cases,
so please double check that the problem can still
be reproduced with the set of files listed.
Consider also -gnatd.n switch (see debug.adb).

gnat_bug.adb
chords.ads
namedstructures.ads
notes.ads
intervals.ads

gnat_bug.adb:9:04: warning: "Failling_Chord" is not modified, could be declared
constant
compilation abandoned
gnatmake: "gnat_bug.adb" compilation error

[Bug gcov-profile/51113] New: [4.7 regression] rev. 181105 causes Firefox profiledbuild failure

[markus at trippelsdorf dot de]

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

 Bug #: 51113
   Summary: [4.7 regression] rev. 181105 causes Firefox
profiledbuild failure
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: gcov-profile
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mar...@trippelsdorf.de


Firefox fails to build during the -fprofile-generate phase 
of a "profiledbuild":

c++ -o js  -fno-rtti -pedantic -Wall -Wpointer-arith -Woverloaded-virtual
-Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wcast-align -W
no-invalid-offsetof -Wno-variadic-macros -Werror=return-type -Wno-long-long
-march=native -fvisibility-inlines-hidden -Wno-delete-non-virtual-dtor -p
thread -pipe  -DNDEBUG -DTRIMMED -fprofile-generate -O3 -fomit-frame-pointer
js.i_o jsworkers.i_o jsoptparse.i_o jsheaptools.i_o   -lpthread -Wl,-O1,
--hash-style=gnu,--as-needed,--no-keep-memory,--gc-sections  -fprofile-generate
-Wl,-rpath-link,../../../dist/bin -Wl,-rpath-link,/var/tmp/mozilla-ce
ntral/moz-build-dir/dist/lib   -Wl,--whole-archive
../../../dist/lib/libmozutils.a -Wl,--no-whole-archive -rdynamic
-L../../../dist/bin -L../../../di
st/lib -Wl,-R/usr/lib64 -L/usr/lib64 -lplds4 -lplc4 -lnspr4 -lpthread -ldl
../editline/libeditline.a ../libjs_static.a -ldl
jsoptparse.i_o:jsoptparse.cpp:function vtable for
js::cli::detail::StringOption: warning: relocation refers to discarded section
/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.0/../../../../x86_64-pc-linux-gnu/bin/ld:
error: hidden symbol '_ZN2js3cli6detail12StringOptionD1Ev' is not defi
ned locally
jsoptparse.i_o:jsoptparse.cpp:function vtable for
js::cli::detail::StringOption: warning: relocation refers to discarded section
/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.0/../../../../x86_64-pc-linux-gnu/bin/ld:
error: hidden symbol '_ZN2js3cli6detail12StringOptionD0Ev' is not defi
ned locally
jsoptparse.i_o:jsoptparse.cpp:function vtable for
js::cli::detail::StringOption: warning: relocation refers to discarded section
/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.0/../../../../x86_64-pc-linux-gnu/bin/ld:
error: hidden symbol '_ZNK2js3cli6detail12ValuedOption8isValuedEv' is 
not defined locally
jsoptparse.i_o:jsoptparse.cpp:function vtable for js::cli::detail::IntOption:
warning: relocation refers to discarded section
/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.0/../../../../x86_64-pc-linux-gnu/bin/ld:
error: hidden symbol '_ZN2js3cli6detail9IntOptionD1Ev' is not defined 
locally
jsoptparse.i_o:jsoptparse.cpp:function vtable for js::cli::detail::IntOption:
warning: relocation refers to discarded section
/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.0/../../../../x86_64-pc-linux-gnu/bin/ld:
error: hidden symbol '_ZN2js3cli6detail9IntOptionD0Ev' is not defined 
locally
jsoptparse.i_o:jsoptparse.cpp:function vtable for js::cli::detail::IntOption:
warning: relocation refers to discarded section
/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.0/../../../../x86_64-pc-linux-gnu/bin/ld:
error: hidden symbol '_ZNK2js3cli6detail12ValuedOption8isValuedEv' is 
not defined locally
jsoptparse.i_o:jsoptparse.cpp:function vtable for
js::cli::detail::MultiStringOption: warning: relocation refers to discarded
section
/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.0/../../../../x86_64-pc-linux-gnu/bin/ld:
error: hidden symbol '_ZN2js3cli6detail17MultiStringOptionD1Ev' is not
 defined locally
jsoptparse.i_o:jsoptparse.cpp:function vtable for
js::cli::detail::MultiStringOption: warning: relocation refers to discarded
section
/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.0/../../../../x86_64-pc-linux-gnu/bin/ld:
error: hidden symbol '_ZN2js3cli6detail17MultiStringOptionD0Ev' is not
 defined locally
jsoptparse.i_o:jsoptparse.cpp:function vtable for
js::cli::detail::MultiStringOption: warning: relocation refers to discarded
section
/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.0/../../../../x86_64-pc-linux-gnu/bin/ld:
error: hidden symbol '_ZNK2js3cli6detail12ValuedOption8isValuedEv' is 
not defined locally
...

I've git bisected this to the following commit:
5014df5d02d9d90bb0a749a035f86bbfbe94bfa4 is the first bad commit
commit 5014df5d02d9d90bb0a749a035f86bbfbe94bfa4
Author: nathan 
Date:   Mon Nov 7 18:14:46 2011 +

libgcc/
* libgcov.c (struct gcov_fn_buffer): New struct.
(buffer_fn_data): New helper.
(gcov_exit): Rework for new gcov data structures.

gcc/
* gcov.c (object_summary): Replace with ...
(object_runs): ... this.
(process_file): Remove functions with no data.
(generate_results): Ignore files with no lines.
(release_function): New helper, broken out of ...
(release_structures): ... here.  Use it.
(read_count_file): Adjust for new data file format.
(output_lines): Use object_runs.
* gcov-io.h (GCOV_TAG_OBJECT_SUMMARY): Obsolete.
(struct gcov_ctr_info): Move definition.
(st

[Bug bootstrap/51112] New: [4.7 Regression] LTO bootstrap failed with bootstrap-profiled

[hjl.tools at gmail dot com]

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

 Bug #: 51112
   Summary: [4.7 Regression] LTO bootstrap failed with
bootstrap-profiled
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com


On Linux/x86-64, revision 181327 failed to profiledbootstrap
with LTO enabled:

../../src-trunk/gcc/tree-vect-stmts.c: In function
'vectorizable_condition(gimple_statement_d*, gimple_stmt_iterator*,
gimple_statement_d**, tree_node*, int, _slp_tree*)':
../../src-trunk/gcc/tree-vect-stmts.c:5060:59: error: 'comp_vectype' may be
used uninitialized in this function [-Werror=maybe-uninitialized]

[Bug fortran/38312] Unexpected STATEMENT FUNCTION statement

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #6 from Steve Kargl  
2011-11-12 22:41:06 UTC ---
On Sat, Nov 12, 2011 at 10:03:49PM +, kargl at gcc dot gnu.org wrote:
> 
> --- Comment #5 from kargl at gcc dot gnu.org 2011-11-12 22:03:49 UTC ---
> I've looked at this issue, and I have come to the conclusion
> that it should be closed as WONTFIX.  First, an error is 
> issued, so one can fix their Fortran code.
> 
> Now, for the problem.  The matchers are called from the 
> parser according this diagram (parse.c line 1717).
> 
> +---+
> | program  subroutine  function  module |
> +---+
> |use|
> +---+
> |import |
> +---+
> | |implicit none|
> | +---+-+
> | | parameter |  implicit   |
> | +---+-+
> | format  |   |  derived type   |
> | entry   | parameter |  interface  |
> | |   data|  specification  |
> | |   |  statement func |
> | +---+-+
> | |   data|executable   |
> +-+---+-+
> |contains   |
> +---+
> |  internal module/subprogram   |
> +---+
> |end|
> +---+
> 
> As one can see, a DATA statement and a statement function are
> parsed at the same level.  A programmer can use an implied
> do-loop within a DATA statement.  Unfortunately, an implied
> do-loop is parsed by the same code that parses a regular
> do-loop.  It appears that insufficient information is contained
> within the parser at the point where the error is issued
> to determine that the do-loop is in an executable portion of
> the program.
> 

I can generate

laptop:kargl[230] gfc4x -c foo.f90
foo.f90:6.19:

  co(i)=t1(i)*2
   1
Warning: Line at (1) parsed as a STATEMENT FUNCTION
foo.f90:6.8:

  co(i)=t1(i)*2
1
Error: Variable type is UNKNOWN in assignment at (1)

with this very ugly kludge.

Index: parse.c
===
--- parse.c(revision 181307)
+++ parse.c(working copy)
@@ -1723,30 +1723,30 @@ unexpected_statement (gfc_statement st)
valid before calling here, i.e., ENTRY statements are not allowed in
INTERFACE blocks.  The following diagram is taken from the standard:

-+---+
-| program  subroutine  function  module |
-+---+
-| use   |
-+---+
-| import|
-+---+
-||implicit none |
-|+---+--+
-|| parameter |  implicit|
-|+---+--+
-| format |   |  derived type|
-| entry  | parameter |  interface   |
-||   data|  specification   |
-||   |  statement func  |
-|+---+--+
-||   data|executable|
-++---+--+
-|contains   |
-+---+
-|  internal module/subprogram   |
-+---+
-|   end |
-+---+
++---+
+| program  subroutine  function  module |
++---+
+|use|
++---+
+|import |
++---+
+| |implicit none|
+| +---+-+
+| | parameter |  implicit   |
+| +---+-+
+| format  |   |  derived type   |
+| entry   | parameter |  interface  |
+| |   data|  specification  |
+| |   |  statement func |
+| +---+-+
+| |   data|executable   |
++-+---+-+
+|contains   |
++--

[Bug web/50642] onlinedocs formated text too small to read

[jg at jguk dot org]

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

--- Comment #6 from Jon Grant  2011-11-12 22:15:36 UTC ---
Could this be followed up with the proposed change implemented?

pre.smallexample { font-size:normal }

Thanks, Jon

[Bug fortran/38312] Unexpected STATEMENT FUNCTION statement

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #5 from kargl at gcc dot gnu.org 2011-11-12 22:03:49 UTC ---
I've looked at this issue, and I have come to the conclusion
that it should be closed as WONTFIX.  First, an error is 
issued, so one can fix their Fortran code.

Now, for the problem.  The matchers are called from the 
parser according this diagram (parse.c line 1717).

+---+
| program  subroutine  function  module |
+---+
|use|
+---+
|import |
+---+
| |implicit none|
| +---+-+
| | parameter |  implicit   |
| +---+-+
| format  |   |  derived type   |
| entry   | parameter |  interface  |
| |   data|  specification  |
| |   |  statement func |
| +---+-+
| |   data|executable   |
+-+---+-+
|contains   |
+---+
|  internal module/subprogram   |
+---+
|end|
+---+

As one can see, a DATA statement and a statement function are
parsed at the same level.  A programmer can use an implied
do-loop within a DATA statement.  Unfortunately, an implied
do-loop is parsed by the same code that parses a regular
do-loop.  It appears that insufficient information is contained
within the parser at the point where the error is issued
to determine that the do-loop is in an executable portion of
the program.

[Bug bootstrap/51094] [4.7 Regression] Bootstrap failure at revision 181279 on non-ELF targets

[jason at gcc dot gnu.org]

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

--- Comment #14 from Jason Merrill  2011-11-12 
21:44:17 UTC ---
As you can see, I applied the stpcpy patch and the change to define/use
STRING_ASM_OP.  I don't have a strong opinion about which way to go with the
macro renaming.

[Bug bootstrap/51094] [4.7 Regression] Bootstrap failure at revision 181279 on non-ELF targets

[jason at gcc dot gnu.org]

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

--- Comment #13 from Jason Merrill  2011-11-12 
21:40:10 UTC ---
Author: jason
Date: Sat Nov 12 21:40:07 2011
New Revision: 181327

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=181327
Log:
PR bootstrap/51094
* config/elfos.h (STRING_ASM_OP): Define.
* varasm.c (default_elf_asm_output_limited_string): Use it.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/elfos.h
trunk/gcc/varasm.c

[Bug bootstrap/51094] [4.7 Regression] Bootstrap failure at revision 181279 on non-ELF targets

[jason at gcc dot gnu.org]

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

--- Comment #12 from Jason Merrill  2011-11-12 
21:40:03 UTC ---
Author: jason
Date: Sat Nov 12 21:39:59 2011
New Revision: 181326

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=181326
Log:
PR bootstrap/51094
* gcc/configure.ac: Check for stpcpy declaration.
* system.h: Declare it if not.
* config.in, configure: Regenerate.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config.in
trunk/gcc/configure
trunk/gcc/configure.ac
trunk/gcc/system.h

[Bug c/51111] New: Optimization bug with array

[vova7890 at mail dot ru]

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

 Bug #: 5
   Summary: Optimization bug with array
Classification: Unclassified
   Product: gcc
   Version: 4.6.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: vova7...@mail.ru


Have array like void *__sys_switab_addres[65536];
this array containing pointers to functions.

 │.text:08FC main 
 │.text:08FC 
 │.text:08FC var_3C  = -0x3C  
 │.text:08FC  
 │.text:08FC STMFD   SP!, {R4,R5,LR}
 │.text:0900 LDR R4, =__sys_switab_addres
 │.text:0904 SUB SP, SP, #0x34
 │.text:0908 LDR R3, [R4]
 │.text:090C LDR R5, =_ZL7MAINCSM
 │.text:0910 LDR R3, [R3,#0x518]
 │.text:0914 BLX R3
 │.text:0918 LDR R3, [R4]   ;duplicate
 │.text:091C LDR R1, =aNatalarm  
 │.text:0920 LDR R3, [R3,#0x490]  
 │.text:0924 ADD R0, R5, #0x28
 │.text:0928 BLX R3 
 │.text:092C LDR R3, [R4]   ;duplicate
 │.text:0930 ADD R1, SP, #0x40+var_3C
 │.text:0934 MOV R2, #0
 │.text:0938 LDR R3, [R3,#0x41C]
 │.text:093C MOV R0, R5
 │.text:0940 BLX R3
 │.text:0944 LDR R3, [R4]   ;duplicate
 │.text:0948 LDR R3, [R3,#0x51C]
 │.text:094C BLX R3
 │.text:0950 MOV R0, #0
 │.text:0954 ADD SP, SP, #0x34
 │.text:0958 LDMFD   SP!, {R4,R5,PC}

can be smaller with construction like this:

LDR R4, =__sys_switab_addres
LDR R4, [R4]
...
LDR R3, [R4,#0x518]
...
LDR R3, [R4,#0x490]  
...
LDR R3, [R4,#0x490]   
...
LDR R3, [R4,#0x41C]
...
LDR R3, [R4,#0x51C]

[Bug c/51110] New: Intel pentium G9650 (core i5) identified as core i7

[a...@vanhout-narvaez.com]

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

 Bug #: 51110
   Summary: Intel pentium G9650 (core i5) identified as core i7
Classification: Unclassified
   Product: gcc
   Version: 4.6.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: a...@vanhout-narvaez.com


Pentium G9650 is identiefied as corei7 by march=native

For G9650 being corei5 see:
http://download.intel.com/design/processor/datashts/322910.pdf

For identification used the following lines:

uname -a
ouput:
Linux MYSERVERNAME 3.0.8 #1 SMP Wed Nov 9 12:13:59 CET 2011 x86_64 Intel(R)
Pentium(R) CPUG6950  @ 2.80GHz GenuineIntel GNU/Linux

_AND_

echo 'int main(){return 0;}' > test.c && gcc -v -Q -march=native -O2 test.c -o
test && rm test.c test

output:
.
GNU C (GCC) version 4.6.2 (x86_64-slackware-linux)
compiled by GNU C version 4.6.2, GMP version 5.0.1, MPFR version 3.0.1,
MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
options passed:  -v test.c -march=corei7 -mcx16 -msahf -mno-movbe -mno-aes
..


Regards,
Alex

[Bug c++/51107] [C++11] Accepts invalid literal operator with void argument list.

[jason at redhat dot com]

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

--- Comment #2 from Jason Merrill  2011-11-12 20:54:02 
UTC ---
On 11/12/2011 02:10 PM, 3dw4rd at verizon dot net wrote:
> But is there a test for when you're looking at a template specialization?

DECL_TEMPLATE_SPECIALIZATION (current_function_decl)

Jason

[Bug target/51109] New: bdver1 scheduler state machine too large

[andi-gcc at firstfloor dot org]

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

 Bug #: 51109
   Summary: bdver1 scheduler state machine too large
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: andi-...@firstfloor.org
CC: harsha.jaga...@amd.com, hubi...@gcc.gnu.org


I noticed that the i386 bdver1 scheduler generates some of the largest symbols
in the compiler, much larger than any of the other x86 scheduler state machines

% nm -t d --size-sort .../cc1 | c++filt | tail
...
00040480 r bdver1_int_min_issue_delay
...
00161920 r bdver1_int_transitions

Likely that means it's slow too.

Honza thought it was a bug, so I'm filling it for reference.

[Bug c++/51107] [C++11] Accepts invalid literal operator with void argument list.

[3dw4rd at verizon dot net]

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

--- Comment #1 from Ed Smith-Rowland <3dw4rd at verizon dot net> 2011-11-12 
19:10:38 UTC ---
As I was testing a patch that turned out to be totally bogus, it looked like
maybe processing_template_decl is false when processing a template
specialization.  Is this true?

In fact I know it's true.

I can't add a spurious (even literal-allowed) argument list because I'll get 
error: template-id ‘operator"" _foo<'1'>’ for ‘int operator"" _foo(long
double)’ does not match any template declaration
But is there a test for when you're looking at a template specialization?

Oh well.  it doesn't affect this bug.  Just curious.

[Bug c++/51108] New: g++ segfault

[rec-for-bugzilla at yandex dot ru]

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

 Bug #: 51108
   Summary: g++ segfault
Classification: Unclassified
   Product: gcc
   Version: 4.6.1
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rec-for-bugzi...@yandex.ru


I know, that this code snippet is very bizarre and strange...
But anyway, i think that compiler must show nice error message
instead of segfaulting.
If i comment out line with 'case 2:' then code compiles without
errors and warnings, that isn't good too.


= begin code =
int main(int argc, char **argv)
{
switch (argc)
{
case 2:
struct Test
{
Test()
{
case 1:;
}
} x;
}
return 0;
}
= end code =

Command line:
g++ -c -v -save-temps 1.cpp

Output:
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-linux-gnu/4.6.1/lto-wrapper
Target: i686-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.6.1-9ubuntu3' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++,go --prefix=/usr
--program-suffix=-4.6 --enable-shared --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-plugin
--enable-objc-gc --enable-targets=all --disable-werror --with-arch-32=i686
--with-tune=generic --enable-checking=release --build=i686-linux-gnu
--host=i686-linux-gnu --target=i686-linux-gnu
Thread model: posix
gcc version 4.6.1 (Ubuntu/Linaro 4.6.1-9ubuntu3) 
COLLECT_GCC_OPTIONS='-c' '-v' '-save-temps' '-shared-libgcc' '-mtune=generic'
'-march=i686'
 /usr/lib/gcc/i686-linux-gnu/4.6.1/cc1plus -E -quiet -v -imultilib .
-imultiarch i386-linux-gnu -D_GNU_SOURCE 1.cpp -mtune=generic -march=i686
-fpch-preprocess -fstack-protector -o 1.ii
ignoring nonexistent directory "/usr/local/include/i386-linux-gnu"
ignoring nonexistent directory
"/usr/lib/gcc/i686-linux-gnu/4.6.1/../../../../i686-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/include/c++/4.6
 /usr/include/c++/4.6/i686-linux-gnu/.
 /usr/include/c++/4.6/backward
 /usr/lib/gcc/i686-linux-gnu/4.6.1/include
 /usr/local/include
 /usr/lib/gcc/i686-linux-gnu/4.6.1/include-fixed
 /usr/include/i386-linux-gnu
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-c' '-v' '-save-temps' '-shared-libgcc' '-mtune=generic'
'-march=i686'
 /usr/lib/gcc/i686-linux-gnu/4.6.1/cc1plus -fpreprocessed 1.ii -quiet -dumpbase
1.cpp -mtune=generic -march=i686 -auxbase 1 -version -fstack-protector -o 1.s
GNU C++ (Ubuntu/Linaro 4.6.1-9ubuntu3) version 4.6.1 (i686-linux-gnu)
compiled by GNU C version 4.6.1, GMP version 5.0.1, MPFR version 3.0.1-p3,
MPC version 0.9
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++ (Ubuntu/Linaro 4.6.1-9ubuntu3) version 4.6.1 (i686-linux-gnu)
compiled by GNU C version 4.6.1, GMP version 5.0.1, MPFR version 3.0.1-p3,
MPC version 0.9
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: d77347ff65634d82ca51aadf7727a2c5
1.cpp: In constructor 'main(int, char**)::Test::Test()':
1.cpp:10:17: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
Preprocessed source stored into /tmp/cclIXtNW.out file, please attach this to
your bugreport.

[Bug fortran/51103] configure: error: GNU Fortran is not working

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #13 from Steve Kargl  
2011-11-12 17:58:18 UTC ---
On Sat, Nov 12, 2011 at 05:53:39PM +, richalewis at gmail dot com wrote:
> This is what I originally did:
> 
> 1. tar xvjf gcc-4.6.2.tar.bz
> 2. mkdir build
> 3. ../gcc-4.6.2/configure
> 4. make -j 8
> 
> Doesn't matter where I build it from, it fails
> 

--with-gmp=something_goes_here
--with-mpfr=something_goes_here
--with-mpc=something_goes_here

[Bug c++/51107] New: [C++11] Accepts invalid literal operator with void argument list.

[3dw4rd at verizon dot net]

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

 Bug #: 51107
   Summary: [C++11] Accepts invalid literal operator with void
argument list.
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: 3dw...@verizon.net


Created attachment 25809
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25809
Test case that should fail every which way.

I found that a non-template literal operator with no arguments is accepted by
g++.

#include 

//  This argument list should not be allowed but is.
int
operator"" _foo()
{ return 66; }

int
main()
{
  assert(operator"" _foo() == 66);  //  This is bad!
}

[Bug fortran/51103] configure: error: GNU Fortran is not working

[richalewis at gmail dot com]

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

--- Comment #12 from Richard Lewis  2011-11-12 
17:53:39 UTC ---

This is what I originally did:

1. tar xvjf gcc-4.6.2.tar.bz
2. mkdir build
3. ../gcc-4.6.2/configure
4. make -j 8

Doesn't matter where I build it from, it fails

(In reply to comment #11)
> On Sat, Nov 12, 2011 at 05:22:42PM +, richalewis at gmail dot com wrote:
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51103
> > 
> > --- Comment #9 from Richard Lewis  2011-11-12 
> > 17:22:42 UTC ---
> > (In reply to comment #8)
> > > On Sat, Nov 12, 2011 at 02:51:32PM +, richalewis at gmail dot com 
> > > wrote:
> > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51103
> > > > 
> > > > --- Comment #7 from Richard Lewis  
> > > > 2011-11-12 14:51:32 UTC ---
> > > > Created attachment 25807 [details]
> > > >   --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25807
> > > > libgfortran build log
> > > > 
> > > > -- 
> > > 
> > > In what directory is the gcc source code?
> > > 
> > > In what directory did you run configure?
> > 
> > ./gcc-4.6.2
> > 
> > configure and make in the top level directory, libgfortran.a build fails
> > 
> 
> What happens if you actually follow the installation instruction?
> 
> Building gcc within its source directory hierarchy has not been
> supported for years.   One can get lucky and have a successful
> build, but it is neither guaranteed to work nor recommended.

[Bug fortran/51103] configure: error: GNU Fortran is not working

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #11 from Steve Kargl  
2011-11-12 17:29:38 UTC ---
On Sat, Nov 12, 2011 at 05:22:42PM +, richalewis at gmail dot com wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51103
> 
> --- Comment #9 from Richard Lewis  2011-11-12 
> 17:22:42 UTC ---
> (In reply to comment #8)
> > On Sat, Nov 12, 2011 at 02:51:32PM +, richalewis at gmail dot com wrote:
> > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51103
> > > 
> > > --- Comment #7 from Richard Lewis  
> > > 2011-11-12 14:51:32 UTC ---
> > > Created attachment 25807 [details]
> > >   --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25807
> > > libgfortran build log
> > > 
> > > -- 
> > 
> > In what directory is the gcc source code?
> > 
> > In what directory did you run configure?
> 
> ./gcc-4.6.2
> 
> configure and make in the top level directory, libgfortran.a build fails
> 

What happens if you actually follow the installation instruction?

Building gcc within its source directory hierarchy has not been
supported for years.   One can get lucky and have a successful
build, but it is neither guaranteed to work nor recommended.

[Bug fortran/51103] configure: error: GNU Fortran is not working

[richalewis at gmail dot com]

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

--- Comment #10 from Richard Lewis  2011-11-12 
17:25:05 UTC ---
Created attachment 25808
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25808
gcc-4.6.2/x86_64-apple-darwin11.2.0/libgfortran/config.log

Builds to completion if I don't build fortran

[Bug fortran/51103] configure: error: GNU Fortran is not working

[richalewis at gmail dot com]

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

--- Comment #9 from Richard Lewis  2011-11-12 
17:22:42 UTC ---
(In reply to comment #8)
> On Sat, Nov 12, 2011 at 02:51:32PM +, richalewis at gmail dot com wrote:
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51103
> > 
> > --- Comment #7 from Richard Lewis  2011-11-12 
> > 14:51:32 UTC ---
> > Created attachment 25807 [details]
> >   --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25807
> > libgfortran build log
> > 
> > -- 
> 
> In what directory is the gcc source code?
> 
> In what directory did you run configure?

./gcc-4.6.2

configure and make in the top level directory, libgfortran.a build fails

[Bug fortran/51103] configure: error: GNU Fortran is not working

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #8 from Steve Kargl  
2011-11-12 16:52:37 UTC ---
On Sat, Nov 12, 2011 at 02:51:32PM +, richalewis at gmail dot com wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51103
> 
> --- Comment #7 from Richard Lewis  2011-11-12 
> 14:51:32 UTC ---
> Created attachment 25807
>   --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25807
> libgfortran build log
> 
> -- 

In what directory is the gcc source code?

In what directory did you run configure?

[Bug tree-optimization/50904] [4.7 regression] pessimization when -fno-protect-parens is enabled by -Ofast

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW
 CC||rguenth at gcc dot gnu.org
  Component|rtl-optimization|tree-optimization
 AssignedTo|ebotcazou at gcc dot|unassigned at gcc dot
   |gnu.org |gnu.org

--- Comment #15 from Eric Botcazou  2011-11-12 
16:45:13 UTC ---
> I don't see why RTL invariant motion should move the one variant but not
> the other.  Of course this also shows that we should, after loop unrolling
> on the tree level, also perform loop invariant motion again ...

AFAICS we already do that (lim3 is run after cunroll).  The problem is that
lim3 considers that the loads cannot be hoisted because they are "dependent". 
And it looks like a ccp pass is missing after cunroll as there is a lot of
cruft...

Recategorizing, at least temporarily, for further investigation.  If nothing
can be done at the Tree level, we could consider applying the RTL patch.

[Bug libstdc++/51083] TR1 [tr.c99.cmath.over] and C++11 [cmplx.over] overloads not constrained

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.7.0
Summary|[C++11] [cmplx.over]|TR1 [tr.c99.cmath.over] and
   |overloads not constrained   |C++11 [cmplx.over]
   ||overloads not constrained

--- Comment #14 from Jonathan Wakely  2011-11-12 
16:01:03 UTC ---
fixed for 4.7

summary edited to reflect that this also affected the TR1 overloads in
-std=c++98 mode

[Bug libstdc++/51083] [C++11] [cmplx.over] overloads not constrained

[redi at gcc dot gnu.org]

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

--- Comment #13 from Jonathan Wakely  2011-11-12 
15:57:07 UTC ---
Author: redi
Date: Sat Nov 12 15:57:03 2011
New Revision: 181321

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=181321
Log:
PR libstdc++/51083
* include/ext/type_traits.h (__promote): Only define __type member
for integral and floating point types, to prevent math functions
participating in overload resolution for other types.
(__promote_2, __promote_3, __promote_4): Use __promote in default
template argument values, so deduction only succeeds for integral and
floating point types.
* testsuite/26_numerics/cmath/51083.cc: New.
* testsuite/26_numerics/complex/51083.cc: New.
* testsuite/tr1/8_c_compatibility/cmath/51083.cc: New.
* testsuite/tr1/8_c_compatibility/complex/51083.cc: New.

Added:
trunk/libstdc++-v3/testsuite/26_numerics/cmath/
trunk/libstdc++-v3/testsuite/26_numerics/cmath/51083.cc
trunk/libstdc++-v3/testsuite/26_numerics/complex/51083.cc
trunk/libstdc++-v3/testsuite/tr1/8_c_compatibility/cmath/51083.cc
trunk/libstdc++-v3/testsuite/tr1/8_c_compatibility/complex/51083.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/ext/type_traits.h

[Bug fortran/51103] configure: error: GNU Fortran is not working

[richalewis at gmail dot com]

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

--- Comment #7 from Richard Lewis  2011-11-12 
14:51:32 UTC ---
Created attachment 25807
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25807
libgfortran build log

[Bug testsuite/51059] FAIL: gcc.misc-tests/gcov-14.c (test for excess errors) on *-apple-darwin*

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #10 from Iain Sandoe  2011-11-12 14:31:16 
UTC ---
fixed.

[Bug testsuite/51059] FAIL: gcc.misc-tests/gcov-14.c (test for excess errors) on *-apple-darwin*

[iains at gcc dot gnu.org]

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

--- Comment #9 from Iain Sandoe  2011-11-12 14:30:52 
UTC ---
Author: iains
Date: Sat Nov 12 14:30:45 2011
New Revision: 181317

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=181317
Log:

gcc/testsuite:

PR testsuite/51059
* gcc.misc-tests/gcov-14.c (dg-options): Force flat namespace for
Darwin targets and allow external symbols to be undefined.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.misc-tests/gcov-14.c

[Bug target/45233] FAIL: gcc.c-torture/compile/pr44707.c

[iains at gcc dot gnu.org]

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

--- Comment #12 from Iain Sandoe  2011-11-12 14:14:46 
UTC ---
Author: iains
Date: Sat Nov 12 14:14:43 2011
New Revision: 181316

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=181316
Log:

gcc:

PR target/45233
* config/rs6000/rs6000.c (rs6000_legitimize_reload_address):
Only expand a symbol ref. into an access when the entity is defined
in the TU.


Modified:
branches/gcc-4_6-branch/gcc/ChangeLog
branches/gcc-4_6-branch/gcc/config/rs6000/rs6000.c

[Bug target/45233] FAIL: gcc.c-torture/compile/pr44707.c

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #13 from Iain Sandoe  2011-11-12 14:15:27 
UTC ---
fixed.

[Bug target/45233] FAIL: gcc.c-torture/compile/pr44707.c

[iains at gcc dot gnu.org]

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

--- Comment #11 from Iain Sandoe  2011-11-12 14:12:31 
UTC ---
Author: iains
Date: Sat Nov 12 14:12:26 2011
New Revision: 181315

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=181315
Log:

gcc:

PR target/45233
* config/rs6000/rs6000.c (rs6000_legitimize_reload_address):
Only expand a symbol ref. into an access when the entity is defined
in the TU.


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

[Bug ada/49248] Cross compile ada failed at finding command gnatmake.

[maciej at opencsw dot org]

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

Maciej Bliziński  changed:

   What|Removed |Added

 CC||maciej at opencsw dot org

--- Comment #1 from Maciej Bliziński  2011-11-12 
14:13:10 UTC ---
I observed the same issue when trying to compile GCC with Ada for x86_64. Not
sure whether it's a problem with the GCC, or something I did wrong.

[Bug target/47997] gcc on macosx: "ld: warning: -fwritable-strings not compatible with literal CF/NSString"

[iains at gcc dot gnu.org]

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

--- Comment #28 from Iain Sandoe  2011-11-12 14:05:03 
UTC ---
Author: iains
Date: Sat Nov 12 14:04:58 2011
New Revision: 181314

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=181314
Log:

gcc/objc:

Backport from mainline
2011-10-29  Iain Sandoe  

PR target/47997
* objc-act.c (objc_build_string_object): Remove redundant second
call to fix_string_type ().  Add a checking assert that we are,
indeed, passed a STRING_CST.


Modified:
branches/gcc-4_6-branch/gcc/objc/ChangeLog
branches/gcc-4_6-branch/gcc/objc/objc-act.c

[Bug target/47997] gcc on macosx: "ld: warning: -fwritable-strings not compatible with literal CF/NSString"

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #29 from Iain Sandoe  2011-11-12 14:05:32 
UTC ---
fixed.

[Bug fortran/51103] configure: error: GNU Fortran is not working

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 CC||janus at gcc dot gnu.org

--- Comment #6 from janus at gcc dot gnu.org 2011-11-12 13:39:37 UTC ---
(In reply to comment #5)
> You didn't read the log I attached

... which is probably because you didn't actually attach anything. Please give
the relevant information, instead of telling us how long you've been building
GNU software (which is completely irrelevant here).

Thanks,
Janus

[Bug target/51106] New: [4.5 regression] ICE in move_insn, at haifa-sched.c:2314

[rl at hellgate dot ch]

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

 Bug #: 51106
   Summary: [4.5 regression] ICE in move_insn, at
haifa-sched.c:2314
Classification: Unclassified
   Product: gcc
   Version: 4.5.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@hellgate.ch


Created attachment 25806
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25806
reduced test case by SpanKY

I am getting the following ICE compiling Linux 3.0.4 with gcc 4.5.3 (Gentoo).
It didn't happen with 4.4, but it also happens with 4.6.1 (Ubuntu).

$ gcc-4.5.3  -c -m32 -O2 aesni-intel_glue.i
aesni-intel_glue.i:32:25: warning: initialization from incompatible pointer
type [enabled by default]
aesni-intel_glue.i: In function 'aes_decrypt':
aesni-intel_glue.i:30:1: internal compiler error: in move_insn, at
haifa-sched.c:2314
Please submit a full bug report,
[...]

$ gcc-4.6.1  -c -m32 -O2 aesni-intel_glue.i
aesni-intel_glue.i:32:25: warning: initialization from incompatible pointer
type [enabled by default]
aesni-intel_glue.i: In function 'aes_decrypt':
aesni-intel_glue.i:30:1: internal compiler error: in move_insn, at
haifa-sched.c:2353
Please submit a full bug report,
[...]

Reported as https://bugs.gentoo.org/show_bug.cgi?id=388835

[Bug bootstrap/50822] [4.7 regression] Solaris/SPARC bootstrap failure with Sun as: invalid assembler for ios_init.cc

[hubicka at gcc dot gnu.org]

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

--- Comment #11 from Jan Hubicka  2011-11-12 
13:19:59 UTC ---
Author: hubicka
Date: Sat Nov 12 13:19:55 2011
New Revision: 181311

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=181311
Log:

PR bootstrap/50822
* cgraphunit.c (output_weakrefs): Output really only weakrefs.

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

[Bug target/51093] GCC 4.4.3 build fails with 'OPTION_ISA_AES' as undefined

[mikpe at it dot uu.se]

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

--- Comment #4 from Mikael Pettersson  2011-11-12 
13:12:05 UTC ---
(In reply to comment #0)
> I've downloaded gcc 4.4.3 tar-ball package.
> Configured and build as follows for host-x86_64-unknown-linux-gnu:
> <./configure --prefix=$HOME/install/dir/ --enable-languages=c++>
> 

I just successfully bootstrapped gcc-4.4.3 on x86_64 (Fedora 13) configured
exactly as indicated above, except I also passed in --with-gmp= and
--with-mpfr= to pick up my locally built gmp/mpfr libraries, and I built in a
separate object directory.

Are you sure you didn't supply any other options to configure?
Ditto for 'make bootstrap'?
Are you sure there were no errors from configure?
Where there any warnings or errors from 'make bootstrap' before the one you
showed here?
What's the host environment (Linux distro, host gcc version, binutils version,
glibc version, how much memory, how much swap)?

> gcc -c -g -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes
> -Wmissing-prototypes -Wcast-qual -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE
> -I. -Ibuild -I../.././gcc -I../.././gcc/build -I../.././gcc/../include
> -I../.././gcc/../libcpp/include -I/usr/intel/pkgs/libgmp/4.3.0/include
> -I/usr/intel/pkgs/libgmp/4.3.0/include -I/usr/intel/pkgs/libmpfr/2.4.1/include

These paths to /usr/intel/pkgs/ look non-standard.  Where did they come from?

[Bug libstdc++/51078] [PATCH] performance improvement of std::count algorithm

[paolo.carlini at oracle dot com]

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

--- Comment #19 from Paolo Carlini  2011-11-12 
12:34:51 UTC ---
All in all - again, without having analyzed in any detail the optimization
passes - I come to the conclusion that -funroll-loops is doing its job pretty
well, and also that manually unrolling the loop make its life quite a bit
harder.

[Bug libstdc++/51078] [PATCH] performance improvement of std::count algorithm

[paolo.carlini at oracle dot com]

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

--- Comment #18 from Paolo Carlini  2011-11-12 
12:32:22 UTC ---
Created attachment 25805
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25805
Same, without -funroll-loops

[Bug lto/51105] New: [4.7 Regression] FAIL: gcc.c-torture/execute/920501-1.c compilation, -O2 -flto -flto-partition=none

[dominiq at lps dot ens.fr]

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

 Bug #: 51105
   Summary: [4.7 Regression] FAIL:
gcc.c-torture/execute/920501-1.c compilation,  -O2
-flto -flto-partition=none
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: domi...@lps.ens.fr
CC: hjl.to...@gmail.com, rguent...@suse.de


Between revisions 181189 (OK) and 181208 (see
http://gcc.gnu.org/ml/gcc-regression/2011-11/msg00230.html : r181205?), the
test gcc.c-torture/execute/920501-1.c compiled with '-O2 -flto
-flto-partition=none' has started to give an ICE:

lto1: internal compiler error: in can_inline_edge_p, at ipa-inline.c:353

This corresponds to the gcc_checking_assert for

/* In -flto-partition=none mode we really keep things out of
   sync because call_stmt_cannot_inline_p is set at cgraph
   merging when function bodies are not there yet.  */
|| (in_lto_p && !gimple_call_cannot_inline_p (e->call_stmt)));

[Bug middle-end/50628] [4.7 Regression] gfortran.fortran-torture/execute/entry_4.f90 fails

[dominiq at lps dot ens.fr]

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

--- Comment #10 from Dominique d'Humieres  
2011-11-12 12:21:27 UTC ---
On x86_64-apple-darwin10 the test was failing for both -m32 and -m64 up to
revision 181046. From revision 181258 it fails only with -m64.

[Bug libstdc++/51078] [PATCH] performance improvement of std::count algorithm

[paolo.carlini at oracle dot com]

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

--- Comment #17 from Paolo Carlini  2011-11-12 
12:14:06 UTC ---
Created attachment 25804
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25804
Some numbers: i7-980X, mainline, -Ofast -funroll-loops, -march=native

[Bug libstdc++/51078] [PATCH] performance improvement of std::count algorithm

[paolo.carlini at oracle dot com]

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

--- Comment #16 from Paolo Carlini  2011-11-12 
12:11:48 UTC ---
By the way, without having investigated at all what the optimizers are actually
doing, in mainline, on an i7-980X I have here at hand I don't see the manual
unrolling providing any advantage over -funroll-loops: I'm using  g++ -Ofast
-march=native -funroll-loops test.cc. Numbers attached.

[Bug libstdc++/51078] [PATCH] performance improvement of std::count algorithm

[paolo.carlini at oracle dot com]

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

--- Comment #15 from Paolo Carlini  2011-11-12 
11:12:36 UTC ---
Actually, patches do not belong to Bugzilla at all thus this issue should have
been posted and discussed only on the mailing list. In any case, we are not
going to add to the library manually unrolled loops for such simple algorithms
until we understand why the loops aren't satisfactorily unrolled, and
vectorized, and all it's profitable, by the compiler.

[Bug libstdc++/51078] [PATCH] performance improvement of std::count algorithm

[grygoriy.fuchedzhy at gmail dot com]

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

--- Comment #14 from Grygoriy Fuchedzhy  
2011-11-12 10:09:52 UTC ---
(In reply to comment #13)
> I would say, the next step, is analyzing why: std::count seems a very simple
> algorithm, no aliasing issues for example, compiler should be able to unroll,
> maybe vectorize too, and everything else, without having to fiddle with the
> code in an ad-hoc way.

I completely agree that analizing why is necessary, but this probably should be
done in separate bug?(should I open it?) As regarding current bug: it seems
that automatic loop unrolling is far from being considered "stable" or
"recommended" optimization, so this patch may improve performance until this
optimization become commonly used. By the way, manually unrolled std::find, one
of old algorithms you mentioned also performs significantly better than version
without loop unrolling.

[Bug fortran/51103] configure: error: GNU Fortran is not working

[richalewis at gmail dot com]

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

--- Comment #5 from Richard Lewis  2011-11-12 
08:33:13 UTC ---
I see... so suddenly from this year, building from a directory 1 level deeper
than the source distribution is "unsupported" even though this has been working
for years. However I was able to successfully build the full compiler suite
(except for Fortran). You didn't read the log I attached in which the error has
nothing to do with the level of directory I ran the config script from. 
On Nov 12, 2011, at 6:20 PM, kargl at gcc dot gnu.org wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51103
> 
> --- Comment #4 from kargl at gcc dot gnu.org 2011-11-12 07:20:10 UTC ---
> (In reply to comment #2)
>> I've been building GNU software since 1988. Perhaps I missed something?
> 
> Yes, I believe you did, which is why I asked if you read the
> installation instruction.  You stated that your configure line started
> with "../configure", which is an unsupported methods to build gcc.
> 
> http://gcc.gnu.org/install/configure.html
> 
> -- 
> Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email
> --- You are receiving this mail because: ---
> You reported the bug.