[Bug fortran/50585] New: ICE with assumed length character array argument

[sgm at objexx dot com]

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

 Bug #: 50585
   Summary: ICE with assumed length character array argument
Classification: Unclassified
   Product: gcc
   Version: 4.6.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: s...@objexx.com


Compiling these 2 routines in the same source file with gfortran -c

  SUBROUTINE SUB1( str )
  IMPLICIT NONE
  CHARACTER(len=*) :: str(2)
  CALL SUB2( str(1)(:3) )
  END SUBROUTINE SUB1

  SUBROUTINE SUB2( str )
  IMPLICIT NONE
  CHARACTER(*) :: str
  END SUBROUTINE SUB2

gives this ICE:

f951: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

with gfortran 4.6.1 on Fedora 15 (x64) and with MinGW on Win32.

The problem was also observed on 4.6.0 on Fedora 15 but was not seen on 4.5.x.

The ICE does not occur if any of these are true:
 -fno-whole-file is used
 The routines are in separate files 
 The str array is changed to a scalar
 The str length is changed to a constant

[Bug c++/36778] [feature request] -Wfatal-warnings

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC|gcc-bugs at gcc dot gnu.org |
 Resolution||INVALID

--- Comment #1 from Paolo Carlini  2011-10-01 
09:18:32 UTC ---
Seems unnecessary, see: http://gcc.gnu.org/ml/gcc/2011-10/msg1.html

[Bug c++/50586] New: Template argument of type "pointer to function" of a template class causes usage error if template is instantiated with pointer-to-private-static-member-function

[mouchtaris at gmail dot com]

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

 Bug #: 50586
   Summary: Template argument of type "pointer to function" of a
template class causes usage error if template is
instantiated with
pointer-to-private-static-member-function
Classification: Unclassified
   Product: gcc
   Version: 4.6.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mouchta...@gmail.com


Created attachment 25390
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25390
A small test file exhibiting the error.

If there is a declared template class, which accepts a pointer-to-function as a
non-type template parameter:

//
template 
struct caller
  { int operator () (void) const { return (*f)(); } };
//

and is instantiated in a class with a pointer to a private static member
function:

//
class A {
  static int f (void) { return 0; }
public:
  caller<&f> get;
};
//

then G++ reports that "f" is private when used in the context of
caller::operator().

I haven't found anything in the standard that would impose this restriction.

(As a cue, this was reported as an error as well in older version of the vc
compiler, but in version 16.00 it is not an error any more)

I am attaching a small test file. I am not attaching any preprocessed file, as
there is no need. No preprocessor directives are used in this test.

I hope this has not been dealt before.

- Detailed information ---

*** Compiler version: ***
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/spare/root/libexec/gcc/i686-pc-linux-gnu/4.6.1/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.6.1/configure --prefix=/spare/root
Thread model: posix
gcc version 4.6.1 (GCC)


*** Compilation command: ***
g++ -ansi -pedantic -Wall -Wextra t.cpp


*** Compiler output: ***
t.cpp: In member function 'int caller::operator()() const [with int (* f)()
= A::f]':
t.cpp:26:   instantiated from here
t.cpp:13: error: 'static int A::f()' is private
t.cpp:5: error: within this context

[Bug fortran/50585] [4.6/4.7 Regression] ICE with assumed length character array argument

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 CC||janus at gcc dot gnu.org
  Known to work||4.5.3
Summary|ICE with assumed length |[4.6/4.7 Regression] ICE
   |character array argument|with assumed length
   ||character array argument
  Known to fail||4.6.1, 4.7.0

--- Comment #1 from janus at gcc dot gnu.org 2011-10-01 09:55:59 UTC ---
This is a regression: Works with 4.5, but fails with 4.6 and trunk.

[Bug fortran/50585] [4.6/4.7 Regression] ICE with assumed length character array argument

[janus at gcc dot gnu.org]

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

--- Comment #2 from janus at gcc dot gnu.org 2011-10-01 10:03:33 UTC ---
Backtrace:

Program received signal SIGSEGV, Segmentation fault.
0x004e1f73 in get_expr_storage_size (e=0x1bc4940) at
/home/jweil/gcc47/trunk/gcc/fortran/interface.c:1963
1963  || ref->u.ss.length->length->expr_type !=
EXPR_CONSTANT)
(gdb) bt
#0  0x004e1f73 in get_expr_storage_size (e=0x1bc4940) at
/home/jweil/gcc47/trunk/gcc/fortran/interface.c:1963
#1  0x004e2dbf in compare_actual_formal (ap=0x1bc4fc0,
formal=0x1bc48a0, ranks_must_agree=0, is_elemental=0, where=0x1bc4f58)
at /home/jweil/gcc47/trunk/gcc/fortran/interface.c:2248
#2  0x004e46ff in gfc_procedure_use (sym=0x1bc5a10, ap=0x1bc4fc0,
where=0x1bc4f58) at /home/jweil/gcc47/trunk/gcc/fortran/interface.c:2877
#3  0x005365a0 in resolve_global_procedure (sym=0x1bc45e0,
where=0x1bc4f58, actual=0x1bc4fc0, sub=)
at /home/jweil/gcc47/trunk/gcc/fortran/resolve.c:2254
#4  0x0053e3f8 in resolve_call (c=0x1bc4f40) at
/home/jweil/gcc47/trunk/gcc/fortran/resolve.c:3656
#5  0x00542a31 in resolve_code (code=0x1bc4f40, ns=) at
/home/jweil/gcc47/trunk/gcc/fortran/resolve.c:9310
#6  0x00544c7d in resolve_codes (ns=0x1bc3210) at
/home/jweil/gcc47/trunk/gcc/fortran/resolve.c:13658
#7  0x0053617c in gfc_resolve (ns=0x1bc3210) at
/home/jweil/gcc47/trunk/gcc/fortran/resolve.c:13685
#8  0x00529ebf in resolve_all_program_units
(gfc_global_ns_list=0x1bc3210) at
/home/jweil/gcc47/trunk/gcc/fortran/parse.c:4336
#9  0x0052a6b7 in gfc_parse_file () at
/home/jweil/gcc47/trunk/gcc/fortran/parse.c:4602
#10 0x00567c1b in gfc_be_parse_file () at
/home/jweil/gcc47/trunk/gcc/fortran/f95-lang.c:250
#11 0x00b5b2fc in compile_file () at
/home/jweil/gcc47/trunk/gcc/toplev.c:565
#12 0x00b5d5b5 in do_compile () at
/home/jweil/gcc47/trunk/gcc/toplev.c:1925
#13 0x00b5d72c in toplev_main (argc=2, argv=0x7fffddc8) at
/home/jweil/gcc47/trunk/gcc/toplev.c:2001
#14 0x0061e71c in main (argc=2, argv=0x7fffddc8) at
/home/jweil/gcc47/trunk/gcc/main.c:36


The problem is:

(gdb) p ref->u.ss.length->length
$3 = (struct gfc_expr *) 0x0

[Bug fortran/50585] [4.6/4.7 Regression] ICE with assumed length character array argument

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011-10-01
 Ever Confirmed|0   |1

--- Comment #3 from janus at gcc dot gnu.org 2011-10-01 10:09:56 UTC ---
Simple fix:

Index: gcc/fortran/interface.c
===
--- gcc/fortran/interface.c (revision 179412)
+++ gcc/fortran/interface.c (working copy)
@@ -1959,7 +1959,7 @@
{
  /* The string length is the substring length.
 Set now to full string length.  */
- if (ref->u.ss.length == NULL
+ if (!ref->u.ss.length || !ref->u.ss.length->length
  || ref->u.ss.length->length->expr_type != EXPR_CONSTANT)
return 0;

[Bug fortran/50585] [4.6/4.7 Regression] ICE with assumed length character array argument

[dominiq at lps dot ens.fr]

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

--- Comment #4 from Dominique d'Humieres  2011-10-01 
10:15:31 UTC ---
> This is a regression: Works with 4.5, but fails with 4.6 and trunk.

4.5 gives a segmentation fault with  -fwhole-file (4.4 does not accept this
option).

[Bug fortran/50585] [4.6/4.7 Regression] ICE with assumed length character array argument

[janus at gcc dot gnu.org]

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

--- Comment #5 from janus at gcc dot gnu.org 2011-10-01 10:24:42 UTC ---
(In reply to comment #4)
> 4.5 gives a segmentation fault with  -fwhole-file (4.4 does not accept this
> option).

Well, then one can even argue that it's a regression in 4.5, too.

IIRC, -fwhole-file is default since 4.6, right? However, if this is true, it is
not documented in the manual:

http://gcc.gnu.org/onlinedocs/gcc-4.6.1/gfortran/Code-Gen-Options.html#Code-Gen-Options

[Bug middle-end/50569] Wrong code error: memcpy eliminated when it is needed

[mikpe at it dot uu.se]

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

--- Comment #6 from Mikael Pettersson  2011-10-01 
10:29:07 UTC ---
This test case fails with a SIGBUS on sparc64-linux when compiled with -O1 -m32
by gcc 4.6-20110923 or 4.7-20110910.  gcc 4.5 and 4.4 generate correct code.

[Bug c/50581] stdarg doesn't support array types

[Wolfgang at Solfrank dot net]

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

--- Comment #2 from Wolfgang at Solfrank dot net 2011-10-01 11:06:48 UTC ---
(In reply to comment #1)

Sorry, I don't quite follow you:

> There is no possible valid use of passing arrays to va_arg.

What makes you think so?  While the 1003.1 definition of va_arg explicitly
specifies that the behaviour when passing a type to va_arg that "is not
compatible with the type of the actual next argument (as promoted according to
the default argument promotions)" is undefined, that doesn't preclude to
implement something reasonable, does it?

> In C90, it is technically possible to use va_arg in this case without 
> undefined behavior.  The argument passed to the function would have to be 
> a non-lvalue array - for example, an array in a structure returned from 
> another function.  The result of va_arg would itself be a non-lvalue 
> array, which it is not possible to convert to a pointer, so it is not 
> possible to access the values in the array in any way; all that can be 
> done is to discard the value (call va_arg for its side effects) or to pass 
> it to another variadic function.

Well, I'm not sure that I buy that.  But even then, the current implementation
in gcc doesn't generate the correct code even only for the side effects.  The
generated code in fact assumes that the array is passed by value, i.e. the
pointer into the argument list (or something equivalent) is incremented by the
size of the array instead of the size of a pointer.

My main use case for this feature isn't with random arrays, but with va_list
itself.  On some architectures (AFAIK all architectures that pass some
arguments in registers) gcc implements va_list as a one element array of some
structure.  Without my proposed change, it isn't possible to have a va_list as
an argument to a variadic function.  This is what my second example in the bug
report was about.  To show it in a somewhat more real live example, let's
assume that vprintf implemented such a feature, something like (using %^ to
mean the next two arguments are a format string and a va_list):
---
#include 

int
vprintf(char *fmt, va_list ap)
{
char *fmt1;
va_list ap1;

while (*fmt)
if (*fmt == '%')
switch (*++fmt) {
case '^':
fmt1 = va_arg(ap, char *);
va_copy(ap1, va_arg(ap, va_list));
vprintf(fmt1, ap1);
va_end(ap1);
break;

}
...
}
---
With current gcc, code like this works as expected on processors that implement
va_list as a pointer into the parameter list passed on the stack, but doesn't
work for processors passing arguments in registers therefor implement va_list
as thje above mentioned one element array.

Even if I buy your arguments, I consider it a bug that while with -std=c89 the
compiler spits an error message, but with -std=c99 it silently generates
incorrect code.

[Bug fortran/50585] [4.6/4.7 Regression] ICE with assumed length character array argument

[janus at gcc dot gnu.org]

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

--- Comment #6 from janus at gcc dot gnu.org 2011-10-01 11:24:46 UTC ---
(In reply to comment #5)
> IIRC, -fwhole-file is default since 4.6, right? However, if this is true, it 
> is
> not documented in the manual:
> 
> http://gcc.gnu.org/onlinedocs/gcc-4.6.1/gfortran/Code-Gen-Options.html#Code-Gen-Options

Apparently I do remember correctly, as http://gcc.gnu.org/gcc-4.6/changes.html
confirms.


Also the patch in comment #3 regtests cleanly. Will commit as obvious.

[Bug fortran/50585] [4.6/4.7 Regression] ICE with assumed length character array argument

[janus at gcc dot gnu.org]

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

--- Comment #7 from janus at gcc dot gnu.org 2011-10-01 11:41:49 UTC ---
Author: janus
Date: Sat Oct  1 11:41:41 2011
New Revision: 179413

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179413
Log:
2011-10-01  Janus Weil  

PR fortran/50585
* interface.c (get_expr_storage_size): Check if 'length' component is
associated.


2011-10-01  Janus Weil  

PR fortran/50585
* gfortran.dg/assumed_charlen_arg_2.f90: New.

Added:
trunk/gcc/testsuite/gfortran.dg/assumed_charlen_arg_2.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/interface.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/50585] [4.6/4.7 Regression] ICE with assumed length character array argument

[janus at gcc dot gnu.org]

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

--- Comment #8 from janus at gcc dot gnu.org 2011-10-01 12:13:04 UTC ---
Fixed on trunk with r179413. Backport to 4.6 (and 4.5?) pending ...

[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO

[hubicka at gcc dot gnu.org]

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

--- Comment #114 from Jan Hubicka  2011-10-01 
13:18:30 UTC ---
So quick summary
 1) -g build is still blocked by dwarf2out ICE
 2) build with gold works, but only without -fprofile-generate. FDO build is
also possible, but -fprofile-generate needs -fno-lto (that makes a lot of
sense, but we still should fix the bug at GCC side)
 3) With GNU LD, there is still bug that blocks Mozilla LTO
http://sourceware.org/bugzilla/show_bug.cgi?id=13244
 4) Slim LTO works well. Build times are about the same as for non-LTO. One
needs the aforementioned configure hacks and ar/nm/ranlib wrappers.

Honza

[Bug c/50581] stdarg doesn't support array types

[joseph at codesourcery dot com]

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

--- Comment #3 from joseph at codesourcery dot com  2011-10-01 14:07:42 UTC ---
On Sat, 1 Oct 2011, Wolfgang at Solfrank dot net wrote:

> > There is no possible valid use of passing arrays to va_arg.
> 
> What makes you think so?  While the 1003.1 definition of va_arg explicitly

That the C semantics mean that:

* for C90 it is impossible to access values in the non-lvalue array passed 
(the existence of the possibility of passing an array by value to a 
variadic function in C90 is one of the most obscure and useless C 
standards corner cases there is);

* for C99, calling va_arg with such a type always results in undefined 
behavior at runtime because a pointer will have been passed rather than an 
array.

So no valid C program can ever actually access a value in this way.  Of 
course, if you tried to pass an *lvalue* array (the normal case for arrays 
in C) then it was converted to a pointer rather than passed by value, for 
both C90 and C99, and so you had undefined behavior at runtime, for both 
C90 and C99.

If you want to access a pointer, you need to pass a pointer type to 
va_arg.  This is just like accessing a promoted float or char where you 
need to specify "double" or "int".  Which is why generating an abort with 
a warning at compile time seems appropriate - it's the well-established 
practice for "char" and "float" here.  (Given the obscurity, there should 
probably be a warning for C90 as well, but without the abort.)

> > In C90, it is technically possible to use va_arg in this case without 
> > undefined behavior.  The argument passed to the function would have to be 
> > a non-lvalue array - for example, an array in a structure returned from 
> > another function.  The result of va_arg would itself be a non-lvalue 
> > array, which it is not possible to convert to a pointer, so it is not 
> > possible to access the values in the array in any way; all that can be 
> > done is to discard the value (call va_arg for its side effects) or to pass 
> > it to another variadic function.
> 
> Well, I'm not sure that I buy that.  But even then, the current implementation
> in gcc doesn't generate the correct code even only for the side effects.  The
> generated code in fact assumes that the array is passed by value, i.e. the
> pointer into the argument list (or something equivalent) is incremented by the
> size of the array instead of the size of a pointer.

Here is an example program that is valid as C90 but not as C99.  It passes 
for me with all the C90 options I tried.  That is, the caller and callee 
are consistent about the space expected to be taken by the array on the 
stack, which is all that's required since there is no way of accessing the 
array's value.  (C ABIs won't generally specify this for interoperation 
between implementations, given that passing by value an array whose value 
you can't access isn't useful and the possibility of doing so has 
disappeared in C99.)

#include 

extern void abort (void);
extern void exit (int);

typedef char array[1];
struct s { array a; } x;
void g (int a, ...);

int
main (void)
{
  g (0, (0, x).a, 1234);
  exit (0);
}

void
g (int a, ...)
{
  va_list ap;
  va_start (ap, a);
  va_arg (ap, array);
  if (va_arg (ap, int) != 1234)
abort ();
  va_end (ap);
}

> My main use case for this feature isn't with random arrays, but with va_list
> itself.  On some architectures (AFAIK all architectures that pass some
> arguments in registers) gcc implements va_list as a one element array of some
> structure.  Without my proposed change, it isn't possible to have a va_list as
> an argument to a variadic function.  This is what my second example in the bug

Passing va_list as a function argument is generally hard, whether or not 
variadic, since you don't know whether it will be passed by reference or 
by value or what the type of the address of a va_list parameter will be.  
Portable code needs to pass a pointer to va_list or a structure containing 
va_list or use some other such means of avoiding dependence on whether 
va_list is an array.

[Bug tree-optimization/50587] New: ICE init_range_entry, at tree-ssa-reassoc.c:1698 caused by recent change

[andi-gcc at firstfloor dot org]

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

 Bug #: 50587
   Summary: ICE init_range_entry, at tree-ssa-reassoc.c:1698
caused by recent change
Classification: Unclassified
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: andi-...@firstfloor.org


Jakub, your recent change

PR tree-optimization/46309
* fold-const.c (make_range, merge_ranges): Remove prototypes.
(make_range_step): New function.
(make_range): Use it.
* tree.h (make_range_step): New prototypes.
* Makefile.in (tree-ssa-reassoc.o): Depend on $(DIAGNOSTIC_CORE_H).
* tree-ssa-reassoc.c: Include diagnostic-core.h.
(struct range_entry): New type.
(init_range_entry, range_entry_cmp, update_range_test,
optimize_range_tests): New functions.
(reassociate_bb): Call optimize_range_tests.

* gcc.dg/pr46309.c: New test.

breaks my LTO kernel builds.

I get a lot of

internal compiler error: in init_range_entry, at tree-ssa-reassoc.c:1698

in different files. With the patch reverted things are fine

[Bug c/50581] stdarg doesn't support array types

[Wolfgang at Solfrank dot net]

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

--- Comment #4 from Wolfgang at Solfrank dot net 2011-10-01 14:43:32 UTC ---
(In reply to comment #3)

Thanks for the insight regarding passing arrays by value in C90, I wasn't even
aware of that.

However:

> Passing va_list as a function argument is generally hard, whether or not 
> variadic, since you don't know whether it will be passed by reference or 
> by value or what the type of the address of a va_list parameter will be.  
> Portable code needs to pass a pointer to va_list or a structure containing 
> va_list or use some other such means of avoiding dependence on whether 
> va_list is an array.

Huh?  What about vprintf and friends?  They are defined to take a va_list as
their last parameter.

[Bug debug/50279] [4.7 Regression] ICE while building the go front-end with LTO enabled

[jpfoley2 at verizon dot net]

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

--- Comment #5 from Peter Foley  2011-10-01 
14:59:16 UTC ---
I still get this with fc393cf

/root/gcc/lto/./prev-gcc/g++ -B/root/gcc/lto/./prev-gcc/
-B/usr/local/x86_64-unknown-linux-gnu/bin/ -nostdinc++
-B/root/gcc/lto/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs
-B/root/gcc/lto/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
-I/root/gcc/lto/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu
-I/root/gcc/lto/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include
-I/root/gcc/libstdc++-v3/libsupc++
-L/root/gcc/lto/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs
-L/root/gcc/lto/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs   -g
-O2 -flto=jobserver -frandom-seed=1 -DIN_GCC   -W -Wall -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common 
-DHAVE_CONFIG_H -static-libstdc++ -static-libgcc  -o go1 \
  go/ast-dump.o go/dataflow.o go/export.o go/expressions.o go/go-backend.o
go/go-dump.o go/go-gcc.o go/go-lang.o go/go-optimize.o go/go.o go/gogo-tree.o
go/gogo.o go/import.o go/import-archive.o go/lex.o go/parse.o go/runtime.o
go/statements.o go/types.o go/unsafe.o attribs.o main.o tree-browser.o
libbackend.a libcommon-target.a libcommon.a ../libcpp/libcpp.a
../libdecnumber/libdecnumber.a libcommon.a ../libcpp/libcpp.a  
../libiberty/libiberty.a ../libdecnumber/libdecnumber.a   -lppl_c -lppl 
-lgmpxx -lmpc -lmpfr -lgmp -rdynamic -ldl  -L../zlib -lz
In member function '_M_insert_aux':
lto1: internal compiler error: in splice_child_die, at dwarf2out.c:5007
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[4]: *** [/tmp/ccOGb3DK.ltrans2.ltrans.o] Error 1
lto-wrapper: make returned 2 exit status
/usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/../../../../x86_64-pc-linux-gnu/bin/ld:
lto-wrapper failed
collect2: error: ld returned 1 exit status
make[3]: *** [go1] Error 1

[Bug c++/50586] Template argument of type "pointer to function" of a template class causes usage error if template is instantiated with pointer-to-private-static-member-function

[daniel.kruegler at googlemail dot com]

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

Daniel Krügler  changed:

   What|Removed |Added

 CC||daniel.kruegler at
   ||googlemail dot com

--- Comment #1 from Daniel Krügler  
2011-10-01 15:18:04 UTC ---
The problem also occurs with gcc 4.7.0 20110924 (experimental)

[Bug target/36798] internal compiler error: in arm_expand_binop_builtin, at config/arm/arm.c:12548

[mattst88 at gmail dot com]

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

Matt Turner  changed:

   What|Removed |Added

 CC||mattst88 at gmail dot com

--- Comment #8 from Matt Turner  2011-10-01 15:24:46 
UTC ---
This is a duplicate of bug 35294.

[Bug target/35294] iwmmxt intrinsics, internal compiler error

[mattst88 at gmail dot com]

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

--- Comment #14 from Matt Turner  2011-10-01 
15:26:10 UTC ---
Created attachment 25391
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25391
[PATCH] Wire-up missing ARM iwmmxt intrinsics

Fixes it for me for gcc-4.6.1. Allows me to build an iwmmxt-optimized pixman
using the standard _mm_* intrinsics.

[Bug target/36966] arm iwmmxt builtin problem

[mattst88 at gmail dot com]

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

--- Comment #4 from Matt Turner  2011-10-01 15:24:57 
UTC ---
This is a duplicate of bug 35294.

[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO

[hubicka at gcc dot gnu.org]

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

--- Comment #115 from Jan Hubicka  2011-10-01 
15:28:46 UTC ---
OK the same errors also happens with GNU LD build
http://sourceware.org/bugzilla/show_bug.cgi?id=13244
https://bugzilla.mozilla.org/show_bug.cgi?id=691053

I will analyze what happens with -fprofile-generate and gold but I bet it all
fails because we now take address of the constructor and consequentely the
constructor is exported out of libxul, but visibilities are wrong.

Honza

[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO

[hubicka at gcc dot gnu.org]

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

--- Comment #116 from Jan Hubicka  2011-10-01 
15:52:51 UTC ---
Solving http://sourceware.org/bugzilla/show_bug.cgi?id=13245
should make that linker error with -flto -fprofile-generate to go away.

[Bug c/50581] stdarg doesn't support array types

[joseph at codesourcery dot com]

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

--- Comment #5 from joseph at codesourcery dot com  2011-10-01 18:45:43 UTC ---
On Sat, 1 Oct 2011, Wolfgang at Solfrank dot net wrote:

> > Passing va_list as a function argument is generally hard, whether or not 
> > variadic, since you don't know whether it will be passed by reference or 
> > by value or what the type of the address of a va_list parameter will be.  
> > Portable code needs to pass a pointer to va_list or a structure containing 
> > va_list or use some other such means of avoiding dependence on whether 
> > va_list is an array.
> 
> Huh?  What about vprintf and friends?  They are defined to take a va_list as
> their last parameter.

There are some things you can do - for example, calling those functions in 
accordance with the rules given in the C standard.  There are various 
things that cause problems - for example, taking the address of a 
parameter declared as a va_list (because the parameter type may have been 
changed from va_list to pointer-to-element-of-va_list as part of the 
parameter type adjustment of parameters declared as arrays, so the type of 
¶meter may not be va_list *).

[Bug gcov-profile/45890] Coverage may be weakened by r164986

[singhai at gcc dot gnu.org]

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

--- Comment #1 from Sharad Singhai  2011-10-01 
19:39:32 UTC ---
Created attachment 25392
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25392
tar of source and coverage files

[Bug gcov-profile/45890] Coverage may be weakened by r164986

[singhai at gcc dot gnu.org]

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

--- Comment #2 from Sharad Singhai  2011-10-01 
19:42:48 UTC ---
I don't know if it is related. But the coverage is imprecise in case of
attached source file foo.c. Build it with O2, as 

gcc --coverage -O2 foo.c
./a.out
gcov -b foo.c

Now the coverage data for the 'if' condition in 'sum' looks like this:
(in attached file foo.c.gcov)

   8:8:if (v[i]) total += 1;
branch  0 never executed
branch  1 never executed
branch  2 taken 75% (fallthrough)
branch  3 taken 25%

Thus a simple two-way conditional looks like a four-way branch. It is due to
early inlining of 'sum' into 'main where a couple of bb's get eliminated/merged
so  that the branch coverage incorrectly gets attributed to the conditional.
Similarly the coverage data for the for-loop in 'sum' looks like this

   9:7:  for (i = 0; i < N; ++i) {
branch  0 never executed
branch  1 never executed
branch  2 taken 89%
branch  3 taken 11% (fallthrough)

After disabling early inlining, the coverage data looks saner. (Attached in
foo.c.gcov.no-early-inlining.)

gcc --coverage -O2 -fno-early-inlining foo.c
./a.out
gcov -b foo.c

Adding the following patch mitigates the issue.

2011-09-30   Sharad Singhai  

   * gcc.c (cc1_options): Added -fno-early-inlining for coverage.

Index: gcc.c
===
--- gcc.c   (revision 179402)
+++ gcc.c   (working copy)
@@ -776,7 +776,7 @@
 %{!fsyntax-only:%{S:%W{o*}%{!o*:-o %b.s}}}\
 %{fsyntax-only:-o %j} %{-param*}\
 %{fmudflap|fmudflapth:-fno-builtin -fno-merge-constants}\
- %{coverage:-fprofile-arcs -ftest-coverage}";
+ %{coverage:-fprofile-arcs -ftest-coverage -fno-early-inlining}";

 /* If an assembler wrapper is used to invoke post-assembly tools
   like MAO, --save-temps need to be passed to save the output of

[Bug middle-end/50565] [4.5/4.6/4.7 Regression] initializer element is not computable at load time

[mikpe at it dot uu.se]

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

Mikael Pettersson  changed:

   What|Removed |Added

 CC||mikpe at it dot uu.se

--- Comment #2 from Mikael Pettersson  2011-10-01 
20:36:57 UTC ---
This test case started being rejected with r145254:
http://gcc.gnu.org/ml/gcc-cvs/2009-03/msg00761.html

[Bug c++/50586] Template argument of type "pointer to function" of a template class causes usage error if template is instantiated with pointer-to-private-static-member-function

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011-10-01
 CC|mouchtaris at gmail dot com |
 Ever Confirmed|0   |1

--- Comment #2 from Paolo Carlini  2011-10-01 
22:33:38 UTC ---
Confirmed of course. Doesn't seem a regression.

[Bug c++/30205] RFE: g++ --unmangle

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC|gcc-bugs at gcc dot gnu.org |
 Resolution||INVALID

--- Comment #4 from Paolo Carlini  2011-10-01 
22:58:39 UTC ---
So closing as invalid, right?

[Bug c++/38020] Undiagnosed const violation in pointer conversion in CRTP context.

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC|gcc-bugs at gcc dot gnu.org |paolo.carlini at oracle dot
   ||com
 Resolution||FIXED

--- Comment #2 from Paolo Carlini  2011-10-01 
23:37:06 UTC ---
Fixed in 4.6.x.