[Bug fortran/48448] Implement -f(no-)frontend-optimization

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011.04.05 07:11:33
 AssignedTo|unassigned at gcc dot   |tkoenig at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

--- Comment #1 from Thomas Koenig  2011-04-05 
07:11:33 UTC ---
Working on this.

[Bug lto/48447] LTO link fails to link libgcc correctly when -nostdlib option is specified

[d.g.gorbachev at gmail dot com]

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

Dmitry Gorbachev  changed:

   What|Removed |Added

 CC||davek at gcc dot gnu.org

--- Comment #1 from Dmitry Gorbachev  
2011-04-05 07:13:35 UTC ---
I believe it's a linker bug. I can reproduce it with analogous testcase on
i686-pc-linux-gnu. It fails only with BFD ld. Works with:
1) Gold;
2) BFD ld from Hongjiu Lu's lto-mixed branch
;
3) BFD ld with Dave Korn's experimental patch
.

[Bug c++/48453] New: [C++0x] Invalid reference initialization via explicit conversion

[daniel.kruegler at googlemail dot com]

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

   Summary: [C++0x] Invalid reference initialization via explicit
conversion
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: daniel.krueg...@googlemail.com
CC: ja...@redhat.com


GCC 4.7.0 accepts the following code in C++0x mode:

template
T&& create();

template
void test() {
 T t(create());
 (void) t;
}

template
struct To {
 explicit operator T();
};

int main()
{
 test>(); // a Well-formed
 test>(); // b Well-formed
}

This code should be ill-formed because of the *explicit* conversion to a
reference type. 

The semantics of this program is described in 8.5.3 [dcl.init.ref] p. 5
(referring to WD N3242). In case of (a) we first inter into bullet 1 ("If the
reference is an lvalue reference"). Sub-bullet 1 does not apply, then we have
to inspect sub-bullet 2:

"has a class type (i.e., T2 is a class type), where T1 is not reference-related
to T2, and can be implicitly converted to an lvalue of type “cv3 T3,” where
“cv1 T1” is reference-compatible with “cv3 T3”106 (this conversion is selected
by enumerating the applicable conversion functions (13.3.1.6) and choosing the
best one through overload resolution (13.3)),"

This *seems* to fit, except that there is no *implicit* conversion possible
here, so we cannot enter this rule. For (a) bullet 2 does not apply and we must
fail immediately.

For (b) we ignore bullet 1, but step into bullet 2 because of the
rvalue-reference. Again, sub-bullet 1 does not apply, only sub-bullet 2 comes
near:

"has a class type (i.e., T2 is a class type), where T1 is not reference-related
to T2, and can be implicitly converted to an xvalue, class prvalue, or function
lvalue of type “cv3 T3”, where “cv1 T1” is reference-compatible with “cv3 T3”,"

Again, we have *no* implicit conversion, but now we need to try the last
sub-bullet 3:

"Otherwise, a temporary of type “cv1 T1” is created and initialized from the
initializer expression using the rules for a non-reference copy-initialization
(8.5). [..]"

The semantics of a non-reference copy-initialization forbids the consideration
of the explicit conversion function, thus, we should fail again.

[Bug rtl-optimization/48455] New: Huge code size regression for all ARM configurations

[rearnsha at gcc dot gnu.org]

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

   Summary: Huge code size regression for all ARM configurations
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rearn...@gcc.gnu.org


SVN rev 171649 has caused huge code size (>3%) regressions on ARM, particularly
when compiling for Thumb2 or when using VFP.  This is equivalent to reversing
all the improvements of the last 2 years.

How to reproduce

Use the CSiBE benchmark. (ttp://www.inf.u-szeged.hu/csibe/)

[Bug target/48454] New: gfortran.dg/char_result_13.f90 fails with -O3 -funroll-loops -mvectorize-with-neon-quad

[irar at il dot ibm.com]

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

   Summary: gfortran.dg/char_result_13.f90 fails with -O3
-funroll-loops -mvectorize-with-neon-quad
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: i...@il.ibm.com
  Host: arm-linux-gnueabi
Target: arm-linux-gnueabi
 Build: arm-linux-gnueabi


The error message:

/tmp/ccJ4gZxY.s: Assembler messages:
/tmp/ccJ4gZxY.s:635: Error: invalid constant (40c) after fixup


There is no failure with doubleword vectors or without -funroll-loops.

[Bug fortran/48456] New: [4.6/4.7 Regression] ICE in fold_binary_loc, at fold-const.c:9324

[burnus at gcc dot gnu.org]

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

   Summary: [4.6/4.7 Regression] ICE in fold_binary_loc, at
fold-const.c:9324
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bur...@gcc.gnu.org


Created attachment 23880
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23880
Test case

Reported by Douglas Foulds at
http://gcc.gnu.org/ml/fortran/2011-04/msg00033.html

Said to fail (on Windows/MinGW) with:
  4.6.0 20110214 (experimental) [trunk revision 170140]
said to work with:
  4.6.0 20101027 (experimental) [trunk revision 166022]

Fails also with the current 4.7 trunk (on x86-64-linux).


The attached program fails with:

test.f90: In function ‘print_after_transfer’:
test.f90:99:0: internal compiler error: in fold_binary_loc, at
fold-const.c:9324

[Bug fortran/48456] [4.6/4.7 Regression] ICE in fold_binary_loc, at fold-const.c:9324

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

   Priority|P3  |P4
  Known to work||4.1.2, 4.3.4, 4.4.0, 4.5.2
   Target Milestone|--- |4.6.1
  Known to fail||4.6.0, 4.7.0

[Bug fortran/48456] [4.6/4.7 Regression] Realloc on assignment: ICE in fold_binary_loc

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 CC||pault at gcc dot gnu.org
 Depends on||48360
Summary|[4.6/4.7 Regression] ICE in |[4.6/4.7 Regression]
   |fold_binary_loc, at |Realloc on assignment: ICE
   |fold-const.c:9324   |in fold_binary_loc

--- Comment #1 from Tobias Burnus  2011-04-05 
08:48:34 UTC ---
The test case works with -fno-realloc-lhs.

Thus, it might be related to PR 48360 (there one has a segfault and no ICE).

[Bug fortran/48456] [4.6/4.7 Regression] Realloc on assignment: ICE in fold_binary_loc

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.04.05 08:51:15
 Ever Confirmed|0   |1

--- Comment #2 from Dominique d'Humieres  2011-04-05 
08:51:15 UTC ---
Confirmed on x86_64-apple-darwin10.7.0. The breakage occurred between revisions
167173 and 167584.

[Bug bootstrap/48403] [4.7 Regression] bootstrap comparison failure

[ebotcazou at gcc dot gnu.org]

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

--- Comment #43 from Eric Botcazou  2011-04-05 
09:02:56 UTC ---
> mips64-linux, right?

No, IA-64/Linux, I was replying to Steve, but this is indeed not very clear.

[Bug other/48434] Large SpecCPUFP Performance Regression for Thumb-2

[ibolton at gcc dot gnu.org]

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

Ian Bolton  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.04.05 09:07:14
 Ever Confirmed|0   |1

--- Comment #2 from Ian Bolton  2011-04-05 09:07:14 
UTC ---
(In reply to comment #1)
> Re-commit of IRA improvements?  Are the results visible somewhere, similar to
> gcc.opensuse.org?

r171648 (just before the first IRA change) does not show the regression.
r171649 did not build for me - probably because it was the first of a few IRA
patches.
r171713 did build, and does show the regression.

I think it is an IRA thing, as there aren't many non-IRA changes between the
good and bad revisions.

[Bug rtl-optimization/48434] Large SpecCPUFP Performance Regression for Thumb-2

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot
   ||gnu.org
  Component|other   |rtl-optimization
   Severity|critical|major

--- Comment #3 from Eric Botcazou  2011-04-05 
09:17:37 UTC ---
See also PR rtl-opt/48455.

[Bug rtl-optimization/48455] Huge code size regression for all ARM configurations

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #1 from Eric Botcazou  2011-04-05 
09:17:48 UTC ---
Probably related to PR rtl-opt/48434.

[Bug target/48252] ARM neon: problem with consecutive vzip, vuzp and vtrn

[irar at il dot ibm.com]

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

--- Comment #3 from Ira Rosen  2011-04-05 09:33:40 UTC 
---
Created attachment 23881
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23881
patch

[Bug target/48252] ARM neon: problem with consecutive vzip, vuzp and vtrn

[irar at il dot ibm.com]

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

Ira Rosen  changed:

   What|Removed |Added

 CC||irar at il dot ibm.com

--- Comment #4 from Ira Rosen  2011-04-05 09:34:37 UTC 
---
I attached the patch. I am going to test and submit it.

Ira

[Bug c++/48457] New: [C++0x] GCC does not recognize function rvalue reference expressions as lvalues

[daniel.kruegler at googlemail dot com]

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

   Summary: [C++0x] GCC does not recognize function rvalue
reference expressions as lvalues
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: daniel.krueg...@googlemail.com
CC: ja...@redhat.com


GCC 4.7.0 rejects the following code in C++0x mode:

template
T&& create();

template
void test() {
 T t(create());
 (void) t;
}

int main() {
   test();
}

"error: invalid initialization of non-const reference of type 'void
(&)()' from an rvalue of type 'void()'"

This code should be well-formed, because the expression create(), which
is a function call expression returning an rvalue reference of function type,
is supposed to be an lvalue, not an xvalue. According to (N3242) 3.10
[basic.lval] and confirmed by 5 [expr] p. 6 there are only xvalues of object
type and the semantics of above initialization is described by 8.5.3
[dcl.init.ref] p. 5 bullet 1, sub-bullet 1 where an lvalue-reference binds to
an lvalue (of function type).

[Bug target/43920] Choosing conditional execution over conditional branches for code size in some cases.

[vries at gcc dot gnu.org]

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

--- Comment #5 from vries at gcc dot gnu.org 2011-04-05 10:04:48 UTC ---
Author: vries
Date: Tue Apr  5 10:04:44 2011
New Revision: 171976

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=171976
Log:
2011-04-05  Tom de Vries  

PR target/43920
* cfgcleanup.c (flow_find_cross_jump): Don't count USE or CLOBBER as
insn.

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

[Bug target/43920] Choosing conditional execution over conditional branches for code size in some cases.

[vries at gcc dot gnu.org]

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

--- Comment #6 from vries at gcc dot gnu.org 2011-04-05 10:12:17 UTC ---
Author: vries
Date: Tue Apr  5 10:12:14 2011
New Revision: 171977

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=171977
Log:
2011-04-05  Tom de Vries  

PR target/43920
* function.c (emit_use_return_register_into_block): New function.
(thread_prologue_and_epilogue_insns): Use
emit_use_return_register_into_block.

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

[Bug target/43920] Choosing conditional execution over conditional branches for code size in some cases.

[vries at gcc dot gnu.org]

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

--- Comment #7 from vries at gcc dot gnu.org 2011-04-05 10:33:16 UTC ---
Author: vries
Date: Tue Apr  5 10:33:13 2011
New Revision: 171978

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=171978
Log:
2011-04-05  Tom de Vries  

PR target/43920
* config/arm/arm.h (BRANCH_COST): Set to 1 for Thumb-2 when optimizing
for size.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/arm.h

[Bug middle-end/48441] [4.7 Regression] ICE in mark_oprs_set

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.7.0

[Bug middle-end/48440] [4.7 Regression] FAIL: gcc.c-torture/compile/labels-3.c

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Guenther  2011-04-05 
11:02:50 UTC ---
-  static const short int ar[2] = {0, (short unsigned int) &l2 - (short
unsigned int) &l1};
+  static const short int ar[2] = {0, (short int) ((short unsigned int) (int)
&l2 - (short unsigned int) (int) &l1)};

this transformation is completely reasonable for any pointer size.  The
bug must be elsewhere and latent.

[Bug other/48445] Release does not generate fixincludes directory needed by Makefile

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Guenther  2011-04-05 
11:06:23 UTC ---
Would be interesting to know why fixincludes is not built.  Can you try to
track that down?

[Bug c++/48446] internal compiler error: in gimplify_var_or_parm_decl, at gimplify.c:1946

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.04.05 11:13:04
 Ever Confirmed|0   |1
  Known to fail||4.3.5, 4.5.2, 4.6.0

--- Comment #1 from Richard Guenther  2011-04-05 
11:13:04 UTC ---
Confirmed.  Seems to have always crashed.  ICC accepts it.

Reduced testcase:

namespace std {
typedef long unsigned int size_t;
}
typedef unsigned char uint8_t;
template class RefPtr {
public:
~RefPtr();
T *operator->() const;
};
class Message {
public:
typedef RefPtr Ptr;
static Ptr create(const void *data, std::size_t len);
};
template class BitArray {
public:
static const std::size_t byte_count = (N + 7) / 8;
};
class Recipient {
public:
typedef RefPtr Ptr;
BitArray<80> data;
};
class Sender {
Recipient::Ptr recipient(unsigned int i);
void flush();
};
void Sender::flush()
{
uint8_t buffer[64 / (recipient(0)->data.byte_count +
2)][recipient(0)->data.byte_count + 2];
std::size_t wptr = 0;
if (wptr == sizeof(buffer) / sizeof(*buffer)) {
Message::Ptr msg = Message::create(buffer, wptr * sizeof(buffer[0]));
}
}

[Bug lto/48447] LTO link fails to link libgcc correctly when -nostdlib option is specified

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.04.05 11:15:12
 Ever Confirmed|0   |1

--- Comment #2 from Richard Guenther  2011-04-05 
11:15:12 UTC ---
I think the references to the functions are introduced late, so the
archive re-scanning has to work.

[Bug rtl-optimization/48455] [4.7 Regression] Huge code size regression for all ARM configurations

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.7.0
Summary|Huge code size regression   |[4.7 Regression] Huge code
   |for all ARM configurations  |size regression for all ARM
   ||configurations

[Bug c++/48446] internal compiler error: in gimplify_var_or_parm_decl, at gimplify.c:1946

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  2011-04-05 
11:21:35 UTC ---
slightly further reduced:

template struct RefPtr {
~RefPtr();

T *operator->() const;
};

struct Message  {
typedef RefPtr Ptr;

static Ptr create(int);
};


struct Recipient  {
typedef RefPtr Ptr;

static const int byte_count = 80;
};


Recipient::Ptr recipient();

void flush()
{
char buffer[(recipient()->byte_count)];

{
Message::Ptr msg = Message::create(sizeof(buffer));
}
}


This is a regression as it compiles OK with GCC 4.1

[Bug c++/48446] [4.3/4.4/4.5/4.6 Regression] internal compiler error: in gimplify_var_or_parm_decl, at gimplify.c:1946

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

  Known to work||3.4.3

--- Comment #3 from Jonathan Wakely  2011-04-05 
11:28:17 UTC ---
(In reply to comment #2)
> This is a regression as it compiles OK with GCC 4.1

... and 3.4

[Bug inline-asm/48458] New: avr: inline assembly is broken

[avr at gjlay dot de]

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

   Summary: avr: inline assembly is broken
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: inline-asm
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: a...@gjlay.de


Inline assembly that used to work fine now breaks:

long val (unsigned int addr)
{
long val;
asm volatile ("; " : "+z" (addr), "=r" (val));
return val;
}

compile with -S -Os

Command line avr-gcc iasm.c -S -Os -v
Using built-in specs.
COLLECT_GCC=/mnt/nfs/home/georg/gnu/install/gcc-4.6/bin/avr-gcc
COLLECT_LTO_WRAPPER=/local/gnu/install/gcc-4.6/libexec/gcc/avr/4.7.0/lto-wrapper
Target: avr
Configured with: ../../gcc.gnu.org/trunk/configure --target=avr
--prefix=/local/gnu/install/gcc-4.6 --enable-languages=c,c++ --disable-libssp
--disable-libada --disable-nls --disable-shared
Thread model: single
gcc version 4.7.0 20110404 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-S' '-Os' '-v'
 /local/gnu/install/gcc-4.6/libexec/gcc/avr/4.7.0/cc1 -quiet -v iasm.c -quiet
-dumpbase iasm.c -auxbase iasm -Os -version -o iasm.s
GNU C (GCC) version 4.7.0 20110404 (experimental) (avr)
compiled by GNU C version 4.3.2 [gcc-4_3-branch revision 141291], GMP
version 5.0.1, MPFR version 3.0.0-p8, MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
ignoring nonexistent directory
"/local/gnu/install/gcc-4.6/lib/gcc/avr/4.7.0/../../../../avr/sys-include"
#include "..." search starts here:
#include <...> search starts here:
 /local/gnu/install/gcc-4.6/lib/gcc/avr/4.7.0/include
 /local/gnu/install/gcc-4.6/lib/gcc/avr/4.7.0/include-fixed
 /local/gnu/install/gcc-4.6/lib/gcc/avr/4.7.0/../../../../avr/include
End of search list.
GNU C (GCC) version 4.7.0 20110404 (experimental) (avr)
compiled by GNU C version 4.3.2 [gcc-4_3-branch revision 141291], GMP
version 5.0.1, MPFR version 3.0.0-p8, MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 184db0370fcb053833cf7d160d5a7a38
iasm.c: In function 'val':
iasm.c:5:5: error: can't find a register in class 'POINTER_REGS' while
reloading 'asm'
iasm.c:5:5: error: 'asm' operand has impossible constraints

Presumably, it's because of the changes in
http://gcc.gnu.org/viewcvs?view=revision&revision=171731

[Bug lto/48437] LTO crashes with block-local function declarations

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011.04.05 11:34:38
 AssignedTo|unassigned at gcc dot   |rguenth at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

--- Comment #1 from Richard Guenther  2011-04-05 
11:34:38 UTC ---
The problem is we merge those function decls.  We shouldn't even enter
them into the merging process though.

Mine.

[Bug other/48459] New: avr: Assertion failure with -gdwarf-2

[avr at gjlay dot de]

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

   Summary: avr: Assertion failure with -gdwarf-2
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: a...@gjlay.de


Source:

char c;

char getc (void)
{
return c;
}

compile with avr-gcc-4.7.0 (SVN 171936)

avr-gcc abi.c -S -Os -gdwarf-2 -v
Using built-in specs.
COLLECT_GCC=/mnt/nfs/home/georg/gnu/install/gcc-4.6/bin/avr-gcc
COLLECT_LTO_WRAPPER=/local/gnu/install/gcc-4.6/libexec/gcc/avr/4.7.0/lto-wrapper
Target: avr
Configured with: ../../gcc.gnu.org/trunk/configure --target=avr
--prefix=/local/gnu/install/gcc-4.6 --enable-languages=c,c++ --disable-libssp
--disable-libada --disable-nls --disable-shared
Thread model: single
gcc version 4.7.0 20110404 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-S' '-Os' '-gdwarf-2' '-v'
 /local/gnu/install/gcc-4.6/libexec/gcc/avr/4.7.0/cc1 -quiet -v abi.c -quiet
-dumpbase abi.c -auxbase abi -gdwarf-2 -Os -version -o abi.s
GNU C (GCC) version 4.7.0 20110404 (experimental) (avr)
compiled by GNU C version 4.3.2 [gcc-4_3-branch revision 141291], GMP
version 5.0.1, MPFR version 3.0.0-p8, MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
ignoring nonexistent directory
"/local/gnu/install/gcc-4.6/lib/gcc/avr/4.7.0/../../../../avr/sys-include"
#include "..." search starts here:
#include <...> search starts here:
 /local/gnu/install/gcc-4.6/lib/gcc/avr/4.7.0/include
 /local/gnu/install/gcc-4.6/lib/gcc/avr/4.7.0/include-fixed
 /local/gnu/install/gcc-4.6/lib/gcc/avr/4.7.0/../../../../avr/include
End of search list.
GNU C (GCC) version 4.7.0 20110404 (experimental) (avr)
compiled by GNU C version 4.3.2 [gcc-4_3-branch revision 141291], GMP
version 5.0.1, MPFR version 3.0.0-p8, MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 184db0370fcb053833cf7d160d5a7a38
abi.c: In function 'getc':
abi.c:6:1: internal compiler error: in
compute_frame_pointer_to_fb_displacement, at dwarf2out.c:17293
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Something is going wron with argp/fp elimination, presumably due to changes in
http://gcc.gnu.org/viewcvs?view=revision&revision=171731

[Bug c++/48446] [4.3/4.4/4.5/4.6 Regression] internal compiler error: in gimplify_var_or_parm_decl, at gimplify.c:1946

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.3.6

[Bug inline-asm/48435] Assertion failure during IRA (df_scan)

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Guenther  2011-04-05 
11:57:39 UTC ---
*** Bug 48458 has been marked as a duplicate of this bug. ***

[Bug inline-asm/48458] avr: inline assembly is broken

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE

--- Comment #1 from Richard Guenther  2011-04-05 
11:57:39 UTC ---
.

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

[Bug rtl-optimization/33928] [4.3/4.4/4.5/4.6/4.7 Regression] 30% performance slowdown in floating-point code caused by r118475

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
  Known to work||4.6.0
 Resolution||FIXED
   Target Milestone|4.3.6   |4.6.0
  Known to fail||4.5.2

--- Comment #123 from Richard Guenther  2011-04-05 
12:02:16 UTC ---
Fixed for GCC 4.6.

[Bug c++/48460] New: The compilation of Qemu 0.14.0 stops on a ARM cpu based board

[marietto2008 at gmail dot com]

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

   Summary: The compilation of Qemu 0.14.0 stops on a ARM cpu
based board
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: blocker
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: marietto2...@gmail.com


I'm trying to compile qemu 0.14.0 on the Insignia Infocast 8" (its a chumby
based device : www.chumby.com) it is based on a ARM cpu based board. 

chumby:/qemu/i386-softmmu# uname -a
Linux chumby 2.6.28-M2.1.8.12 #1 Thu Dec 9 13:04:27 PST 2010 armv5tejl
GNU/Linux

The compilation stops on the translate.o file :

chumby:/qemu# apt-get install git-core gitweb
chumby:/qemu# git clone git://git.qemu.org/qemu.git
chumby:/qemu# cd qemu
chumby:/qemu# ./configure
chumby:/qemu# make

  CCi386-softmmu/translate.o
gcc: Internal error: Killed (program cc1)
Please submit a full bug report.
See  for instructions.
make[1]: *** [translate.o] Error 1
make: *** [subdir-i386-softmmu] Error 2
chumby:/qemu#

chumby:/# gcc -v
Using built-in specs.
Target: arm-linux-gnueabi
Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.2-1.1'
--with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3
--program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug
--enable-objc-gc --enable-mpfr --disable-libssp --disable-sjlj-exceptions
--enable-checking=release --build=arm-linux-gnueabi --host=arm-linux-gnueabi
--target=arm-linux-gnueabi
Thread model: posix
gcc version 4.3.2 (Debian 4.3.2-1.1)

[Bug c/48460] The compilation of Qemu 0.14.0 stops on a ARM cpu based board

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

  Component|c++ |c
Version|unknown |4.3.2
   Severity|blocker |normal

[Bug lto/48431] patch to fix a compile error in lto-plugin.c when using older C compilers

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

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

--- Comment #4 from Richard Guenther  2011-04-05 
12:13:42 UTC ---
Fixed.

[Bug middle-end/48441] [4.7 Regression] ICE in mark_oprs_set

[steven at gcc dot gnu.org]

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

--- Comment #7 from Steven Bosscher  2011-04-05 
12:03:38 UTC ---
OK, confirmed that cprop_insn makes the insn deleted, in the second CPROP pass:

Breakpoint 3, one_cprop_pass () at ../../trunk/gcc/cprop.c:1799
1799changed |= cprop_insn (insn);
(gdb) p debug_rtx(insn)
(jump_insn 214 213 303 29 (set (pc)
(if_then_else (eq (reg/v:SI 202 [ rval ])
(const_int 7 [0x7]))
(label_ref:SI 303)
(pc))) charset.i:106 25 {*pa.md:1330}
 (expr_list:REG_BR_PROB (const_int 9550 [0x254e])
(nil))
 -> 303)
$12 = void
(gdb) next
1805if (! NOTE_P (insn))
(gdb) p debug_rtx(insn)
(jump_insn/v 214 213 303 29 (set (pc)
(if_then_else (eq (reg/v:SI 202 [ rval ])
(const_int 7 [0x7]))
(label_ref:SI 303)
(pc))) charset.i:106 25 {*pa.md:1330}
 (expr_list:REG_BR_PROB (const_int 9550 [0x254e])
(nil))
 -> 303)
$13 = void
(gdb)

CPROP finds that rval==22 and folds away the comparsion "(eq (rval==22) (7))"
in cprop_jump, and then goes on to:

  /* If this is now a no-op delete it, otherwise this must be a valid insn.  */
  if (new_rtx == pc_rtx)
delete_insn (jump);

I also verified that the same occurred before my patch, i.e. we were doing
mark_oprs_set on dead/deleted insns.

I'll submit the patch.

[Bug lto/48431] patch to fix a compile error in lto-plugin.c when using older C compilers

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Guenther  2011-04-05 
12:11:13 UTC ---
Author: rguenth
Date: Tue Apr  5 12:11:08 2011
New Revision: 171982

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=171982
Log:
2011-04-05  Richard Guenther  

PR bootstrap/48431
* lto-plugin.c (claim_file_handler): Do not declare vars in code.

Modified:
trunk/lto-plugin/ChangeLog
trunk/lto-plugin/lto-plugin.c

[Bug lto/48431] patch to fix a compile error in lto-plugin.c when using older C compilers

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Guenther  2011-04-05 
12:13:31 UTC ---
Author: rguenth
Date: Tue Apr  5 12:13:27 2011
New Revision: 171983

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=171983
Log:
2011-04-05  Richard Guenther  

PR bootstrap/48431
* lto-plugin.c (claim_file_handler): Do not declare vars in code.

Modified:
branches/gcc-4_6-branch/lto-plugin/ChangeLog
branches/gcc-4_6-branch/lto-plugin/lto-plugin.c

[Bug lto/48447] LTO link fails to link libgcc correctly when -nostdlib option is specified

[d.g.gorbachev at gmail dot com]

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

--- Comment #3 from Dmitry Gorbachev  
2011-04-05 12:42:52 UTC ---
For now, option -Wl,-plugin-opt=-pass-through=$(LIBGCC) can be manually added
to the command line (as discussed in PR42690).

[Bug c/48460] The compilation of Qemu 0.14.0 stops on a ARM cpu based board

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #1 from Richard Guenther  2011-04-05 
12:51:38 UTC ---
gcc: Internal error: Killed (program cc1)

you ran out of memory.

[Bug target/43920] Choosing conditional execution over conditional branches for code size in some cases.

[vries at gcc dot gnu.org]

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

--- Comment #8 from vries at gcc dot gnu.org 2011-04-05 13:01:55 UTC ---
Author: vries
Date: Tue Apr  5 13:01:50 2011
New Revision: 171986

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=171986
Log:
2011-04-05  Tom de Vries  

PR target/43920
* gcc.target/arm/pr43920-1.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/arm/pr43920-1.c
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug c/48460] The compilation of Qemu 0.14.0 stops on a ARM cpu based board

[marietto2008 at gmail dot com]

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

--- Comment #2 from Marietto  2011-04-05 
13:02:21 UTC ---
(In reply to comment #1)
> gcc: Internal error: Killed (program cc1)
> 
> you ran out of memory.

I've read somewhere that's possible to compile qemu without to go out of
memory.

[Bug other/48445] Release does not generate fixincludes directory needed by Makefile

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Severity|blocker |normal

--- Comment #6 from Jonathan Wakely  2011-04-05 
14:48:01 UTC ---
(In reply to comment #4)
> checking for suffix of object files... configure: error: in
> `/home/mancilla/current/soft/src/gcc-build-latest/x86_64-unknown-linux-gnu/libgcc':
> configure: error: cannot compute suffix of object files: cannot compile
> See `config.log' for more details.

See http://gcc.gnu.org/wiki/FAQ#configure_suffix
It usually means libgmp.so etc. can't be found by the runtime linker, have you
put /home/mancilla/current/soft/install in the linker's path?
e.g. LD_LIBRARY_PATH=/home/mancilla/current/soft/install

[Bug other/48445] Release does not generate fixincludes directory needed by Makefile

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely  2011-04-05 
14:51:15 UTC ---
(In reply to comment #6)
> (In reply to comment #4)
> > checking for suffix of object files... configure: error: in
> > `/home/mancilla/current/soft/src/gcc-build-latest/x86_64-unknown-linux-gnu/libgcc':
> > configure: error: cannot compute suffix of object files: cannot compile
> > See `config.log' for more details.
> 
> See http://gcc.gnu.org/wiki/FAQ#configure_suffix
> It usually means libgmp.so etc. can't be found by the runtime linker, have you
> put /home/mancilla/current/soft/install in the linker's path?
> e.g. LD_LIBRARY_PATH=/home/mancilla/current/soft/install

oops, that should be:
LD_LIBRARY_PATH=/home/mancilla/current/soft/install/lib

[Bug bootstrap/48444] [4.7 Regression] bootstrap failure with --disable-checking

[dominiq at lps dot ens.fr]

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

--- Comment #4 from Dominique d'Humieres  2011-04-05 
14:51:46 UTC ---
On x86_64-apple-darwin10 r171957, I bootstrap with --enable-checking=release
(or with the default value), but I also get

Bootstrap comparison failure!
gcc/final.o differs
gcc/haifa-sched.o differs
libiberty/cp-demangle.o differs
make[2]: *** [compare] Error 1

with --disable-checking.

[Bug other/48445] Release does not generate fixincludes directory needed by Makefile

[redi at gcc dot gnu.org]

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

--- Comment #8 from Jonathan Wakely  2011-04-05 
14:55:41 UTC ---
(In reply to comment #4)
> checking for suffix of object files... configure: error: in
> `/home/mancilla/current/soft/src/gcc-build-latest/x86_64-unknown-linux-gnu/libgcc':
> configure: error: cannot compute suffix of object files: cannot compile
> See `config.log' for more details.
> make[2]: *** [configure-stage1-target-libgcc] Error 1
> make[2]: Leaving directory `/home/mancilla/current/soft/src/gcc-build-latest'
> make[1]: *** [stage1-bubble] Error 2
> make[1]: Leaving directory `/home/mancilla/current/soft/src/gcc-build-latest'
> make: *** [all] Error 2
> Installing gcc-latest

^^ Where does this message come from?

> make[1]: Entering directory `/home/mancilla/current/soft/src/gcc-build-latest'
> /bin/bash
> /home/mancilla/current/soft/src/gcc-build-latest/../gcc-svn/mkinstalldirs
> /home/mancilla/current/soft/install-latest
> /home/mancilla/current/soft/install-latest
> /bin/bash: line 3: cd: ./fixincludes: No such file or directory
> make[1]: *** [install-fixincludes] Error 1
> make[1]: Leaving directory `/home/mancilla/current/soft/src/gcc-build-latest'
> make: *** [install] Error 2


It looks to me as though your build script does
  make
  make install
which assumes the 'make' step works.

But it doesn't, because of the configure error because your linker can't find
the prerequisite libs (which is documented at
http://gcc.gnu.org/install/configure.html under the --with-gmp docs)

So the reason fixincludes doesn't exist is because you never finished running
"make"

[Bug fortran/45586] [4.6 Regression] ICE non-trivial conversion at assignment

[Joost.VandeVondele at pci dot uzh.ch]

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

Joost VandeVondele  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |

--- Comment #50 from Joost VandeVondele  
2011-04-05 15:05:52 UTC ---
The original problem in comment #0 fails (i.e. the build of CP2K) with trunk
4.7, at what I believe is essentially the same issue. Unfortunately the smaller
testcase (comment #1) doesn't fail anymore.

In file included from :363:0:
/data03/vondele/cp2k_gcc/cp2k/makefiles/../src/qs_linres_current.F: In function
‘calculate_jrho_resp’:
/data03/vondele/cp2k_gcc/cp2k/makefiles/../src/qs_linres_current.F:612:0:
error: non-trivial conversion at assignment
struct array3_real(kind=8)
struct array3_real(kind=8)
# .MEM_3879 = VDEF <.MEM_3388>
my_gauge = D.66078_1423->r;

/data03/vondele/cp2k_gcc/cp2k/makefiles/../src/qs_linres_current.F:612:0:
internal compiler error: verify_gimple failed
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[3]: *** [/dev/shm/vondele/cciVnmd6.ltrans0.ltrans.o] Error 1
make[3]: Target `all' not remade because of errors.
lto-wrapper: make returned 2 exit status
/data03/vondele/gnu/binutils-2.21/install/bin/ld.gold: fatal error: lto-wrapper
failed
collect2: ld returned 1 exit status

[Bug target/47119] sh-symbianelf: symbian-base.o won't build

[jsm28 at gcc dot gnu.org]

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

Joseph S. Myers  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WONTFIX

--- Comment #5 from Joseph S. Myers  2011-04-05 
15:11:16 UTC ---
sh-symbianelf support has been removed for 4.7.

[Bug other/46677] frontends and tree optimizers use *_TYPE_SIZE

[jsm28 at gcc dot gnu.org]

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

--- Comment #24 from Joseph S. Myers  2011-04-05 
15:13:38 UTC ---
The sort of patches here should be updated for trunk and resubmitted now we are
in stage 1 for 4.7 and such patches are appropriate.

[Bug fortran/45586] [4.6/4.7 Regression] ICE non-trivial conversion at assignment

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|4.6.0   |4.6.1
Summary|[4.6 Regression] ICE|[4.6/4.7 Regression] ICE
   |non-trivial conversion at   |non-trivial conversion at
   |assignment  |assignment

[Bug middle-end/46500] target.h includes tm.h

[jsm28 at gcc dot gnu.org]

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

--- Comment #6 from Joseph S. Myers  2011-04-05 
15:17:44 UTC ---
The cumulative_args_t changes should be updated and resubmitted now we are in
4.7 stage 1.

[Bug middle-end/48461] New: [4.7 Regression function.c:5268:1: error: emit_use_return_register_into_block defined but not used

[danglin at gcc dot gnu.org]

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

   Summary: [4.7 Regression function.c:5268:1: error:
emit_use_return_register_into_block defined but not
used
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dang...@gcc.gnu.org
CC: vr...@gcc.gnu.org


/home/dave/opt/gnu/gcc/gcc-4.7.0/hppa-linux-gnu/sys-include-c   -g -O2
-DIN_GCC   -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes
-Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-overlength-strings -Werror -Wold-style-definition
-Wc++-compat -fno-common  -DHAVE_CONFIG_H -I. -I. -I../../gcc/gcc
-I../../gcc/gcc/. -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include 
-I../../gcc/gcc/../libdecnumber -I../../gcc/gcc/../libdecnumber/dpd
-I../libdecnumber../../gcc/gcc/function.c -o function.o
../../gcc/gcc/function.c:5268:1: error: âemit_use_return_register_into_blockâ
defined but not used [-Werror=unused-function]
cc1: all warnings being treated as errors

[Bug fortran/48462] New: matmul Segmentation Fault with Allocatable Array

[ortp21 at gmail dot com]

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

   Summary: matmul Segmentation Fault with Allocatable Array
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ort...@gmail.com


The segmentation fault occurs in the current stable release version of gcc
(4.6.0). The release version source code was downloaded from a gcc mirror and
configured in the following way:

Target: x86_64-apple-darwin10.6.0
Configured with: ../gcc-4.6.0/configure --prefix=$HOME/gcc/gcc-release
--enable-languages=fortran --enable-checking=release --disable-bootstrap
Thread model: posix
gcc version 4.6.0 (GCC) 

Small example:


! matmulTester.f90
program main
implicit none
integer, parameter :: dp = kind(0.0d0)
real(kind=dp), allocatable :: a(:,:)
real(kind=dp), allocatable :: b(:,:)

allocate(a(3,3))
allocate(b(3,3))

a(1,:) = [ 3.11_dp, 3.12_dp, 3.13_dp ]
a(2,:) = [ 3.21_dp, 3.22_dp, 3.23_dp ]
a(3,:) = [ 3.31_dp, 3.32_dp, 3.33_dp ]

b = 6.0_dp * a

a = matmul( matmul( a, b ), b ) ! Segmentation Fault
end program main


The segmentation fault occurs on the last line of the program above. It can be
fixed by separating the lines:

a = matmul(a,b)
a = matmul(a,b)

The segmentation fault also disappears, and the program runs fine, if
non-allocatable arrays are used for a and b. In addition, replacing the last
line of the program with the following removes the segmentation fault:

b = matmul( matmul( a, b ), b ) ! NO Segmentation Fault

Also, the segmentation fault disappears when another allocatable array is
introduced to the code above:

real(kind=dp), allocatable :: c(:,:)
allocate(3,3)
...
c = matmul( matmul( a, b ), b ) ! NO Segmentation Fault

I used the following command:

gfortran -o matmulTester matmulTester.f90

Finally, building in debug mode and running yields the following:

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x
0x00010008b3ab in __gfortran_matmul_r8 (retarray=, a=, b=,
try_blas=, blas_limit=24,
gemm=0x18) at ../../../gcc-4.6.0/libgfortran/generated/matmul_r8.c:284
284  dest_y[x] += abase_n[x] * bbase_yn;


I hope this is not a duplicate and was a worthwhile reporting. If not, I
apologize.

Thanks,
John N.

[Bug middle-end/48461] [4.7 Regression function.c:5268:1: error: emit_use_return_register_into_block defined but not used

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Keywords||build
 Target||hppa-linux-gnu
   Target Milestone|--- |4.7.0

[Bug middle-end/48461] [4.7 Regression function.c:5268:1: error: emit_use_return_register_into_block defined but not used

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot   |vries at gcc dot gnu.org
   |gnu.org |
   Target Milestone|4.7.0   |---

[Bug middle-end/48461] [4.7 Regression] function.c:5268:1: error: emit_use_return_register_into_block defined but not used

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.7.0
Summary|[4.7 Regression |[4.7 Regression]
   |function.c:5268:1: error:   |function.c:5268:1: error:
   |emit_use_return_register_in |emit_use_return_register_in
   |to_block defined but not|to_block defined but not
   |used|used

[Bug gcov-profile/48463] New: gcov generating bad function coverage

[lieutenantfeist at hotmail dot de]

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

   Summary: gcov generating bad function coverage
   Product: gcc
   Version: 4.3.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: gcov-profile
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: lieutenantfe...@hotmail.de


Created attachment 23882
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23882
1.png, 2.png, src/ (has 3 source files)

Gcov is generating a lot of useless output when it comes to function coverage.
The problem really came to our attention when looking at classes with virtual
destructors like the one in the following class example:

[code]
class ClassA
{
public:
ClassA();
virtual ~ClassA();
};

class ClassB : public ClassA
{
public:
ClassB();
~ClassB();
};
[/code]

The list of function names then contains three destructors for ClassA (two of
which are apparently not called, one which is) and three destructors for ClassB
(two of which are apparently not called, one which is). They all have the same
signature. When disabling then genhtml option --demangle-cpp, or by viewing the
.gcov files, you can see, that each of these destructors (of ClassA for
example) has a different name. Example (excerpt of gcov file for classA.cpp):

Function '_ZN6ClassAD0Ev'
Lines executed:0.00% of 3
Branches executed:0.00% of 2
Taken at least once:0.00% of 2
Calls executed:0.00% of 3

Function '_ZN6ClassAD1Ev'
No executable lines
Branches executed:0.00% of 2
Taken at least once:0.00% of 2
Calls executed:0.00% of 3

Function '_ZN6ClassAD2Ev'
No executable lines
Branches executed:100.00% of 2
Taken at least once:50.00% of 2
Calls executed:66.67% of 3

The mangled names differ only in the parts: D0, D1, D2. It's odd that one
destructor apparently has 3 executable lines (in the attached source, you can
see it's only one line), and that the two others have no executable lines, yet
they have branches that can be covered. 
These "IDs" 'D0', 'D1', 'D2' are given to the mangled function names by the gcc
compiler, yet I am unsure of what the difference is supposed to be. 
Nevertheless, it isn't really of interest to the person analyzing the coverage
of his code, what gcc generates in the background. Only those desctructors,
that the programmer can actually see in HIS code, should show up in the list of
covered (or not covered) functions. 
This goes for the other functions that show up in the example's list as well:
global destructors keyed to _ZN6ClassAC2Ev 
global constructors keyed to _ZN6ClassAC2Ev
__static_initialization_and_destruction_0(int, int)

It leads to wrong numbers for the function and branch coverage of what you
really want to see.

To reproduce:

I wrote a two classes: ClassA and ClassB. ClassA has a public constructor (no
args, just prints something) and a public virtual destructor (no args, just
prints something). ClassB inherits from ClassA (publicly) and has a public
constructor (no args, just prints something) and a public destructor (no args,
just prints something). The main file just creates an instance of ClassB,
stores it in a pointer to ClassA and calls delete on that pointer variable. 

The source files were compiled using:
g++ -fprofile-arcs -ftest-coverage -o prog main.cpp classA.cpp

Then ./prog was run once.

A .info file was generated using lcov (version 1.9) in the following command:
lcov -d . -c -f -o NewInfo.info

The final html overview was generated using genhtml (also version 1.9) in the
following command:
genhtml --demangle-cpp --prefix . -o html/ NewInfo.info 

Alternatively, to reproduce, you can also use the attached source files. The
attachment also include two pictures, displaying a listing of all the functions
that have apparently been covered or not covered.

Hope this info helps solve the problem. 
Chris

[Bug gcov-profile/48463] gcov generating bad function coverage

[lieutenantfeist at hotmail dot de]

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

Christian  changed:

   What|Removed |Added

   Severity|normal  |major

[Bug fortran/48462] [4.6/4.7 Regression] matmul Segmentation Fault with Allocatable Array

[Joost.VandeVondele at pci dot uzh.ch]

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

Joost VandeVondele  changed:

   What|Removed |Added

   Keywords||wrong-code
  Known to work||4.5.0
Summary|matmul Segmentation Fault   |[4.6/4.7 Regression] matmul
   |with Allocatable Array  |Segmentation Fault with
   ||Allocatable Array
  Known to fail||4.6.1, 4.7.0

--- Comment #1 from Joost VandeVondele  
2011-04-05 15:38:21 UTC ---
so, the segfault is at run time. 4.5 is doing fine.

==14586== Invalid read of size 8
==14586==at 0x4EC9AD1: _gfortran_matmul_r8 (matmul_r8.c:284)
==14586==by 0x400877: main (in /data03/vondele/bugs/a.out)
==14586==  Address 0x0 is not stack'd, malloc'd or (recently) free'd

looks like an important issue to me.

[Bug fortran/48462] [4.6/4.7 Regression] matmul Segmentation Fault with Allocatable Array

[Joost.VandeVondele at pci dot uzh.ch]

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

--- Comment #2 from Joost VandeVondele  
2011-04-05 15:40:41 UTC ---
somewhat reduced:

program main
implicit none
integer, parameter :: dp = kind(0.0d0)
real(kind=dp), allocatable :: a(:,:)
real(kind=dp), allocatable :: b(:,:)
allocate(a(3,3))
allocate(b(3,3))
a = matmul( matmul( a, b ), b ) ! Segmentation Fault
end program main

[Bug bootstrap/48444] [4.7 Regression] bootstrap failure with --disable-checking

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot   |law at redhat dot com
   |gnu.org |

--- Comment #5 from Jeffrey A. Law  2011-04-05 15:42:31 
UTC ---
I've got a handle on this one...

[Bug fortran/48462] [4.6/4.7 Regression] matmul Segmentation Fault with Allocatable Array

[Joost.VandeVondele at pci dot uzh.ch]

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

Joost VandeVondele  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.04.05 15:43:17
 Ever Confirmed|0   |1

[Bug other/46489] tree optimizer and frontend files use target macros

[jsm28 at gcc dot gnu.org]

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

--- Comment #7 from Joseph S. Myers  2011-04-05 
15:43:46 UTC ---
FWIW, the following files include tm.h and appear not to have any direct uses
of target macros, or uses of the most common headers (such as rtl.h or
cp-tree.h) that depend on tm.h.  They require more careful checks of what
headers they are using for any hidden tm.h dependencies, but may be good
candidates for the removal of tm.h includes.

gcc/ada/gcc-interface/cuintp.c
gcc/attribs.c
gcc/c-aux-info.c
gcc/c-convert.c
gcc/c-errors.c
gcc/c-family/c-ada-spec.c
gcc/c-family/c-dump.c
gcc/c-family/c-gimplify.c
gcc/c-family/c-pretty-print.c
gcc/c-family/c-semantics.c
gcc/c-lang.c
gcc/c-parser.c
gcc/cgraphbuild.c
gcc/cppspec.c
gcc/debug.c
gcc/domwalk.c
gcc/fixed-value.c
gcc/gencheck.c
gcc/gimple-iterator.c
gcc/gimple-low.c
gcc/gimple-pretty-print.c
gcc/hooks.c
gcc/ipa-pure-const.c
gcc/ipa-reference.c
gcc/ipa-utils.c
gcc/java/except.c
gcc/java/jvgenmain.c
gcc/java/jvspec.c
gcc/java/mangle.c
gcc/java/zextract.c
gcc/lto-section-in.c
gcc/lto-section-out.c
gcc/lto-streamer-out.c
gcc/lto-streamer.c
gcc/lto/lto.c
gcc/main.c
gcc/objc/objc-lang.c
gcc/params.c
gcc/print-tree.c
gcc/tree-call-cdce.c
gcc/tree-cfg.c
gcc/tree-cfgcleanup.c
gcc/tree-complex.c
gcc/tree-dump.c
gcc/tree-eh.c
gcc/tree-if-conv.c
gcc/tree-into-ssa.c
gcc/tree-nomudflap.c
gcc/tree-nrv.c
gcc/tree-optimize.c
gcc/tree-outof-ssa.c
gcc/tree-predcom.c
gcc/tree-pretty-print.c
gcc/tree-profile.c
gcc/tree-ssa-coalesce.c
gcc/tree-ssa-copy.c
gcc/tree-ssa-copyrename.c
gcc/tree-ssa-dce.c
gcc/tree-ssa-dom.c
gcc/tree-ssa-dse.c
gcc/tree-ssa-ifcombine.c
gcc/tree-ssa-live.c
gcc/tree-ssa-loop-ch.c
gcc/tree-ssa-loop-im.c
gcc/tree-ssa-loop-ivcanon.c
gcc/tree-ssa-loop-manip.c
gcc/tree-ssa-loop-niter.c
gcc/tree-ssa-loop-unswitch.c
gcc/tree-ssa-loop.c
gcc/tree-ssa-operands.c
gcc/tree-ssa-phiopt.c
gcc/tree-ssa-phiprop.c
gcc/tree-ssa-pre.c
gcc/tree-ssa-propagate.c
gcc/tree-ssa-reassoc.c
gcc/tree-ssa-sink.c
gcc/tree-ssa-ter.c
gcc/tree-ssa-threadedge.c
gcc/tree-ssa-threadupdate.c
gcc/tree-ssa-uncprop.c
gcc/tree-ssa-uninit.c
gcc/tree-ssanames.c
gcc/tree-stdarg.c
gcc/tree-switch-conversion.c
gcc/tree-tailcall.c
gcc/tree-vect-patterns.c
gcc/tree-vect-slp.c
gcc/tree-vectorizer.c
gcc/tree-vrp.c
libdecnumber/dconfig.h
libgcc/generic-morestack-thread.c

[Bug bootstrap/48403] [4.7 Regression] bootstrap comparison failure

[law at redhat dot com]

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

--- Comment #44 from Jeffrey A. Law  2011-04-05 15:45:20 
UTC ---
Just a note for those experiencing a comparison failure with
--disable-checking, I know what's causing it and should have a fix shortly.   
That failure is being tracked by PR48444.

[Bug middle-end/48461] [4.7 Regression] function.c:5268:1: error: emit_use_return_register_into_block defined but not used

[vries at gcc dot gnu.org]

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

--- Comment #1 from vries at gcc dot gnu.org 2011-04-05 15:54:17 UTC ---
Author: vries
Date: Tue Apr  5 15:54:13 2011
New Revision: 171990

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=171990
Log:
2011-04-05  Tom de Vries  

PR middle-end/48461
* function.c (emit_use_return_register_into_block): Only define if
HAVE_return.

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

[Bug fortran/48462] [4.6/4.7 Regression] realloc on assignment: matmul Segmentation Fault with Allocatable Array

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org,
   ||pault at gcc dot gnu.org
 Depends on||48360
   Target Milestone|--- |4.6.1
Summary|[4.6/4.7 Regression] matmul |[4.6/4.7 Regression]
   |Segmentation Fault with |realloc on assignment:
   |Allocatable Array   |matmul Segmentation Fault
   ||with Allocatable Array

--- Comment #3 from Tobias Burnus  2011-04-05 
15:57:52 UTC ---
Work around: -fno-realloc-lhs

See also other (re)allocation on assignment related bugs: PR 48360 and 48456.

[Bug bootstrap/48444] [4.7 Regression] bootstrap failure with --disable-checking

[bkoz at gcc dot gnu.org]

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

Benjamin Kosnik  changed:

   What|Removed |Added

   Target Milestone|4.7.0   |---

--- Comment #6 from Benjamin Kosnik  2011-04-05 
15:58:33 UTC ---

Hey Jeff. Yes, I always build with checking disabled, as it means libstdc++
make check is 27 minutes, not 40. I should have given you a configure line on
#gcc.

FWIW, --enable-checking=release and --disable-checking are the same code path

[Bug middle-end/48461] [4.7 Regression] function.c:5268:1: error: emit_use_return_register_into_block defined but not used

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #2 from vries at gcc dot gnu.org 2011-04-05 16:01:17 UTC ---
The function emit_use_return_register_into_block is only used in code guarded
with HAVE_return, and therefore the definition of
emit_use_return_register_into_block should also be guarded with HAVE_return.

Failing to do this caused the error mentioned in the description field.

This is fixed by the check-in in comment 1.

[Bug bootstrap/48444] [4.7 Regression] bootstrap failure with --disable-checking

[law at redhat dot com]

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

--- Comment #7 from Jeffrey A. Law  2011-04-05 16:03:32 
UTC ---
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 04/05/11 09:58, bkoz at gcc dot gnu.org wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48444
> 
> Benjamin Kosnik  changed:
> 
>What|Removed |Added
> 
>Target Milestone|4.7.0   |---
> 
> --- Comment #6 from Benjamin Kosnik  2011-04-05 
> 15:58:33 UTC ---
> 
> Hey Jeff. Yes, I always build with checking disabled, as it means libstdc++
> make check is 27 minutes, not 40. I should have given you a configure line on
> #gcc.
> 
> FWIW, --enable-checking=release and --disable-checking are the same code path
No worries.  I've got my bit of mess from this shit-storm under control.
 It'll take a few hours to get all the tests run, but I'm confident my
little piece will get fixed shortly :-)

jeff
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJNmz1EAAoJEBRtltQi2kC7TDsH/AiduwnUnU9BxzhdBXN2+z3h
BpEEthsww2Ns731aRb7XECf0MyzocOjKG6X4KUI/VWpG3Xoi4f+RoRstjsl5UbQi
zeEv88gq4Dw/QbZs/LHFYfa9mpaY2bsrT7yK9EUEYVCc5nfjcoVAh95rGPMv9vVz
HQFCHc/AQdxpMIGiX1/Y4CPBPj1vIEcJ49yv9dSy5AdkDSLEhD77KCfh1AvtFG1j
q9VfO12Wpg3yYt4ojg7WLXVSb1g/8/6WnSzn6IjpEpIRdAxL47BRTp66wAfVXxu9
x0fPCkORh+E1lJGyfSatEtC6iOTiYDu8HIehKF9wJQ/DJ5WNYHLZEr2uewo/LFA=
=vSy+
-END PGP SIGNATURE-

[Bug middle-end/48464] New: Regression @171649: ICE in setup_pressure_classes, at ira.c:877

[jbg...@lug-owl.de]

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

   Summary: Regression @171649: ICE in setup_pressure_classes, at
ira.c:877
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jbg...@lug-owl.de


Hi!

The large IRA merge (=66d9a7b9e8a0c85a51467330f51ead74e77b7eb8 in GIT) broke
the vax-linux target:

jbglaw@jbarbeitsplatz:/mnt/nfs-programming/toolchain/gcc-build/gcc$ ./xgcc -B .
-c foo.c
foo.c:1:0: internal compiler error: in setup_pressure_classes, at ira.c:877
Please submit a full bug report,
[...]


jbglaw@jbarbeitsplatz:/mnt/nfs-programming/toolchain/gcc-build/gcc$ cat foo.c   
extern int xx (int a, int b);
int
blub (double boo, int oo)   
{
long x;
x = boo * oo;
x += xx (boo, oo);
return x;
}

This is just configured with ../gcc/configure --target=vax-linux
--enable-languages=c --disable-threads on a i686-linux host/build system.

[Bug middle-end/48464] Regression @171649: ICE in setup_pressure_classes, at ira.c:877

[jbg...@lug-owl.de]

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

Jan-Benedict Glaw  changed:

   What|Removed |Added

 Target||vax-linux
 CC||jbg...@lug-owl.de, vmakarov
   ||at redhat dot com
   Host||i686-linux
  Build||i686-linux

--- Comment #1 from Jan-Benedict Glaw  2011-04-05 16:07:47 
UTC ---
Hint for VCS users (as bugzilla only wants to see released version names).

Known to work: r171648 = 9f50fa3742ab7c20e3e8ceb48b26c920b22ecd62
Known to fail: r171649 = 66d9a7b9e8a0c85a51467330f51ead74e7

[Bug target/48454] gfortran.dg/char_result_13.f90 fails with -O3 -funroll-loops -mvectorize-with-neon-quad

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 CC||ramana at gcc dot gnu.org

--- Comment #1 from Ramana Radhakrishnan  2011-04-05 
16:22:30 UTC ---
Can you show the assembler generated here ? I don't see the same error that you
get here with a cross-compiler. 

Ramana

[Bug target/46548] Build arm gcc failure after patch 165463

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 CC||ramana at gcc dot gnu.org

--- Comment #4 from Ramana Radhakrishnan  2011-04-05 
16:30:33 UTC ---
Is this now fixed ?

[Bug target/48328] GCC failed to generate 16bit relative jump table

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

   Target Milestone|--- |4.7.0
   Severity|normal  |enhancement

[Bug target/46548] Build arm gcc failure after patch 165463

[froydnj at gcc dot gnu.org]

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

--- Comment #5 from Nathan Froyd  2011-04-05 
16:33:00 UTC ---
I believe this was fixed by the fix for PR 46040.

[Bug target/46548] Build arm gcc failure after patch 165463

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||DUPLICATE

--- Comment #6 from Ramana Radhakrishnan  2011-04-05 
16:36:31 UTC ---
It probably is a dup of PR46040 I think . Ah I remember now. 

Ramana

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

[Bug target/46040] crtstuff.c:308:26: error: '__DTOR_LIST__' undeclared

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 CC||carrot at google dot com

--- Comment #12 from Ramana Radhakrishnan  
2011-04-05 16:36:31 UTC ---
*** Bug 46548 has been marked as a duplicate of this bug. ***

[Bug bootstrap/48444] [4.7 Regression] bootstrap failure with --disable-checking

[steven at gcc dot gnu.org]

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

Steven Bosscher  changed:

   What|Removed |Added

 CC||steven at gcc dot gnu.org

--- Comment #8 from Steven Bosscher  2011-04-05 
16:47:41 UTC ---
(In reply to comment #6)
> FWIW, --enable-checking=release and --disable-checking are the same code path

Is this really true? I thought that assert checking is also disabled with
--disable-checking, but that it's enabled with release checking...?

[Bug libstdc++/48465] New: [4.6/4.7 Regression] undefined reference to std::basic_string::_S_compare(unsigned long, unsigned long)

[zsojka at seznam dot cz]

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

   Summary: [4.6/4.7 Regression] undefined reference to
std::basic_string::_S_compare(unsigned long, unsigned
long)
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu


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

Compiler output:
$ g++ -finline-small-functions -O testcase.C
--param=hot-bb-frequency-fraction=1
/tmp/ccRTQGpy.o: In function `foo(int, int, char*)':
testcase.C:(.text+0x70): undefined reference to `std::basic_string, std::allocator >::_S_compare(unsigned long,
unsigned long)'
collect2: ld returned 1 exit status

Tested revisions:
r171979 - fail
4.6 r171597 - fail
4.5 r171597 - OK

[Bug libstdc++/48465] [4.6/4.7 Regression] undefined reference to std::basic_string::_S_compare(unsigned long, unsigned long)

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.04.05 17:23:03
 Ever Confirmed|0   |1

--- Comment #1 from Jonathan Wakely  2011-04-05 
17:23:03 UTC ---
I can reproduce this, but I don't think it can be a libstdc++ bug when it
depends on optimisation and --param=hot-bb-frequency-fraction=1

[Bug rtl-optimization/48455] [4.7 Regression] Huge code size regression for all ARM configurations

[steven at gcc dot gnu.org]

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

Steven Bosscher  changed:

   What|Removed |Added

 CC||steven at gcc dot gnu.org

--- Comment #2 from Steven Bosscher  2011-04-05 
18:00:12 UTC ---
Do you have compiler options for a particularly bad configuration? 
Which benchmark files grow the most?

[Bug debug/48466] New: [4.4/4.5/4.6 Regression] Wrong variable locations at -O0 on i686

[jakub at gcc dot gnu.org]

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

   Summary: [4.4/4.5/4.6 Regression] Wrong variable locations at
-O0 on i686
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ja...@gcc.gnu.org
CC: tro...@gcc.gnu.org, h...@gcc.gnu.org


struct S { int a; int *b; };
struct T { struct S a; struct S b; };
struct U { const char *u; };
int n[10];
volatile int v;

struct U
foo (const char *s)
{
  struct U r;
  r.u = s;
  return r;
}

void
bar (struct T *s, int a, int b)
{
  s->a.a = a;
  s->a.b = &s->a.a;
  s->b.a = b;
  s->b.b = &s->b.a;
}

int
main ()
{
  struct T t;
  struct U x = foo ("this is x");
  struct S y, z;
  y.b = n;
  y.a = 0;
  bar (&t, 1, 2);
  v++;
  z = y;
  return 0;
}

compiled with -g -O0 -dA, when you debug this in the debugger, &t is different
from the address passed to bar and after the bar call t contains garbage.
Most likely this started with
http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=138438
The t variable has DECL_RTL (mem (plus (frame) (const_int -16)), (frame) is
eliminated to bp - 4, but crtl->stack_realign_tried is true (eventhough
fde->stack_realign is false) and thus it is encoded as sp - 20 instead of bp -
20.  fde->drap_reg is -1.
http://gcc.gnu.org/ml/gcc-patches/2008-07/msg02391.html

[Bug debug/48466] [4.4/4.5/4.6 Regression] Wrong variable locations at -O0 on i686

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|--- |4.4.6

[Bug middle-end/48441] [4.7 Regression] ICE in mark_oprs_set

[steven at gcc dot gnu.org]

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

--- Comment #8 from Steven Bosscher  2011-04-05 
18:15:08 UTC ---
Author: steven
Date: Tue Apr  5 18:15:04 2011
New Revision: 171994

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=171994
Log:
PR middle-end/48441
* cprop.c (one_cprop_pass): Do not mark_oprs_set of deleted insns.

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

[Bug middle-end/48441] [4.7 Regression] ICE in mark_oprs_set

[steven at gcc dot gnu.org]

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

Steven Bosscher  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #9 from Steven Bosscher  2011-04-05 
18:16:34 UTC ---
Eet eez feexeth.

[Bug lto/48467] New: [LTO/driver] Anomalous behavior of -save-temps

[d.g.gorbachev at gmail dot com]

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

   Summary: [LTO/driver] Anomalous behavior of -save-temps
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: lto
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: d.g.gorbac...@gmail.com


Created attachment 23884
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23884
DIFF file with 4 tests

1. After running the 1st test, notice the absence of one generated assembler
file (1.s), which is deleted by lto1. In toplev.c,

1851  if (flag_wpa)
1852unlink_if_ordinary (asm_file_name);

2. As the 2nd and 3rd tests show, it can also be misused as an output file for
lto1, so its original, written by cc1, content gets lost.

3. The 4th test gives good, expected results.

[Bug c++/48468] New: [C++0x][SFINAE] noexcept operator does handle function templates well

[gintensubaru at gmail dot com]

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

   Summary: [C++0x][SFINAE] noexcept operator does handle function
templates well
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: gintensub...@gmail.com


template
T&& declval() noexcept;

template< class T >
inline void f1( T& x ) noexcept( noexcept( declval().foo() ) )
{
  x.foo();
}

template< class T,
  bool Noexcept = noexcept( declval().foo() )
>
inline void f2( T& x ) noexcept( Noexcept )
{
  x.foo();
}

// a common and trivial mistake
template< class T >
inline void f3( T& x ) noexcept( declval().foo() )
{
  x.foo();
}


struct X
{
  void foo();
};

struct Y
{
  void foo() noexcept;
};

struct Z {};


int main()
{
  X x; Y y; Z z;

  static_assert( !noexcept( f1(x) ), "OK." );
  static_assert( !noexcept( f2(x) ), "OK." );
  // static_assert( !noexcept( f3(x) ), "shall be ill-formed(OK)." );

  static_assert(  noexcept( f1(y) ), "OK." );
  static_assert(  noexcept( f2(y) ), "OK." );
  // static_assert(  noexcept( f3(y) ), "shall be ill-formed(OK)." );

  static_assert(  noexcept( f1(z) ), "shall be ill-formed." );
  static_assert(  noexcept( f2(z) ), "shall be ill-formed." );
  static_assert( !noexcept( f3(z) ), "shall be ill-formed." );

}

-

GCC-4.6.0 compiles this code successfully, but expressions "noexcept( f1(z) )",
"noexcept( f2(z) )", and "noexcept( f3(z) )" shall be ill-formed, because
unevaluated operand "declval().foo()" is ill-formed.


This behavior prevents using noexcept for switching implementations by SFINAE:

-

// if x.swap(y) is exist, calls it.
template
void my_swap_( T& x, T& y, int )
  noexcept( noexcept( std::declval().swap( std::declval() ) ) )
{
  x.swap( y );
}

// otherwise, calls [std::]swap
using std::swap;
template
void my_swap_( T& x, T& y, ... )
  noexcept( noexcept( swap( std::declval(), std::declval() ) ) )
{
  swap( x, y );
}


template
void my_swap( T& x, T& y )
  noexcept( noexcept( my_swap_( std::declval(), std::declval(), 0 ) ) )
{
  my_swap_( x, y, 0 );
}

-

Of course, this code can be written with another C++0x feature (e.g. decltype),
I'd prefer to use noexcept when result type is void, because it's simple.

[Bug fortran/48404] SELECTED_REAL_KIND is returning KIND=16 when not available

[brtnfld at hdfgroup dot org]

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

--- Comment #7 from Scot Breitenfeld  2011-04-05 
18:46:26 UTC ---
(In reply to comment #3)

> Thus: How have you obtained the compiler? Are you sure that the correct
> compiler/library combination is used?
> 
One compiler was from Debian packages, other compilers were from compiling from
source. Rolling back libgfortran to find an older version fixes the problem. I
guess the best solution is to compile the code with -static to avoid the issue.

Probably can close the bug report.

[Bug debug/48466] [4.4/4.5/4.6 Regression] Wrong variable locations at -O0 on i686

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  2011-04-05 
18:55:37 UTC ---
Created attachment 23885
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23885
gcc46-pr48466.patch

This seems to work and doesn't regress PR36977 (which I've added as guality
testcase too).  Whether it is the right thing to do, I'm not 100% sure though.
H.J.?

[Bug gcov-profile/48463] gcov generating bad function coverage

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|major   |normal

--- Comment #1 from Andrew Pinski  2011-04-05 
19:02:57 UTC ---
>The mangled names differ only in the parts: D0, D1, D2. 

This is because the ABI defines these names.  IIRC this has been improved in
4.5 or 4.6 where only one gets defined now and the rest are aliases.

[Bug debug/48466] [4.4/4.5/4.6 Regression] Wrong variable locations at -O0 on i686

[hjl.tools at gmail dot com]

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

--- Comment #2 from H.J. Lu  2011-04-05 19:12:53 
UTC ---
(In reply to comment #1)
> Created attachment 23885 [details]
> gcc46-pr48466.patch
> 
> This seems to work and doesn't regress PR36977 (which I've added as guality
> testcase too).  Whether it is the right thing to do, I'm not 100% sure though.
> H.J.?

Looks good to me.  Thanks.

[Bug bootstrap/48469] New: [4.7 Regression] bootstrap failure

[hjl.tools at gmail dot com]

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

   Summary: [4.7 Regression] bootstrap failure
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com


On Linux/ia32, revision 171995 gave

../../src-trunk/gcc/combine.c: In function 'combine_instructions':
../../src-trunk/gcc/combine.c:1142:17: error: unused variable 'links'
[-Werror=unused-variable]

[Bug bootstrap/48469] [4.7 Regression] bootstrap failure

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 CC||froydnj at codesourcery dot
   ||com
   Target Milestone|--- |4.7.0

--- Comment #1 from H.J. Lu  2011-04-05 19:30:49 
UTC ---
It may be caused by revision 171995:

http://gcc.gnu.org/ml/gcc-cvs/2011-04/msg00188.html

[Bug bootstrap/48469] [4.7 Regression] bootstrap failure

[froydnj at gcc dot gnu.org]

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

--- Comment #2 from Nathan Froyd  2011-04-05 
19:33:52 UTC ---
Author: froydnj
Date: Tue Apr  5 19:33:49 2011
New Revision: 171998

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=171998
Log:
PR bootstrap/48469
* combine.c (combine_instructions): #ifdef AUTO_INC_DEC links
declaration.

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

[Bug c/48470] New: ICE in expand_expr_addr_expr_1 at expr.c:6835

[gcc.ourteddybear at xoxy dot net]

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

   Summary: ICE in expand_expr_addr_expr_1 at expr.c:6835
   Product: gcc
   Version: 4.4.5
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: gcc.ourteddyb...@xoxy.net


Created attachment 23886
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23886
Proprocessed source (built with -E, since -save-temps is an unrecognized
option)

Version (output from --version, since -v is apparently a verbose flag, not a
version flag):

GNU C (GCC) version 4.4.5 (arm-unknown-elf)
compiled by GNU C version 3.4.4 (mingw special), GMP version 4.3.2,
MPFR
 version 2.4.2.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072


Command line:

"C:/Program Files/Rowley Associates Limited/CrossWorks for ARM 2.0/gcc/bin/cc1"
-fmessage-length=0 -mcpu=arm7tdmi -mthumb-interwork -mlittle-endian -mfpu=vfp
-mfloat-abi=soft -nostdinc "-isystemC:/Program Files/Rowley Associates
Limited/CrossWorks for ARM 2.0/include" "-isystemC:/Documents and
Settings/sacleary/Local Settings/Application Data/Rowley Associates
Limited/CrossWorks for ARM/packages/include" "-IC:/Code/v2/LN-200
IMU/../Components/include/FreeRTOS" "-IC:/Code/v2/LN-200
IMU/../Components/include/lwIP" "-IC:/Code/v2/LN-200
IMU/../Components/include/lwIP/ipv4" "-IC:/Code/v2/LN-200
IMU/../Components/include/lwIP glue" -I. "-IC:/Code/v2/LN-200
IMU/../Components/include" "-IC:/Code/v2/LN-200 IMU/../Common"
-D__ARM_ARCH_4T__ -D__CROSSWORKS_ARM -D__CROSSWORKS_MAJOR_VERSION=2
-D__CROSSWORKS_MINOR_VERSION=0 -D__CROSSWORKS_REVISION=8
-D__TARGET_PROCESSOR=AT91SAM7X256 -DOSCILLATOR_CLOCK_FREQUENCY=18432000
"-DBOARDINIPATH = "imu.ini"" "-DdefaultIPAddr = 0x0006000A" "-DdefaultCANAddr =
0x00100600" "-DdefaultMacAddrA = 0x06" "-DBOARD_ID = BOARD_TYPE_LN200"
"-D_DRIVES = 1" -D__THUMB -D__FLASH_BUILD -DNDEBUG -DSAM7_GCC -DTHUMB_INTERWORK
-DSUPERVISOR_START -DSMARTPIGHARDWARE -MD "FPGA ISR.d" -MQ "FPGA ISR.o" -Werror
-quiet -g1 -Wall -Wextra -Wstrict-prototypes -Wmissing-prototypes
-Wmissing-declarations -fms-extensions -O1 -fno-dwarf2-cfi-asm -fno-builtin
"C:/Code/v2/LN-200 IMU/FPGA ISR.c"

[Bug bootstrap/48469] [4.7 Regression] bootstrap failure

[sje at cup dot hp.com]

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

Steve Ellcey  changed:

   What|Removed |Added

 CC||sje at cup dot hp.com

--- Comment #3 from Steve Ellcey  2011-04-05 20:32:01 
UTC ---
Is this the same problem I am seeing on IA64:

/proj/opensrc_nobackup/sje/reg/src/trunk/gcc/dbxout.c:107:12: error:
'debug_nesting' defined but not used [-Werror=unused-variable]
/proj/opensrc_nobackup/sje/reg/src/trunk/gcc/dbxout.c:109:14: error:
'symbol_queue' defined but not used [-Werror=unused-variable]
/proj/opensrc_nobackup/sje/reg/src/trunk/gcc/dbxout.c:110:12: error:
'symbol_queue_index' defined but not used [-Werror=unused-variable]
/proj/opensrc_nobackup/sje/reg/src/trunk/gcc/dbxout.c:111:12: error:
'symbol_queue_size' defined but not used [-Werror=unused-variable]
cc1: all warnings being treated as errors

I think it is coming from this change, though I don't see a ChangeLog
entry for it.


r171981 | froydnj | 2011-04-05 05:02:55 -0700 (Tue, 05 Apr 2011) | 8 lines

* debug.h (debug_flush_symbol_queue, debug_queue_symbol): Delete.
(debug_free_queue, debug_nesting, symbol_queue_index): Delete.
* final.c (debug_flush_symbol_queue, debug_queue_symbol):
Move these...
(debug_free_queue, debug_nesting, symbol_queue_index):
...and these...
* dbxout.c: ...to here.  Make static.

[Bug bootstrap/48469] [4.7 Regression] bootstrap failure

[froydnj at gcc dot gnu.org]

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

Nathan Froyd  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||froydnj at gcc dot gnu.org
 Resolution||FIXED

--- Comment #4 from Nathan Froyd  2011-04-05 
20:36:15 UTC ---
No, it's not the same change.  If you like, you could open a different PR and I
could attach a patch I think works.

[Bug middle-end/48377] [4.6 regression] miscompilation at -O3

[matt at use dot net]

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

--- Comment #6 from Matt Hargett  2011-04-05 20:38:41 UTC 
---
in the 46bug/ dir in the attached tarball:
g++ -O3 -g -I. -c te_field_id.cpp && g++ *.o -o test

induces the crash:

==31412==  General Protection Fault
==31412==at 0x400F38: TE_Field_id::Initialize_token_maps()
(hashmap.hpp:710)
==31412==by 0x4017A8: main (te_main.cpp:5)


This is the same crash I described before. Compiling with -O2 eliminates the
crash. In te_field_id.hpp, there is a commented out
__attribute__((optimize(2))). In the non-reduced case, adding that annotation
just moves the crash around. I may file a separate bug for that, depending on
the outcome of this bug.