[Bug lto/50394] [meta-bug] Issues with building libreoffice with LTO

[markus at trippelsdorf dot de]

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

--- Comment #18 from Markus Trippelsdorf  
2011-09-21 07:13:12 UTC ---
(In reply to comment #17)
> > I haven't found out exactly what libs are affected yet, because I've copied
> > them in large chunks.
> 
> Hmm, this is quite weird. I am not aware of any really important LTO related
> wrong code issues (and in general my experience is that LTO tends to ICE or
> produce missing symbols, not really produce wrong code that often).
> So my bet would be that libreoffice uses some tricks that breaks with LTO and
> we will need to idenitfy which one.
> 
> If you could look into it, perhaps it would be interesting to identify 
> smallest
> library that misoptimize and see what is happening with it.
> 
> One common cause of problems is that -flto confuse the configure scripts.
> Some of configure tests are written in a way so LTO optimize the interesting
> part away and the test always pass. This usually leads to some link/parse
> errors
> but it also might break other things. Since you have both lto and non-lto
> builds,
> you could compare the config caches and see if they match?

Yes, they are identical as far as I can tell.

The problem seems to be that Libreoffice is ATM just too fragile when it comes
to optimization flags. In other words, it will silently misoptimize in case
of a non-supported -O flag. Quote from the Gentoo ebuild:

 # silent miscompiles; LO/OOo adds -O2/1/0 where appropriate
filter-flags "-O*

And because the effect of LTO is to fully optimize the important parts of
a program and use -Os for the rest, this could explain the crashes.

[Bug ada/48835] Porting GNAT to GNU/Linux/m68k

[mikpe at it dot uu.se]

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

--- Comment #31 from Mikael Pettersson  2011-09-21 
07:34:33 UTC ---
(In reply to comment #29)
> (In reply to comment #28)
> > Created attachment 24791 [details]
> > working patch for gcc-4.7-20110709
> > 
> > gcc-4.7-20110709 bootstrapped fine with the attached forward-port of the
> > gcc-4.5 patch.  I'm starting a bisection to see when trunk started to work
> > again, hoping that the same change will unbreak 4.6.1.
> 
> After a lengthy bisection process, I've now finally identified r171341
>  as the critical change
> that unbroke GNAT/m68k on trunk.  r171341 mixes cleanups with bugfixes, and is
> far too big to backport as-is to 4.6, so I'm now trying to split it up to
> identify a minimal bugfix-only fragment that unbreaks GNAT/m68k.

It's the store_bit_field_1 changes + the new helpers that do the trick,
specifically:

* optabs.h
(expand_operand_type): New enum.
(expand_operand): New structure.
(create_expand_operand): New function.
(create_fixed_operand, create_output_operand): Likewise
(create_input_operand, create_convert_operand_to): Likewise.
(create_convert_operand_from, create_address_operand): Likewise.
(create_integer_operand): Likewise.
(create_convert_operand_from_type, maybe_legitimize_operands): Declare.
(maybe_gen_insn, maybe_expand_insn, maybe_expand_jump_insn): Likewise.
(expand_insn, expand_jump_insn): Likewise.
* optabs.c
(create_convert_operand_from_type): New function.
(maybe_legitimize_operand, maybe_legitimize_operands): Likewise.
(maybe_gen_insn, maybe_expand_insn, maybe_expand_jump_insn): Likewise.
(expand_insn, expand_jump_insn): Likewise.

* expmed.c
(store_bit_field_1): Use the new interfaces.

I'll continue trying to minimize the changeset.

[Bug regression/50472] New: Volatile qualification in data is not enough to avoid optimization over pointer to data

[Paulo.Matos at csr dot com]

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

 Bug #: 50472
   Summary: Volatile qualification in data is not enough to avoid
optimization over pointer to data
Classification: Unclassified
   Product: gcc
   Version: 4.6.1
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: regression
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: paulo.ma...@csr.com


Given the following code:
static const unsigned int foo = 1;
unsigned int test( void )
{
  const volatile unsigned int *bar = &foo;
  return ( *bar );
}

GCC46 is generating:
$ local/gcc-4.6.1/bin/gcc -Os -S vol.c
$ cat vol.s
...
test:
.LFB0:
.cfi_startproc
movl$1, %eax
ret
.cfi_endproc
...


This is optimizing away bar even though the data bar points to is being
qualified as volatile. The way to ensure this doesn't happen requires
qualifying the pointer as a volatile too:
static const unsigned int foo = 1;
unsigned int test( void )
{
  const volatile unsigned int * volatile bar = &foo;
  return ( *bar );
}

$ local/gcc-4.6.1/bin/gcc -Os -S vol.c
$ cat vol.s
...
test:
.LFB0:
.cfi_startproc
movq$foo, -8(%rsp)
movq-8(%rsp), %rax
movl(%rax), %eax
ret
.cfi_endproc
...


This is a regression to what GCC45 used to do. Qualification of the data as
volatile used to be enough to block the optimization.

Posting this to the mailing list revealed Ian agrees this is a regression:
http://gcc.gnu.org/ml/gcc/2011-09/msg00197.html

[Bug target/50449] [avr] Loading some 32 constants not optimal

[gjl at gcc dot gnu.org]

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

--- Comment #1 from Georg-Johann Lay  2011-09-21 
08:22:08 UTC ---
Author: gjl
Date: Wed Sep 21 08:21:57 2011
New Revision: 179037

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179037
Log:
PR target/50449
PR target/50465
* config/avr/avr.md (adjust_len): New insn attribute.
(*reload_insi, *reload_insf): Use it.
(*movsi, *movsf): Use new interface of output_movsisf.
* config/avr/avr-protos.h (output_movsisf): Change prototype.
* config/avr/avr.c (output_movsisf): Ditto.
(adjust_insn_length): Use insn attribute "adjust_len" to adjust
lengths of insns *reload_insi, *reload_insf.
(output_reload_insisf_1): New static function.
(output_reload_insisf): Use it.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/avr/avr-protos.h
trunk/gcc/config/avr/avr.c
trunk/gcc/config/avr/avr.md

[Bug target/50465] [avr] Use insn attribute to depict if and how instruction lengths have to be adjusted

[gjl at gcc dot gnu.org]

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

--- Comment #1 from Georg-Johann Lay  2011-09-21 
08:22:10 UTC ---
Author: gjl
Date: Wed Sep 21 08:21:57 2011
New Revision: 179037

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179037
Log:
PR target/50449
PR target/50465
* config/avr/avr.md (adjust_len): New insn attribute.
(*reload_insi, *reload_insf): Use it.
(*movsi, *movsf): Use new interface of output_movsisf.
* config/avr/avr-protos.h (output_movsisf): Change prototype.
* config/avr/avr.c (output_movsisf): Ditto.
(adjust_insn_length): Use insn attribute "adjust_len" to adjust
lengths of insns *reload_insi, *reload_insf.
(output_reload_insisf_1): New static function.
(output_reload_insisf): Use it.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/avr/avr-protos.h
trunk/gcc/config/avr/avr.c
trunk/gcc/config/avr/avr.md

[Bug regression/50472] Volatile qualification in data is not enough to avoid optimization over pointer to data

[mikpe at it dot uu.se]

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

--- Comment #1 from Mikael Pettersson  2011-09-21 
08:29:07 UTC ---
Duplicate of PR50078?

[Bug lto/50394] [meta-bug] Issues with building libreoffice with LTO

[hubicka at ucw dot cz]

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

--- Comment #19 from Jan Hubicka  2011-09-21 09:38:57 
UTC ---
>  # silent miscompiles; LO/OOo adds -O2/1/0 where appropriate
> filter-flags "-O*
> 
> And because the effect of LTO is to fully optimize the important parts of
> a program and use -Os for the rest, this could explain the crashes.

GCC does not really bump up optimization levels and same heuristics is in
limited
degree applied w/o LTO as well. Debugging this seems quite important.  Perhaps
hacking -fno-strict-aliasing in addition to -flto at linktime could be first
shot
to get working binary?

[Bug target/45099] [avr] Warning could be issued for use of register variables that will fail.

[gjl at gcc dot gnu.org]

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

--- Comment #3 from Georg-Johann Lay  2011-09-21 
09:40:17 UTC ---
Author: gjl
Date: Wed Sep 21 09:40:13 2011
New Revision: 179040

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179040
Log:
PR target/45099
* config/avr/avr.c (avr_function_arg_advance): Change error to
warning if a fixed register is needed as function argument.


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

[Bug c++/50454] Unexpected problems with -pedantic / -pedantic-errors and __int128 and unsigned __int128 specializations

[paolo at gcc dot gnu.org]

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

--- Comment #8 from paolo at gcc dot gnu.org  
2011-09-21 09:56:49 UTC ---
Author: paolo
Date: Wed Sep 21 09:56:45 2011
New Revision: 179042

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179042
Log:
/cp
2011-09-21  Paolo Carlini  

PR c++/50454
* decl.c (grokdeclarator): Consistently handle both __int128
and unsigned __int128 with -pedantic; suppress diagnostic in
system headers.

/testsuite
2011-09-21  Paolo Carlini  

PR c++/50454
* g++.dg/ext/int128-1.C: New.
* g++.dg/ext/int128-2.C: Likewise.
* g++.dg/ext/int128-2.h: Likewise.

Added:
trunk/gcc/testsuite/g++.dg/ext/int128-1.C
trunk/gcc/testsuite/g++.dg/ext/int128-2.C
trunk/gcc/testsuite/g++.dg/ext/int128-2.h
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/50454] Unexpected problems with -pedantic / -pedantic-errors and __int128 and unsigned __int128 specializations

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #9 from Paolo Carlini  2011-09-21 
09:58:05 UTC ---
Fixed.

[Bug driver/50470] gcc does not respect -nostdlib with regard to search paths

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

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

Andreas Schwab  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #3 from Andreas Schwab  2011-09-21 09:59:32 
UTC ---
-nostdlib is not called -nostdlibpath for a reason.  It is doing what it is
documented to do, and that does not include resetting the lib path.  Changing
that would break a lot of valid uses.

[Bug c++/50471] Qualified lookup fails to find template function

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  2011-09-21 
10:19:21 UTC ---
The name lookup is delayed until instantiation, however [temp.dep.candidate]
says that the qualified lookup in g1 only finds declarations visible at the
point of definition of g1:

For a function call that depends on a template parameter, the candidate
functions are found using the usual lookup rules (3.4.1, 3.4.2, 3.4.3) except
that:
— For the part of the lookup using unqualified name lookup (3.4.1) or qualified
name lookup (3.4.3), only function declarations from the template definition
context are found.
— For the part of the lookup using associated namespaces (3.4.2), only function
declarations found in either the template definition context or the template
instantiation context are found.

[Bug c++/50471] Qualified lookup fails to find template function

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  2011-09-21 
10:22:48 UTC ---
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#448

[Bug libstdc++/49561] [C++0x] std::list::size complexity

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 AssignedTo|unassigned at gcc dot   |paolo.carlini at oracle dot
   |gnu.org |com

--- Comment #4 from Paolo Carlini  2011-09-21 
10:56:00 UTC ---
Maybe I can do this in time for 4.7, I don't make promises however, the changes
are conceptually simple but quite a few throughout the class. Of course then it
will definitely impossible to mix C++98 and C++11 std::lists, a data member
must be added in c++0x mode in order to implement this.

[Bug lto/50394] [meta-bug] Issues with building libreoffice with LTO

[michael.meeks at suse dot com]

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

Michael Meeks  changed:

   What|Removed |Added

 CC||michael.meeks at suse dot
   ||com

--- Comment #20 from Michael Meeks  2011-09-21 
11:03:30 UTC ---
For:

terminate called after throwing an instance of
'com::sun::star::container::NoSuchElementException'
It throws an exception in: xmlreader::XmlReader::XmlReader(rtl::OUString
const&) () from image/usr/ure/lib/libxmlreader.so.
This happens in xmlreader/source/xmlreader.cxx.

This is new code, and shouldn't suffer lots of aliasing / compilation
nasties I hope - it is also -fairly- self-standing and relatively simple. If we
have a problem here - we have a real problem I think. I'd personally focus on
that, it should (I hope) be easier.

How did you install though ? run a 'make dev-install' ? and then run
install/program/soffice ? 

this:

#6  0x77d0d741 in __cxa_throw () from /usr/lib64/libstdc++.so.6
#7  0x718915c8 in gcc3::raiseException(_uno_Any*, _uno_Mapping*) ()
from
/var/tmp/portage/app-office/libreoffice--r1/image/usr/ure/lib/libgcc3_uno.so
#8  0x71892dff in
cpp2uno_call(bridges::cpp_uno::shared::CppInterfaceProxy*,
_typelib_TypeDescription const*, _typelib_TypeDescriptionReference*, int,
_typelib_MethodParameter*, void**, void**, void**, unsigned long*) () from
/var/tmp/portage/app-office/libreoffice--r1/image/usr/ure/lib/libgcc3_uno.so
#9  0x71893553 in cpp_vtable_call () from

is altogether more hairy - we create at run-time C++ vtables packed with
trampolines so we can intercept / model native C++ objects and interact with
them via python etc. that would need some more intense debugging love I guess.

[Bug middle-end/50451] [4.7 regression] internal compiler error at tree-vect-loop.c:3557

[irar at il dot ibm.com]

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

Ira Rosen  changed:

   What|Removed |Added

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

--- Comment #4 from Ira Rosen  2011-09-21 11:55:29 UTC 
---
SLP should be fixed to support reduction with constant.

[Bug tree-optimization/50374] Support vectorization of min/max location pattern

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

  Attachment #25320|0   |1
is obsolete||
  Attachment #25324|0   |1
is obsolete||
  Attachment #25325|0   |1
is obsolete||

--- Comment #14 from Jakub Jelinek  2011-09-21 
12:10:28 UTC ---
Created attachment 25331
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25331
gcc47-pr50374.patch

Updated patch, not very heavily tested yet.
The optabs stuff needs to change, because currently i?86 has 480 gen_reduc*loc*
expanders, that's way too much.

Thus I think it will be better to only iterate on the two modes, and pass
the comparison operator as another argument like we pass to vcond{,u}, from
which the expansion can determine what kind of comparison is supposed to happen
(signed vs. unsigned, min vs. max and first vs. last).  I'll change it now.

Another thing is that this really ought to work even with -ftree-pre, having a
vectorization that requires users to disable PRE would be weird.  I believe
there is one extra assignment, will look at that.

Then there is the question if ifcvt should, as richi asked, fold the COND_EXPR
into MIN/MAX and vectorizer be adjusted for that.  Or, if we just should it
vectorize it using two VECT_COND_EXPRs instead (with the same condition).

Then, can also vectorize e.g. double comparisons, but only int indexes?

[Bug bootstrap/50326] [4.7 regression] ICE in set_lattice_value, at tree-ssa-ccp.c:456

[jamborm at gcc dot gnu.org]

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

--- Comment #8 from Martin Jambor  2011-09-21 
12:18:46 UTC ---
The different alias set (4 instead of 10) is then just carried along
in the RTL dumps not causing any different behavior until
tree-ssa-ccp.c.192r.postreload where we get the following diff:

--- /tmp/zzz/12011-09-21 14:08:26.0 +0200
+++ /tmp/zzz/22011-09-21 14:10:18.0 +0200
@@ -48,6 +48,8 @@
 verify found no changes in insn with uid = 4249.
 verify found no changes in insn with uid = 4435.
 verify found no changes in insn with uid = 4531.
+rescanning insn with uid = 5957.
+deleting insn with uid = 5957.
 verify found no changes in insn with uid = 5017.
 verify found no changes in insn with uid = 5065.
 verify found no changes in insn with uid = 5096.
@@ -16908,12 +16910,12 @@
 (reg:DI 15 r15 [orig:2693 val ] [2693]))
/abuild/mjambor/trunk/src/gcc/tree-ssa-ccp.c:1685 5 {movdi_internal}
  (nil))

-(insn 4927 4910 5957 500 (set (mem/s/c:SI (reg/f:DI 14 r14 [2688]) [10
MEM[(struct prop_value_d *)&D.39146].lattice_val+0 S4 A128])
+(insn 4927 4910 5957 500 (set (mem/s/c:SI (reg/f:DI 14 r14 [2688]) [4
MEM[(struct prop_value_d *)&D.39146].lattice_val+0 S4 A128])
 (reg:SI 16 r16 [orig:433 val$lattice_val ] [433]))
/abuild/mjambor/trunk/src/gcc/tree-ssa-ccp.c:1685 4 {movsi_internal}
  (nil))

 (insn 5957 4927 5963 500 (set (reg:DI 8 r8)
-(mem/s/c:DI (reg/f:DI 14 r14 [2688]) [0+0 S8 A128]))
/abuild/mjambor/trunk/src/gcc/tree-ssa-ccp.c:1686 5 {movdi_internal}
+(reg:DI 15 r15 [orig:2693 val ] [2693]))
/abuild/mjambor/trunk/src/gcc/tree-ssa-ccp.c:1686 5 {movdi_internal}
  (nil))

 (insn 5963 5957 4970 500 (use (reg/i:OI 8 r8))
/abuild/mjambor/trunk/src/gcc/tree-ssa-ccp.c:1686 -1

[Bug tree-optimization/50374] Support vectorization of min/max location pattern

[irar at il dot ibm.com]

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

--- Comment #15 from Ira Rosen  2011-09-21 12:20:47 UTC 
---
(In reply to comment #14)

> Another thing is that this really ought to work even with -ftree-pre, having a
> vectorization that requires users to disable PRE would be weird.  I believe
> there is one extra assignment, will look at that.

It was discussed in pr 44711 and
http://gcc.gnu.org/ml/gcc-patches/2010-06/msg02982.html.

[Bug target/50350] [4.6 Regression] ICE (segfault) in canonicalize_float_value

[bernds at gcc dot gnu.org]

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

Bernd Schmidt  changed:

   What|Removed |Added

 CC||bernds at gcc dot gnu.org

--- Comment #1 from Bernd Schmidt  2011-09-21 
12:44:09 UTC ---
Almost certainly a dup of 50326.

[Bug c++/18610] bad error message

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #4 from Manuel López-Ibáñez  2011-09-21 
12:51:32 UTC ---
(In reply to comment #3)
> Subject: Re:  bad error message
> 
> "bangerth at dealii dot org"  writes:
> 
> | I think the fact that we may print a message saying that the overload 
> | set is empty but that there are functions of the same name that aren't 
> | viable has been discussed in at least one other PR already. 
> 
> yes,  We should implement that functionality, but in 4.1.
> 
> -- Gaby
> 

Still valid in 4.5.2. Clang gives:

/tmp/webcompile/_30907_0.cc:7:13: warning: class template 'Q' was previously
declared as a struct template [-Wmismatched-tags]
template <> class Q;
^
struct
/tmp/webcompile/_30907_0.cc:2:8: note: previous use is here
struct Q
   ^
/tmp/webcompile/_30907_0.cc:17:5: error: no matching function for call to 'g'
g(a );
^
/tmp/webcompile/_30907_0.cc:12:22: note: candidate template ignored:
substitution failure [with T = int]
F< typename Q::t> g( const F& a );
 ^
1 warning and 1 error generated.

[Bug c++/50473] New: [C++0x] ICE in type_has_nontrivial_copy_init, at cp/tree.c:2574

[y121516 at gmail dot com]

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

 Bug #: 50473
   Summary: [C++0x] ICE in type_has_nontrivial_copy_init, at
cp/tree.c:2574
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: y121...@gmail.com


ICE occured.

Codes (a.cpp):

template
struct s
{};

template
constexpr s f()
{
 return {};
}

template
struct test
{
 static constexpr auto&& value = f();
};

int main(){}


Compile error messages:

$ g++4.7 -std=c++0x -Wall -Wextra -pedantic a.cpp
a.cpp:14:36: internal compiler error: in type_has_nontrivial_copy_init, at
cp/tree.c:2574
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


Vesion info:

$ g++4.7 -v
Built by Equation Solution .
Using built-in specs.
COLLECT_GCC=C:\cygwin\home\RiSK\misc\gcc4.7\bin\g++.exe
COLLECT_LTO_WRAPPER=c:/cygwin/home/risk/misc/gcc4.7/bin/../libexec/gcc/i686-pc-mingw32/4.7.0/lto-wrapper.exe
Target: i686-pc-mingw32
Configured with: ../gcc-4.7-20110917-mingw/configure --host=i686-pc-mingw32
--build=x86_64-unknown-linux-gnu --target
=i686-pc-mingw32
--prefix=/home/gfortran/gcc-home/binary/mingw32/native/x86_32/gcc/4.7-20110917
--with-gcc --with-gnu
-as --with-gnu-ld --with-host-libstdcxx='-lstdc++ -lsupc++ -lm'
--with-ppl=/home/gfortran/gcc-home/binary/mingw32/nat
ive/x86_32/ppl
--with-cloog=/home/gfortran/gcc-home/binary/mingw32/native/x86_32/cloog
--with-gmp=/home/gfortran/gcc-
home/binary/mingw32/native/x86_32/gmp
--with-mpfr=/home/gfortran/gcc-home/binary/mingw32/native/x86_32/mpfr --with-mp
c=/home/gfortran/gcc-home/binary/mingw32/native/x86_32/mpc
--with-sysroot=/home/gfortran/gcc-home/binary/mingw32/cros
s/x86_32/gcc/4.7-20110917 --disable-shared --disable-nls --disable-tls
--disable-win32-registry --enable-libquadmath-
support --enable-libquadmath --enable-languages=c,c++,fortran --enable-libgomp
--enable-threads=win32 --enable-lto --
enable-static --enable-shared=lto-plugin --enable-plugins --enable-ld=yes
--enable-cloog-backend=ppl
Thread model: win32
gcc version 4.7.0 20110917 (experimental) (GCC)

[Bug lto/50394] [meta-bug] Issues with building libreoffice with LTO

[hubicka at ucw dot cz]

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

--- Comment #21 from Jan Hubicka  2011-09-21 13:08:43 
UTC ---
> is altogether more hairy - we create at run-time C++ vtables packed with
> trampolines so we can intercept / model native C++ objects and interact with
> them via python etc. that would need some more intense debugging love I guess.

Hmm, this sounds scary. (I remember Kendy explaining me this years back when
OOo
was ported to x86_64.) More or less everything that is reachable externally
ought to
be annotated with used/externally_visible attributes or the assembly wrappers
has
to be visible at linktime.  Is there some short overview of the machinery?
(or could you explain it somehow? :)

Honza

[Bug c++/18610] bad error message

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  2011-09-21 
13:09:55 UTC ---
But I think it can be considered fixed for 4.7 by Nathan's excellent work in
giving reasons why candidate functions are not viable:

t.cc: In function 'int f()':
t.cc:17:9: error: no matching function for call to 'g(F&)'
t.cc:17:9: note: candidate is:
t.cc:12:22: note: template F::t> g(const F&)
t.cc:12:22: note:   template argument deduction/substitution failed:
t.cc: In substitution of 'template F::t> g(const F&)
[with T = int]':
t.cc:17:9:   required from here
t.cc:12:22: error: invalid use of incomplete type 'struct Q'
t.cc:2:8: error: declaration of 'struct Q'

[Bug tree-optimization/50433] [4.7 Regression] ACATS c460010 fails to compile

[hubicka at gcc dot gnu.org]

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

--- Comment #3 from Jan Hubicka  2011-09-21 
13:10:37 UTC ---
Author: hubicka
Date: Wed Sep 21 13:10:31 2011
New Revision: 179046

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

PR tree-optimization/50433
* ipa-inline-analysis.c (eliminated_by_inlining_prob): Use
get_base_address.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-inline-analysis.c

[Bug c++/18610] bad error message

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  2011-09-21 
13:11:47 UTC ---
N.B. that's even better than clang, as it tells you *why* substitution failed:
the specialization Q is incomplete

[Bug c++/49152] Unhelpful diagnostic for iterator dereference

[giecrilj at stegny dot 2a.pl]

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

Christopher Yeleighton  changed:

   What|Removed |Added

 CC||giecrilj at stegny dot
   ||2a.pl

--- Comment #1 from Christopher Yeleighton  
2011-09-21 13:17:44 UTC ---
To figure out what the types involved are, you can say 

(int &) first; (int &) val;

which would work most of the time.

However, this requires modifying the source and recompiling, which is such a
waste of time.

[Bug tree-optimization/50433] [4.7 Regression] ACATS c460010 fails to compile

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #4 from Eric Botcazou  2011-09-21 
13:51:03 UTC ---
Presumably.  Reopen if not.

[Bug target/50449] [avr] Loading some 32 constants not optimal

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #2 from Georg-Johann Lay  2011-09-21 
13:56:04 UTC ---
Fixed now.

[Bug target/35860] [4.4/4.5/4.6/4.7 Regression] [avr] code bloat caused by -fsplit-wide-types

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

 CC||gjl at gcc dot gnu.org
 Depends on||50447

--- Comment #14 from Georg-Johann Lay  2011-09-21 
14:25:09 UTC ---
The bloat is partly caused by PR50447 because the a |= 1 leads to reload of the
constant 1 into an SI register.  For that constant no reloading is needed. 
However, insn *iorsi3_clobber is hidden behind iorsi3 so that a reload happens
and causes a part of the observed code bloat.  Moreover, operations like AND,
IOR, XOR are implemented in a suboptimal way.

The other part of the code bloat is simply because of -f[no-]split-wide-types;
there will always be cases where splitting wide types leads to bloated (or sort
of) code because there might be SUBREGs all over the place.  Not all insns can
be split, e.g. addition, subtraction, comparison, etc. so that there will be
mixture of split and non-split insns.

[Bug c++/18610] bad error message

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #7 from Manuel López-Ibáñez  2011-09-21 
14:28:05 UTC ---
(In reply to comment #6)
> N.B. that's even better than clang, as it tells you *why* substitution failed:
> the specialization Q is incomplete

Great! 

I agree it is better that it tells you *why*, but g++'s output is also
extremely verbose: 2 diagnostics versus 8, plus the repetition of
'template F::t> g(const F&)' and 'struct Q'.
Moreover, the use of "note" and "error" is inconsistent.

I would wish for something like:

t.cc:17:9: error: no matching function for call to 'g'
t.cc:12:22: note: candidate template ignored: template argument
deduction/substitution failed [with T = int]
t.cc:12:22: note: reason: invalid use of incomplete type 'struct Q'
t.cc:2:8: note: declared here

Current output will explode with large number of candidates and complex
template instantiations (e.g., STL stuff). But that is an old problem, in
general, and I guess hard to fix in g++.

Let's mark this as FIXED in GCC 4.7. If someone disagrees, just reopen it.

[Bug c++/18724] missleading error message with undeclared template name

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

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

--- Comment #2 from Manuel López-Ibáñez  2011-09-21 
14:30:38 UTC ---
GCC 4.5.2:

test.cc:1:1: error: ‘list’ in namespace ‘std’ does not name a type

So FIXED, I would say.

[Bug c++/10618] Error message for function declarations with invalid return type could be improved

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW
 CC||manu at gcc dot gnu.org

--- Comment #7 from Manuel López-Ibáñez  2011-09-21 
14:39:29 UTC ---
(In reply to comment #5)
> The second part (the non-template case) of the bug is already fixed in 3.5.0:
> pr10618.cc:15: error: `k' in class `B' does not name a type

I would say it got broken again (GCC 4.5.2)

test.cc:12:1: error: need ‘typename’ before ‘A::k’ because ‘A’ is a
dependent scope
test.cc:14:6: error: expected constructor, destructor, or type conversion
before ‘func2’

If one adds the typename as suggested, it gets better but the first part is not
even reported:

test.cc:14:1: error: ‘k’ in class ‘B’ does not name a type


Clang gives the correct output:

/tmp/webcompile/_10395_0.cc:12:1: error: missing 'typename' prior to dependent
type name 'A::k'
A::k func1(); 
^~~
typename 
/tmp/webcompile/_10395_0.cc:14:4: error: no type named 'k' in 'B'
B::k func2();
~~~^
2 errors generated.

[Bug c++/18610] bad error message

[redi at gcc dot gnu.org]

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

--- Comment #8 from Jonathan Wakely  2011-09-21 
14:48:34 UTC ---
(In reply to comment #7)
> (In reply to comment #6)
> > N.B. that's even better than clang, as it tells you *why* substitution 
> > failed:
> > the specialization Q is incomplete
> 
> Great! 
> 
> I agree it is better that it tells you *why*, but g++'s output is also
> extremely verbose: 2 diagnostics versus 8, plus the repetition of
> 'template F::t> g(const F&)' and 'struct Q'.
> Moreover, the use of "note" and "error" is inconsistent.
> 
> I would wish for something like:
> 
> t.cc:17:9: error: no matching function for call to 'g'

No, you need to know the argument types used for the call, not just the name of
the function called.

> t.cc:12:22: note: candidate template ignored: template argument
> deduction/substitution failed [with T = int]

Which candidate function?  If there are several 'g' overloads you will get a
note about each, I want them to be identified by more than the line they are
declared on.

> t.cc:12:22: note: reason: invalid use of incomplete type 'struct Q'
> t.cc:2:8: note: declared here

This is just clang's output without the original source code snippets, which
would definitely not be an improvement.

> Current output will explode with large number of candidates and complex
> template instantiations (e.g., STL stuff). But that is an old problem, in
> general, and I guess hard to fix in g++.

That's the whole point - it shows you *all* the candidates, why they were not
viable, and the context that caused them to be instantiated - that's a Good
Thing.

[Bug c/10143] -Wsequence-point missing warnings

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

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

--- Comment #14 from Manuel López-Ibáñez  2011-09-21 
14:55:16 UTC ---
I implemented a lot of new Wsequence-point warnings in GCC 4.4, so this is
likely fixed now. If you find an instance where it isn't, please open a new PR.

[Bug c++/10618] Error message for function declarations with invalid return type could be improved

[redi at gcc dot gnu.org]

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

--- Comment #8 from Jonathan Wakely  2011-09-21 
14:56:03 UTC ---
(In reply to comment #7)
> (In reply to comment #5)
> > The second part (the non-template case) of the bug is already fixed in 
> > 3.5.0:
> > pr10618.cc:15: error: `k' in class `B' does not name a type
> 
> I would say it got broken again (GCC 4.5.2)

That's not the current version, 4.6 and 4.7 have a lot of C++ diagnostic
improvements (although they don't affect this case.)

> test.cc:12:1: error: need ‘typename’ before ‘A::k’ because ‘A’ is a
> dependent scope
> test.cc:14:6: error: expected constructor, destructor, or type conversion
> before ‘func2’
> 
> If one adds the typename as suggested, it gets better but the first part is 
> not
> even reported:
> 
> test.cc:14:1: error: ‘k’ in class ‘B’ does not name a type

That's because you didn't instantiate the function template 'func1'

> Clang gives the correct output:
> 
> /tmp/webcompile/_10395_0.cc:12:1: error: missing 'typename' prior to dependent
> type name 'A::k'
> A::k func1(); 
> ^~~
> typename 
> /tmp/webcompile/_10395_0.cc:14:4: error: no type named 'k' in 'B'
> B::k func2();
> ~~~^
> 2 errors generated.

Huh? This is the same as G++'s output

If you instantiate the function template G++ trunk gives a better diagnostic
than clang 3.0

t.cc:12:18: error: no type named 'k' in 'struct A'

[Bug c++/50344] friend declaration confused by const qualifier

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011-09-21
 AssignedTo|unassigned at gcc dot   |paolo.carlini at oracle dot
   |gnu.org |com
   Target Milestone|--- |4.7.0
 Ever Confirmed|0   |1

[Bug driver/50470] gcc does not respect -nostdlib with regard to search paths

[joseph at codesourcery dot com]

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

--- Comment #4 from joseph at codesourcery dot com  2011-09-21 15:03:18 UTC ---
On Wed, 21 Sep 2011, bugdal at aerifal dot cx wrote:

> The sysroot features may be nice but they're not a substitute for being able 
> to
> eliminate the default library search path. For example, when using sysroot,
> -L/new/path will prepend the sysroot to /new/path.

No, you need -L=/new/path for that.

[Bug c/13050] RFE: Support for implementation-specific format specifiers in format string warnings

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

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

--- Comment #3 from Manuel López-Ibáñez  2011-09-21 
15:04:16 UTC ---
(In reply to comment #2)
> This feature was added to 4.4.0 and there are now format specifiers for ms and
> gnu printf/scanf styles.
> As this feature won't be backported to 3.4.0, this bug should be closed.
> Danny any objections about this?

No, be bold and close stuff. So much useless open stuff that nobody cares
anymore about the ~2000 unconfirmed bugs.

[Bug c/13050] RFE: Support for implementation-specific format specifiers in format string warnings

[dominiq at lps dot ens.fr]

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

--- Comment #4 from Dominique d'Humieres  2011-09-21 
15:08:38 UTC ---
> about the ~2000 unconfirmed bugs.

2622 last time (i.e. today) I looked at the number vs. 3670 new;-(

[Bug c++/10618] Error message for function declarations with invalid return type could be improved

[manu at gcc dot gnu.org]

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

--- Comment #9 from Manuel López-Ibáñez  2011-09-21 
15:30:26 UTC ---
> 
> > test.cc:12:1: error: need ‘typename’ before ‘A::k’ because ‘A’ is a
> > dependent scope
> > test.cc:14:6: error: expected constructor, destructor, or type conversion
> > before ‘func2’
> 
> > Clang gives the correct output:
> > 
> > /tmp/webcompile/_10395_0.cc:12:1: error: missing 'typename' prior to 
> > dependent
> > type name 'A::k'
> > A::k func1(); 
> > ^~~
> > typename 
> > /tmp/webcompile/_10395_0.cc:14:4: error: no type named 'k' in 'B'
> > B::k func2();
> > ~~~^
> > 2 errors generated.
> 
> Huh? This is the same as G++'s output
> 

The second diagnostic from G++ does not make sense. Clang gives the correct
diagnostics in that case.

> If you instantiate the function template G++ trunk gives a better diagnostic
> than clang 3.0

Great! Let's say this is almost fixed then.

[Bug middle-end/49705] -Wstrict-overflow should not diagnose unevaluated expressions

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

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

--- Comment #9 from Manuel López-Ibáñez  2011-09-21 
15:33:24 UTC ---
(In reply to comment #8)
> Fixed in mainline.

So closing.

[Bug c++/10618] Error message for function declarations with invalid return type could be improved

[redi at gcc dot gnu.org]

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

--- Comment #10 from Jonathan Wakely  2011-09-21 
15:38:49 UTC ---
(In reply to comment #9)
> 
> The second diagnostic from G++ does not make sense. Clang gives the correct
> diagnostics in that case.

Ah, that's because you're using 4.5.2 -- stop it! ;)

If you use 4.6 the diagnostics are almost exactly the same as clang's, with and
without 'typename'

If you use 4.7 and instantiate the template the diagnostic is better than
clang's

[Bug c++/10618] Error message for function declarations with invalid return type could be improved

[manu at gcc dot gnu.org]

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

--- Comment #11 from Manuel López-Ibáñez  2011-09-21 
15:46:59 UTC ---
(In reply to comment #10)
> (In reply to comment #9)
> > 
> > The second diagnostic from G++ does not make sense. Clang gives the correct
> > diagnostics in that case.
> 
> Ah, that's because you're using 4.5.2 -- stop it! ;)

Ah, ok, sorry for the noise. I don't have a recent GCC trunk around anymore.
Maybe I will find some free hours to set up one. Or GCC could have an online
demo like http://llvm.org/demo? ;-)

[Bug c++/10618] Error message for function declarations with invalid return type could be improved

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #12 from Manuel López-Ibáñez  2011-09-21 
15:47:39 UTC ---

> If you use 4.7 and instantiate the template the diagnostic is better than
> clang's

So fully FIXED!

[Bug c++/50474] New: GCC (cc1plus) hangs forever compiling with -O2 (-fcse-follow-jumps)

[steffen-schmidt at siemens dot com]

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

 Bug #: 50474
   Summary: GCC (cc1plus) hangs forever compiling with -O2
(-fcse-follow-jumps)
Classification: Unclassified
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: steffen-schm...@siemens.com


Created attachment 25332
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25332
Source example

Compilation hangs forever in the following example when using optimization >=
-O2
The option causing the hang seems to be -fcse-follow-jumps, when lowering
optimization level or explicitly excluding the option cse-follow-jumps
(-fno-cse-follow-jumps) compilation works as expected.

Compiler command line:
mips-sde-elf-gcc -O2 -c -oopterror.o opterror.cpp //<-- this hangs
mips-sde-elf-gcc -O2 -fno-cse-follow-jumps -c -oopterror.o opterror.cpp //<--
this works fine

//=
// File opterror.cpp
unsigned short global;
void get_R(unsigned char * data);

bool processFirstCall() {
unsigned char r = 0; 
get_R(&r);
if(r != !!r) {
  return false;
}
if(r) global = 1;
return true;
}
//=


I was only able to reproduce this behavour on mips toolchains (4.3.2, 4.5.1,
4.6.0) provided by CodeSourcery and own compilation (MinGW32).

gcc -v shows:

Target: mips-sde-elf
Configured with: /scratch/clm/2011.03-sde-lite/src/gcc-4.5-2011.03/configure
--build=i686-pc-linux-gnu --host=i686-mingw32 --target=mips-sde-elf
--enable-threads --disable-libmudflap --disable-libssp --disable-libstdcxx-pch
--with-arch=mips32r2 --enable-sgxx-sde-multilibs --disable-threads
--with-gnu-as --with-gnu-ld --with-specs='%{save-temps: -fverbose-asm}
-D__CS_SOURCERYGXX_MAJ__=2011 -D__CS_SOURCERYGXX_MIN__=3
-D__CS_SOURCERYGXX_REV__=52 %{O2:%{!fno-remove-local-statics:
-fremove-local-statics}} %{O*:%{O|O0|O1|O2|Os:;:%{!fno-remove-local-statics:
-fremove-local-statics}}}' --enable-languages=c,c++ --disable-shared
--enable-lto --with-newlib --with-pkgversion='Sourcery G++ Lite 2011.03-52'
--with-bugurl=https://support.codesourcery.com/GNUToolchain/ --disable-nls
--prefix=/opt/codesourcery --with-headers=yes
--with-sysroot=/opt/codesourcery/mips-sde-elf
--with-build-sysroot=/scratch/clm/2011.03-sde-lite/install/host-i686-mingw32/mips-sde-elf
--with-libiconv-prefix=/scratch/clm/2011.03-sde-lite/obj/host-libs-2011.03-52-mips-sde-elf-i686-mingw32/usr
--with-gmp=/scratch/clm/2011.03-sde-lite/obj/host-libs-2011.03-52-mips-sde-elf-i686-mingw32/usr
--with-mpfr=/scratch/clm/2011.03-sde-lite/obj/host-libs-2011.03-52-mips-sde-elf-i686-mingw32/usr
--with-mpc=/scratch/clm/2011.03-sde-lite/obj/host-libs-2011.03-52-mips-sde-elf-i686-mingw32/usr
--with-ppl=/scratch/clm/2011.03-sde-lite/obj/host-libs-2011.03-52-mips-sde-elf-i686-mingw32/usr
--with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm'
--with-cloog=/scratch/clm/2011.03-sde-lite/obj/host-libs-2011.03-52-mips-sde-elf-i686-mingw32/usr
--with-libelf=/scratch/clm/2011.03-sde-lite/obj/host-libs-2011.03-52-mips-sde-elf-i686-mingw32/usr
--disable-libgomp --enable-poison-system-directories
--with-build-time-tools=/scratch/clm/2011.03-sde-lite/obj/tools-i686-pc-linux-gnu-2011.03-52-mips-sde-elf-i686-mingw32/mips-sde-elf/bin
--with-build-time-tools=/scratch/clm/2011.03-sde-lite/obj/tools-i686-pc-linux-gnu-2011.03-52-mips-sde-elf-i686-mingw32/mips-sde-elf/bin
Thread model: single
gcc version 4.5.2 (Sourcery G++ Lite 2011.03-52)

[Bug tree-optimization/50374] Support vectorization of min/max location pattern

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

  Attachment #25331|0   |1
is obsolete||

--- Comment #16 from Jakub Jelinek  2011-09-21 
16:08:29 UTC ---
Created attachment 25333
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25333
gcc47-pr50374.patch

Updated patch which changes the optab as I mentioned, and adds the testcases
(both original Ira's and two new testcases, one which tries various type
combinations).
Currently on both x86_64 and i686 the big new testcase (-12.c) fails,
apparently some issue with float comparison and unsigned int index, likely a
backend issue, debugging, and -3.c fails with an ICE in the vectorizer, Ira,
could you look at that?  Let's leave the PRE issue for PRE for now, I'll try
tomorrow to adjust ifcvt for the min/max folding.

[Bug tree-optimization/50374] Support vectorization of min/max location pattern

[jakub at gcc dot gnu.org]

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

--- Comment #17 from Jakub Jelinek  2011-09-21 
16:57:08 UTC ---
Seems my reduction patterns just give some extreme's index, but not necessarily
the first or last extreme's index.  It was just narrowing down the index vector
together with the comparison vector the same way, picking the values the
comparison picked.  Seems Ira's patch does the right thing, in particular,
finding the minimum resp. maximum (then at least on i?86 I'll need to broadcast
that value to all vector members as the shifts have zero filled instead of kept
the upper bits as is), then compare that to the original comparison vector
(i.e. get mask where the minimum values were), mask the index vector with that
mask, find the minimum (for *FIRST_LOC*) resp. maximum (for *LAST_LOC*) in the
index vector (for FIRST_LOC ~mask actually needs to be ored in).
I'll fix that up tomorrow.

Now, does the generic vectorizer code ensure that the biv has the right
properties (doesn't wrap in the loop and is strictly increasing)?  And, if it
is signed that it is never negative?

[Bug fortran/50410] [4.6/4.7 Regression] ICE in record_reference

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
 CC||janus at gcc dot gnu.org

--- Comment #5 from janus at gcc dot gnu.org 2011-09-21 16:58:29 UTC ---
(In reply to comment #4)
> The code is invalid and so gfortran can do anything that it
> wishes, including segfault.

Well, no. An ICE on invalid code may not be as bad as an ICE on valid code, but
it's still a bug. gfortran should give a meaningful error message.

[Bug target/50464] Using -Ofast -march=bdver1 results in internal compiler error: in extract_insn, at recog.c:2109

[uros at gcc dot gnu.org]

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

--- Comment #3 from uros at gcc dot gnu.org 2011-09-21 17:37:06 UTC ---
Author: uros
Date: Wed Sep 21 17:37:00 2011
New Revision: 179053

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179053
Log:
PR target/50464
* config/i386/sse.md (xop_pcmov_): Change
operand 1 predicate to register_operand and operand 2 predicate
to nonimmediate_operand.
* config/i386/i386.c (ix86_expand_sse_movcc): When generating
xop_pcmov, force op_true to register.  Also, force op_false to
register if it doesn't satisfy nonimmediate_operand predicate.

testsuite/ChangeLog:

PR target/50464
* g++.dg/other/pr50464.C: New test.


Added:
trunk/gcc/testsuite/g++.dg/other/pr50464.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/config/i386/sse.md
trunk/gcc/testsuite/ChangeLog

[Bug c/50380] cc1 hangs eating 100% CPU

[mikpe at it dot uu.se]

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

Mikael Pettersson  changed:

   What|Removed |Added

 CC||mikpe at it dot uu.se

--- Comment #1 from Mikael Pettersson  2011-09-21 
19:17:10 UTC ---
I can reproduce the cc1-goes-into-a-cpu-consuming loop issue with gcc
4.6-20110916, 4.5-20110915, 4.4.3, 4.3.4, 4.2.4, and 4.1.2, built as crosses to
mips-linux.  However 4.7-20110917 seems to work.  Various native i686-linux gcc
versions also work.  Starting a bisection..

[Bug c++/49152] Unhelpful diagnostic for iterator dereference

[giecrilj at stegny dot 2a.pl]

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

--- Comment #2 from Christopher Yeleighton  
2011-09-21 20:06:42 UTC ---
== Code ==

struct X { int x; }; 
void trigger (X x []) { x [01] = 0; }

== Result (v4.6) ==

doit.cpp:2:34: error: no match for ‘operator=’ in ‘*(x + 4u) = 0’

But who referenced (x + 4u)?

[Bug c++/49152] Unhelpful diagnostic for iterator dereference

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  2011-09-21 
20:16:24 UTC ---
Wow, that one is worthy of its own bug report, it's not just an unclear
diagnostic, it's completely bogus.

x[01] is *(x+1) or *((char*)x + 4) but what G++ prints is just wrong

[Bug c++/49152] Unhelpful diagnostic for iterator dereference

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  2011-09-21 
21:03:37 UTC ---
The common thing in my original example and comment 2 is that when printing "no
match" for a binary operator, the diagnostic machinery tries to "reconstruct"
the left operand, but produces a poor result if that left operand is itself the
result of an operator expression

e.g. in my case *first gets "reconstructed" to first.foo::operator*
(while technically equivalent, noone would write the latter)

in comment 2 x[1] gets "reconstructed" to *(x + 4)
(not even equivalent, the reconstruction has forgotten to divide the offset by
sizeof(*x))

[Bug c++/49152] Unhelpful diagnostic for iterator dereference

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #5 from Manuel López-Ibáñez  2011-09-21 
21:50:21 UTC ---
This is a very old issue, and there are several PRs open already. It is widely
acknowledged that GCC needs to print the input expression instead of
reconstructing it. But this is (very) hard to fix with current GCC design. See
point A) in

http://gcc.gnu.org/wiki/Better_Diagnostics

and the several PRs mentioned there.

Dodji is working on A.0, and it will probably land on 4.7, but nobody else is
working in any other point there. I started working on A.3 but I got totally
discouraged and gave up.

The only short term solution is to stop printing expressions and let the user
check the source by the location. In fact, this is also part of the long-term
solution, because printing whole expressions in diagnostics is just clutter if
those expressions take several lines. The only fix is to implement caret
diagnostics and avoid expressions in diagnostic messages, like clang does. But
who is going to work on that?

[Bug c++/49152] Unhelpful diagnostic for iterator dereference

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  2011-09-21 
23:30:34 UTC ---
Thanks, Manu.  Most of the PRs mentioned on that page are FIXED, and I don't
see specific mention of outputting the types involved in the operation, just
better way of outputting the original source instead of reconstructing it.  In
many cases the types would be more useful than printing the original source
range.

i.e. I'd rather see:

   no match for operator== with operands X& and Y&

than:

   no match for operator== in 'foo == bar'

because whether a suitable operator exists is a property of the variables'
types, not their names.

That might also be easier to implement, since the compiler knows the types. It
doesn't (without a lot of work) know the character range from the original
source file that corresponds to the expression.

Another alternative would be to note when operator notation is used, so that
when *foo is transformed to a call to the member function foo.operator*()
internally, the diagnostic can know to reconstruct it to *foo not
foo.operator*() in diagnostics.
This might only be needed for operators, since I haven't encountered such
serious problems with reconstructing normal function calls such as bar(g), only
for operator notation.

[Bug c/50380] cc1 hangs eating 100% CPU

[mikpe at it dot uu.se]

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

--- Comment #2 from Mikael Pettersson  2011-09-21 
23:30:32 UTC ---
The test case got unbroken on trunk by r176563:

http://gcc.gnu.org/ml/gcc-cvs/2011-07/msg00830.html

[Bug c++/49152] Unhelpful diagnostic for iterator dereference

[manu at gcc dot gnu.org]

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

--- Comment #7 from Manuel López-Ibáñez  2011-09-21 
23:56:25 UTC ---
(In reply to comment #6)
> Thanks, Manu.  Most of the PRs mentioned on that page are FIXED, and I don't

PR 35441 is still broken. In any case, most of the fixes just gave up on
printing a reconstructed expression, and they print something else, for example
'({...})'.

> i.e. I'd rather see:
> 
>no match for operator== with operands X& and Y&
> 
> than:
> 
>no match for operator== in 'foo == bar'
> 
> because whether a suitable operator exists is a property of the variables'
> types, not their names.
> 
> That might also be easier to implement, since the compiler knows the types.

I agree that this would be an improvement, even without clang's selective
typedef unwrapping. But I have some doubts such a patch will be accepted. I was
told in a couple of occasions that I cannot just remove the expression from the
diagnostic and rely on the user to look up the source code location.

[Bug driver/50475] New: [4.7 regression] internal compiler error at passes.c:1730

[jojelino at gmail dot com]

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

 Bug #: 50475
   Summary: [4.7 regression] internal compiler error at
passes.c:1730
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: driver
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jojel...@gmail.com


Created attachment 25334
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25334
preprocessed source

g++ -L/tmp/winsup/i686-pc-cygwin/winsup -L/tmp/winsup/i686-pc-
cygwin/winsup/cygwin -L/tmp/winsup/i686-pc-cygwin/winsup/w32api/lib -isystem
/tmp/winsup/winsup/include -isystem /tmp/winsup/winsup/cygwin/include -isystem
/tmp/winsup/winsup/w32api/include -B/tmp/winsup/i686-pc-cygwin/newlib/ -isystem
/tmp/winsup/i686-pc-cygwin/newlib/targ-include -isystem
/tmp/winsup/newlib/libc/include-c -nostdinc++  -DHAVE_CONFIG_H   -MMD 
-fmerge-constants -ftracer -mno-use-libstdc-wrappers  -DPROFILE -O4 
-mstackrealign -march=core2 -g -mfpmath=sse -g -pg -finstrument-functions -Wall
-Wstrict-aliasing -Wwrite-strings -fno-common -pipe -fbuiltin
-fmessage-length=0  -I.  -I/tmp/winsup/winsup/cygwin 
-I/tmp/winsup/winsup/w32api/include -I../../.././winsup/cygwin/config/i386
-I/usr/lib/gcc/i686-pc-cygwin/4.7.0/include -fno-rtti -fno-exceptions -o
./syscalls.o /tmp/winsup/winsup/cygwin/syscalls.cc -v -save-temps
g++: warning: -pipe ignored because -save-temps specified
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/i686-pc-cygwin/4.7.0/lto-wrapper.exe
Target: i686-pc-cygwin
Configured with: ./configure --config-cache --prefix=/usr
--disable-win32-registry --enable-threads=win32 --enable-languages=c,c++,lto
--with-win32-nlsapi=unicode --enable-tls --disable-bootstrap --enable-shared
--disable-sjlj-exceptions --enable-gomp --enable-cloog-backend=isl :
(reconfigured) ./configure --config-cache --prefix=/usr
--disable-win32-registry --enable-threads=win32 --with-win32-nlsapi=unicode
--enable-tls --disable-bootstrap --enable-shared --disable-sjlj-exceptions
--enable-gomp --enable-cloog-backend=isl --enable-languages=c,c++,lto
--no-create --no-recursion
Thread model: win32
gcc version 4.7.0 20110921 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-L/tmp/winsup/i686-pc-cygwin/winsup'
'-L/tmp/winsup/i686-pc-cygwin/winsup/cygwin'
'-L/tmp/winsup/i686-pc-cygwin/winsup/w32api/lib' '-isystem'
'/tmp/winsup/winsup/include' '-isystem' '/tmp/winsup/winsup/cygwin/include'
'-isystem' '/tmp/winsup/winsup/w32api/include' '-B'
'/tmp/winsup/i686-pc-cygwin/newlib/' '-isystem'
'/tmp/winsup/i686-pc-cygwin/newlib/targ-include' '-isystem'
'/tmp/winsup/newlib/libc/include' '-c' '-nostdinc++' '-D' 'HAVE_CONFIG_H'
'-MMD' '-fmerge-constants' '-ftracer' '-mno-use-libstdc-wrappers' '-D'
'PROFILE' '-O4' '-mstackrealign' '-march=core2' '-g' '-mfpmath=sse' '-g' '-pg'
'-finstrument-functions' '-Wall' '-Wstrict-aliasing' '-Wwrite-strings'
'-fno-common' '-pipe' '-fbuiltin' '-fmessage-length=0' '-I' '.' '-I'
'/tmp/winsup/winsup/cygwin' '-I' '/tmp/winsup/winsup/w32api/include' '-I'
'../../.././winsup/cygwin/config/i386' '-I'
'/usr/lib/gcc/i686-pc-cygwin/4.7.0/include' '-fno-rtti' '-fno-exceptions' '-o'
'./syscalls.o' '-v' '-save-temps' '-shared-libgcc'
 /usr/libexec/gcc/i686-pc-cygwin/4.7.0/cc1plus.exe -E -quiet -nostdinc++ -v -I
. -I /tmp/winsup/winsup/cygwin -I /tmp/winsup/winsup/w32api/include -I
../../.././winsup/cygwin/config/i386 -I
/usr/lib/gcc/i686-pc-cygwin/4.7.0/include -MMD ./syscalls.d -MQ ./syscalls.o
-D__CYGWIN32__ -D__CYGWIN__ -Dunix -D__unix__ -D__unix -idirafter
/usr/lib/gcc/i686-pc-cygwin/4.7.0/../../../../i686-pc-cygwin/lib/../include/w32api
-idirafter
/usr/lib/gcc/i686-pc-cygwin/4.7.0/../../../../i686-pc-cygwin/lib/../../include/w32api
-D HAVE_CONFIG_H -D PROFILE -isystem /tmp/winsup/winsup/include -isystem
/tmp/winsup/winsup/cygwin/include -isystem /tmp/winsup/winsup/w32api/include
-isystem /tmp/winsup/i686-pc-cygwin/newlib/targ-include -isystem
/tmp/winsup/newlib/libc/include /tmp/winsup/winsup/cygwin/syscalls.cc
-mno-use-libstdc-wrappers -mstackrealign -march=core2 -mfpmath=sse -Wall
-Wstrict-aliasing -Wwrite-strings -fmerge-constants -ftracer
-finstrument-functions -fno-common -fbuiltin -fmessage-length=0 -fno-rtti
-fno-exceptions -g -g -fworking-directory -O4 -fpch-preprocess -o syscalls.ii
ignoring nonexis

[Bug c/50476] New: Warn of pointer set to object whose lifetime is limited

[rui.maciel at gmail dot com]

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

 Bug #: 50476
   Summary: Warn of pointer set to object whose lifetime is
limited
Classification: Unclassified
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rui.mac...@gmail.com


Consider the following code:


#include 

int *x = NULL;

void f(void)
{
int y = 1;

x = &y;
}


int main(void)
{
f();

printf("int: %d\n", *x);

return 0;
}



Function f() assigns a global pointer to a local object, so that the global
pointer refers to the local object's address even when the object's lifetime
ends.  This represents undefined behaviour, and therefore can be a potential
source of problems.  It would be great if gcc at least threw a warning
informing the user of this problem, similar to how Bug 14156 handles it's use
case.

[Bug libstdc++/50348] -fvisibility=hidden doesn't hide stl implementation details.

[paolo.carlini at oracle dot com]

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

--- Comment #2 from Paolo Carlini  2011-09-22 
00:29:43 UTC ---
Jason, could you please help me triaging this PR? Should the library do
something else here? Thanks!

[Bug target/48974] VIS intrinsics improvement opportunities

[hp at gcc dot gnu.org]

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

--- Comment #1 from Hans-Peter Nilsson  2011-09-22 
01:25:13 UTC ---
For an example of working around (2), see
.

[Bug c++/50477] New: -Wunused-parameter should not warn about virtual method declarations with bodies

[miles at gnu dot org]

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

 Bug #: 50477
   Summary: -Wunused-parameter should not warn about virtual
method declarations with bodies
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: trivial
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mi...@gnu.org


In the following code:

   struct X { virtual void f (int a) { } };

One gets a warning from -Wunused-parameter, "unused parameter 'a'".

While this is understandable, I think it's undesirable -- clearly the parameter
'a' will often be used by overrides of X::f, and the parameter name 'a' serves
a valuable documentation purpose here, even if it's not strictly required.

The basic problem of course, is that in this case, f is both a virtual method
declaration which covers overriding methods as well, and a definition of X's
definition of it.

One can avoid this by defining X::f outside the class definition, but for
trivial definitions like the above, this would seem like annoying make-work if
done only to shut up -Wunused-parameter.

My current method of avoiding the warning is to comment out the parameter name: 

   virtual void f (int /* a */) { }

but this again seems like an annoying wart, rather than natural code -- it's
both less readable (especially when the parameter has a funny type like a
function pointer) and yields a slightly confusing inconsistency ("why do
comment-out some method parameter names but not others?!" "oh it's just to shut
up -Wunused-parameter... :(").

Anyway, the current behavior seems wrong to me; I think -Wunused-parameter
shoul d stay silent for method virtual definitions inside the class definition.

[If this were a very rare scenario, I suppose I wouldn't care about the need to
work around it, but it seems to happen all the time for me...]

Thanks,

-Miles

[Bug bootstrap/50461] mpfr.h found in mpfr-3.1.0/src instead of mpfr-3.0.1/. as previously

[g...@denis-excoffier.org]

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

--- Comment #1 from Denis Excoffier  2011-09-22 
05:22:47 UTC ---
Also with mpfr-3.1.0-rc2.

[Bug c++/50478] New: Internal compiler error when using initializer lists

[bitti at iki dot fi]

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

 Bug #: 50478
   Summary: Internal compiler error when using initializer lists
Classification: Unclassified
   Product: gcc
   Version: 4.6.1
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bi...@iki.fi


The following short program shows the problem:

#include 
#include 

int main() {
std::set s;
s.insert( {"abc", "def", "hij"} ); // This line is the problem
}

> g++ -std=c++0x test.cc
test.cc: In function ‘int main()’:
test.cc:6:37: internal compiler error: in joust, at cp/call.c:7646

If I compile with -pedantic, the program compiles fine.

[Bug target/47855] missed cbnz optimization

[jye2 at gcc dot gnu.org]

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

--- Comment #4 from jye2 at gcc dot gnu.org 2011-09-22 06:41:49 UTC ---
Author: jye2
Date: Thu Sep 22 06:41:44 2011
New Revision: 179077

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179077
Log:
2011-09-22  Joey Ye  

Backport r178852 from mainline
2011-09-14  Julian Brown  

* config/arm/arm.c (arm_override_options): Add unaligned_access
support.
(arm_file_start): Emit attribute for unaligned access as appropriate.
* config/arm/arm.md (UNSPEC_UNALIGNED_LOAD)
(UNSPEC_UNALIGNED_STORE): Add constants for unspecs.
(insv, extzv): Add unaligned-access support.
(extv): Change to expander. Likewise.
(extzv_t1, extv_regsi): Add helpers.
(unaligned_loadsi, unaligned_loadhis, unaligned_loadhiu)
(unaligned_storesi, unaligned_storehi): New.
(*extv_reg): New (previous extv implementation).
* config/arm/arm.opt (munaligned_access): Add option.
* config/arm/constraints.md (Uw): New constraint.
* expmed.c (store_bit_field_1): Adjust bitfield numbering according
to size of access, not size of unit, when BITS_BIG_ENDIAN !=
BYTES_BIG_ENDIAN. Don't use bitfield accesses for
volatile accesses when -fstrict-volatile-bitfields is in effect.
(extract_bit_field_1): Likewise.

Backport r172697 from mainline
2011-04-19  Wei Guozhi  

PR target/47855
* config/arm/arm-protos.h (thumb1_legitimate_address_p): New prototype.
* config/arm/arm.c (thumb1_legitimate_address_p): Remove the static
linkage.
* config/arm/constraints.md (Uu): New constraint.
* config/arm/arm.md (*arm_movqi_insn): Compute attr "length".

Modified:
branches/ARM/embedded-4_6-branch/gcc/ChangeLog.arm
branches/ARM/embedded-4_6-branch/gcc/config/arm/arm-protos.h
branches/ARM/embedded-4_6-branch/gcc/config/arm/arm.c
branches/ARM/embedded-4_6-branch/gcc/config/arm/arm.md
branches/ARM/embedded-4_6-branch/gcc/config/arm/arm.opt
branches/ARM/embedded-4_6-branch/gcc/config/arm/constraints.md
branches/ARM/embedded-4_6-branch/gcc/expmed.c