[Bug fortran/55591] strict-aliasing & Fortran

[Joost.VandeVondele at mat dot ethz.ch]

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



Joost VandeVondele  changed:



   What|Removed |Added



 CC||Joost.VandeVondele at mat

   ||dot ethz.ch



--- Comment #4 from Joost VandeVondele  
2012-12-19 07:47:41 UTC ---

(In reply to comment #3)

> Untested (but successfully compiled) patch:



I would say, deserves to be posted, since it fixes PR55585 as a side effect. I

have been running with -fstrict-aliasing now at -O1, and this looks good.

[Bug gcov-profile/55734] [4.8 Regression] gcov-io.c uses builtins not available in non-GCC compilers

[tejohnson at google dot com]

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



--- Comment #13 from Teresa Johnson  2012-12-19 
06:49:50 UTC ---

On Tue, Dec 18, 2012 at 2:48 PM, Teresa Johnson  wrote:

>

>

>

>

> On Tue, Dec 18, 2012 at 2:41 PM, aldyh at gcc dot gnu.org 
>  wrote:

>>

>>

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

>>

>> --- Comment #11 from Aldy Hernandez  2012-12-18 
>> 22:41:13 UTC ---

>> Teresa, I think this is what you were referring to, and the reason for my

>> original patch:

>>

>> houston:/build/trunkboot$ ./install/bin/gcc a.c -fprofile-generate

>> /home/build/trunkboot/install/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.8.0/libgcov.a(_gcov.o):

>> In function `gcov_histo_index':

>> libgcov.c:(.text+0x213): undefined reference to `clz_hwi'

>> /home/build/trunkboot/install/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.8.0/libgcov.a(_gcov.o):

>> In function `__gcov_read_summary':

>> libgcov.c:(.text+0x7f3): undefined reference to `popcount_hwi'

>> collect2: error: ld returned 1 exit status

>

>

> Yep. I've got a patch in the works that is a slightly simplified version of 
> what you did. I'll send that a little later today once I get it tested.





Here is the patch. I am doing some final regression testing on it, but

earlier testing and my own testing looked good. It is similar to what

Aldy did, pulling some of the hwi routines into a new hwint-helper.c

file. However, in this case, it is included normally into hwint.c, and

the routines are only pulled in as static copies to gcov-io.c when we

are building libgcov.a (in other cases gcov-io.c is being built when

system.h is included, which includes hwint.h already). In the case of

libgcov.a, I also had to add support for the fact that the HOST_*

variables that were being used in the hwint routines are not defined.



Richard, let me know if this looks like a reasonable approach. The

only other solution I had was to simply inline copies of popcount_hwi

and clz_hwi into gcov-io.c when we are building libgcov.a.



Thanks,

Teresa



2012-12-18  Teresa Johnson  

Aldy Hernandez  



* hwint-helper.c (floor_log2): Moved from hwint.c

(ceil_log2): Ditto.

(exact_log2): Ditto.

(ctz_hwi): Ditto.

(clz_hwi): Ditto.

(ffs_hwi): Ditto.

(popcount_hwi): Ditto.

* gcov-io.c (gcov_read_summary): Invoke popcount_hwi.

(gcov_histo_index): Invoke clz_hwi.

* Makefile.in (hwint.o): Depend on hwint-helper.c

* hwint.c (floor_log2): Moved to hwint-helper.c

(ceil_log2): Ditto.

(exact_log2): Ditto.

(ctz_hwi): Ditto.

(clz_hwi): Ditto.

(ffs_hwi): Ditto.

(popcount_hwi): Ditto.



Index: hwint-helper.c

===

--- hwint-helper.c (revision 0)

+++ hwint-helper.c (revision 0)

@@ -0,0 +1,130 @@

+/* Supporting bit functions for older versions of GCC, and non-GCC

+   bootstrap compilers.

+

+   Copyright (C) 1987, 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998,

+   1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010,

+   2012 Free Software Foundation, Inc.

+

+This file is part of GCC.

+

+GCC is free software; you can redistribute it and/or modify it under

+the terms of the GNU General Public License as published by the Free

+Software Foundation; either version 3, or (at your option) any later

+version.

+

+GCC is distributed in the hope that it will be useful, but WITHOUT ANY

+WARRANTY; without even the implied warranty of MERCHANTABILITY or

+FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License

+for more details.

+

+Under Section 7 of GPL version 3, you are granted additional

+permissions described in the GCC Runtime Library Exception, version

+3.1, as published by the Free Software Foundation.

+

+You should have received a copy of the GNU General Public License and

+a copy of the GCC Runtime Library Exception along with this program;

+see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see

+.  */

+

+#if GCC_VERSION < 3004

+

+/* The functions clz_hwi, ctz_hwi, ffs_hwi, floor_log2, ceil_log2,

+   and exact_log2 are defined as inline functions in hwint.h

+   if GCC_VERSION >= 3004.

+   The definitions here are used for older versions of GCC and

+   non-GCC bootstrap compilers.  */

+

+/* Given X, an unsigned number, return the largest int Y such that 2**Y <= X.

+   If X is 0, return -1.  */

+

+HWINT_LINKAGE int

+floor_log2 (HWINT_TYPE x)

+{

+  int t = 0;

+

+  if (x == 0)

+return -1;

+

+  if (HWINT_TYPE_SIZE > 64)

+if (x >= (HWINT_TYPE) 1 << (t + 64))

+  t += 64;

+  if (HWINT_TYPE_SIZE > 32)

+if (x >= ((HWINT_TYPE) 1) << (t + 32))

+  t += 32;

+  if (x >= ((HWINT_TYPE) 1) << (t + 16))

+t += 16;

+  if (x >= ((HWINT_TYPE) 1) << (t + 8))

+t += 8;

+  if (x >= ((HWINT_TYPE) 1) << (t + 4))

+t += 4;

+  if (x >= ((HWINT_TYPE) 1) << (t + 2))

+t += 2;

+  if (x >= ((HWINT_TYPE) 1) << (t + 1))

+t += 1;

+

+

[Bug lto/55736] lto ICE: tree code ''junl is not supported in LTO streams

[kilobyte at angband dot pl]

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

--- Comment #1 from Adam Borowski  2012-12-19 
00:57:12 UTC ---
Fails on armhf as well:
lto1: internal compiler error: tree code ‘\�PF9F���G�P.�.lЕ�"0�+’ is not
supported in LTO streams

Works on i386.

[Bug c++/55737] Template and the constant, short-form if-then-else condition issue

[pinskia at gcc dot gnu.org]

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



--- Comment #1 from Andrew Pinski  2012-12-19 
00:24:09 UTC ---

I think GCC is correct here as for a?b:c to be an integer constant expression,

all three (a, b, and c) have to be an integer constant expressions even if a is

true or false.

[Bug c++/55737] New: Template and the constant, short-form if-then-else condition issue

[greenscape777 at gmail dot com]

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

 Bug #: 55737
   Summary: Template and the constant, short-form if-then-else
condition issue
Classification: Unclassified
   Product: gcc
   Version: 4.6.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: greenscape...@gmail.com


Please part me if the summary isn't so informative. Can't put what's on my mind
in a few words.

So my system info is:
gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Linux 3.2.0-34-generic-pae #53-Ubuntu SMP Thu Nov 15 11:11:12 UTC 2012 i686
athlon i386 GNU/Linux

Consider the next code snippet:

template 
struct DivByX
{
enum
{
value1 = X,
value2 = int(100.f / value1)
};
};

enum
{
valueA = 0,
/// False branch in the condition should never be taken into account.
/// And moreover, template should be constructed.
valueB = (/* Always false >>>*/1 > 2 /*<<<*/) ? /* False branch >>>*/((1 <
DivByX<0>::value2) ? 2 : 3)/*<<<*/ : 1
};


I did some template research and stumbled upon this annoying bug. It's really
annoying because i need to do stuff like:

template 
struct DivByX
{
enum
{
real_x = X == 0 ? 1 : X,
value1 = X,
value2 = int(100.f / value1)
};
};

So the problem hides in the if-then-else branch, that is discarded because of
the condition, but in fact processed by the compiler. Though this happens only
when in the false branch expression there is template used. The error i get:

test.cpp: In instantiation of ‘DivByX<0>’:
test.cpp:63:89:   instantiated from here
test.cpp:52:5: warning: division by zero [-Wdiv-by-zero]
test.cpp:52:5: error: ‘(1.0e+2f / 0.0f)’ is not a constant expression
test.cpp:52:5: error: enumerator value for ‘value2’ is not an integer constant

To give some comparison: clang works as intended.

Thank you for your attention.

[Bug target/55721] -mabi=64 compilation results in unknown UNSPEC note

[pinskia at gcc dot gnu.org]

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



--- Comment #5 from Andrew Pinski  2012-12-19 
00:04:57 UTC ---

(In reply to comment #4)

> (In reply to comment #1)

> > Actually the MIPS backend does have an UNSPEC 230.  It is one of the

> > SYMBOL_64_* unspecs.

> 

> Then, why is symbol_type not defined within define_c_enum "unspec"?

> That'd make the dumps easier to interpret, the name will be printed...



These unspecs don't show up at all in the .md file and it looks like Richard S.

did not change how the ADDRESS unspecs were handled when he implemented

define_c_enum in the first place:

http://gcc.gnu.org/ml/gcc-patches/2010-05/msg01180.html

http://gcc.gnu.org/ml/gcc-patches/2010-05/msg02353.html

[Bug gcov-profile/55734] [4.8 Regression] gcov-io.c uses builtins not available in non-GCC compilers

[tejohnson at google dot com]

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



--- Comment #12 from Teresa Johnson  2012-12-18 
22:49:20 UTC ---

On Tue, Dec 18, 2012 at 2:41 PM, aldyh at gcc dot gnu.org <

gcc-bugzi...@gcc.gnu.org> wrote:



>

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

>

> --- Comment #11 from Aldy Hernandez  2012-12-18

> 22:41:13 UTC ---

> Teresa, I think this is what you were referring to, and the reason for my

> original patch:

>

> houston:/build/trunkboot$ ./install/bin/gcc a.c -fprofile-generate

>

> /home/build/trunkboot/install/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.8.0/libgcov.a(_gcov.o):

> In function `gcov_histo_index':

> libgcov.c:(.text+0x213): undefined reference to `clz_hwi'

>

> /home/build/trunkboot/install/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.8.0/libgcov.a(_gcov.o):

> In function `__gcov_read_summary':

> libgcov.c:(.text+0x7f3): undefined reference to `popcount_hwi'

> collect2: error: ld returned 1 exit status

>



Yep. I've got a patch in the works that is a slightly simplified version of

what you did. I'll send that a little later today once I get it tested.



Teresa



>

> --

> Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email

> --- You are receiving this mail because: ---

> You are on the CC list for the bug.

>

[Bug c/39464] [4.6/4.7/4.8 Regression] Attribute may_alias causes invalid warning

[jakub at gcc dot gnu.org]

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



--- Comment #15 from Jakub Jelinek  2012-12-18 
22:48:09 UTC ---

Author: jakub

Date: Tue Dec 18 22:48:04 2012

New Revision: 194594



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

Log:

PR c/39464

* c-typeck.c (convert_for_assignment): For -Wpointer-sign

warning require that both c_common_unsigned_type as well as

c_common_signed_type is the same for both mvl and mvr types.



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



Modified:

trunk/gcc/c/ChangeLog

trunk/gcc/c/c-typeck.c

trunk/gcc/testsuite/ChangeLog

[Bug target/55721] -mabi=64 compilation results in unknown UNSPEC note

[steven at gcc dot gnu.org]

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



--- Comment #4 from Steven Bosscher  2012-12-18 
22:47:15 UTC ---

(In reply to comment #1)

> Actually the MIPS backend does have an UNSPEC 230.  It is one of the

> SYMBOL_64_* unspecs.



Then, why is symbol_type not defined within define_c_enum "unspec"?

That'd make the dumps easier to interpret, the name will be printed...

[Bug gcov-profile/55734] [4.8 Regression] gcov-io.c uses builtins not available in non-GCC compilers

[aldyh at gcc dot gnu.org]

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



--- Comment #11 from Aldy Hernandez  2012-12-18 
22:41:13 UTC ---

Teresa, I think this is what you were referring to, and the reason for my

original patch:



houston:/build/trunkboot$ ./install/bin/gcc a.c -fprofile-generate

/home/build/trunkboot/install/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.8.0/libgcov.a(_gcov.o):

In function `gcov_histo_index':

libgcov.c:(.text+0x213): undefined reference to `clz_hwi'

/home/build/trunkboot/install/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.8.0/libgcov.a(_gcov.o):

In function `__gcov_read_summary':

libgcov.c:(.text+0x7f3): undefined reference to `popcount_hwi'

collect2: error: ld returned 1 exit status

[Bug other/54814] [4.8 Regression] ICE: unable to find a register to spill in class 'R0_REG'

[gjl at gcc dot gnu.org]

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



--- Comment #13 from Georg-Johann Lay  2012-12-18 
22:33:41 UTC ---

(In reply to comment #12)

> Created attachment 28990 [details]

> Better patch

> 

> Sorry for doing this, but here's a slightly improved version of the patch. 
> Does

> this also fix the issue?



Yes, at least I don't see "spill in class 'R0_REG'" in the testsuite with

attachment 28990.

[Bug go/55201] [4.8 regression] libgo.so: undefined reference to `__atomic_compare_exchange_8'

[ian at gcc dot gnu.org]

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



--- Comment #5 from ian at gcc dot gnu.org  2012-12-18 
22:07:43 UTC ---

Author: ian

Date: Tue Dec 18 22:07:38 2012

New Revision: 194593



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

Log:

libgo: Link against libatomic_convenience.la.



gcc/go:

PR go/55201

* gospec.c: Revert last patch.



gcc/testsuite:

PR go/55201

* lib/go.exp: Revert last patch.



Modified:

trunk/gcc/go/ChangeLog

trunk/gcc/go/gospec.c

trunk/gcc/testsuite/ChangeLog

trunk/gcc/testsuite/lib/go.exp

trunk/libgo/Makefile.am

trunk/libgo/Makefile.in

[Bug go/55201] [4.8 regression] libgo.so: undefined reference to `__atomic_compare_exchange_8'

[ian at gcc dot gnu.org]

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



--- Comment #4 from ian at gcc dot gnu.org  2012-12-18 
22:04:13 UTC ---

Author: ian

Date: Tue Dec 18 22:04:08 2012

New Revision: 194592



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

Log:

PR go/55201

* Makefile.am (noinst_LTLIBRARIES): Define new make variable.

(libatomic_convenience_la_SOURCES): Likewise.

(libatomic_convenience_la_LIBADD): Likewise.

* Makefile.in: Rebuild.

* testsuite/Makefile.in: Rebuild.



Modified:

trunk/libatomic/ChangeLog

trunk/libatomic/Makefile.am

trunk/libatomic/Makefile.in

trunk/libatomic/testsuite/Makefile.in

[Bug libstdc++/54351] ~unique_ptr() should not set stored pointer to null

[gromer at google dot com]

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



--- Comment #11 from Geoff Romer  2012-12-18 21:59:23 
UTC ---

>From discussion on the C++ LWG reflector, it appears that the standard's

requirements on library types are intended to apply only during their lifetime,

although the standard does not currently make this clear. LWG 2224

(http://cplusplus.github.com/LWG/lwg-active.html#2224) is tracking this issue,

and its resolution should give a definitive answer.



That being the case, the old behavior was not a bug, but conformant with the

the intent of the standard (if not the precise wording). The new behavior is

conformant as well, of course, so it's up to you whether to revert the changes;

I just wanted to document for future reference that ~unique_ptr is in fact

permitted to modify the stored pointer before invoking the deleter, so this bug

report should not be an obstacle to e.g. having ~unique_ptr store a poison

value in order to catch client bugs.

[Bug target/55562] [4.8 Regression] FAIL: gcc.dg/sms-* on powerpc*-*-*

[jakub at gcc dot gnu.org]

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



--- Comment #6 from Jakub Jelinek  2012-12-18 
21:40:36 UTC ---

Author: jakub

Date: Tue Dec 18 21:40:29 2012

New Revision: 194591



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

Log:

PR target/55562

* sbitmap.c (bitmap_and, bitmap_xor, bitmap_ior): Return whether

dst sbitmap changed even if it doesn't have popcount.



Modified:

trunk/gcc/ChangeLog

trunk/gcc/sbitmap.c

[Bug c/52991] attribute packed broken on mingw32?

[ktietz at gcc dot gnu.org]

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



--- Comment #10 from Kai Tietz  2012-12-18 21:35:27 
UTC ---

(In reply to comment #9)

> It doesn't look to me that the first two hunks of the patch are needed.



Yes, that's right.



> The last hunk doesn't look like it should be considering either TYPE_PACKED

> of the parent structure, or TYPE_ALIGN of the field type, but rather

> using DECL_ALIGN of the field.  Which ought already have been assigned

> by layout_decl via update_alignment_for_field.



Well, nothing considers TYPE_PACKED of the parent structure for ms_struct.  The

field's type-alignment needs to be considered for checking, if type has

user-specified alignment AFAICS.



> The biggest problem to me appears to be the entire ms_bitfield_layout_p

> block of code there, whose block comments talk about adjusting bitfields,

> and yet is firing for structures that contain no bitfields at all.  That

> tells me that the logic higher in the block (or elsewere wrt 
> bitfield_layout_p)

> is in error.

That isn't the fully story for ms_struct here, the ms_biffield_layout_p block

has  as internal packing of same-types - that's not related to aligned or

packed attributes at all - and needs to be done dependent to its offset, when

type's offset is known.   So there is no logical-error in this code, beside. 

Nevertheless I admit that the ms_struct code-path and the gnu_struct code-path

could win by separating them, and for both some documention about used schema

in source would be great.



In general it would be great to have somebody with a VC, who would be willing

to compile some test-cases by this VC.  The documention about structure-layout

on msdn it pretty poor and most stuff needs to be collected or done via

best-guess.  User-specified alignment within structures (not via #pragma pack)

seems to be introduced in recent VC versions, so tester should have a modern

version.

[Bug lto/55736] New: lto ICE: tree code ''junl is not supported in LTO streams

[kilobyte at angband dot pl]

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

 Bug #: 55736
   Summary: lto ICE: tree code ''junl is not supported in LTO
streams
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: kilob...@angband.pl


Created attachment 29004
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29004
massive amd64 example

Another LTO breakage:
lto1: internal compiler error: tree code ‘�’ is not supported in LTO
streams

Too bad, the smallest test case I have right now is 73 files big (attached,
preprocessed for x86-64).  Multidelta takes an enormous amount of time: after
~36 hours, it processed only first --level=0 run on four of the files, and
they're still massive after deltaing.  Thus, this test case is enormous, sorry.

Fails on amd64 with gcc-4.8 svn 194557 (Debian 4.8-20121217-1) and gcc-snapshot
(trunk), 4.7 works fine.  So does 4.8 on i386.

[Bug c++/55726] assignment of a scalar to a vector

[glisse at gcc dot gnu.org]

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



Marc Glisse  changed:



   What|Removed |Added



 CC|marc.glisse at ens dot fr   |glisse at gcc dot gnu.org



--- Comment #3 from Marc Glisse  2012-12-18 20:53:52 
UTC ---

If I have:

void f(double);

void f(float32x4_t);

float a;

what should f(a) do? Not sure that's the right question (I am sick this week,

so I have an excuse for posting nonsense), but hopefully you see the point,

adding implicit conversions has a lot of consequences, which might be good but

need to be considered.

[Bug rtl-optimization/55672] [4.8 Regression] -fstack-check=generic ICEs in print_reg, at config/i386/i386.c:13868

[hjl.tools at gmail dot com]

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



H.J. Lu  changed:



   What|Removed |Added



  Component|target  |rtl-optimization



--- Comment #8 from H.J. Lu  2012-12-18 20:35:17 
UTC ---

(In reply to comment #4)

> If stack_realign_p is true, frame_pointer_needed is also true.   So we can use

> fp to eliminate frame but i386.c::x86_can_eliminate prohibits it.  The code

> looks strange:

> 

> 

>  if (stack_realign_fp)

> return ((from == ARG_POINTER_REGNUM

>  && to == HARD_FRAME_POINTER_REGNUM)

> || (from == FRAME_POINTER_REGNUM

> && to == STACK_POINTER_REGNUM));

> 

> So we permit to change argument pointer but not frame pointer to FP which 
> again

> is strange IMHO.   Changing the code to

> 

>  if (stack_realign_fp)

> return ((from == ARG_POINTER_REGNUM

>  && to == HARD_FRAME_POINTER_REGNUM)

> || (from == FRAME_POINTER_REGNUM

> && to == STACK_POINTER_REGNUM)

> || (from == FRAME_POINTER_REGNUM

> && to == HARD_FRAME_POINTER_REGNUM));

> 

> solves the problem.



It fixes ICE, but generates questionable code:



main:

.LFB0:

.cfi_startproc

pushl%ebp

.cfi_def_cfa_offset 8

.cfi_offset 5, -8

movl%esp, %ebp

.cfi_def_cfa_register 5

andl$-16, %esp

subl$8236, %esp

orl$0, (%esp)

addl$8204, %esp

cmpl$4, -40(%ebp)

je.L2

callabort

.L2:

movl$0, %eax

leave

.cfi_restore 5

.cfi_def_cfa 4, 4

ret



Without LRA, we got



main:

.LFB0:

.cfi_startproc

pushl%ebp

.cfi_def_cfa_offset 8

.cfi_offset 5, -8

movl%esp, %ebp

.cfi_def_cfa_register 5

andl$-16, %esp

subl$8236, %esp

orl$0, (%esp)

addl$8204, %esp

cmpl$4, (%esp)

je.L2

callabort

.L2:

movl$0, %eax

leave

.cfi_restore 5

.cfi_def_cfa 4, 4

ret



The difference is



--- x.s2012-12-18 12:24:17.072888139 -0800

+++ no-lra.s2012-12-18 12:30:11.419157548 -0800

@@ -14,7 +14,7 @@ main:

 subl$8236, %esp

 orl$0, (%esp)

 addl$8204, %esp

-cmpl$4, -40(%ebp)

+cmpl$4, (%esp)

 je.L2

 callabort

 .L2:



I think LRA generated code is wrong.  The reason we don't allow

converting software frame pointer to hardware frame pointer is

when stack alignment is needed, hardware frame pointer is used

to save stack pointer.  We can no longer use it for software

frame pointer.

[Bug fortran/55735] ICE with deferred-length strings in COMMON

[burnus at gcc dot gnu.org]

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



--- Comment #3 from Tobias Burnus  2012-12-18 
20:04:12 UTC ---

(In reply to comment #2)

> (In reply to comment #1)

> > Postscript: The example in comment 0 mixes a scalar and an array pointers.

> > While the ICE occurs with either, the declaration should be consistent.

>

> I could be wrong, but I believe that the program in comment 0

> is invalid.



Mixing scalars and arrays is invalid. But as written, the same ICE occurs if

one has only arrays or only scalars (which I intended but didn't post). And do

I believe the program(s) is (are) valid in that case.





> I doubt that it is possible to catch the rank mismatch



Well, the compiler does warn that the named common blocks have a different

size.

[Bug target/55672] [4.8 Regression] -fstack-check=generic ICEs in print_reg, at config/i386/i386.c:13868

[hjl.tools at gmail dot com]

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



--- Comment #7 from H.J. Lu  2012-12-18 19:42:59 
UTC ---

LRA doesn't handle HARD_FRAME_POINTER_IS_FRAME_POINTER at all.

[Bug libstdc++/55727] better support for dynamic allocation of over-aligned types

[kretz at kde dot org]

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



Matthias Kretz  changed:



   What|Removed |Added



  Attachment #29002|0   |1

is obsolete||



--- Comment #5 from Matthias Kretz  2012-12-18 18:30:43 
UTC ---

Created attachment 29003

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29003

updated the patch

[Bug libstdc++/55727] better support for dynamic allocation of over-aligned types

[kretz at kde dot org]

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

--- Comment #4 from Matthias Kretz  2012-12-18 18:20:00 
UTC ---
Created attachment 29002
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29002
support for over-aligned types in new_allocator

I finished my allocator to fix the issue and it was easy to port it over to
new_allocator. So here's the patch.

Questions:
1. I use sizeof(void*) for the natural alignment or alignof(std::max_align_t)
for C++11. Is there a better way to do this?
2. I'm not sure you like the way I abuse enum for compile-time constants. May I
use constexpr, or would that have to be ifdefed?
3. What's the proper integer type to use for pointer manipulation? I'd really
like to write __p &= ~__alignment_mask, but I don't see how to not breaking
strict-aliasing with this.

Note that new_allocator will compile to the same code as long as alignof(_Tp1)
is <= alignof(std::max_align_t). The extra code to handle alignment will only
kick in for over-aligned types - and those want the extra complexity.

[Bug c++/55724] [4.7/4.8 Regression] [C++11] Default type of a template value is not working

[jason at gcc dot gnu.org]

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



Jason Merrill  changed:



   What|Removed |Added



 Status|NEW |ASSIGNED

 CC||jason at gcc dot gnu.org

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

   |gnu.org |

[Bug target/55562] [4.8 Regression] FAIL: gcc.dg/sms-* on powerpc*-*-*

[dje at gcc dot gnu.org]

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



--- Comment #5 from David Edelsohn  2012-12-18 17:30:55 
UTC ---

I did a quick test on powerpc-ibm-aix and the patch seems to fix the problem.



You should have access to a lot of PPC systems for testing.

[Bug bootstrap/50148] GCC fails to bootstrap with -O3 due to "may be used uninitialized" errors

[matt at use dot net]

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

--- Comment #6 from Matt Hargett  2012-12-18 17:26:54 UTC 
---
Applying the supplied patch reveals another issue underneath, which is a false
positive:

/work/mhargett/gcc-trunk-obj/./prev-gcc/xg++
-B/work/mhargett/gcc-trunk-obj/./prev-gcc/
-B/u/mhargett/x86_64-unknown-linux-gnu/bin/ -nostdinc++
-B/work/mhargett/gcc-trunk-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs
-B/work/mhargett/gcc-trunk-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
-I/work/mhargett/gcc-trunk-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu
-I/work/mhargett/gcc-trunk-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include
-I/work/mhargett/gcc-trunk/libstdc++-v3/libsupc++
-L/work/mhargett/gcc-trunk-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs
-L/work/mhargett/gcc-trunk-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
  -g -O2 -O3 -march=nocona -mtune=core2 -floop-block -floop-interchange
-floop-strip-mine -flto=jobserver -frandom-seed=1 -DIN_GCC   -fno-exceptions
-fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -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 gengtype \
gengtype.o gengtype-lex.o gengtype-parse.o gengtype-state.o version.o
errors.o libcommon.a ../libcpp/libcpp.a ../libiberty/libiberty.a
../libdecnumber/libdecnumber.a ../libbacktrace/.libs/libbacktrace.a libcommon.a
../libcpp/libcpp.a   ../libbacktrace/.libs/libbacktrace.a
../libiberty/libiberty.a ../libdecnumber/libdecnumber.a 
In file included from ../../gcc-trunk/libiberty/cp-demangle.c:876:0,
 from :51:
../../gcc-trunk/libbacktrace/elf.c: In function ‘elf_add’:
../../gcc-trunk/libbacktrace/mmapio.c:98:14: error: ‘ehdr_view.len’ may be used
uninitialized in this function [-Werror=maybe-uninitialized]
   if (munmap (const_cast.v, view->len) < 0)
  ^
In file included from ../../gcc-trunk/libiberty/cp-demangle.c:879:0,
 from :51:
../../gcc-trunk/libbacktrace/elf.c:476:25: note: ‘ehdr_view.len’ was declared
here
   struct backtrace_view ehdr_view;
 ^
In file included from ../../gcc-trunk/libiberty/cp-demangle.c:876:0,
 from :51:
../../gcc-trunk/libbacktrace/mmapio.c:98:14: error: ‘ehdr_view.base’ may be
used uninitialized in this function [-Werror=maybe-uninitialized]
   if (munmap (const_cast.v, view->len) < 0)
  ^
In file included from ../../gcc-trunk/libiberty/cp-demangle.c:879:0,
 from :51:
../../gcc-trunk/libbacktrace/elf.c:476:25: note: ‘ehdr_view.base’ was declared
here
   struct backtrace_view ehdr_view;
 ^
In file included from ../../gcc-trunk/libiberty/cp-demangle.c:879:0,
 from :51:
../../gcc-trunk/libbacktrace/elf.c:516:10: error: ‘ehdr_view.data’ may be used
uninitialized in this function [-Werror=maybe-uninitialized]
   memcpy (&ehdr, ehdr_view.data, sizeof ehdr);
  ^
In file included from ../../gcc-trunk/libiberty/cp-demangle.c:879:0,
 from :51:
../../gcc-trunk/libbacktrace/elf.c:476:25: note: ‘ehdr_view.data’ was declared
here
   struct backtrace_view ehdr_view;
 ^
lto1: all warnings being treated as errors
make[4]: *** [/tmp/ccQGEpYR.ltrans15.ltrans.o] Error 1


in libbacktrace/elf.c, elf_add() calls backtrace_get_view(..., &ehdr_view).
ehdr_view isn't initialized. backtrace_get_view() will return 1 and leave
edhr_view uninitialized, but the potential uninitialized use of ehdr_view is
guarded in get_elf() with a 'goto fail'. Therefore, the uninitialized ehdr_view
would never get to backtrace_release_view().

Let me know if I should file a separate bug for this.

[Bug gcov-profile/55674] [4.8 Regression] >20% size increase of lto/pgo binaries since r193747

[hubicka at ucw dot cz]

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



--- Comment #17 from Jan Hubicka  2012-12-18 17:25:37 
UTC ---

> I did some measurements with tramp3d and in this case

> the default (999) gives the best performance:

> 

> par. sizetime

> 

> 999  955859  3.71752

> 990  933390  3.73969

> 980  904718  3.84547

> ...""

> 750  904718  3.84769

> 740  837654  7.67177

> 600  836024  8.80879



Yep, tramp3d is unforutnately quite special case: we measure the number of

instructions prior

late optimization, while in tramp3d over 90% of code disappear as a result of

inlining and further

simplification, so we get GIGO problem...



I am not sure how to handle these things in any resonable way



I will test couple of values on spec2k this week and lets see how things scale

elsewhere.



Honza

[Bug tree-optimization/55683] [4.8 Regression] ICE in inline_call, at ipa-inline-transform.c:270

[hubicka at gcc dot gnu.org]

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



--- Comment #11 from Jan Hubicka  2012-12-18 
17:15:51 UTC ---

Created attachment 29001

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29001

proposed patch



OK,

we know the argument is constant

 

unit size 

align 64 symtab 0 alias set 4 canonical type 0x77560f18 fields

 context 

full-name "struct C"

needs-constructor X() X(constX&) this=(X&) n_parents=0

use_template=0 interface-unknown

pointer_to_this  chain >

public unsigned DI

size 

unit size 

align 64 symtab 0 alias set -1 canonical type 0x775741f8>

constant

arg 0 

addressable used static tree_1 tree_3 decl_5 decl_6 BLK file t.C line

25 col 12 size  unit size 

align 128 context >>



ipa_get_indirect_edge_target used when we estimate effect of inlining goes into

path looking up the binfo based on constant



  if (TREE_CODE (t) != TREE_BINFO)

{ 

  tree binfo;

  binfo = gimple_extract_devirt_binfo_from_cst (t);

  if (!binfo)

return NULL_TREE;

  binfo = get_binfo_at_offset (binfo, anc_offset, otr_type);

  if (!binfo)

return NULL_TREE;

  return gimple_get_virt_method_for_binfo (token, binfo);

}



this code is missing in try_make_edge_direct_virtual_call that is actually

responsible for devirtualizing.  I am testing the attached patch.



If I read this right, we should get the problem every time we devirtualize

based on static object.  I am surprised this do not trigger in

testsuite/bootstrap.



Honza

[Bug c/52991] attribute packed broken on mingw32?

[rth at gcc dot gnu.org]

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



Richard Henderson  changed:



   What|Removed |Added



 CC||rth at gcc dot gnu.org



--- Comment #9 from Richard Henderson  2012-12-18 
17:14:37 UTC ---

It doesn't look to me that the first two hunks of the patch are needed.



The last hunk doesn't look like it should be considering either TYPE_PACKED

of the parent structure, or TYPE_ALIGN of the field type, but rather

using DECL_ALIGN of the field.  Which ought already have been assigned

by layout_decl via update_alignment_for_field.



The biggest problem to me appears to be the entire ms_bitfield_layout_p

block of code there, whose block comments talk about adjusting bitfields,

and yet is firing for structures that contain no bitfields at all.  That

tells me that the logic higher in the block (or elsewere wrt bitfield_layout_p)

is in error.

[Bug gcov-profile/55674] [4.8 Regression] >20% size increase of lto/pgo binaries since r193747

[markus at trippelsdorf dot de]

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



--- Comment #16 from Markus Trippelsdorf  
2012-12-18 17:03:52 UTC ---

I did some measurements with tramp3d and in this case

the default (999) gives the best performance:



par. sizetime



999  955859  3.71752

990  933390  3.73969

980  904718  3.84547

...""

750  904718  3.84769

740  837654  7.67177

600  836024  8.80879

[Bug gcov-profile/55734] [4.8 Regression] gcov-io.c uses builtins not available in non-GCC compilers

[aldyh at redhat dot com]

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



--- Comment #10 from Aldy Hernandez  2012-12-18 
16:48:40 UTC ---

Ah yes, now I remember.  Yes, there is a problem with libgcov.a.  I 

wasn't seeing it because I was only building cc1.  You are correct 

Teresa, that is the reason for the gymnastics in my original patch.



houston:/build/trunkboot/gcc$ nm libgcov.a |grep popc

  U popcount_hwi



I will let you and Richard sort it out :).

[Bug fortran/55735] ICE with deferred-length strings in COMMON

[kargl at gcc dot gnu.org]

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



kargl at gcc dot gnu.org changed:



   What|Removed |Added



 CC||kargl at gcc dot gnu.org



--- Comment #2 from kargl at gcc dot gnu.org 2012-12-18 16:47:10 UTC ---

(In reply to comment #1)

> Postscript: The example in comment 0 mixes a scalar and an array pointers.

> While the ICE occurs with either, the declaration should be consistent.



I could be wrong, but I believe that the program in comment 0

is invalid.



F2008: p. 116

A data pointer shall be storage associated only with data pointers of the

same type and rank.  Data pointers that are storage associated shall have

deferred the same type parameters; corresponding nondeferred type parameters

shall have the same value.



I doubt that it is possible to catch the rank mismatch (except 

maybe under -fwhole-program with everything in one file).

[Bug fortran/53732] [4.7/4.8 Regression] "mismatching comparison operand types" on compile

[dominiq at lps dot ens.fr]

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



Dominique d'Humieres  changed:



   What|Removed |Added



 CC||pmarguinaud at hotmail dot

   ||com



--- Comment #12 from Dominique d'Humieres  
2012-12-18 16:39:51 UTC ---

*** Bug 55729 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/55683] [4.8 Regression] ICE in inline_call, at ipa-inline-transform.c:270

[hubicka at gcc dot gnu.org]

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



--- Comment #10 from Jan Hubicka  2012-12-18 
16:39:47 UTC ---

OK,

we are inlining

Inline summary for bool C::c1(float, float)/7 inlinable

  self time:   34

  global time: 34

  self size:   18

  global size: 18

  self stack:  0

  global stack:0

  estimated growth:-6

size:1.50, time:1.50, predicate:(true)

size:3.50, time:2.50, predicate:(not inlined)

size:0.50, time:0.50, predicate:(op0[ref offset: 64] changed) &&

(not inlined)

size:0.50, time:0.50, predicate:(op0[ref offset: 64] changed)

size:2.00, time:2.00, predicate:(op0[ref offset: 64] changed || op1

changed)

size:0.50, time:0.355000, predicate:(op0[ref offset: 96] changed) &&

(not inlined)

size:0.50, time:0.355000, predicate:(op0[ref offset: 96] changed)

size:2.00, time:1.42, predicate:(op0[ref offset: 96] changed || op2

changed)

  calls:

void B::b2()/12 function body not available

  loop depth: 0 freq: 723 size: 2 time: 11 callee size: 0 stack: 0

indirect call loop depth: 0 freq:1000 size: 5 time: 17



into 



Inline summary for void bar()/8 inlinable

  self time:   38

  global time: 53

  self size:   22

  global size: 32

  self stack:  0

  global stack:0

size:14.50, time:8.849000, predicate:(true)

size:3.00, time:2.00, predicate:(not inlined)

  calls:

bool C::c1(float, float)/7 inlined

  loop depth: 0 freq:1000 size: 4 time: 13 callee size: 9 stack: 0

  Stack frame offset 0, callee self size 0, callee size 0

  void B::b2()/12 function body not available

loop depth: 0 freq: 723 size: 2 time: 11 callee size: 0 stack: 0

  indirect call loop depth: 0 freq:1000 size: 5 time: 17

double foo()/11 function body not available

  loop depth: 0 freq:1000 size: 2 time: 11 callee size: 0 stack: 0

void __cxa_guard_release(long long int*)/10 function body not available

  loop depth: 0 freq: 151 size: 2 time: 11 callee size: 0 stack: 0

   op0 is compile time invariant

int __cxa_guard_acquire(long long int*)/9 function body not available

  loop depth: 0 freq: 389 size: 3 time: 12 callee size: 0 stack: 0

   op0 is compile time invariant



ipa-inline-analysis figures out that we can devirtualize call to b3, but ipa-cp

won't.

So this seems another disagreement in between ipa-cp and ipa-prop...



Honza

[Bug fortran/55729] Problem with sum intrinsic

[dominiq at lps dot ens.fr]

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



Dominique d'Humieres  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||DUPLICATE



--- Comment #3 from Dominique d'Humieres  2012-12-18 
16:39:51 UTC ---

This appeared between revisions 180652, 2011-10-29 (OK), and 180989, 2011-11-04

(ICE), and has been fixed between revisions 188914, 2012-06-24 (still ICE), and

189336, 2012-07-06 (OK again). 



It looks like a duplicate of pr53732, fixed on trunk at revision 189292 and on

4.7 at revision 189341.



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

[Bug debug/54731] [4.8 regression] arm-elf/arm-eabisim crosses fails in make-check due to undefined LFE references: corrupt debug_line tables

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 Status|NEW |RESOLVED

 Resolution||FIXED



--- Comment #5 from Jakub Jelinek  2012-12-18 
16:37:21 UTC ---

Fixed then.

[Bug gcov-profile/55734] [4.8 Regression] gcov-io.c uses builtins not available in non-GCC compilers

[tejohnson at google dot com]

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



--- Comment #9 from Teresa Johnson  2012-12-18 
16:31:08 UTC ---

On Tue, Dec 18, 2012 at 8:25 AM, aldyh at gcc dot gnu.org

 wrote:

>

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

>

> Aldy Hernandez  changed:

>

>What|Removed |Added

> 

>   Attachment #28999|0   |1

> is obsolete||

>

> --- Comment #8 from Aldy Hernandez  2012-12-18 
> 16:25:49 UTC ---

> Created attachment 29000

>   --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29000

> proposed patch

>

> Duh, they're always available.  Like this?



Things will build, but you will presumably get an undefined symbol in

your libgcov.a, which would result in an undefined trying to build

with -fprofile-generate. Can you verify that this works. I just

checked with a similar change, which yields:



$ nm gcc/libgcov.a | grep popc

 U popcount_hwi



/home/tejohnson/extra/gcc_trunk_5_validate/bld-gcc/gcc/libgcov.a(_gcov.o):

In function `__gcov_read_summary':

libgcov.c:(.text+0x7f3): undefined reference to `popcount_hwi'

collect2: error: ld returned 1 exit status



Teresa



>

> --

> Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email

> --- You are receiving this mail because: ---

> You are on the CC list for the bug.







--

Teresa Johnson | Software Engineer | tejohn...@google.com | 408-460-2413

[Bug gcov-profile/55734] [4.8 Regression] gcov-io.c uses builtins not available in non-GCC compilers

[aldyh at gcc dot gnu.org]

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



Aldy Hernandez  changed:



   What|Removed |Added



  Attachment #28999|0   |1

is obsolete||



--- Comment #8 from Aldy Hernandez  2012-12-18 
16:25:49 UTC ---

Created attachment 29000

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29000

proposed patch



Duh, they're always available.  Like this?

[Bug fortran/55729] Problem with sum intrinsic

[pmarguinaud at hotmail dot com]

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



--- Comment #2 from pmarguinaud at hotmail dot com 2012-12-18 16:25:01 UTC ---

Hi Tobias,



I use gfortran 4.7.0. It was build and installed by our admin, as you can see

below : 



$ gfortran -v

Using built-in specs.

COLLECT_GCC=gfortran

COLLECT_LTO_WRAPPER=/home_nfs/softs/gnu/4.7.0/libexec/gcc/x86_64-unknown-linux-gnu/4.7.0/lto-wrapper

Target: x86_64-unknown-linux-gnu

Configured with: ./configure CC=/usr/bin/gcc --prefix=/home_nfs/softs/gnu/4.7.0

Thread model: posix

gcc version 4.7.0 (GCC) 



Our cluster is a SandyBridge with a RedHat 6.0; uname -a says :



Linux login0 2.6.32-220.23.1.bl6.Bull.28.8.x86_64 #1 SMP Thu Jul 5 17:34:18

CEST 2012 x86_64 x86_64 x86_64 GNU/Linux



I will try newer versions of gcc, as you suggest.

[Bug gcov-profile/55734] [4.8 Regression] gcov-io.c uses builtins not available in non-GCC compilers

[tejohnson at google dot com]

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



--- Comment #7 from Teresa Johnson  2012-12-18 
16:24:13 UTC ---

On Tue, Dec 18, 2012 at 7:53 AM, rguenth at gcc dot gnu.org

 wrote:

>

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

>

> --- Comment #5 from Richard Biener  2012-12-18 
> 15:53:42 UTC ---

> (In reply to comment #4)

>> (In reply to comment #3)

>> > In that thread, I had asked:

>> >

>> > ---

>> > If you prefer, I can simply inline the popcount/clz functionality into

>> > gcov-io.c directly (or at least when not using recent versions of

>> > GCC). But that in fact would be duplicating the code, when I thought

>> > Aldy's solution was trying to avoid that by providing the more general

>> > interfaces.

>> >

>> > Teresa

>> > ---

>> >

>> > but didn't get a response. Richard, is that your preferred route for

>> > fixing this issue?

>>

>> We already have popcount_hwi and clz_hwi available.  Can't you piggy-back

>> on that to provide (inline in gcov-io.c) popcountll and clzll?  Why do

>> you need the long long variants anyway?

>

> You don't seem to:

>

>   unsigned histo_bitvector[GCOV_HISTOGRAM_BITVECTOR_SIZE];

> ...

>  h_cnt += __builtin_popcountll (histo_bitvector[bv_ix]);

>

> so just use popcount_hwi.



The complication seems to be that hwint is not currently available for

libgcov.a (it is included by system.h which is not in libgcov.a). I

thought this was why Aldy took the approach of splitting out the hwi

routines into a separate helper file included by both hwint.c and

gcov-io. I can see if there is a way to simplify this, but I'm not

sure it is simple to include hwint into the gcov-io.c (and therefore

libgcov.a).



Teresa



>

> --

> Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email

> --- You are receiving this mail because: ---

> You are on the CC list for the bug.







--

Teresa Johnson | Software Engineer | tejohn...@google.com | 408-460-2413

[Bug other/54324] [4.8 Regression] GCC install document does not list minimum required g++ version

[aldyh at gcc dot gnu.org]

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



--- Comment #11 from Aldy Hernandez  2012-12-18 
16:22:11 UTC ---

Author: aldyh

Date: Tue Dec 18 16:21:57 2012

New Revision: 194586



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

Log:

PR other/54324

* doc/install.texi (Tools/packages necessary for building GCC):

Suggest --disable-stage1-checking for older GCC's.



Modified:

trunk/gcc/ChangeLog

trunk/gcc/doc/install.texi

[Bug gcov-profile/55734] [4.8 Regression] gcov-io.c uses builtins not available in non-GCC compilers

[aldyh at gcc dot gnu.org]

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



--- Comment #6 from Aldy Hernandez  2012-12-18 
16:19:33 UTC ---

Created attachment 28999

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28999

proposed patch



Oh, I didn't realize we always had the HWI variants available (inlined in

hwint.h).



Is something like this what you have in mind Richard?

[Bug fortran/55729] Problem with sum intrinsic

[burnus at gcc dot gnu.org]

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



Tobias Burnus  changed:



   What|Removed |Added



 CC||burnus at gcc dot gnu.org



--- Comment #1 from Tobias Burnus  2012-12-18 
16:12:59 UTC ---

Works for me with GCC 4.1 to 4.8: It compiles without any warning/error on

x86-64-linux.



What exactly is your GCC 4.7 version and which platform are you using?

("gfortran -v" shows this data. For instance, I used "4.7.2 20120920

[gcc-4_7-branch revision 191568]" on "x86_64-gnu-linux".)





GCC 4.7.0 can is either the 4.7.0 version, released on 2012-03-22, or to any

developer version between 2011-03-14 and that date.





You could additionally re-check whether a newer GCC 4.7 or current GCC 4.8

fixes the issue.

[Bug fortran/55735] ICE with deferred-length strings in COMMON

[burnus at gcc dot gnu.org]

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



Tobias Burnus  changed:



   What|Removed |Added



 CC||burnus at gcc dot gnu.org



--- Comment #1 from Tobias Burnus  2012-12-18 
16:06:14 UTC ---

Postscript: The example in comment 0 mixes a scalar and an array pointers.

While the ICE occurs with either, the declaration should be consistent.

[Bug fortran/55733] -fno-automatic: Fails for scalar allocatables

[burnus at gcc dot gnu.org]

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



Tobias Burnus  changed:



   What|Removed |Added



 CC||burnus at gcc dot gnu.org



--- Comment #3 from Tobias Burnus  2012-12-18 
15:59:28 UTC ---

Maybe for BLOCK DATA something similar has to be done. Cf. PR 55735.

[Bug fortran/55735] New: ICE with deferred-length strings in COMMON

[burnus at gcc dot gnu.org]

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



 Bug #: 55735

   Summary: ICE with deferred-length strings in COMMON

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Keywords: ice-on-valid-code

  Severity: normal

  Priority: P3

 Component: fortran

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

ReportedBy: bur...@gcc.gnu.org





I think the following test case it valid. In any case, an ICE is a bug. Vaguely

related is PR 55733.



block data

  character(len=:), pointer :: str(:)

  common /foo/ str

end block data



subroutine bar()

  character(len=:), pointer :: str

  common /foo/ str

!  print *, len(str), '"'//str//'"' !ICE in gfc_conv_intrinsic_len

  print '(3a)', '"',str(1:6),'"' ! ICE in gfc_conv_variable

end



character(len=:), pointer :: str(:)

common /foo/ str

allocate (character(len=6) :: str(1))

str = "ABCDEF"

call bar()

end

[Bug gcov-profile/55734] [4.8 Regression] gcov-io.c uses builtins not available in non-GCC compilers

[rguenth at gcc dot gnu.org]

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



--- Comment #5 from Richard Biener  2012-12-18 
15:53:42 UTC ---

(In reply to comment #4)

> (In reply to comment #3)

> > In that thread, I had asked:

> > 

> > ---

> > If you prefer, I can simply inline the popcount/clz functionality into

> > gcov-io.c directly (or at least when not using recent versions of

> > GCC). But that in fact would be duplicating the code, when I thought

> > Aldy's solution was trying to avoid that by providing the more general

> > interfaces.

> > 

> > Teresa

> > ---

> > 

> > but didn't get a response. Richard, is that your preferred route for

> > fixing this issue?

> 

> We already have popcount_hwi and clz_hwi available.  Can't you piggy-back

> on that to provide (inline in gcov-io.c) popcountll and clzll?  Why do

> you need the long long variants anyway?



You don't seem to:



  unsigned histo_bitvector[GCOV_HISTOGRAM_BITVECTOR_SIZE];

...

 h_cnt += __builtin_popcountll (histo_bitvector[bv_ix]);



so just use popcount_hwi.

[Bug gcov-profile/55734] [4.8 Regression] gcov-io.c uses builtins not available in non-GCC compilers

[rguenth at gcc dot gnu.org]

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



--- Comment #4 from Richard Biener  2012-12-18 
15:52:40 UTC ---

(In reply to comment #3)

> In that thread, I had asked:

> 

> ---

> If you prefer, I can simply inline the popcount/clz functionality into

> gcov-io.c directly (or at least when not using recent versions of

> GCC). But that in fact would be duplicating the code, when I thought

> Aldy's solution was trying to avoid that by providing the more general

> interfaces.

> 

> Teresa

> ---

> 

> but didn't get a response. Richard, is that your preferred route for

> fixing this issue?



We already have popcount_hwi and clz_hwi available.  Can't you piggy-back

on that to provide (inline in gcov-io.c) popcountll and clzll?  Why do

you need the long long variants anyway?

[Bug gcov-profile/55734] [4.8 Regression] gcov-io.c uses builtins not available in non-GCC compilers

[tejohnson at google dot com]

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



--- Comment #3 from Teresa Johnson  2012-12-18 
15:49:03 UTC ---

In that thread, I had asked:



---

If you prefer, I can simply inline the popcount/clz functionality into

gcov-io.c directly (or at least when not using recent versions of

GCC). But that in fact would be duplicating the code, when I thought

Aldy's solution was trying to avoid that by providing the more general

interfaces.



Teresa

---



but didn't get a response. Richard, is that your preferred route for

fixing this issue?



Thanks,

Teresa



On Tue, Dec 18, 2012 at 7:45 AM, aldyh at gcc dot gnu.org

 wrote:

>

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

>

> --- Comment #2 from Aldy Hernandez  2012-12-18 
> 15:45:17 UTC ---

> I have a proposed patch here:

>

> http://gcc.gnu.org/ml/gcc-patches/2012-12/msg00766.html

>

> ...which was deemed not sexy at all.  So perhaps Richard or someone else can

> suggest another route?

>

> --

> Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email

> --- You are receiving this mail because: ---

> You are on the CC list for the bug.

[Bug gcov-profile/55734] [4.8 Regression] gcov-io.c uses builtins not available in non-GCC compilers

[aldyh at gcc dot gnu.org]

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



--- Comment #2 from Aldy Hernandez  2012-12-18 
15:45:17 UTC ---

I have a proposed patch here:



http://gcc.gnu.org/ml/gcc-patches/2012-12/msg00766.html



...which was deemed not sexy at all.  So perhaps Richard or someone else can

suggest another route?

[Bug gcov-profile/55674] [4.8 Regression] >20% size increase of lto/pgo binaries since r193747

[hubicka at ucw dot cz]

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



--- Comment #15 from Jan Hubicka  2012-12-18 15:40:34 
UTC ---

> It's hard to say in case of Firefox, because the only thing

> that one can reliably measure is the JavaScript performance.

> And this varies only very slightly with different compiler options.



One way to get better differences is to disable the JIT :)

Doesn't snappy allow us to measure things like startup time and

other stuff where not much of JITed code is involved?



> So you have no way to measure up to which point more inlining

> is still beneficial.



I will do some testing on SPEC on when the performance starts dropping.

Setting limit to 890 seems bit dangerous.  -Os can slow down the code

considerably, so if 10% of time program will be running -Os code, we probably

get measurable slowdowns overall.



Thanks!

Honza

[Bug gcov-profile/55734] [4.8 Regression] gcov-io.c uses builtins not available in non-GCC compilers

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



   Priority|P3  |P1

 Status|UNCONFIRMED |NEW

   Keywords||build

   Last reconfirmed||2012-12-18

 Ever Confirmed|0   |1

Summary|gcov-io.c uses builtins not |[4.8 Regression] gcov-io.c

   |available in non-GCC|uses builtins not available

   |compilers   |in non-GCC compilers

   Target Milestone|--- |4.8.0



--- Comment #1 from Richard Biener  2012-12-18 
15:37:47 UTC ---

Confirmed.

[Bug tree-optimization/55731] Issue with complete innermost loop unrolling (cunrolli)

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2012-12-18

 Ever Confirmed|0   |1



--- Comment #3 from Richard Biener  2012-12-18 
15:34:51 UTC ---

The reason is that unrolling early can be harmful to for example vectorization

and thus cunrolli restricts itself to "obviously" profitable cases.



In this case the loop is not an "inner" loop - it doesn't have a containing

loop and so growth is not allowed even with -O3 (we otherwise will fail

to vectorize if the unrolled body ends up as part of other basic-blocks).



It's a know issue that after cunroll there is no strong value-numbering

pass that handles memory (there is DOM which only has weak memory handling).



So, it's a trade-off we make, mostly for the sake of loop optimizations

that do not handle unrolled loops well.

[Bug libstdc++/55728] std::bad_function_call has misleading what() result

[redi at gcc dot gnu.org]

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



Jonathan Wakely  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2012-12-18

  Component|c++ |libstdc++

 Ever Confirmed|0   |1

[Bug gcov-profile/55734] New: gcov-io.c uses builtins not available in non-GCC compilers

[aldyh at gcc dot gnu.org]

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



 Bug #: 55734

   Summary: gcov-io.c uses builtins not available in non-GCC

compilers

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: blocker

  Priority: P3

 Component: gcov-profile

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

ReportedBy: al...@gcc.gnu.org





gcov-io.c uses the following builtins that are not available in non-GCC

compilers or in older GCC's (pre 3.4):



__builtin_popcountll

__builtin_clzll

[Bug c++/55436] g++ compiles invalid code with child class of nested class in template class

[redi at gcc dot gnu.org]

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



--- Comment #7 from Jonathan Wakely  2012-12-18 
15:29:59 UTC ---

(In reply to comment #6)

> > If it was a serious problem it would have been reported before by more 
> > people.

> 

> I'm not sure if the degree of popularity of a bug should diminish its

> seriousness.



If noone else has ever reported it in all the time it's been in GCC it's not

causing a lot of problems, then it's not causing serious problems to most GCC

users.  It's not a regression and there's a workaround (qualify the names) so

it's not P2.



>  This is an "accepts-invalid, rejects-valid, wrong-code" bug,

> which is pretty nasty as far as bugs go.



Almost any name lookup bug can be turned into all three categories, it doesn't

alter its seriousness.



> The use of C++ is expanding (including

> GCC's own code base), meaning this bug is going to bite more people as time

> goes on.



It will get fixed, it doesn't need to be P2 for that.

[Bug other/54324] [4.8 Regression] GCC install document does not list minimum required g++ version

[aldyh at gcc dot gnu.org]

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



--- Comment #10 from Aldy Hernandez  2012-12-18 
15:26:50 UTC ---

Author: aldyh

Date: Tue Dec 18 15:26:27 2012

New Revision: 194584



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

Log:

PR other/54324

* tree-ssa-coalesce.c (struct ssa_name_var_hash): Remove "union"

from template parameter.



Modified:

trunk/gcc/ChangeLog

trunk/gcc/tree-ssa-coalesce.c

[Bug fortran/55733] -fno-automatic: Fails for scalar allocatables

[burnus at gcc dot gnu.org]

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



--- Comment #2 from Tobias Burnus  2012-12-18 
15:24:16 UTC ---

The following test case also fails; I think the problem is the string

components which isn't marked as TREE_STATIC:



! { dg-do run }

! { dg-options "-fno-automatic" }

!

subroutine foo()

  logical, save :: first = .false.

  character(len=:), allocatable :: str(:)

  if (first) then

if (allocated (str)) call abort ()

str = ["ABCDEF", "ABCDEF" ]

  end if

  if (.not. allocated (str)) call abort ()

  if (len (str) /= 6) call abort ()

  if (any (str(:)(1:6) /= "ABCDEF")) call abort ()

end subroutine foo



call foo()

call foo()

end

[Bug middle-end/55045] ira.c:879:32: error: array subscript is above array bounds (for vax)

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 Status|WAITING |RESOLVED

 Resolution||FIXED



--- Comment #3 from Richard Biener  2012-12-18 
15:23:35 UTC ---

Doesn't reproduce for me anymore, thus fixed (likely either by my fixes or

by Honzas unrollings).

[Bug debug/55730] [4.8 Regression] ICE in mem_loc_descriptor, at dwarf2out.c:12725

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2012-12-18

 CC||jakub at gcc dot gnu.org

 Ever Confirmed|0   |1



--- Comment #3 from Jakub Jelinek  2012-12-18 
15:21:00 UTC ---

Even further reduced (-g -O2):

union U

{

  float f;

  int i;

};



void

foo (unsigned short *x, unsigned char y)

{

  unsigned char g;

  union U u;

  if (u.i < 0)

g = 0;

  else

{

  u.f = u.f * (255.0F / 256.0F) + 32768.0F;

  g = (unsigned char) u.i;

}

  *x = (g << 8) | y;

}

[Bug fortran/55732] -fno-automatic: Doesn'

[burnus at gcc dot gnu.org]

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



Tobias Burnus  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 CC||burnus at gcc dot gnu.org

 Resolution||DUPLICATE



--- Comment #1 from Tobias Burnus  2012-12-18 
15:20:40 UTC ---

Stupid bugzilla!



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

[Bug fortran/55733] -fno-automatic: Fails for scalar allocatables

[burnus at gcc dot gnu.org]

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



--- Comment #1 from Tobias Burnus  2012-12-18 
15:20:40 UTC ---

*** Bug 55732 has been marked as a duplicate of this bug. ***

[Bug other/54324] [4.8 Regression] GCC install document does not list minimum required g++ version

[aldyh at gcc dot gnu.org]

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



--- Comment #9 from Aldy Hernandez  2012-12-18 
15:19:55 UTC ---

Author: aldyh

Date: Tue Dec 18 15:19:43 2012

New Revision: 194583



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

Log:

PR other/54324

* ansidecl.h (ATTRIBUTE_UNUSED): Do not set __attribute__ for GCC

< 3.4.



Modified:

trunk/include/ChangeLog

trunk/include/ansidecl.h

[Bug fortran/55733] New: -fno-automatic: Fails for scalar allocatables

[burnus at gcc dot gnu.org]

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



 Bug #: 55733

   Summary: -fno-automatic: Fails for scalar allocatables

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Keywords: wrong-code

  Severity: normal

  Priority: P3

 Component: fortran

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

ReportedBy: bur...@gcc.gnu.org

CC: ja...@gcc.gnu.org





-fno-automatic implies SAVE. However, it doesn't work for scalar allocatables:





subroutine foo(i)

  integer :: i

  integer, allocatable :: j

  if (i == 1) j = 42

  if (.not. allocated (j)) call abort ()

  if (j /= 42) call abort ()

end



call foo(1)

call foo(2)

end

[Bug tree-optimization/52588] false warning: array subscript is above array bounds: number of elements is 1

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||FIXED

   Target Milestone|--- |4.8.0



--- Comment #2 from Richard Biener  2012-12-18 
15:19:01 UTC ---

Fixed for 4.8.0.

[Bug debug/54731] [4.8 regression] arm-elf/arm-eabisim crosses fails in make-check due to undefined LFE references: corrupt debug_line tables

[ktkachov at gcc dot gnu.org]

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



ktkachov at gcc dot gnu.org changed:



   What|Removed |Added



 CC||ktkachov at gcc dot gnu.org



--- Comment #4 from ktkachov at gcc dot gnu.org 2012-12-18 15:18:44 UTC ---

I couldn't reproduce it on arm-eabi.



Kyrill

[Bug fortran/55732] New: -fno-automatic: Doesn'

[burnus at gcc dot gnu.org]

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



 Bug #: 55732

   Summary: -fno-automatic: Doesn'

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: fortran

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

ReportedBy: bur...@gcc.gnu.org





subroutine foo(i)

  integer :: i

  integer, allocatable :: j

  if (i == 1) j = 42

  if (.not. allocated (j)) call abort ()

  if (j /= 42) call abort ()

end



call foo(1)

call foo(2)

end

[Bug tree-optimization/53198] [4.6/4.7 Regression] gcc wrongly emits "array subscript is above array bounds" for simple arrays

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||4.8.0
  Known to fail|4.7.0, 4.8.0|4.7.2

--- Comment #5 from Richard Biener  2012-12-18 
15:16:16 UTC ---
(In reply to comment #4)
> (In reply to comment #3)
> > Created attachment 27801 [details]
> > another testcase - from xorg mouse driver
> 
> This warns with GCC 4.8 r192379:
> 
> pr53198.c: In function ‘CheckProtocol’:
> pr53198.c:35:30: warning: array subscript is above array bounds
> [-Warray-bounds]
>  for (i = 0; internalNames[i]; i++)
>   ^
> 
> It doesn't warn with gcc 4.5.1

Doesn't warn any longer on trunk.

[Bug sanitizer/55679] new asan tests from r194458 fail on x86_64-apple-darwin10

[howarth at nitro dot med.uc.edu]

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



--- Comment #18 from Jack Howarth  2012-12-18 
15:15:38 UTC ---

(In reply to comment #16)



I am puzzled as to why this issue with global-overflow-1.c and

stack-overflow-1.c can't be triggered on x86_64 linux. The obvious change of

-mtune=core2 seems to be insufficient to cause the failures.

[Bug target/55672] [4.8 Regression] -fstack-check=generic ICEs in print_reg, at config/i386/i386.c:13868

[hjl.tools at gmail dot com]

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



--- Comment #6 from H.J. Lu  2012-12-18 15:11:38 
UTC ---

This is what we changed in reload for stack realignment:



diff --git a/gcc/reload1.c b/gcc/reload1.c

index f28b01c..9b81062 100644

--- a/gcc/reload1.c

+++ b/gcc/reload1.c

@@ -3663,8 +3663,11 @@ update_eliminables (HARD_REG_SET *pset)

   frame_pointer_needed = 1;

   for (ep = reg_eliminate; ep < ®_eliminate[NUM_ELIMINABLE_REGS]; ep++)

 {

-  if (ep->can_eliminate && ep->from == FRAME_POINTER_REGNUM

- && ep->to != HARD_FRAME_POINTER_REGNUM)

+  if (ep->can_eliminate

+ && ep->from == FRAME_POINTER_REGNUM

+ && ep->to != HARD_FRAME_POINTER_REGNUM

+ && (! SUPPORTS_STACK_ALIGNMENT

+ || ! crtl->stack_realign_needed))

frame_pointer_needed = 0;



   if (! ep->can_eliminate && ep->can_eliminate_previous)

@@ -3720,7 +3723,10 @@ init_elim_table (void)

   ep->to = ep1->to;

   ep->can_eliminate = ep->can_eliminate_previous

= (CAN_ELIMINATE (ep->from, ep->to)

-  && ! (ep->to == STACK_POINTER_REGNUM && frame_pointer_needed));

+  && ! (ep->to == STACK_POINTER_REGNUM

+&& frame_pointer_needed 

+&& (! SUPPORTS_STACK_ALIGNMENT

+|| ! stack_realign_fp)));

 }

 #else

   reg_eliminate[0].from = reg_eliminate_1[0].from;





LRA should have similar codes.

[Bug c++/55724] [4.7/4.8 Regression] [C++11] Default type of a template value is not working

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



   Target Milestone|--- |4.7.3



--- Comment #2 from Richard Biener  2012-12-18 
15:08:44 UTC ---

trunk now says:



t.C: In function 'int main()':

t.C:3:25: error: no matching function for call to 'f(S<1>&)'

 int main() { S<1> s; f(s); }

 ^

t.C:3:25: note: candidate is:

t.C:2:38: note: template void f(S)

 template void f(S) {}

  ^

t.C:2:38: note:   template argument deduction/substitution failed:

t.C:3:25: note:   couldn't deduce template parameter 'N'

 int main() { S<1> s; f(s); }

 ^

[Bug c++/55436] g++ compiles invalid code with child class of nested class in template class

[conradsand.arma at gmail dot com]

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



Conrad  changed:



   What|Removed |Added



Version|4.7.2   |4.8.0



--- Comment #6 from Conrad  2012-12-18 
14:54:50 UTC ---

> If it was a serious problem it would have been reported before by more people.



I'm not sure if the degree of popularity of a bug should diminish its

seriousness.  This is an "accepts-invalid, rejects-valid, wrong-code" bug,

which is pretty nasty as far as bugs go. The use of C++ is expanding (including

GCC's own code base), meaning this bug is going to bite more people as time

goes on.



However, I do understand that bugs which affect more people right now should

get looked at first. Furthermore, given its wide ranging impact, perhaps fixing

this bug in 4.7.x would not be doable (ie. too invasive).  As such, I'll

reassign this bug to 4.8.0.

[Bug target/55565] [4.8 regression] FAIL: gcc.target/powerpc/ppc-mov-1.c scan-assembler-not fmr [0-9]+,[0-9]+

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 CC||jakub at gcc dot gnu.org



--- Comment #1 from Jakub Jelinek  2012-12-18 
14:53:52 UTC ---

Started with http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190339

which changed *.optimized dump tiny bit.

I'd say the testcase is questionable, on such large routine assuming there

can't be any floating point register moves is dubious.

[Bug debug/55730] [4.8 Regression] ICE in mem_loc_descriptor, at dwarf2out.c:12725

[rguenth at gcc dot gnu.org]

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



--- Comment #2 from Richard Biener  2012-12-18 
14:51:11 UTC ---

Reduced with a cross from x86_64 configured with --target=powerpc64-suse-linux

--with-cpu-64=power4 --enable-secureplt --with-long-double-128

--enable-languages=c,c++





typedef int GLint;

typedef unsigned char GLubyte;

typedef unsigned short GLushort;

typedef float GLfloat;

typedef union {

GLfloat f;

GLint i;

} fi_type;

void pack_float_GR88 (void *dst)

{

  GLushort *d = ((GLushort *) dst);

  GLubyte r, g;

  fi_type __tmp;

  if (__tmp.i < 0) 

g = (GLubyte) 0;

  else 

{

  __tmp.f = __tmp.f * (255.0F/256.0F) + 32768.0F;

  g = (GLubyte) __tmp.i;

}

  *d = (((g) << 8) | (r));

}



> ./cc1 -fpreprocessed format_pack.3.i -msecure-plt -quiet -mcpu=power4 -g -O2

(clobber:QI (const_int 0 [0]))format_pack.3.i: In function 'pack_float_GR88':

format_pack.3.i:22:1: internal compiler error: in mem_loc_descriptor, at

dwarf2out.c:12729

 }

 ^

0x76b280 mem_loc_descriptor(rtx_def*, machine_mode, machine_mode,

var_init_status)

/space/rguenther/src/svn/trunk/gcc/dwarf2out.c:12729

0x76c090 loc_descriptor

/space/rguenther/src/svn/trunk/gcc/dwarf2out.c:13068

0x76b85a loc_descriptor

/space/rguenther/src/svn/trunk/gcc/dwarf2out.c:12894

0x76c4c4 dw_loc_list_1

/space/rguenther/src/svn/trunk/gcc/dwarf2out.c:13167

0x76cc5c dw_loc_list

/space/rguenther/src/svn/trunk/gcc/dwarf2out.c:13423

0x76dab1 loc_list_from_tree

/space/rguenther/src/svn/trunk/gcc/dwarf2out.c:13808

0x771ea7 add_location_or_const_value_attribute

/space/rguenther/src/svn/trunk/gcc/dwarf2out.c:15302

0x77a85b gen_variable_die

/space/rguenther/src/svn/trunk/gcc/dwarf2out.c:18415

0x77fbce gen_decl_die

/space/rguenther/src/svn/trunk/gcc/dwarf2out.c:20051

0x77e3aa process_scope_var

/space/rguenther/src/svn/trunk/gcc/dwarf2out.c:19595

0x77e416 decls_for_scope

/space/rguenther/src/svn/trunk/gcc/dwarf2out.c:19617

0x779393 gen_subprogram_die

/space/rguenther/src/svn/trunk/gcc/dwarf2out.c:18004

0x77f84d gen_decl_die

/space/rguenther/src/svn/trunk/gcc/dwarf2out.c:19984

0x780836 dwarf2out_decl(tree_node*)

/space/rguenther/src/svn/trunk/gcc/dwarf2out.c:20366

0x780870 dwarf2out_function_decl

/space/rguenther/src/svn/trunk/gcc/dwarf2out.c:20374

0x7e6ccc rest_of_handle_final

/space/rguenther/src/svn/trunk/gcc/final.c:4302

Please submit a full bug report,

with preprocessed source if appropriate.

Please include the complete backtrace with any bug report.

See  for instructions.

[Bug target/55642] [4.8 Regression] Invalid thumb code generated ("thumb conditional instruction should be in IT block")

[ktkachov at gcc dot gnu.org]

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



ktkachov at gcc dot gnu.org changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 CC||ktkachov at gcc dot gnu.org

 Resolution||FIXED



--- Comment #6 from ktkachov at gcc dot gnu.org 2012-12-18 14:45:31 UTC ---

Fixed.

[Bug go/55201] [4.8 regression] libgo.so: undefined reference to `__atomic_compare_exchange_8'

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

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



Andreas Schwab  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||FIXED



--- Comment #3 from Andreas Schwab  2012-12-18 14:45:00 
UTC ---

Fixed.

[Bug middle-end/54838] [4.8 Regression] ICE: in merge_latch_edges, at cfgloop.c:678 with -ftracer

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 Status|REOPENED|RESOLVED

 Resolution||FIXED



--- Comment #19 from Richard Biener  2012-12-18 
14:40:28 UTC ---

Fixed.

[Bug middle-end/54838] [4.8 Regression] ICE: in merge_latch_edges, at cfgloop.c:678 with -ftracer

[rguenth at gcc dot gnu.org]

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



--- Comment #18 from Richard Biener  2012-12-18 
14:39:55 UTC ---

Author: rguenth

Date: Tue Dec 18 14:39:49 2012

New Revision: 194582



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

Log:

2012-12-18  Richard Biener  



PR middle-end/54838

* cfgloopmanip.c (fix_loop_structure): Re-discover latch

edges first and mark loops for removal if no latch edges remain.

Properly re-create LOOPS_HAVE_FALLTHRU_PREHEADERS.

* loop-init.c (loop_optimizer_finalize): Set

LOOPS_MAY_HAVE_MULTIPLE_LATCHES.



* g++.dg/torture/pr54838.C: New testcase.



Added:

trunk/gcc/testsuite/g++.dg/torture/pr54838.C

Modified:

trunk/gcc/ChangeLog

trunk/gcc/cfgloopmanip.c

trunk/gcc/loop-init.c

trunk/gcc/testsuite/ChangeLog

[Bug debug/55730] [4.8 Regression] ICE in mem_loc_descriptor, at dwarf2out.c:12725

[rguenth at gcc dot gnu.org]

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



--- Comment #1 from Richard Biener  2012-12-18 
14:37:47 UTC ---

Reducing.

[Bug go/55201] [4.8 regression] libgo.so: undefined reference to `__atomic_compare_exchange_8'

[ian at gcc dot gnu.org]

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



--- Comment #2 from ian at gcc dot gnu.org  2012-12-18 
14:28:31 UTC ---

Author: ian

Date: Tue Dec 18 14:28:24 2012

New Revision: 194581



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

Log:

libgo: Link against libatomic.



./:

PR go/55201

* Makefile.def (all-target-libgo): Depend on all-target-libatomic.

* Makefile.in: Regenerate.

gcc/go:

PR go/55201

* gospec.c (LIBATOMIC): Define.

(LIBATOMIC_PROFILE): Define.

(lang_specific_driver): Add LIBATOMIC[_PROFILE] option.

gcc/testsuite:

* lib/go.exp (go_link_flags): Add libatomic location to flags and

ld_library_path.



Modified:

trunk/ChangeLog

trunk/Makefile.def

trunk/Makefile.in

trunk/gcc/go/ChangeLog

trunk/gcc/go/gospec.c

trunk/gcc/testsuite/ChangeLog

trunk/gcc/testsuite/lib/go.exp

trunk/libgo/Makefile.am

trunk/libgo/Makefile.in

[Bug tree-optimization/55731] Issue with complete innermost loop unrolling (cunrolli)

[ysrumyan at gmail dot com]

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



--- Comment #2 from Yuri Rumyantsev  2012-12-18 
14:24:05 UTC ---

Created attachment 28998

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28998

testcase2

[Bug tree-optimization/55731] Issue with complete innermost loop unrolling (cunrolli)

[ysrumyan at gmail dot com]

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



--- Comment #1 from Yuri Rumyantsev  2012-12-18 
14:23:30 UTC ---

Created attachment 28997

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28997

testcase1

[Bug tree-optimization/55731] New: Issue with complete innermost loop unrolling (cunrolli)

[ysrumyan at gmail dot com]

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



 Bug #: 55731

   Summary: Issue with complete innermost loop unrolling

(cunrolli)

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: tree-optimization

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

ReportedBy: ysrum...@gmail.com

CC: hubi...@ucw.cz, izamya...@gmail.com





I attached 2 test-cases extracted from important benchmark at which clang and

icc outperform gcc for x86 target (atom). For 1st test-case (t.c) cunrolli

phase does not perform complete loop unrolling with the following message (test

was compiled with -O3 -funroll-loops options):



  Loop size: 23

  Estimated size after unrolling: 33

Not unrolling loop 1: size would grow.



but it is unrolled by cunroll phase:



  Loop size: 24

  Estimated size after unrolling: 32

Unrolled loop 1 completely (duplicated 2 times).



I wonder why this loop was not unrolled by cunrolli? We lost a lot of

optimizations for unrolled loop such as Constant (address) Propagation, Dead

code elimination etc. and got non-optimal binaries.



For comparsion I added another test (t2.c) with successfull complete unrolling

by cunrolli, at which we can see that all assignments to local array 'b' were

properly propagated and deleted but we don't have such transformations for 1st

test-case.

[Bug debug/55730] [4.8 Regression] ICE in mem_loc_descriptor, at dwarf2out.c:12725

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



  Component|rtl-optimization|debug

   Target Milestone|--- |4.8.0

[Bug rtl-optimization/55730] New: [4.8 Regression] ICE in mem_loc_descriptor, at dwarf2out.c:12725

[rguenth at gcc dot gnu.org]

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



 Bug #: 55730

   Summary: [4.8 Regression] ICE in mem_loc_descriptor, at

dwarf2out.c:12725

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Keywords: ice-on-valid-code

  Severity: normal

  Priority: P3

 Component: rtl-optimization

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

ReportedBy: rgue...@gcc.gnu.org

Target: powerpc64-linux





Created attachment 28996

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28996

preprocessed source



/usr/lib64/gcc/powerpc64-suse-linux/4.8/cc1 -fpreprocessed format_pack.i

-msecure-plt -quiet -dumpbase format_pack.c -mcpu=power4 -auxbase-strip

.libs/format_pack.o -g -O2 -Wall -Werror=implicit-function-declaration

-Werror=missing-prototypes -std=c99 -version -fvisibility=hidden

-fmessage-length=0 -fstack-protector -funwind-tables

-fasynchronous-unwind-tables -fno-strict-aliasing -fno-builtin-memcmp -fPIC -o

format_pack.s

GNU C (SUSE Linux) version 4.8.0 20121217 [trunk revision 194556]

(powerpc64-suse-linux)

compiled by GNU C version 4.8.0 20121217 [trunk revision 194556], GMP

version 5.0.5, MPFR version 3.1.1, MPC version 1.0

GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096

GNU C (SUSE Linux) version 4.8.0 20121217 [trunk revision 194556]

(powerpc64-suse-linux)

compiled by GNU C version 4.8.0 20121217 [trunk revision 194556], GMP

version 5.0.5, MPFR version 3.1.1, MPC version 1.0

GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096

Compiler executable checksum: 95572fc9d0aa2e1ae6283f447379255d

(clobber:QI (const_int 0 [0]))../../src/mesa/main/format_pack.c: In function

'pack_float_RGB565':

../../src/mesa/main/format_pack.c:467:1: internal compiler error: in

mem_loc_descriptor, at dwarf2out.c:12725

 }

 ^

libbacktrace could not find executable to open

Please submit a full bug report,

with preprocessed source if appropriate.

See  for instructions.

[Bug target/55562] [4.8 Regression] FAIL: gcc.dg/sms-* on powerpc*-*-*

[jakub at gcc dot gnu.org]

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



--- Comment #4 from Jakub Jelinek  2012-12-18 
13:47:34 UTC ---

Can somebody please test this on ppc?  I'll bootstrap/regtest it on

x86_64-linux and i686-linux momentarily.

[Bug target/55562] [4.8 Regression] FAIL: gcc.dg/sms-* on powerpc*-*-*

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 Status|NEW |ASSIGNED

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

   |gnu.org |



--- Comment #3 from Jakub Jelinek  2012-12-18 
13:41:07 UTC ---

Created attachment 28995

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28995

gcc48-pr55562.patch



Broken by the http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=192969 sbitmap

changes.  modulo-sched.c seemed to be using sbitmap_a_and_b_cg in 4 places,

that change replaced that by bitmap_and, but apparently the new function only

returns non-zero (something changed) if destination sbitmap has popcount. 

sbitmap_a_and_b_cg on the other side asserted it doesn't have popcount.

[Bug tree-optimization/55683] [4.8 Regression] ICE in inline_call, at ipa-inline-transform.c:270

[hubicka at ucw dot cz]

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



--- Comment #9 from Jan Hubicka  2012-12-18 13:39:45 UTC 
---

> Bumping the limit to assert on to off-by-two doesn't fix all cases (I can

> hand you a testcase if you like...)



Yep, i guess it just depends on how many calls we diverge.  I will take a look

today after meeting.



Honza

[Bug middle-end/55555] [4.8 Regression] miscompilation at -O2 (number_of_iterations)

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 Status|ASSIGNED|RESOLVED

 Resolution||FIXED



--- Comment #13 from Richard Biener  2012-12-18 
13:29:52 UTC ---

Fixed.

[Bug libstdc++/55727] better support for dynamic allocation of over-aligned types

[kretz at kde dot org]

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



--- Comment #3 from Matthias Kretz  2012-12-18 13:26:21 
UTC ---

(In reply to comment #2)

> (In reply to comment #0)

> > Right now it does not even suffice to reimplement new/delete inside Foo to 
> > make

> > std::vector work.

> 

> Sorry, this statement seems to be wrong.



After more investigation I see that my original statement was right. The

default allocator uses ::operator new(size_t) instead of T::operator new - and

obviously it has to use the global one because allocation and construction are

split into two functions.



I just created an allocator class that uses posix_memalign and __alignof to

implement an allocator as I'd like to have for a proof of concept.



If you are interested, I can patch the new_allocator class to support

over-alignment (while still using operator new). Would you be interested?

[Bug middle-end/55555] [4.8 Regression] miscompilation at -O2 (number_of_iterations)

[rguenth at gcc dot gnu.org]

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



--- Comment #12 from Richard Biener  2012-12-18 
13:12:39 UTC ---

Author: rguenth

Date: Tue Dec 18 13:12:34 2012

New Revision: 194578



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

Log:

2012-12-18  Richard Biener  



PR tree-optimization/5

* tree-ssa-loop-niter.c (idx_infer_loop_bounds): Properly

analyze evolution of the index for the loop it is used in.

* tree-scalar-evolution.c (instantiate_scev_name): Take

inner loop we will be creating a chrec for.  Generalize

fix for PR40281 and prune invalid SCEVs.

(instantiate_scev_poly): Likewise - pass down inner loop

we will be creating a chrec for.

(instantiate_scev_binary): Take and pass through inner loop.

(instantiate_array_ref): Likewise.

(instantiate_scev_convert): Likewise.

(instantiate_scev_not): Likewise.

(instantiate_scev_3): Likewise.

(instantiate_scev_2): Likewise.

(instantiate_scev_1): Likewise.

(instantiate_scev_r): Likewise.

(resolve_mixers): Adjust.

(instantiate_scev): Likewise.



* gcc.dg/torture/pr5.c: New testcase.

* gcc.dg/vect/vect-iv-11.c: Adjust.



Added:

trunk/gcc/testsuite/gcc.dg/torture/pr5.c

Modified:

trunk/gcc/ChangeLog

trunk/gcc/testsuite/ChangeLog

trunk/gcc/testsuite/gcc.dg/vect/vect-iv-11.c

trunk/gcc/tree-scalar-evolution.c

trunk/gcc/tree-ssa-loop-niter.c

[Bug tree-optimization/55683] [4.8 Regression] ICE in inline_call, at ipa-inline-transform.c:270

[rguenth at gcc dot gnu.org]

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



--- Comment #8 from Richard Biener  2012-12-18 
12:46:52 UTC ---

Bumping the limit to assert on to off-by-two doesn't fix all cases (I can

hand you a testcase if you like...)

[Bug c/55695] Miscompilation of pow() & sqrt() using musl libc

[ojab at ojab dot ru]

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



ojab  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||INVALID



--- Comment #5 from ojab  2012-12-18 12:45:57 UTC ---

Closing per http://www.openwall.com/lists/musl/2012/12/18/6

[Bug fortran/55729] New: Problem with sum intrinsic

[pmarguinaud at hotmail dot com]

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

 Bug #: 55729
   Summary: Problem with sum intrinsic
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: pmarguin...@hotmail.com


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

$ /opt/softs/gnu/4.7.0/bin/gfortran -c init_isba_sbl.F90 
init_isba_sbl.F90: In function ‘MAIN__’:
init_isba_sbl.F90:1:0: error: mismatching comparison operand types
real(kind=4)
integer(kind=8)
if (D.1941 > 0) goto ; else goto ;

init_isba_sbl.F90:1: confused by earlier errors, bailing out

[Bug c++/55728] New: std::bad_function_call has misleading what() result

[joerg.rich...@pdv-fs.de]

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



 Bug #: 55728

   Summary: std::bad_function_call has misleading what() result

Classification: Unclassified

   Product: gcc

   Version: 4.7.2

Status: UNCONFIRMED

  Severity: minor

  Priority: P3

 Component: c++

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

ReportedBy: joerg.rich...@pdv-fs.de





cat t.cc << EOF

#include 

#include 



int main()

{

  try

  {

std::function()();

  }

  catch( std::exception const& e )

  {

std::cout << e.what() << std::endl;

  }

}

EOF



g++ -std=c++11 -o t t.cc

t



# gives me "std::exception"



Not wrong, but "std::bad_function_call" would have saved me some debug time.

[Bug bootstrap/54283] [4.8 regression] build tools don't run after cxx-conversion merge

[ro at CeBiTec dot Uni-Bielefeld.DE]

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



--- Comment #12 from ro at CeBiTec dot Uni-Bielefeld.DE  2012-12-18 12:12:32 UTC ---

> --- Comment #11 from Jakub Jelinek  2012-12-18

> 12:09:52 UTC ---

> If you don't add that /vol/gcc-4.4/lib/ to ld.so.conf (or ld.so.conf.d), it is

> your responsibility to build with LD_LIBRARY_PATH, otherwise you are

> bootstrapping with a non-working C++ compiler.



Not if you build with -static-libstdc++, which does work for e.g. go1

before the cxx-conversion and cc1* afterwards, just not for the build

tools.  That's what this is all about.



Rainer

[Bug bootstrap/54283] [4.8 regression] build tools don't run after cxx-conversion merge

[jakub at gcc dot gnu.org]

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



--- Comment #11 from Jakub Jelinek  2012-12-18 
12:09:52 UTC ---

If you don't add that /vol/gcc-4.4/lib/ to ld.so.conf (or ld.so.conf.d), it is

your responsibility to build with LD_LIBRARY_PATH, otherwise you are

bootstrapping with a non-working C++ compiler.

[Bug bootstrap/54283] [4.8 regression] build tools don't run after cxx-conversion merge

[ro at CeBiTec dot Uni-Bielefeld.DE]

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



--- Comment #10 from ro at CeBiTec dot Uni-Bielefeld.DE  2012-12-18 12:06:21 UTC ---

> --- Comment #9 from Jakub Jelinek  2012-12-18 
> 10:30:12 UTC ---

> So not a bug then?



I don't think so: even on x86_64-unknown-linux-gnu, when building an

i686-unknown-linux-gnu compiler with an unbundled gcc 4.4 (which does

support -static-libstdc++) where the 32-bit libstdc++.so.6 doesn't live

in /usr/lib, but only in /vol/gcc-4.4/lib, the build tools are the only

ones that don't run.  If it were host and build tools alike, I'd agree,

but the host tools are fine, as they were before the cxx-conversion.



Rainer

[Bug c++/55726] assignment of a scalar to a vector

[vincenzo.innocente at cern dot ch]

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

--- Comment #2 from vincenzo Innocente  
2012-12-18 11:39:22 UTC ---
no

gcc -Ofast -march=corei7 assign.c  -std=c99
assign.c: In function ‘main’:
assign.c:9:21: error: incompatible types when initializing type ‘float32x4_t’
using type ‘float’
   float32x4_t va =  a;

[Bug rtl-optimization/55717] [4.8 Regression] ICE in form_sum, at reload.c:5400

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 Status|ASSIGNED|RESOLVED

 Resolution||FIXED



--- Comment #8 from Jakub Jelinek  2012-12-18 
11:37:48 UTC ---

Fixed.