[Bug target/55909] libtool test exposes what I think is some alignment issue in libstdc++

[philip.copeland at oracle dot com]

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



--- Comment #14 from philip.copeland at oracle dot com 2013-01-09 08:27:19 UTC 
---

Smallest test case program



#include iostream

int main()

{

std::cerr  we are able to write to stderr\n;

}



bash-4.2# g++ test.c

bash-4.2# ./a.out

we are able to write to stderr

Segmentation fault (core dumped)







#0  0xf8010030a558 in __frame_dummy_init_array_entry ()

   from /lib64/libstdc++.so.6

#1  0xf80100180988 in __cxxabiv1::__cxa_get_globals ()

at ../../../../libstdc++-v3/libsupc++/eh_globals.cc:63

#2  0xf801001807cc in std::uncaught_exception ()

at ../../../../libstdc++-v3/libsupc++/eh_catch.cc:136

#3  0xf801001bcbe4 in ~sentry (this=0x7fef0b0, 

__in_chrg=optimized out)

at

/usr/src/debug/gcc-4.7.2-20121109/obj-sparc64-redhat-linux/sparc64-redhat-linux/libstdc++-v3/include/ostream:429

#4  std::__ostream_insertchar, std::char_traitschar  (__out=..., 

__s=__s@entry=0x100a00 we are able to write to stderr\n, 

__n=optimized out)

at

/usr/src/debug/gcc-4.7.2-20121109/obj-sparc64-redhat-linux/sparc64-redhat-linux/libstdc++-v3/include/bits/ostream_insert.h:112

#5  0xf801001bcfc4 in std::operator std::char_traitschar  (

__out=..., __s=0x100a00 we are able to write to stderr\n)

at

/usr/src/debug/gcc-4.7.2-20121109/obj-sparc64-redhat-linux/sparc64-redhat-linux/libstdc++-v3/include/ostream:533

#6  0x0010087c in main ()

[Bug tree-optimization/43716] [4.6/4.7/4.8 Regression] Revision 158105 miscompiles doduc.f90

[richard.guenther at gmail dot com]

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



--- Comment #49 from richard.guenther at gmail dot com richard.guenther at 
gmail dot com 2013-01-09 08:52:21 UTC ---

On Tue, Jan 8, 2013 at 8:52 PM, dominiq at lps dot ens.fr

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



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



 --- Comment #48 from Dominique d'Humieres dominiq at lps dot ens.fr 
 2013-01-08 19:52:39 UTC ---

 From comment #40:



 with -ffast-math, so for example



   if (x != 0)

 tem = y / x;

   else

 tem = 0.;

   ... do sth with tem ...



 will execute y / x unconditionally based on the fact that it cannot trap.



 This optimization generates an exception trapped when using -ffpe-trap=invalid

 along with -ffast-math.

 This unfortunately prevents any debugging based -ffpe-trap=invalid for

 miscompilations occurring with -ffast-math.



Well - that's maybe unfortunate but expected.  You can't have both ;)



 One thing I hope, though I am not

 sure about it, is that the above block is still compiled as



 tem=y/x

 if (x==0) tem=0.



Yes, it's basically turned into an unconditional divide plus a conditional move

based on the fact that we cannot vectorize non-straight-line-code (so

it's really

only a vectorization enabler).



 My original report was for '-O3 -funsafe-math-optimizations 
 -ffinite-math-only'

 without -ffpe-trap=invalid. The segmentation fault resulted from the fact that

 some variables were used to access a table and were out of bound when the

 miscompilation generated some NAN (see comment #13).



Yes, that's another common issue - with FP indexing even slight

rounding differences can cause bogus accesses (consider producing

a[0.99] instead of a[1.0]).  That mostly happens with FP loop induction

variables that are also used for indexing (a really bad practice the frontend

should warn about - at least when -funsafe-math-optimizations is in effect).



Richard.



 --

 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 tree-optimization/55912] missing optimization of x/x and x/std::abs(x)

[glisse at gcc dot gnu.org]

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



Marc Glisse glisse at gcc dot gnu.org changed:



   What|Removed |Added



 CC||glisse at gcc dot gnu.org



--- Comment #1 from Marc Glisse glisse at gcc dot gnu.org 2013-01-09 08:59:26 
UTC ---

Thanks.



Hmm, what I was suggesting in the other bug (trivial code in fold-const.c)

would probably only help for sign2, and only if you use fabsf instead of

std::abs :-(

[Bug tree-optimization/48189] [4.6/4.7/4.8 Regression] ICE: SIGFPE (division by zero) in in predict_loops () at predict.c:991 with --param max-predicted-iterations=0

[jakub at gcc dot gnu.org]

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



--- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-09 
09:00:32 UTC ---

Author: jakub

Date: Wed Jan  9 09:00:22 2013

New Revision: 195046



URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195046

Log:

PR tree-optimization/48189

* predict.c (predict_loops): If max is 0, don't call compare_tree_int.

If nitercst is 0, don't predict the exit edge.



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



Added:

trunk/gcc/testsuite/gcc.dg/pr48189.c

Modified:

trunk/gcc/ChangeLog

trunk/gcc/predict.c

trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/48189] [4.6/4.7 Regression] ICE: SIGFPE (division by zero) in in predict_loops () at predict.c:991 with --param max-predicted-iterations=0

[jakub at gcc dot gnu.org]

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



Jakub Jelinek jakub at gcc dot gnu.org changed:



   What|Removed |Added



  Known to work||4.8.0

Summary|[4.6/4.7/4.8 Regression]|[4.6/4.7 Regression] ICE:

   |ICE: SIGFPE (division by|SIGFPE (division by zero)

   |zero) in in predict_loops   |in in predict_loops () at

   |() at predict.c:991 with|predict.c:991 with --param

   |--param |max-predicted-iterations=0

   |max-predicted-iterations=0  |



--- Comment #10 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-09 
09:03:38 UTC ---

Fixed on the trunk so far.

[Bug target/55909] libtool test exposes what I think is some alignment issue in libstdc++

[philip.copeland at oracle dot com]

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



--- Comment #15 from philip.copeland at oracle dot com 2013-01-09 09:06:38 UTC 
---

I've a fc17 x86_64 box in the backroom here that I'm going to generate a

comparison trace with



[root@ZenV tmp]# gdb a.out

(gdb) break ../../../../libstdc++-v3/libsupc++/eh_globals.cc:63

No symbol table is loaded.  Use the file command.

Make breakpoint pending on future shared library load? (y or [n]) y



Breakpoint 1 (../../../../libstdc++-v3/libsupc++/eh_globals.cc:63) pending.

(gdb) run

Starting program: /tmp/a.out 

we are able to write to stderr



Breakpoint 1, __cxxabiv1::__cxa_get_globals ()

at ../../../../libstdc++-v3/libsupc++/eh_globals.cc:63

63  { return get_global(); }

(gdb) where

#0  __cxxabiv1::__cxa_get_globals ()

at ../../../../libstdc++-v3/libsupc++/eh_globals.cc:63

#1  0x00354f25e0d9 in std::uncaught_exception ()

at ../../../../libstdc++-v3/libsupc++/eh_catch.cc:136

#2  0x00354f295a12 in ~sentry (this=0x7fffe360, 

__in_chrg=optimized out)

at

/usr/src/debug/gcc-4.7.2-20120921/obj-x86_64-redhat-linux/x86_64-redhat-linux/libstdc++-v3/include/ostream:429

#3  std::__ostream_insertchar, std::char_traitschar  (__out=..., 

__s=__s@entry=0x400870 we are able to write to stderr\n, __n=31)

at

/usr/src/debug/gcc-4.7.2-20120921/obj-x86_64-redhat-linux/x86_64-redhat-linux/libstdc++-v3/include/bits/ostream_insert.h:112

#4  0x00354f295d8f in std::operator std::char_traitschar  (

__out=..., __s=0x400870 we are able to write to stderr\n)

at

/usr/src/debug/gcc-4.7.2-20120921/obj-x86_64-redhat-linux/x86_64-redhat-linux/libstdc++-v3/include/ostream:533

#5  0x0040075f in main ()



(gdb) step

std::uncaught_exception ()

at ../../../../libstdc++-v3/libsupc++/eh_catch.cc:137

137   return globals-uncaughtExceptions != 0;

(gdb) list

132

133 bool

134 std::uncaught_exception() throw()

135 {

136   __cxa_eh_globals *globals = __cxa_get_globals ();

137   return globals-uncaughtExceptions != 0;

138 }

[Bug tree-optimization/55823] [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=55823



--- Comment #9 from Jan Hubicka hubicka at gcc dot gnu.org 2013-01-09 
09:07:24 UTC ---

We no longer ICE in the testcase. We still regress by missing devirtualization

in new ipa-cp implementation and I would like Martin to double check that the

right thing happens when combining the ancestor jump function.



No ICE, no wrong code, so no longer P1 I guess.

[Bug pch/54117] [4.8 Regression] FAIL: ./decl-3.h -O0 -g (internal compiler error)

[rguenth at gcc dot gnu.org]

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



--- Comment #12 from Richard Biener rguenth at gcc dot gnu.org 2013-01-09 
09:22:21 UTC ---

(In reply to comment #11)

  All that to avoid one #include output.h in one file?

 

 Is that one little thing really the only change you see? I see a

 different picture.

 

 The change is a major step in the direction of making a clear cut

 between the middle/back end and the front ends. A front end should not

 output assembly, period, if we want the front ends to become separate

 libraries, in the long run, that can be used by external tools (static

 checkers, IDEs, etc.) like clang. For the long term, this is IMHO the

 only viable solution for keeping the GCC front ends relevant.

 

 The change also allows the compiler to open the assembler file in

 write-only mode and to open it only after the front end is done. My

 plan is to postponed it even further: for GCC 4.9 I'd like to work on

 streaming slim LTO objects directly to a .o file, without going

 through an assembler file at all (this is relatively simple for ELF

 targets).

 

 Finally, the change also simplifies the PCH mechanism further. If

 we're ever going to replace PCH-as-a-memory-dump with something

 streamed, we'll have to make an effort at only streaming IR objects,

 not assembler output.

 

 Had I known this change would break stabs like this, I'd obviously

 have tried to solve that problem first. But to back out the change now

 would be a mistake. Nobody is going to fix those *out.c back ends, as

 you very well know.



That's exactly my thinking of the whole picture.



Timing seems to be bad now - so as compromise I'd accept reverting the

patch for 4.8 and immediately re-installing it when stage1 for 4.9

re-opens.



If dwarf2out.c is really set up nicely enough (just dump

its internal dwarf tree to asm_out_file at some point) then doing

dwarf - Y translation at that point should be possible.  Of course

I don't see anybody doing that either - nobody is really interested

in debug formats besides dwarf apart from keeping the legacy going.

IMHO we can direct them to use oder versions of GCC.



Thus, let's deprecate anything but dwarf in 4.8 ;)

[Bug tree-optimization/55912] missing optimization of x/x and x/std::abs(x)

[rguenth at gcc dot gnu.org]

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



Richard Biener rguenth at gcc dot gnu.org changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2013-01-09

 Ever Confirmed|0   |1



--- Comment #2 from Richard Biener rguenth at gcc dot gnu.org 2013-01-09 
09:26:58 UTC ---

Most of the math builtin folding needs to be re-done at GIMPLE level based

on SSA form.  Convenient places are either tree-ssa-forwprop.c or

tree-ssa-math-opts.c (sincos pass which also does power series expansion now).

[Bug bootstrap/55792] [4.8 Regression] Bad memory access with profiledbootstrap and LTO

[rguenth at gcc dot gnu.org]

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



--- Comment #18 from Richard Biener rguenth at gcc dot gnu.org 2013-01-09 
09:31:45 UTC ---

(In reply to comment #17)

 gimple_location is duplicated by:

 

 #1  0x00751f32 in gimple_copy (stmt=0x7fffe8d75a00)

 at /export/gnu/import/git/gcc/gcc/gimple.c:2205

 #2  0x009c960d in gimple_duplicate_bb (bb=0x7fffe8d768f0)

 at /export/gnu/import/git/gcc/gcc/tree-cfg.c:5397

 #3  0x005b27a5 in duplicate_block (bb=0x7fffe8d768f0, 

 e=0x7fffe8d793f0, after=0x7fffe8d76888)

 at /export/gnu/import/git/gcc/gcc/cfghooks.c:1012

 #4  0x0099c511 in tail_duplicate ()

 at /export/gnu/import/git/gcc/gcc/tracer.c:323

 #5  0x0099c765 in tracer ()

 at /export/gnu/import/git/gcc/gcc/tracer.c:380

 #6  0x008ae0e6 in execute_one_pass (pass=0x16d18a0 pass_tracer)

 at /export/gnu/import/git/gcc/gcc/passes.c:2335

 #7  0x008ae2da in execute_pass_list (pass=0x16d18a0 pass_tracer)

 at /export/gnu/import/git/gcc/gcc/passes.c:2383

 #8  0x008ae30b in execute_pass_list (

 pass=0x16d07e0 pass_all_optimizations)

 at /export/gnu/import/git/gcc/gcc/passes.c:2384

 #9  0x005da366 in expand_function (node=0x717536f0)

 at /export/gnu/import/git/gcc/gcc/cgraphunit.c:1641

 #10 0x005da821 in expand_all_functions ()

 at /export/gnu/import/git/gcc/gcc/cgraphunit.c:1745

 (gdb) p copy

 $176 = (gimple) 0x7fffe8e0a320

 (gdb) 



The BLOCK of the location is kept live by being referenced by the stmt

copy (what kind is the stmt?  the only stmt not well handled seems to

be CLOBBERs)



 Later, the original location is removed:

 

 #0  remove_unused_locals ()

 at /export/gnu/import/git/gcc/gcc/tree-ssa-live.c:793

 #1  0x008ad5cb in execute_function_todo (data=0x8800)

 at /export/gnu/import/git/gcc/gcc/passes.c:1952

 #2  0x008ac965 in do_per_function (

 callback=0x8ad4ae execute_function_todo(void*), data=0x8800)

 at /export/gnu/import/git/gcc/gcc/passes.c:1703

 #3  0x008ad765 in execute_todo (flags=34816)

 at /export/gnu/import/git/gcc/gcc/passes.c:2001

 #4  0x008ae175 in execute_one_pass (

 pass=0x16d3220 pass_cleanup_cfg_post_optimizing)

 at /export/gnu/import/git/gcc/gcc/passes.c:2349

 #5  0x008ae2da in execute_pass_list (

 pass=0x16d3220 pass_cleanup_cfg_post_optimizing)

 at /export/gnu/import/git/gcc/gcc/passes.c:2383

 #6  0x005da366 in expand_function (node=0x717536f0)

 at /export/gnu/import/git/gcc/gcc/cgraphunit.c:1641

 #7  0x005da821 in expand_all_functions ()

 at /export/gnu/import/git/gcc/gcc/cgraphunit.c:1745

 

 and freed.



You probably mean BLOCK - it should be still live as referenced from

the stmt, or cleaned from the stmt if it was a debug stmt.



  Then we copy the freed gimple_location:

 

 #0  expand_gimple_stmt_1 (stmt=0x7fffe8e0a320)

 at /export/gnu/import/git/gcc/gcc/cfgexpand.c:2202

 #1  0x005a7786 in expand_gimple_stmt (stmt=0x7fffe8e0a320)

 at /export/gnu/import/git/gcc/gcc/cfgexpand.c:2305

 #2  0x005ad975 in expand_gimple_basic_block (bb=0x7fffe8d76888, 

 disable_tail_calls=false)

 at /export/gnu/import/git/gcc/gcc/cfgexpand.c:4084

 #3  0x005af426 in gimple_expand_cfg ()

 at /export/gnu/import/git/gcc/gcc/cfgexpand.c:4603

 #4  0x008ae0e6 in execute_one_pass (pass=0x16ce300 pass_expand)

 at /export/gnu/import/git/gcc/gcc/passes.c:2335

 #5  0x008ae2da in execute_pass_list (pass=0x16ce300 pass_expand)

 at /export/gnu/import/git/gcc/gcc/passes.c:2383

 #6  0x005da366 in expand_function (node=0x717536f0)

 at /export/gnu/import/git/gcc/gcc/cgraphunit.c:1641

 #7  0x005da821 in expand_all_functions ()

 at /export/gnu/import/git/gcc/gcc/cgraphunit.c:1745

 #8  0x005db2ab in compile ()

 at /export/gnu/import/git/gcc/gcc/cgraphunit.c:2043

 #9  0x0053c60a in lto_main ()

 at /export/gnu/import/git/gcc/gcc/lto/lto.c:3390

 #10 0x00999401 in compile_file ()

 at /export/gnu/import/git/gcc/gcc/toplev.c:545

[Bug tree-optimization/55823] [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=55823



Richard Biener rguenth at gcc dot gnu.org changed:



   What|Removed |Added



 Status|NEW |RESOLVED

 Resolution||FIXED



--- Comment #10 from Richard Biener rguenth at gcc dot gnu.org 2013-01-09 
09:32:21 UTC ---

Fixed instead.  Missed devirt is something completely different.

[Bug fortran/54286] [4.8 Regression] Accepts invalid proc-pointer assignments involving proc-ptr function result

[pault at gcc dot gnu.org]

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



--- Comment #3 from Paul Thomas pault at gcc dot gnu.org 2013-01-09 09:44:07 
UTC ---

Please find below my interpretation of the validity or not of the testcase for

this PR.



 The following test is probably invalid, but not rejected by recent trunk

 versions:

 

 

 type :: t

   procedure(a), pointer, nopass :: p

 end type

 

 type(t) :: x

 procedure(iabs), pointer :: pp

 

 x%p = a ! ok



[A] I believe that this is invalid because the interfaces do not match

procedure(iabs), pointer  =  integer pointer procedure (integer formal)



It strikes me as being a moot point as to whetehr or not the processor is

required to report it though, on the gorunds that anything goes with

pointers! That said, the interface check is easy to implement.



 x%p = a(1)  ! invalid, but not rejected by 4.8



[B] This is valid:

procedure(iabs), pointer  =  pointer to integer procedure(iabs)



It has the pleasing property of providing the correct result for

print *, x%p(-99) .eq. iabs(-99)



 

 pp = a(2)   ! ok



[B] applies - it also gives the correct result.



 pp = a  ! invalid, but not rejected by 4.8



[A] applies - invalid.



 

 contains

 

   function a (c) result (b)

 integer, intent(in) :: c

 procedure(iabs), pointer :: b

 b = iabs

   end function

 

 end



Interestingly, both invalid lines run and provide results that are consistent

with INT (loc (iabs)) :-)



Paul

[Bug tree-optimization/55913] New: ipa-cp should consider also constants implied by the context it is clonning for

[hubicka at gcc dot gnu.org]

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



 Bug #: 55913

   Summary: ipa-cp should consider also constants implied by the

context it is clonning for

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: enhancement

  Priority: P3

 Component: tree-optimization

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

ReportedBy: hubi...@gcc.gnu.org





In the following testcase (devirt10-C) ipa-cp should devirtualize both calls

class wxPaintEvent {  };

struct wxDCBase

{ 

  wxDCBase ();

  virtual int GetLayoutDirection() const{}

  virtual void SetLayoutDirection(int){}

};

struct wxWindowDC  : public wxDCBase {};

struct wxBufferedDC  : public wxDCBase

{ 

  void Init(wxDCBase*dc) {

InitCommon(dc);

  }

  void InitCommon(wxDCBase*dc) {

if (dc)

  SetLayoutDirection(dc-GetLayoutDirection());

  }

};

struct wxBufferedPaintDC  : public wxBufferedDC {

  wxBufferedPaintDC() {

Init(m_paintdc);

  }

 wxWindowDC m_paintdc;

};

void  OnPaint(wxPaintEvent  event) {

  wxBufferedPaintDC dc;

}



On all calls both THIS and DC binfos are known.  There is no need to create

clone for THIS binfo known and DC unknown as it is done presently.

[Bug c++/55910] One of instances generated for a method with -O3 uses incorrect parameter cleanup size with 'ret'

[ebotcazou at gcc dot gnu.org]

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



Eric Botcazou ebotcazou at gcc dot gnu.org changed:



   What|Removed |Added



 CC||ebotcazou at gcc dot

   ||gnu.org



--- Comment #6 from Eric Botcazou ebotcazou at gcc dot gnu.org 2013-01-09 
09:55:35 UTC ---

 IMHO, I've localized the issue clearly enough. The code that generates

 instances for methods may sometimes consider some of those instances as having

 no parameters in method instance itself and as having some nonzero size of

 parameters (namely 0x38) in caller that re-adjusts stack after method instance

 has cleared the parameters.

 If those numbers would be taken from single variable that kind of bug would be

 impossible. So please examine the code and see where do you get total 
 parameter

 size for 'ret' instruction from and where do you get total parameter size for

 stack re-adjustment from. And then please try to realize why those locations

 could possibly have different numbers in them.



When -O2 is enabled, there are dozens of different passes massaging the initial

code and trying to optimize it.  It is essentially impossible to predict how

they interact with each other given the complexity explosion, that's why being

able to replay the compilation is required.



The rules are clear: if you want the GCC team to look at your problem, you must

provide a reproducer.  Otherwise this PR will be closed as WONTFIX.

[Bug libstdc++/55911] Segfault in unordered_map with max_load_factor 1

[paolo.carlini at oracle dot com]

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



Paolo Carlini paolo.carlini at oracle dot com changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2013-01-09

 CC||fdumont at gcc dot gnu.org,

   ||frs.dumont at gmail dot com

 Ever Confirmed|0   |1



--- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2013-01-09 
10:08:19 UTC ---

I can reproduce this.



Francois can you have a look ASAP? Thanks in advance.

[Bug c++/55914] New: [C++11] Pack expansion for class member expression fails in lambda expressions

[daniel.kruegler at googlemail dot com]

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



 Bug #: 55914

   Summary: [C++11] Pack expansion for class member expression

fails in lambda expressions

Classification: Unclassified

   Product: gcc

   Version: 4.7.2

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: c++

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

ReportedBy: daniel.krueg...@googlemail.com





The following code, compiled with 



-Wall -std=c++11 -pedantic



is rejected by gcc 4.7.2 and gcc 4.8.0 20130106 (experimental):



//-

struct S {

  int foo(){ return 0; }

};



templateclass... Args

void evaluate(Args...){}



template class... Args

void bar(Args... args) {

  evaluate(args.foo()...); // OK

  auto lmb = [=](){ evaluate(args.foo()...); }; // Error

  lmb();

}



int main() {

  S s{};

  bar(s);

}

//-



11|error: parameter packs not expanded with '...':|

11|note: 'args'|

In instantiation of 'void bar(Args ...) [with Args = {S}]':|

17|required from here|

11|error: using invalid field 'bar(Args ...)::__lambda0::__args'|





The problem also occurs for class member expressions of the form E1-E2 instead

of E1.E2.

[Bug c/55915] New: fails to build lto-compress.c, zlib.h not found

[alexpux at gmail dot com]

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



 Bug #: 55915

   Summary: fails to build lto-compress.c, zlib.h not found

Classification: Unclassified

   Product: gcc

   Version: lto

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: c

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

ReportedBy: alex...@gmail.com





I have trouble with building GCC from trunk with system zlib. My configure line

is:

configure --host=x86_64-w64-mingw32 --build=x86_64-w64-mingw32

--target=x86_64-w64-mingw32 

--prefix=/temp/x64-trunk-snapshot-posix-seh-rev3/prefix 

--with-sysroot=/temp/x64-trunk-snapshot-posix-seh-rev3/prefix 

--enable-shared --enable-static --disable-multilib 

--enable-languages=c,c++,fortran,lto 

--enable-libstdcxx-time=yes 

--enable-threads=posix 

--enable-libgomp 

--enable-lto 

--enable-graphite 

--enable-cloog-backend=isl

--enable-checking=release 

--enable-fully-dynamic-string 

--enable-version-specific-runtime-libs 

--disable-ppl-version-check 

--disable-cloog-version-check 

--disable-libstdcxx-pch 

--disable-libstdcxx-debug 

--disable-bootstrap 

--disable-rpath 

--disable-win32-registry 

--disable-nls 

--disable-werror 

--disable-symvers 

--with-gnu-as 

--with-gnu-ld 

--with-arch=nocona --with-tune=core2 

--with-host-libstdcxx=-static -lstdc++ 

--with-libiconv

 --with-system-zlib 

--with-gmp=/temp/mingw-prereq/x86_64-w64-mingw32-static 

--with-mpfr=/temp/mingw-prereq/x86_64-w64-mingw32-static

--with-mpc=/temp/mingw-prereq/x86_64-w64-mingw32-static 

--with-ppl=/temp/mingw-prereq/x86_64-w64-mingw32-static 

--with-cloog=/temp/mingw-prereq/x86_64-w64-mingw32-static 

--with-pkgversion=Built by MinGW-builds project 

--with-bugurl=http://sourceforge.net/projects/mingwbuilds/ 

CFLAGS=-O2 -pipe -fomit-frame-pointer

-I/temp/x64-trunk-snapshot-posix-seh-rev3/libs/include

-I/temp/mingw-prereq/x86_64-w64-mingw32-static/include

-I/temp/mingw-prereq/x64-zlib/include 

CXXFLAGS=-O2 -pipe -fomit-frame-pointer 

CPPFLAGS= 

LDFLAGS=-pipe -L/temp/x64-trunk-snapshot-posix-seh-rev3/libs/lib

-L/temp/mingw-prereq/x86_64-w64-mingw32-static/lib

-L/temp/x64-trunk-snapshot-posix-seh-rev3/prefix/opt/lib

-L/temp/mingw-prereq/x64-zlib/lib



I have prebuilded zlib in /temp/mingw-prereq/x64-zlib.

During build I nave error:



x86_64-w64-mingw32-g++ -c   -O2 -pipe -fomit-frame-pointer -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   -DHAVE_CONFIG_H -I. -I.

-I../../../../mingw-sources/gcc-trunk/gcc

-I../../../../mingw-sources/gcc-trunk/gcc/.

-I../../../../mingw-sources/gcc-trunk/gcc/../include

-I../../../../mingw-sources/gcc-trunk/gcc/../libcpp/include

-I/temp/mingw-prereq/x86_64-w64-mingw32-static/include

-I/temp/mingw-prereq/x86_64-w64-mingw32-static/include

-I/temp/mingw-prereq/x86_64-w64-mingw32-static/include 

-I../../../../mingw-sources/gcc-trunk/gcc/../libdecnumber

-I../../../../mingw-sources/gcc-trunk/gcc/../libdecnumber/bid -I../libdecnumber

-I../../../../mingw-sources/gcc-trunk/gcc/../libbacktrace   

../../../../mingw-sources/gcc-trunk/gcc/lto-compress.c -o lto-compress.o

../../../../mingw-sources/gcc-trunk/gcc/lto-compress.c:28:18: fatal error:

zlib.h: No such file or directory

compilation terminated.

make[2]: *** [lto-compress.o] Error 1

make[2]: Leaving directory

`/temp/x64-trunk-snapshot-posix-seh-rev3/build/gcc-trunk/gcc'

make[1]: *** [all-gcc] Error 2

make[1]: Leaving directory

`/temp/x64-trunk-snapshot-posix-seh-rev3/build/gcc-trunk'

make: *** [all] Error 2

[Bug target/55909] libtool test exposes what I think is some alignment issue in libstdc++

[mikpe at it dot uu.se]

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



Mikael Pettersson mikpe at it dot uu.se changed:



   What|Removed |Added



 CC||mikpe at it dot uu.se



--- Comment #16 from Mikael Pettersson mikpe at it dot uu.se 2013-01-09 
10:13:02 UTC ---

Something is seriously broken in Philip's environment or his gcc-4.7 build.  I

get fairly clean g++/libstdc++ test suite results with vanilla 4.7 on Fedora

15/sparc64 + kernel 3.8-rc2, see e.g.

http://gcc.gnu.org/ml/gcc-testresults/2013-01/msg00571.html.



One thing that differs is that my gcc is configured for 32-bit code by default

with the ability to generate 64-bit code when requested

(--target=sparc-unknown-linux --with-cpu=ultrasparc --enable-targets=all),

whereas I assume that Philip's sparc64 rpms are 64-bit binaries generating

64-bit code by default.



I could do a pure 64-bit bootstrap + regtest in a day or two, just to check.

[Bug target/55909] libtool test exposes what I think is some alignment issue in libstdc++

[paolo.carlini at oracle dot com]

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



--- Comment #17 from Paolo Carlini paolo.carlini at oracle dot com 2013-01-09 
10:18:34 UTC ---

Thanks Mikael. Thus I suppose the minimized snippet in Comment #14 also runs

fine for you? Indeed, it would be nice if you could try to reproduce the exact

problem Philip is seeing in a pure 64-bit setup.

[Bug c++/55914] [C++11] Pack expansion for class member expression fails in lambda expressions

[paolo.carlini at oracle dot com]

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



Paolo Carlini paolo.carlini at oracle dot com changed:



   What|Removed |Added



 Blocks||54367



--- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2013-01-09 
10:23:56 UTC ---

I suspect this is just a different manifestation of PR41933.

[Bug c++/55900] [C++11]internal compiler error with initializer list

[paolo.carlini at oracle dot com]

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



Paolo Carlini paolo.carlini at oracle dot com changed:



   What|Removed |Added



 Status|NEW |RESOLVED

 Resolution||FIXED



--- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 2013-01-09 
10:28:52 UTC ---

The 2nd testcase in PR55753 is now also fixed.

[Bug target/55909] libtool test exposes what I think is some alignment issue in libstdc++

[mikpe at it dot uu.se]

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



--- Comment #18 from Mikael Pettersson mikpe at it dot uu.se 2013-01-09 
10:32:35 UTC ---

Yes, the snippet in Comment #14 works fine for me, with both -m32 and -m64.

[Bug tree-optimization/55264] [4.6/4.7/4.8 Regression] ICE: in ipa_make_edge_direct_to_target, at ipa-prop.c:2141 with -O2 -fno-early-inlining -fno-weak

[jamborm at gcc dot gnu.org]

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



--- Comment #7 from Martin Jambor jamborm at gcc dot gnu.org 2013-01-09 
10:36:02 UTC ---

Unfortunately, that causes the following failures:



g++.dg/lto/20081217-2 cp_lto_20081217-2_0.o-cp_lto_20081217-2_0.o link, -O2

-flto -flto-partition=none -fuse-linker-plugin -fno-fat-lto-objects  (internal

compiler error)

g++.dg/lto/20081217-2 cp_lto_20081217-2_0.o-cp_lto_20081217-2_0.o link, -O2

-flto -fuse-linker-plugin (internal compiler error)

g++.dg/torture/pr34099.C  -O2 -flto -fno-use-linker-plugin -flto-partition=none

 (internal compiler error)

g++.dg/torture/pr45934.C  -O2 -flto -fno-use-linker-plugin -flto-partition=none

 (internal compiler error)

g++.dg/torture/pr45934.C  -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects 

(internal compiler error)

g++.dg/torture/pr47382.C  -O2 -flto -fno-use-linker-plugin -flto-partition=none

 (internal compiler error)

g++.dg/torture/pr47382.C  -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects 

(internal compiler error)



Let me look into those...

[Bug target/55909] libtool test exposes what I think is some alignment issue in libstdc++

[philip.copeland at oracle dot com]

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



--- Comment #19 from philip.copeland at oracle dot com 2013-01-09 10:37:38 UTC 
---

Mikael, could you compare against the versions of packages that I'm using?



gcc requires the following according to fedora)

cloog-ppl-0.15.11-4.fc18.1.sparc64

cpp-4.7.2-8.fc18.sparc64

libmpc-0.9-3.fc18.2.sparc64

mpfr-3.0.0-4.fc18.sparc64

gmp-5.0.5-3.fc18.sparc64

binutils-2.23.51.0.1-3.fc18.sparc64

gcc-4.7.2-8.fc18.sparc64

glibc-2.16-28.fc18.sparc64

elfutils-0.155-2.fc18.sparc64 * modified as per

https://bugzilla.redhat.com/attachment.cgi?id=672431action=diff *



Hurm,.. your build of gcc-4.7.?, was that unmodified or with the slew of RHT

patches that the fc* packages normally gets added, applied?



Thanks

[Bug c++/55914] [C++11] Pack expansion for class member expression fails in lambda expressions

[daniel.kruegler at googlemail dot com]

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

--- Comment #2 from Daniel Krügler daniel.kruegler at googlemail dot com 
2013-01-09 10:39:29 UTC ---
(In reply to comment #1)
 I suspect this is just a different manifestation of PR41933.

Thanks Paolo, I partially agree. Indeed the problem is not depending on class
member expressions (so the issue title should be fixed), a simplified example
can be written as:

//
struct S {};

templateclass... Args
void evaluate(Args...){}

template class... Args
void bar(Args... args) {
  evaluate(args...); // OK
  auto lmb = [=](){ evaluate(args...); }; // Error
  lmb();
}

int main() {
  S s{};
  bar(s);
}
//

with the error:

9|error: parameter packs not expanded with '...':|
9|note: 'args'|
9|error: expansion pattern 'args' contains no argument packs|
|In instantiation of 'void bar(Args ...) [with Args = {S}]':|
15|required from here|
9|error: using invalid field 'bar(Args ...)::__lambda0::__args'|

The reason why I hesitate to agree with that being a dup of bug 41933 is due to
the fact that the corresponding example there depends on a language extension
described in

http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#904

that is not part of C++11. I do think though, that my revised example above is
indeed conforming C++11 because it does not depend on that grammar extension.

Please keep that in mind when considering the category change to DUP, because
that would have impact on which versions of gcc to patch. For example, I assume
that any CWG defect 904 association would presumably not be applied to gcc
4.7.2.

[Bug middle-end/55882] [4.7/4.8 Regression] unaligned load/store : incorrect struct offset

[rguenth at gcc dot gnu.org]

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



Richard Biener rguenth at gcc dot gnu.org changed:



   What|Removed |Added



   Keywords||wrong-code

 Status|WAITING |NEW

 CC||ebotcazou at gcc dot

   ||gnu.org, rguenth at gcc dot

   ||gnu.org

  Component|c   |middle-end

   Target Milestone|--- |4.7.3

Summary|unaligned load/store :  |[4.7/4.8 Regression]

   |incorrect struct offset |unaligned load/store :

   ||incorrect struct offset



--- Comment #10 from Richard Biener rguenth at gcc dot gnu.org 2013-01-09 
10:41:28 UTC ---

Eric, I am double-checking my patch and I believe all this 'bitpos' handling

in set_mem_attributes_minus_bitpos (and/or MEM_OFFSET in general) looks

suspicious.



/* For a MEM rtx, the offset from the start of MEM_EXPR.  */

#define MEM_OFFSET(RTX) (get_mem_attrs (RTX)-offset)



I read from this that the XEXP (RTX, 0) points to MEM_EXPR + MEM_OFFSET

(if MEM_OFFSET_KNOWN_P, and if !MEM_OFFSET_KNOWN_P we don't know how

XEXP (RTX, 0) and MEM_EXPR relate).



Now, in expand_assignment we do



  tem = get_inner_reference (to, bitsize, bitpos, offset, mode1,

 unsignedp, volatilep, true);



  if (TREE_CODE (to) == COMPONENT_REF

   DECL_BIT_FIELD_TYPE (TREE_OPERAND (to, 1)))

get_bit_range (bitregion_start, bitregion_end, to, bitpos, offset);



...

  to_rtx = expand_expr (tem, NULL_RTX, VOIDmode, EXPAND_WRITE);

...

  offset it with variable parts from 'offset'

...

  set_mem_attributes_minus_bitpos (to_rtx, to, 0, bitpos);



but bitpos here is _not_ ontop of 'to' but extracted from 'to' (and

eventually modified by get_bit_range which may shift things to 'offset').



The only 'bitpos' that should be passed to set_mem_attributes_minus_bitpos

is one that reflects - in the bitfield access case - that we actually

access things at a different position.  But at this point we don't know

what optimize_bitfield_assignment_op or store_field will eventually do.

Also MEM_OFFSET is in bytes while I believe 'bitpos' can end up as

an actual bit position, so



  /* If we modified OFFSET based on T, then subtract the outstanding

 bit position offset.  Similarly, increase the size of the accessed

 object to contain the negative offset.  */

  if (apply_bitpos)

{

  gcc_assert (attrs.offset_known_p);

  attrs.offset -= apply_bitpos / BITS_PER_UNIT;

  if (attrs.size_known_p)

attrs.size += apply_bitpos / BITS_PER_UNIT;

}



(whatever this comment means).  I believe my fix is correct following

the MEM_OFFSET description and guessing at what the argument to

set_mem_attributes_minus_bitpos means by looking at its use.  But I

believe that expand_assignment should pass zero as bitpos to

set_mem_attributes_minus_bitpos (making the only caller that calls this

function with bitpos != 0 go).



In this testcase we want to access sth at offset 8 bytes, 0 bits but

the memory model tells us the bitregion to consider is

everything from offset 6 to offset 14 so instead of the correct

initial mem



(mem/j:HI (plus:SI (reg/f:SI 206)

(const_int 8 [0x6])) [0 dmfe[i_1].use_alt_rd_dqs S2 A32])



(with 4 byte alignemnt!) we create



(mem/j:BLK (plus:SI (reg/f:SI 206)

(const_int 6 [0x6])) [0 dmfe[i_1].use_alt_rd_dqs+-6 S8 A32])



where the alignment is bogus.



Thus, given the above general MEM_OFFSET analysis I'd say the following

(ontop of my previous patch) should fix things more correctly:



Index: gcc/expr.c

===

--- gcc/expr.c  (revision 195014)

+++ gcc/expr.c  (working copy)

@@ -4669,7 +4669,7 @@ expand_assignment (tree to, tree from, b

   || TREE_CODE (TREE_TYPE (to)) == ARRAY_TYPE)

 {

   enum machine_mode mode1;

-  HOST_WIDE_INT bitsize, bitpos;

+  HOST_WIDE_INT bitsize, bitpos, bitpos_adj;

   unsigned HOST_WIDE_INT bitregion_start = 0;

   unsigned HOST_WIDE_INT bitregion_end = 0;

   tree offset;

@@ -4683,9 +4683,15 @@ expand_assignment (tree to, tree from, b

   tem = get_inner_reference (to, bitsize, bitpos, offset, mode1,

 unsignedp, volatilep, true);



+  bitpos_adj = 0;

   if (TREE_CODE (to) == COMPONENT_REF

   DECL_BIT_FIELD_TYPE (TREE_OPERAND (to, 1)))

-   get_bit_range (bitregion_start, bitregion_end, to, bitpos, offset);

+   {

+ HOST_WIDE_INT orig_bitpos = bitpos;

+ get_bit_range (bitregion_start, 

[Bug target/55909] libtool test exposes what I think is some alignment issue in libstdc++

[paolo.carlini at oracle dot com]

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



--- Comment #20 from Paolo Carlini paolo.carlini at oracle dot com 2013-01-09 
10:49:44 UTC ---

Thanks Mikael. Having the testresults for -m32 and -m64 is also nice, by the

way. And they indeed look very good!



Philip's latest testsuite results look decent but worse. Some of those

fails are definitely more convenient than Comment #14, because they don't

include anything.  We should figure out whether Philip is seeing something like

an individual miscompilation in a determinant place, like in crtstuff.c, or

many different problems.

[Bug target/55909] libtool test exposes what I think is some alignment issue in libstdc++

[paolo.carlini at oracle dot com]

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



--- Comment #21 from Paolo Carlini paolo.carlini at oracle dot com 2013-01-09 
10:52:07 UTC ---

Philip, from http://gcc.gnu.org/ml/gcc-testresults/2013-01/msg00571.html seems

obvious that Mikael is simply fetching with subversion and building.

[Bug c++/55914] [C++11] Pack expansion fails in lambda expressions

[paolo.carlini at oracle dot com]

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



Paolo Carlini paolo.carlini at oracle dot com changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2013-01-09

 Ever Confirmed|0   |1



--- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 2013-01-09 
10:56:03 UTC ---

Thanks Daniel, don't worry I'm not going to close anything for now. But we

should really clarify in PR41933 that the issue isn't about C++11 proper.

[Bug target/55909] libtool test exposes what I think is some alignment issue in libstdc++

[philip.copeland at oracle dot com]

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



--- Comment #22 from philip.copeland at oracle dot com 2013-01-09 10:59:13 UTC 
---

Ok so he's using 4.7.3 not 4.7.2-(butched by fedora folk) (there's about 24

patchs they apply)



ugh,.. what would you like me to do here then? pull over 4.7.3.svn and give

that a spin?



Phil

=--=

[Bug c++/55914] [C++11] Pack expansion fails in lambda expressions

[paolo.carlini at oracle dot com]

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



--- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com 2013-01-09 
10:59:54 UTC ---

Daniel, are you sure PR41933 isn't C++11 proper? I gather that the

corresponding Core issue (which at the time Jason also referenced) went into

CD2, thus isn't just C++11?!?

[Bug target/55909] libtool test exposes what I think is some alignment issue in libstdc++

[paolo.carlini at oracle dot com]

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



--- Comment #23 from Paolo Carlini paolo.carlini at oracle dot com 2013-01-09 
11:07:10 UTC ---

Oh well, testing the current vanilla 4_7-branch is always a good idea, if you

ask me. That said, it seems very unlikely that back in the 4.7.2 times

something such basic as your reduced Comment #14 could not work (it's the C++

Hello World!, literally!). Well, we could also bootstrap vanilla 4.7.2 and

see what happens.

[Bug middle-end/55882] [4.7/4.8 Regression] unaligned load/store : incorrect struct offset

[rguenth at gcc dot gnu.org]

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



--- Comment #11 from Richard Biener rguenth at gcc dot gnu.org 2013-01-09 
11:26:10 UTC ---

(In reply to comment #8)

 Or more correct

 

 Index: gcc/emit-rtl.c

 ===

 --- gcc/emit-rtl.c  (revision 195014)

 +++ gcc/emit-rtl.c  (working copy)

 @@ -1839,7 +1839,12 @@ set_mem_attributes_minus_bitpos (rtx ref

 

if (!align_computed)

 {

 - unsigned int obj_align = get_object_alignment (t);

 + unsigned int obj_align;

 + unsigned HOST_WIDE_INT obj_bitpos;

 + get_object_alignment_1 (t, obj_align, obj_bitpos);

 + obj_bitpos = (obj_bitpos + apply_bitpos)  (obj_align - 1);



And actually



 obj_bitpos = (obj_bitpos - apply_bitpos)  (obj_align - 1);



 + if (obj_bitpos != 0)

 +   obj_align = (obj_bitpos  -obj_bitpos);

   attrs.align = MAX (attrs.align, obj_align);

 }

  }

[Bug middle-end/55882] [4.7/4.8 Regression] unaligned load/store : incorrect struct offset

[rguenth at gcc dot gnu.org]

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



--- Comment #12 from Richard Biener rguenth at gcc dot gnu.org 2013-01-09 
11:35:33 UTC ---

(In reply to comment #10)

 Eric, I am double-checking my patch and I believe all this 'bitpos' handling

 in set_mem_attributes_minus_bitpos (and/or MEM_OFFSET in general) looks

 suspicious.

 

 /* For a MEM rtx, the offset from the start of MEM_EXPR.  */

 #define MEM_OFFSET(RTX) (get_mem_attrs (RTX)-offset)

 

 I read from this that the XEXP (RTX, 0) points to MEM_EXPR + MEM_OFFSET

 (if MEM_OFFSET_KNOWN_P, and if !MEM_OFFSET_KNOWN_P we don't know how

 XEXP (RTX, 0) and MEM_EXPR relate).

 

 Now, in expand_assignment we do

 

   tem = get_inner_reference (to, bitsize, bitpos, offset, mode1,

  unsignedp, volatilep, true);

 

   if (TREE_CODE (to) == COMPONENT_REF

DECL_BIT_FIELD_TYPE (TREE_OPERAND (to, 1)))

 get_bit_range (bitregion_start, bitregion_end, to, bitpos, 
 offset);

 

 ...

   to_rtx = expand_expr (tem, NULL_RTX, VOIDmode, EXPAND_WRITE);

 ...

   offset it with variable parts from 'offset'

 ...

   set_mem_attributes_minus_bitpos (to_rtx, to, 0, bitpos);

 

 but bitpos here is _not_ ontop of 'to' but extracted from 'to' (and

 eventually modified by get_bit_range which may shift things to 'offset').

 

 The only 'bitpos' that should be passed to set_mem_attributes_minus_bitpos

 is one that reflects - in the bitfield access case - that we actually

 access things at a different position.  But at this point we don't know

 what optimize_bitfield_assignment_op or store_field will eventually do.

 Also MEM_OFFSET is in bytes while I believe 'bitpos' can end up as

 an actual bit position, so

 

   /* If we modified OFFSET based on T, then subtract the outstanding

  bit position offset.  Similarly, increase the size of the accessed

  object to contain the negative offset.  */

   if (apply_bitpos)

 {

   gcc_assert (attrs.offset_known_p);

   attrs.offset -= apply_bitpos / BITS_PER_UNIT;

   if (attrs.size_known_p)

 attrs.size += apply_bitpos / BITS_PER_UNIT;

 }

 

 (whatever this comment means).  I believe my fix is correct following

 the MEM_OFFSET description and guessing at what the argument to

 set_mem_attributes_minus_bitpos means by looking at its use.  But I

 believe that expand_assignment should pass zero as bitpos to

 set_mem_attributes_minus_bitpos (making the only caller that calls this

 function with bitpos != 0 go).

 

 In this testcase we want to access sth at offset 8 bytes, 0 bits but

 the memory model tells us the bitregion to consider is

 everything from offset 6 to offset 14 so instead of the correct

 initial mem

 

 (mem/j:HI (plus:SI (reg/f:SI 206)

 (const_int 8 [0x6])) [0 dmfe[i_1].use_alt_rd_dqs S2 A32])

 

 (with 4 byte alignemnt!) we create

 

 (mem/j:BLK (plus:SI (reg/f:SI 206)

 (const_int 6 [0x6])) [0 dmfe[i_1].use_alt_rd_dqs+-6 S8 A32])

 

 where the alignment is bogus.

 

 Thus, given the above general MEM_OFFSET analysis I'd say the following

 (ontop of my previous patch) should fix things more correctly:

 

 Index: gcc/expr.c

 ===

 --- gcc/expr.c  (revision 195014)

 +++ gcc/expr.c  (working copy)

 @@ -4669,7 +4669,7 @@ expand_assignment (tree to, tree from, b

|| TREE_CODE (TREE_TYPE (to)) == ARRAY_TYPE)

  {

enum machine_mode mode1;

 -  HOST_WIDE_INT bitsize, bitpos;

 +  HOST_WIDE_INT bitsize, bitpos, bitpos_adj;

unsigned HOST_WIDE_INT bitregion_start = 0;

unsigned HOST_WIDE_INT bitregion_end = 0;

tree offset;

 @@ -4683,9 +4683,15 @@ expand_assignment (tree to, tree from, b

tem = get_inner_reference (to, bitsize, bitpos, offset, mode1,

  unsignedp, volatilep, true);

 

 +  bitpos_adj = 0;

if (TREE_CODE (to) == COMPONENT_REF

DECL_BIT_FIELD_TYPE (TREE_OPERAND (to, 1)))

 -   get_bit_range (bitregion_start, bitregion_end, to, bitpos, 
 offset);

 +   {

 + HOST_WIDE_INT orig_bitpos = bitpos;

 + get_bit_range (bitregion_start, bitregion_end,

 +to, bitpos, offset);

 + bitpos_adj = orig_bitpos - bitpos;

 +   }

 

/* If we are going to use store_bit_field and extract_bit_field,

  make sure to_rtx will be safe for multiple use.  */

 @@ -4839,7 +4845,7 @@ expand_assignment (tree to, tree from, b

  DECL_RTX of the parent struct.  Don't munge it.  */

   to_rtx = shallow_copy_rtx (to_rtx);

 

 - set_mem_attributes_minus_bitpos (to_rtx, to, 0, bitpos);

 + set_mem_attributes_minus_bitpos (to_rtx, to, 0, bitpos_adj);

 

   /* Deal with volatile and readonly fields.  The former is only

  done for MEM.  Also 

[Bug target/16350] gcc only understands little endian ARM systems

[sam.thursfield at codethink dot co.uk]

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



Sam Thursfield sam.thursfield at codethink dot co.uk changed:



   What|Removed |Added



 CC||sam.thursfield at codethink

   ||dot co.uk



--- Comment #30 from Sam Thursfield sam.thursfield at codethink dot co.uk 
2013-01-09 11:36:46 UTC ---

I hit this bug trying to build a GCC 4.6.2 that defaulted to ARMv7-a

big-endian. Correct code would only be produced if -mbig-endian was passed

during linking so that the --be8 flag was passed to the linker, but this meant

that the compiler on my target system defaulted to producing code that didn't

work on the target system -- not pretty.



This particular issue has been fixed in 4.7.3 and later, however:



2012-07-25  Bharathi Seshadri  bsesh...@cisco.com

   Jim Wilson  jimwi...@cisco.com



   * config/arm/bpabi.h (BE8_LINK_SPEC): Set according to

   TARGET_BIG_ENDIAN_DEFAULT.



From http://gcc.gnu.org/git/gcc.git:



commit c6e19dd6c296449f6d9e54d630f8198acf103d24

Author: wilson wilson@138bc75d-0d04-0410-961f-82ee72b054a4

Date:   Wed Jul 25 20:13:46 2012 +



Pass -be8 by default for armv7-a when configured big-endian.

config/arm/bpabi.h (BE8_LINK_SPEC): Set according to

TARGET_BIG_ENDIAN_DEFAULT.





git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@189867

138bc75d-0d04-0410-961f-82ee72b054a4



Backporting this patch to 4.6.2 means that I now have a compiler that produces

correct code just from appending eb to the CPU in the target triplet and

configuring GCC with the correct --with-arch= flag.

[Bug c++/55914] [C++11] Pack expansion fails in lambda expressions

[daniel.kruegler at googlemail dot com]

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

--- Comment #5 from Daniel Krügler daniel.kruegler at googlemail dot com 
2013-01-09 11:37:49 UTC ---
(In reply to comment #4)
You are right, I missed the CD2 tag

[Bug libstdc++/55911] Segfault in unordered_map with max_load_factor 1

[paolo.carlini at oracle dot com]

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



--- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2013-01-09 
11:38:03 UTC ---

Important note: I can reproduce the Segmentation fault way back to 4_5-branch,

in other terms, whatever it is, happened also with the old implementation very

close to the TR1 containers.

[Bug target/16350] gcc only understands little endian ARM systems

[sam.thursfield at codethink dot co.uk]

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



--- Comment #31 from Sam Thursfield sam.thursfield at codethink dot co.uk 
2013-01-09 11:46:59 UTC ---

Ignore the comment about GCC 4.7.3, which doesn't even exist. Looks like the

fix is only in trunk so far.

[Bug fortran/55916] New: Alignment issues with real(16) on i686

[jakub at gcc dot gnu.org]

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



 Bug #: 55916

   Summary: Alignment issues with real(16) on i686

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: fortran

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

ReportedBy: ja...@gcc.gnu.org





The following testcase with -m32 -msse4 -g -O3 -fno-inline may segfault

(depending on whether malloc returns just 8-byte or 16-byte aligned pointer).



  real(16), allocatable ::  (:)

  real(16) :: x(10)

  integer :: i,n=10



  allocate((n))

  do i = 1,n

(i) = 8.0

  enddo

  call foo ()

  deallocate()

contains

  subroutine foo ()

real(16), allocatable :: (:)

(1) = (1) + 1

  end subroutine

end



The problem is that __float128 aka real(16) has alignment 128 bits, but on

i686-linux malloc only guarantees 64 bit alignment (2 * sizeof (void *) byte

alignment).  As __float128 is outside of the scope of C/C++, this is not a bug

on the C library side.

Guess for real(16) allocatables or any allocatables that require alignment

bigger than that of standard types Fortran should use posix_memalign (or

perhaps some libgfortran wrapper) that will be passed not just the size to

allocate, but also required alignment.

[Bug target/55909] libtool test exposes what I think is some alignment issue in libstdc++

[ebotcazou at gcc dot gnu.org]

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



--- Comment #24 from Eric Botcazou ebotcazou at gcc dot gnu.org 2013-01-09 
11:51:22 UTC ---

 #1  0xf80100490988 in __cxxabiv1::__cxa_get_globals ()

 at ../../../../libstdc++-v3/libsupc++/eh_globals.cc:63

 63  { return get_global(); }

 (gdb) disassemble

 Dump of assembler code for function __cxxabiv1::__cxa_get_globals():

0xf80100490960 +0: save  %sp, -176, %sp

0xf80100490964 +4: sethi  %hi(0), %o0

0xf80100490968 +8: sethi  %hi(0), %i0

0xf8010049096c +12:sethi  %hi(0x18f400), %l7

0xf80100490970 +16:call  0xf8010048dce0

 __sparc_get_pc_thunk.l7

0xf80100490974 +20:add  %l7, 0x290, %l7! 0x18f690

0xf80100490978 +24:add  %o0, 8, %o0

0xf8010049097c +28:xor  %i0, 0, %i0

0xf80100490980 +32:call  0xf8010061a558

0xf80100490984 +36:add  %l7, %o0, %o0

 = 0xf80100490988 +40:add  %o0, %i0, %i0

0xf8010049098c +44:rett  %i7 + 8

0xf80100490990 +48:nop 



Here's the disassembly for a working version of the compiler:



Dump of assembler code for function __cxxabiv1::__cxa_get_globals():

   0xf801001ea7a0 +0: save  %sp, -176, %sp

   0xf801001ea7a4 +4: sethi  %hi(0xc00), %o0

   0xf801001ea7a8 +8: sethi  %hi(0), %i0

   0xf801001ea7ac +12:sethi  %hi(0x129800), %l7

   0xf801001ea7b0 +16:call  0xf80100182e60

__sparc_get_pc_thunk.l7

   0xf801001ea7b4 +20:add  %l7, 0x50, %l7 ! 0x129850

= 0xf801001ea7b8 +24:add  %o0, 0x140, %o0

   0xf801001ea7bc +28:xor  %i0, 0x10, %i0

   0xf801001ea7c0 +32:call  0xf80100317c20 __tls_get_addr@plt

   0xf801001ea7c4 +36:add  %l7, %o0, %o0

   0xf801001ea7c8 +40:add  %o0, %i0, %i0

   0xf801001ea7cc +44:rett  %i7 + 8

   0xf801001ea7d0 +48:nop 



So it looks like the dynamic linker screwed up the PLT on your system.  I think

that you should rebuild the compiler without --enable-initfini-array.

[Bug fortran/55916] Alignment issues with real(16) on i686

[rguenth at gcc dot gnu.org]

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



Richard Biener rguenth at gcc dot gnu.org changed:



   What|Removed |Added



   Keywords||wrong-code

 Status|UNCONFIRMED |NEW

   Last reconfirmed||2013-01-09

 Ever Confirmed|0   |1



--- Comment #1 from Richard Biener rguenth at gcc dot gnu.org 2013-01-09 
11:55:09 UTC ---

Or inline the re-alignment code (and allocate one more element).  That will

allow for the most optimization opportunities.



posix_memalign unfortunately has a weird enough interface that we can't

easily extract alignment for the pointer.

[Bug fortran/54286] [4.8 Regression] Accepts invalid proc-pointer assignments involving proc-ptr function result

[mikael at gcc dot gnu.org]

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



Mikael Morin mikael at gcc dot gnu.org changed:



   What|Removed |Added



 CC||mikael at gcc dot gnu.org



--- Comment #4 from Mikael Morin mikael at gcc dot gnu.org 2013-01-09 
12:06:53 UTC ---

(In reply to comment #3)

  type :: t

procedure(a), pointer, nopass :: p

  end type

  

  type(t) :: x

  procedure(iabs), pointer :: pp

  

  x%p = a ! ok

 

 [A] I believe that this is invalid because the interfaces do not match

 procedure(iabs), pointer  =  integer pointer procedure (integer formal)



[...] 

  x%p = a(1)  ! invalid, but not rejected by 4.8

 

 [B] This is valid:

 procedure(iabs), pointer  =  pointer to integer procedure(iabs)



Huh? the interface of `x%p' is `a', not `iabs'.

I think the comments are correct; the former is valid, the latter invalid.

[Bug libstdc++/55911] Segfault in unordered_map with max_load_factor 1

[redi at gcc dot gnu.org]

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



--- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2013-01-09 
12:15:39 UTC ---

This is invalid if size()  bucket_count(), which is very likely:



  for (size_t i = 0; i  umap.size(); i++)

{

  const size_t bs = umap.bucket_size (i);



Shouldn't the loop condition be i  umap.bucket_count() instead?

[Bug libstdc++/55911] Segfault in unordered_map with max_load_factor 1

[redi at gcc dot gnu.org]

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



Jonathan Wakely redi at gcc dot gnu.org changed:



   What|Removed |Added



 Status|NEW |RESOLVED

 Resolution||INVALID



--- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org 2013-01-09 
12:16:51 UTC ---

Debug Mode even catches it:



unordered_map:max_size: 576460752303423487

unordered_map:size: 10352716

unordered_map:bucket_count: 218971

unordered_map: load_factor: 47.278938

unordered_map: max_load_factor: 50.00

/home/wakelj/tools/Linux-f12-x86_64/4.8/include/c++/4.8.0/debug/unordered_map:229:

error: attempt to access container with out-of-bounds bucket index

218971, container only holds 218971 buckets.



Objects involved in the operation:

sequence this @ 0x0x7fffd8ae2810 {

  type = NSt7__debug13unordered_mapIld11HashPtrdiffSt8equal_toIlESaIlEEE;

}

Aborted (core dumped)

[Bug libstdc++/55911] Segfault in unordered_map with max_load_factor 1

[redi at gcc dot gnu.org]

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



Jonathan Wakely redi at gcc dot gnu.org changed:



   What|Removed |Added



   Severity|major   |normal



--- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org 2013-01-09 
12:19:11 UTC ---

When load_factor  1 there will be more than 1 element in some buckets,

implying fewer buckets than elements, so the loop accesses non-existent

buckets.



When load_factor==1 the bucket_count() == size() so the loop succeeds (but is

still potentially wrong because the load_factor is only the *average* number of

elements per bucket.)

[Bug target/55909] libtool test exposes what I think is some alignment issue in libstdc++

[philip.copeland at oracle dot com]

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



--- Comment #25 from philip.copeland at oracle dot com 2013-01-09 12:21:19 UTC 
---

Mmm yes I did notice the x86_64 trace I did  bounced off into the tls/PLT area

Breakpoint 1, __cxxabiv1::__cxa_get_globals ()

at ../../../../libstdc++-v3/libsupc++/eh_globals.cc:63

63  { return get_global(); }

(gdb) stepi

0x00354f25e1a7  63  { return get_global(); }

(gdb) stepi

0x00354f25a3f0 in __tls_get_addr@plt () from /lib64/libstdc++.so.6

(gdb) stepi

0x00354f25a3f6 in __tls_get_addr@plt () from /lib64/libstdc++.so.6

(gdb) stepi

0x00354f25a3fb in __tls_get_addr@plt () from /lib64/libstdc++.so.6

(gdb) stepi

0x00354f258ff0 in ?? () from /lib64/libstdc++.so.6





where as the sparc went pretty much nowhere 8/



Ok,.. I was mid compiling 4.7.3  but it's a little more convenient to quickly

change 4.7.2-8 as you suggest and give that a quick check,.. should take a few

hours to get that far. I'll update in mm ~3-4 hours I guess



Thanks



Mikael, as reference was your version of 4.7.3 compiled without

--enable-initfini-array ?

[Bug fortran/55916] Alignment issues with real(16) on i686

[glisse at gcc dot gnu.org]

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



Marc Glisse glisse at gcc dot gnu.org changed:



   What|Removed |Added



 CC||glisse at gcc dot gnu.org



--- Comment #2 from Marc Glisse glisse at gcc dot gnu.org 2013-01-09 12:25:43 
UTC ---

(In reply to comment #1)

 posix_memalign unfortunately has a weird enough interface that we can't

 easily extract alignment for the pointer.



Is it just because it outputs through a pointer? Are aligned_alloc, memalign 

and others easier then?

[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 #11 from Kai Tietz ktietz at gcc dot gnu.org 2013-01-09 12:30:50 
UTC ---

Created attachment 29119

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

Testcase for bitfield and type-packing



This first testcase checking pack-pragma for x64/x86 MS-struct layout.

I got this testcase verified by a VC user.  It was verified with VC10, VC11,

and (Nov2012_CTP).

(Btw no regression with my suggested patch applied).

[Bug target/55909] libtool test exposes what I think is some alignment issue in libstdc++

[mikpe at it dot uu.se]

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



--- Comment #26 from Mikael Pettersson mikpe at it dot uu.se 2013-01-09 
12:42:13 UTC ---

(In reply to comment #19)

 Mikael, could you compare against the versions of packages that I'm using?



Well, my environment is Fedora 15 so all system components are older.  glibc is

2.13.90-4.1 for instance.  The other things that matter for gcc are newer and

compiled and installed privately by myself: gmp-5.0.5, mpfr-3.1.1, mpc-1.0.1,

binutils-2.22, all compiled by my own gcc-4.6.3.



 Hurm,.. your build of gcc-4.7.?, was that unmodified or with the slew of RHT

 patches that the fc* packages normally gets added, applied?



That was with unmodified FSF sources (a weekly svn snapshot tarball).



Note that RH's gcc src rpms are usually (always?) based on RH's own gcc

branches

(see http://gcc.gnu.org/viewcvs/branches/redhat/) rather than vanilla upstream

releases or snapshots, so the amount of modifications are much larger than what

the explicit set of patches indicate.

[Bug target/55909] libtool test exposes what I think is some alignment issue in libstdc++

[mikpe at it dot uu.se]

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



--- Comment #27 from Mikael Pettersson mikpe at it dot uu.se 2013-01-09 
12:46:11 UTC ---

(In reply to comment #25)

 Mikael, as reference was your version of 4.7.3 compiled without

 --enable-initfini-array ?



Yes.

[Bug fortran/54286] [4.8 Regression] Accepts invalid proc-pointer assignments involving proc-ptr function result

[pault at gcc dot gnu.org]

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



--- Comment #5 from Paul Thomas pault at gcc dot gnu.org 2013-01-09 13:07:31 
UTC ---

(In reply to comment #4)

 (In reply to comment #3)

snip

 Huh? the interface of `x%p' is `a', not `iabs'.

 I think the comments are correct; the former is valid, the latter invalid.



Quite right - thanks, Mikael.  I missed/forgot/ignored the first interface. 

That makes life a lot easier because the patch does the right thing :-)



Cheers



Paul

[Bug fortran/55072] [4.6/4.7/4.8 Regression] Missing internal_pack leads to wrong code with derived type

[pault at gcc dot gnu.org]

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



--- Comment #19 from Paul Thomas pault at gcc dot gnu.org 2013-01-09 13:16:59 
UTC ---

(In reply to comment #18)

 (In reply to comment #17)

  (In reply to comment #16)

Question is: Is the packing needed here? I would guess that it isn't.

   

   Of course I might be wrong here. After all, array_t3_ptr is a pointer, so 
   it's

   not guaranteed to be contiguous, right?

  

  To answer that myself, I think the packing is indeed needed here.

 In fact this is exactly the case of comment 0. So, yes, we definitely need the

 packing!



Dear Janus,



R156749 was clearly an optimization too far. As far as correct code generation

is concerned, you cannot have too many PACKs.  Therefore, I would apply your

regression fix, even if you are worried that it over-does it.



Cheers



Paul

[Bug libstdc++/55917] New: Impossible to find/debug unhandled exceptions in an std::thread

[tobias at ringis dot se]

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



 Bug #: 55917

   Summary: Impossible to find/debug unhandled exceptions in an

std::thread

Classification: Unclassified

   Product: gcc

   Version: 4.7.2

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: libstdc++

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

ReportedBy: tob...@ringis.se





If an unhandled exception occurs in an std::thread, the stack is unwound before

std::terminate is called, which makes it impossible to find the location of the

exception.



I emailed gcc-help about this about a year ago, and learned that a fix was

supposed to be applied for 4.7, but that fix didn't work out. Here's my post:



  http://gcc.gnu.org/ml/gcc-help/2011-11/msg00140.html



The reason for the unwound stack is that libstdc++'s function that calls the

user's thread function contains a try/catch all statement.  The supposed fix

was to use noexcept on the internal thread main function, and the reason why it

did not work out is described here:



  http://gcc.gnu.org/ml/gcc-help/2013-01/msg00068.html



I've tested 4.6, 4.7 and a 4.8 snapshot with identical results.  See the

attached test program tmp4.cpp. Compile with:



  g++ -std=c++0x -g tmp4.cpp -lpthread



Run in gdb:



~ gdb a.out

[...]

(gdb) r

Starting program: /home/tobias/a.out 

[Thread debugging using libthread_db enabled]

Using host libthread_db library /lib64/libthread_db.so.1.

[New Thread 0x77fd0700 (LWP 10278)]

terminate called after throwing an instance of 'std::runtime_error'

  what():  foo



Program received signal SIGABRT, Aborted.

[Switching to Thread 0x77fd0700 (LWP 10278)]

0x00318f036285 in raise () from /lib64/libc.so.6

Missing separate debuginfos, use: debuginfo-install

glibc-2.14.90-24.fc16.9.x86_64 libgcc-4.6.3-2.fc16.x86_64

libstdc++-4.6.3-2.fc16.x86_64

(gdb) bt

#0  0x00318f036285 in raise () from /lib64/libc.so.6

#1  0x00318f037b9b in abort () from /lib64/libc.so.6

#2  0x0031964bbc5d in __gnu_cxx::__verbose_terminate_handler() ()

   from /usr/lib64/libstdc++.so.6

#3  0x0031964b9e16 in ?? () from /usr/lib64/libstdc++.so.6

#4  0x0031964b9e43 in std::terminate() () from /usr/lib64/libstdc++.so.6

#5  0x003196470b0b in ?? () from /usr/lib64/libstdc++.so.6

#6  0x00318fc07d90 in start_thread () from /lib64/libpthread.so.0

#7  0x00318f0f119d in clone () from /lib64/libc.so.6

(gdb) 



As you can see, neither the thread's main function, nor foo() is in the

backtrace.

[Bug libstdc++/55917] Impossible to find/debug unhandled exceptions in an std::thread

[tobias at ringis dot se]

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

--- Comment #1 from Tobias Ringström tobias at ringis dot se 2013-01-09 
13:22:52 UTC ---
Created attachment 29120
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29120
Test program to illustrate the problem

[Bug fortran/55916] Alignment issues with real(16) on i686

[rguenth at gcc dot gnu.org]

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



--- Comment #3 from Richard Biener rguenth at gcc dot gnu.org 2013-01-09 
13:30:27 UTC ---

(In reply to comment #2)

 (In reply to comment #1)

  posix_memalign unfortunately has a weird enough interface that we can't

  easily extract alignment for the pointer.

 

 Is it just because it outputs through a pointer? Are aligned_alloc, memalign 

 and others easier then?



Yes.

[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 #12 from Kai Tietz ktietz at gcc dot gnu.org 2013-01-09 13:34:07 
UTC ---

Created attachment 29121

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

Testcase for bitfield and structure-aligning via attribute



This testcase use aligned/align attribute instead of #pragma pack.  With

suggested patch applied no regressions to VC results.

[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 #13 from Kai Tietz ktietz at gcc dot gnu.org 2013-01-09 13:37:13 
UTC ---

Created attachment 29122

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

Testcase for bitfield and structure field-aligning by attribute



By this testcase we validate that structure's member-alignment set by attribute

is applied.  With applied patch this test shows no regressions to VC compiled

variant.

[Bug fortran/55916] Alignment issues with real(16) on i686

[rguenth at gcc dot gnu.org]

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



--- Comment #4 from Richard Biener rguenth at gcc dot gnu.org 2013-01-09 
13:38:12 UTC ---

(In reply to comment #3)

 (In reply to comment #2)

  (In reply to comment #1)

   posix_memalign unfortunately has a weird enough interface that we can't

   easily extract alignment for the pointer.

  

  Is it just because it outputs through a pointer? Are aligned_alloc, 
  memalign 

  and others easier then?

 

 Yes.



We can of course apply the same trick as we do for sincos - transform it to



({ void *tem; int ret;

   tem = __builtin_gcc_posix_memalign (res, alignment, size);

   *memptr = tem;

   ret; })



and then expand it to RTL as posix_memalign using another memory temporary ...



The issue with such return is that we cannot see all possible uses of the

return-by-reference value which is easy to do if it is the actual return

value.



Possibly an alloc_align attribute would be useful as well.

[Bug c++/55918] New: Stack partially unwound when noexcept causes call to std::terminate

[tobias at ringis dot se]

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



 Bug #: 55918

   Summary: Stack partially unwound when noexcept causes call to

std::terminate

Classification: Unclassified

   Product: gcc

   Version: 4.7.2

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: c++

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

ReportedBy: tob...@ringis.se





Created attachment 29123

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

Test program to illustrate the problem



When a noexcept function is violated, std::terminate is called.  While the

standard allows for the stack to be fully unwound, partially unwound, or not

unwound at all, it is impossible to find the location where the exception was

thrown, unless the stack is left unwound.



GCC currently leaves the stack unwound in most cases, but in a very common

case, which is illustrated by the attached example program, the stack is

partially unwound.



If the noexcept is removed to allow the exception to propagate all the way past

main, std::terminate is called with the stack fully unwound, so it seems that

GCC is able to do what I want. It would be highly desirable for the noexcept

case to work in the same way as the unhandled exception case.



# g++ -std=c++0x -g tmp3.cpp

# gdb a.out

[...]

(gdb) bt

#0  0x00318f036285 in raise () from /lib64/libc.so.6

#1  0x00318f037b9b in abort () from /lib64/libc.so.6

#2  0x0031964bbc5d in __gnu_cxx::__verbose_terminate_handler() ()

   from /usr/lib64/libstdc++.so.6

#3  0x0031964b9e16 in ?? () from /usr/lib64/libstdc++.so.6

#4  0x0031964b8e49 in ?? () from /usr/lib64/libstdc++.so.6

#5  0x0031964b973d in __gxx_personality_v0 ()

   from /usr/lib64/libstdc++.so.6

#6  0x00319000f6fb in ?? () from /lib64/libgcc_s.so.1

#7  0x00319000fb58 in _Unwind_Resume () from /lib64/libgcc_s.so.1

#8  0x00400911 in level2 () at tmp3.cpp:16

#9  0x0040091a in level1 () at tmp3.cpp:20

#10 0x00400925 in main () at tmp3.cpp:24



As you can see, bad_guy is not in the backtrace.



There are two simple modifications that makes the backtrace complete. The first

is to remove the noexcept from level1, and the second is to remove the Foo

declaration in level2 (or delete Foo's destructor).

[Bug libstdc++/55917] Impossible to find/debug unhandled exceptions in an std::thread

[redi at gcc dot gnu.org]

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



Jonathan Wakely redi at gcc dot gnu.org changed:



   What|Removed |Added



   Severity|normal  |enhancement



--- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2013-01-09 
13:44:35 UTC ---

As I said at http://gcc.gnu.org/ml/gcc-help/2013-01/msg00068.html this can't be

changed for std::thread, see

http://gcc.gnu.org/ml/libstdc++/2012-12/msg00062.html and the patch at

http://gcc.gnu.org/ml/libstdc++/2012-12/msg00068.html for discussion and code

that absolutely requires exceptions of type __forced_unwind to be able to

escape the thread start function, otherwise thread cancellation crashes the

program, which is not acceptable.



If the function is not noexcept then it must catch exceptions to ensure

std::terminate is called as required, and catching the exception causes the

stack to be unwound. So it's difficult do anything about std::thread.



Please open a separate bug (with Component=c++) for the

http://gcc.gnu.org/ml/gcc-help/2013-01/msg00058.html issue when noexcept

interacts with a destructor on the stack.  That applies to code not using

std::thread too.

[Bug libstdc++/55917] Impossible to find/debug unhandled exceptions in an std::thread

[redi at gcc dot gnu.org]

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



--- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2013-01-09 
13:48:04 UTC ---

Ah, I se PR 55918 - thanks!

[Bug c++/55918] Stack partially unwound when noexcept causes call to std::terminate

[redi at gcc dot gnu.org]

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



Jonathan Wakely redi at gcc dot gnu.org changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2013-01-09

 CC||jason at gcc dot gnu.org

 Ever Confirmed|0   |1



--- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2013-01-09 
13:52:18 UTC ---

I guess Jason can say whether this is a bug in the current behaviour or if your

request should be severity=enhancement, but at the very least we need to

document the intended behaviour at

http://gcc.gnu.org/onlinedocs/gcc/Exception-handling.html

[Bug fortran/53537] [4.6/4.7/4.8 Regression] Explicit IMPORT of renamed USE-associated symbol fails

[mikael at gcc dot gnu.org]

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



--- Comment #5 from Mikael Morin mikael at gcc dot gnu.org 2013-01-09 
13:54:15 UTC ---

Created attachment 29124

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

Fix for the regression in comment #3



For the remaining problem:



(In reply to comment #3)

 The patch of comment 1 fails for testsuite/gfortran.dg/import7.f90:

 

  TYPE(T3) X

1

   Error: The type of 'x' at (1) has not been declared within the interface



maybe we can just remove the error. After all, there is already

non-interface-specific code to diagnose uses of undeclared types.

For that code to trigger in place of the error above, a few adjustments are

needed to avoid searching the type outside the interface (so that the type is

really not found).



With the attached patch, comment #0, comment #1 and comment #4 are accepted,

but a few adjustments are needed in the testsuite:

from:



type(fcnparms) :: fparams ! { dg-error not been declared within the in

 1

Error: The type of 'fparams' at (1) has not been declared within the interface



to:



type(fcnparms) :: fparams ! { dg-error not been declared within the in

  1

Error: Derived type 'fcnparms' at (1) is being used before it is defined





I will test the patch against the full testsuite.  As it touches the core of

the symbol resolution, it's quite to be expected that it has interesting side

effects.

[Bug libstdc++/55917] Impossible to find/debug unhandled exceptions in an std::thread

[redi at gcc dot gnu.org]

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



--- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org 2013-01-09 
13:59:58 UTC ---

One option would be to make the start function have a

dynamic-exception-specification of throw(__cxxabiv1::__forced_unwind), which

would allow the cancellation exception to propagate (as required) but prevent

any other exceptions, but that would result in a call to std::unexpected()

rather than std::terminate(), and a user could have replaced the

unexpected_handler, so we would not be able to meet the requirement that

std::terminate() is called. On top of that, I think the stack would still get

unwound before the call to std:unexpected, and dynamic-exception-specifications

and unexpected handlers are deprecated in C++11.  So I don't think we want to

do that.



My inclination is to close this as WONTFIX.

[Bug libstdc++/55917] Impossible to find/debug unhandled exceptions in an std::thread

[tobias at ringis dot se]

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

--- Comment #5 from Tobias Ringström tobias at ringis dot se 2013-01-09 
14:06:08 UTC ---
Yes, I thought two reports were in order, as they are only vaguely related.  To
me, this one is the most important problem.  I struggle to understand how I can
be the first to have this problem.  Surely it must be an enormous problem if
you use std::thread?  I'm working on a somewhat large multi-threaded program,
and if there's an exception anywhere, e.g. a failed range-check in a container,
it's *completely impossible* to find the problem in a debugger.  We've now
switched to boost::thread instead because it does not have this problem.

I must say that I'm very surprised that you call it an enhancement, and that
you consider closing it as WONTFIX, seeing how the current behavior is so
mindbogglingly unfriendly.  There is a reason why GCC does not unwind the stack
for non-threaded unhandled exceptions.

Perhaps std::thread is not widely used yet, or I'm the only one with buggy
code?

[Bug fortran/55919] New: [4.8 Regression] Bogus warning with -J directory/

[burnus at gcc dot gnu.org]

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



 Bug #: 55919

   Summary: [4.8 Regression] Bogus warning with -J directory/

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Keywords: diagnostic

  Severity: normal

  Priority: P3

 Component: fortran

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

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

CC: tkoe...@gcc.gnu.org





Found at

https://groups.google.com/d/topic/comp.lang.fortran/G6XGIE-lwuk/discussion



The following code in scanner.c's add_path_to_list triggers a bogus warning

under Windows, if a dirname ends in a '/' or a '\\':





  if (stat (p, st))

{

  if (errno != ENOENT)

gfc_warning_now (Include directory \%s\: %s, path,

 xstrerror(errno));

  else

{

  /* FIXME:  Also support -Wmissing-include-dirs.  */

  if (warn)

gfc_warning_now (Nonexistent include directory \%s\, path);

}





Note that the macro  IS_DIR_SEPARATOR can be used to check for / and \.







By the way, one should take the opportunity and add support for

Wmissing-include-dirs. Cf. PR 55534.

[Bug fortran/55919] [4.8 Regression] Bogus warning with -J directory/

[burnus at gcc dot gnu.org]

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



Tobias Burnus burnus at gcc dot gnu.org changed:



   What|Removed |Added



 CC||burnus at gcc dot gnu.org



--- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2013-01-09 
14:14:43 UTC ---

Forgot to add a cross-ref: The warning was added 2012-08-02 for PR 54033. (That

PR is still not closed as fixed).

[Bug lto/55493] [4.8 Regression] LTO always ICEs on i686-mingw32

[fanael4 at gmail dot com]

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



--- Comment #3 from Fanael fanael4 at gmail dot com 2013-01-09 14:19:09 UTC 
---

(In reply to comment #2)

 Are you sure that you do not somehow pull in LTO objects from older releases?



Yes, happens even with -nostdlib, even on builds where I'm absolutely sure

there's no way an old LTO object could sneak in.

[Bug middle-end/55889] [4.8 Regression] ICE: in move_op_ascend, at sel-sched.c:6153 with -fschedule-insns -fselective-scheduling

[abel at gcc dot gnu.org]

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



--- Comment #5 from Andrey Belevantsev abel at gcc dot gnu.org 2013-01-09 
14:26:22 UTC ---

I've just got back from the holidays, I will take a look probably on Friday. 

David's analysis hints that the scheduler should treat the insn as unique (i.e.

it is cannot be copied) but fails to do so.

[Bug fortran/42769] [OOP] ICE in resolve_typebound_procedure

[mikael at gcc dot gnu.org]

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



Mikael Morin mikael at gcc dot gnu.org changed:



   What|Removed |Added



 Status|ASSIGNED|RESOLVED

 Resolution||FIXED

   Target Milestone|--- |4.6.4



--- Comment #39 from Mikael Morin mikael at gcc dot gnu.org 2013-01-09 
14:29:31 UTC ---

Fixed for 4.6.4  4.7.3  4.8.0.

Thanks for the bug report.

[Bug fortran/45836] [OOP] Type Bound Procedure Error - Type Mismatch

[mikael at gcc dot gnu.org]

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



Mikael Morin mikael at gcc dot gnu.org changed:



   What|Removed |Added



 Status|NEW |RESOLVED

 CC||mikael at gcc dot gnu.org

 Resolution||FIXED

   Target Milestone|--- |4.6.4



--- Comment #6 from Mikael Morin mikael at gcc dot gnu.org 2013-01-09 
14:31:53 UTC ---

Fixed for 4.6.4  4.7.3  4.8.0.

Thanks for the bug report.

[Bug fortran/45900] [OOP] Static TBP resolved incorrectly

[mikael at gcc dot gnu.org]

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



Mikael Morin mikael at gcc dot gnu.org changed:



   What|Removed |Added



 Status|NEW |RESOLVED

 CC||mikael at gcc dot gnu.org

 Resolution||FIXED

   Target Milestone|--- |4.6.4



--- Comment #7 from Mikael Morin mikael at gcc dot gnu.org 2013-01-09 
14:32:41 UTC ---

Fixed for 4.6.4  4.7.3  4.8.0.

Thanks for the bug report.

[Bug libstdc++/55917] Impossible to find/debug unhandled exceptions in an std::thread

[redi at gcc dot gnu.org]

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



--- Comment #6 from Jonathan Wakely redi at gcc dot gnu.org 2013-01-09 
14:42:00 UTC ---

(In reply to comment #5)

 Yes, I thought two reports were in order, as they are only vaguely related.  
 To

 me, this one is the most important problem.  I struggle to understand how I 
 can

 be the first to have this problem.  Surely it must be an enormous problem if

 you use std::thread?  I'm working on a somewhat large multi-threaded program,

 and if there's an exception anywhere, e.g. a failed range-check in a 
 container,

 it's *completely impossible* to find the problem in a debugger.



If you're running in the debugger, rather than examining a core file

post-mortem, you can use catch throw or break __cxa_throw to break when the

exception is thrown.



Otherwise you already know the workaround, put 'noexcept' on the function you

pass to std::thread (which breaks pthread_cancel but if you're not using that

it doesn't matter.)



  We've now

 switched to boost::thread instead because it does not have this problem.

 

 I must say that I'm very surprised that you call it an enhancement,



The current implementation conforms to the standard.



 and that

 you consider closing it as WONTFIX,



I've explained why it can't easily be changed, unless anyone has some idea I

haven't thought of yet to preserve pthread_cancel behaviour and preserve the

requirement that std::terminate() is called.



 seeing how the current behavior is so

 mindbogglingly unfriendly.  There is a reason why GCC does not unwind the 
 stack

 for non-threaded unhandled exceptions.



The behaviour comes directly from the explicit requirement in the standard that

an unhandled exception in a std::thread must call std::terminate. 



If it's guaranteed that an uncaught exception leaving that function will still

call terminate, then the catch(...) block could be removed. Maybe I could do

that conditionally for targets where it's known to work as required.

[Bug c++/55918] Stack partially unwound when noexcept causes call to std::terminate

[jason at gcc dot gnu.org]

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



--- Comment #2 from Jason Merrill jason at gcc dot gnu.org 2013-01-09 
14:42:54 UTC ---

If you're looking for 'bad_guy' to be in the backtrace, that sounds to me like

you want it to not be unwound at all, and I'm surprised that it doesn't already

work that way.

[Bug c++/55801] ICE with thread_local after ill-formed forward declaration

[paolo at gcc dot gnu.org]

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



--- Comment #3 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org 
2013-01-09 14:43:59 UTC ---

Author: paolo

Date: Wed Jan  9 14:43:50 2013

New Revision: 195050



URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195050

Log:

/cp

2013-01-09  Paolo Carlini  paolo.carl...@oracle.com



PR c++/55801

* decl2.c (var_needs_tls_wrapper): Return false when error_operand_p

of the argument is true.



/testsuite

2013-01-09  Paolo Carlini  paolo.carl...@oracle.com



PR c++/55801

* g++.dg/tls/thread_local-ice.C: New.



Added:

trunk/gcc/testsuite/g++.dg/tls/thread_local-ice.C

Modified:

trunk/gcc/cp/ChangeLog

trunk/gcc/cp/decl2.c

trunk/gcc/testsuite/ChangeLog

[Bug c++/55801] ICE with thread_local after ill-formed declaration

[paolo.carlini at oracle dot com]

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



Paolo Carlini paolo.carlini at oracle dot com changed:



   What|Removed |Added



 Status|ASSIGNED|RESOLVED

 Resolution||FIXED

   Target Milestone|--- |4.8.0

Summary|ICE with thread_local after |ICE with thread_local after

   |ill-formed forward  |ill-formed declaration

   |declaration |



--- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com 2013-01-09 
14:45:42 UTC ---

Fixed for 4.8.0.

[Bug libstdc++/55911] Segfault in unordered_map with max_load_factor 1

[paolo.carlini at oracle dot com]

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



--- Comment #6 from Paolo Carlini paolo.carlini at oracle dot com 2013-01-09 
14:47:12 UTC ---

Thanks Jon.

[Bug target/55909] libtool test exposes what I think is some alignment issue in libstdc++

[paolo.carlini at oracle dot com]

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



--- Comment #28 from Paolo Carlini paolo.carlini at oracle dot com 2013-01-09 
14:50:16 UTC ---

Thanks Eric for following this.

[Bug c/48418] [4.6/4.7/4.8 Regression] Bit shift operator =

[jakub at gcc dot gnu.org]

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



--- Comment #10 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-09 
14:51:17 UTC ---

Author: jakub

Date: Wed Jan  9 14:51:09 2013

New Revision: 195051



URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195051

Log:

PR c/48418

* c-common.c (c_fully_fold_internal): Warn for LSHIFT_EXPR and

RSHIFT_EXPR, if orig_op1 isn't INTEGER_CST, op1 is INTEGER_CST

and is either negative or bigger or equal to type precision

of the first operand.



* typeck.c (cp_build_binary_op): For LSHIFT_EXPR and RSHIFT_EXPR,

call maybe_constant_value for the negative or too big shift

count warnings.



* c-c++-common/pr48418.c: New test.



Added:

trunk/gcc/testsuite/c-c++-common/pr48418.c

Modified:

trunk/gcc/c-family/ChangeLog

trunk/gcc/c-family/c-common.c

trunk/gcc/cp/ChangeLog

trunk/gcc/cp/typeck.c

trunk/gcc/testsuite/ChangeLog

[Bug c/48418] [4.6/4.7 Regression] Bit shift operator =

[jakub at gcc dot gnu.org]

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



Jakub Jelinek jakub at gcc dot gnu.org changed:



   What|Removed |Added



 CC||jakub at gcc dot gnu.org

Summary|[4.6/4.7/4.8 Regression]|[4.6/4.7 Regression] Bit

   |Bit shift operator =  |shift operator =



--- Comment #11 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-09 
15:03:09 UTC ---

Warning regression fixed for 4.8+ for now.

[Bug tree-optimization/55875] [4.8 Regression] IVopts caused miscompilation

[hubicka at gcc dot gnu.org]

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



--- Comment #10 from Jan Hubicka hubicka at gcc dot gnu.org 2013-01-09 
15:10:55 UTC ---

Author: hubicka

Date: Wed Jan  9 15:10:43 2013

New Revision: 195054



URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195054

Log:

PR tree-optimiation/55875

* gcc.c-torture/execute/pr55875.c: New testcase.

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



* tree-ssa-loop-niter.c (number_of_iterations_cond): Add

EVERY_ITERATION parameter.

(number_of_iterations_exit): Check if exit is executed every

iteration.

(idx_infer_loop_bounds): Similarly here.

(n_of_executions_at_most): Simplify

to only test for cases where statement is dominated by the

particular bound; handle correctly the postdominance

test.

(scev_probably_wraps_p): Use max loop iterations info

as a global bound first.





Added:

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

trunk/gcc/testsuite/gcc.c-torture/execute/pr55875.c

Modified:

trunk/gcc/ChangeLog

trunk/gcc/testsuite/ChangeLog

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

[Bug tree-optimization/55875] [4.8 Regression] IVopts caused miscompilation

[jakub at gcc dot gnu.org]

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



Jakub Jelinek jakub at gcc dot gnu.org changed:



   What|Removed |Added



 Status|NEW |RESOLVED

 Resolution||FIXED



--- Comment #11 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-09 
15:13:20 UTC ---

Fixed, thanks.

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

[hubicka at gcc dot gnu.org]

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



--- Comment #165 from Jan Hubicka hubicka at gcc dot gnu.org 2013-01-09 
15:16:26 UTC ---

OK, I tracked down the undefined reference to

error: /tmp/cc0oq4BG.ltrans1.ltrans.o: requires dynamic R_X86_64_PC32 reloc

against '_ZN12SkAnnotationC1ER23SkFlattenableReadBuffer' which may overflow at

runtime; recompile with -fPIC



it is caused by bug in Mozilla - it includes file defininig virtual function

that use  '_ZN12SkAnnotationC1ER23SkFlattenableReadBuffer' (in SkPaint) but it

never links with implementation.

Normally the function is optimized out.  It is not due to fact that we never

optimize out virtual functions prior inlining for devirtualization and in WPA

path we forget to remove these when done.



Fixed by the following patch

Index: ipa-inline.c

===

--- ipa-inline.c(revision 194916)

+++ ipa-inline.c(working copy)

@@ -1793,7 +1793,7 @@

 }



   inline_small_functions ();

-  symtab_remove_unreachable_nodes (true, dump_file);

+  symtab_remove_unreachable_nodes (false, dump_file);

   free (order);



   /* Inline functions with a property that after inlining into all callers the

Index: lto/lto.c

===

--- lto/lto.c   (revision 194916)

+++ lto/lto.c   (working copy)

@@ -3215,6 +3215,7 @@

   cgraph_state = CGRAPH_STATE_IPA_SSA;



   execute_ipa_pass_list (all_regular_ipa_passes);

+  symtab_remove_unreachable_nodes (false, dump_file);



   if (cgraph_dump_file)

 {

Index: cgraphclones.c

===

--- cgraphclones.c  (revision 194916)

+++ cgraphclones.c  (working copy)

@@ -184,6 +184,7 @@

   new_node-symbol.decl = decl;

   symtab_register_node ((symtab_node)new_node);

   new_node-origin = n-origin;

+  new_node-symbol.lto_file_data = n-symbol.lto_file_data;

   if (new_node-origin)

 {

   new_node-next_nested = new_node-origin-nested;

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

[hubicka at gcc dot gnu.org]

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



--- Comment #166 from Jan Hubicka hubicka at gcc dot gnu.org 2013-01-09 
15:19:41 UTC ---

Markus, the apperance of undefined references I fixed by patch above is highly

sensitive to partitioning and inlining decision.  Can you, please, check if the

problem with PGO remains?  It may be another instance of the same issue.

[Bug tree-optimization/55264] [4.6/4.7/4.8 Regression] ICE: in ipa_make_edge_direct_to_target, at ipa-prop.c:2141 with -O2 -fno-early-inlining -fno-weak

[hubicka at ucw dot cz]

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



--- Comment #8 from Jan Hubicka hubicka at ucw dot cz 2013-01-09 15:23:54 UTC 
---

 Let me look into those...



Try the patch I attached to PR45375



Honza

[Bug target/55909] libtool test exposes what I think is some alignment issue in libstdc++

[philip.copeland at oracle dot com]

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



--- Comment #29 from philip.copeland at oracle dot com 2013-01-09 15:29:26 UTC 
---

Rebuilt fedoras 4.7.2-8 gcc without --enable-initfini-array reinstalled in a

chroot and rebuilt the test program



bash-4.2# g++ -v

Using built-in specs.

COLLECT_GCC=g++

COLLECT_LTO_WRAPPER=/usr/libexec/gcc/sparc64-redhat-linux/4.7.2/lto-wrapper

Target: sparc64-redhat-linux

Configured with: ../configure --prefix=/usr --mandir=/usr/share/man

--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla

--enable-bootstrap --enable-shared --enable-threads=posix

--enable-checking=release --disable-build-with-cxx

--disable-build-poststage1-with-cxx --with-system-zlib --enable-__cxa_atexit

--disable-libunwind-exceptions --enable-gnu-unique-object

--enable-linker-build-id --with-linker-hash-style=gnu

--enable-languages=c,c++,objc,obj-c++,java,fortran,lto --enable-plugin

--enable-java-awt=gtk --disable-dssi

--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre

--enable-libgcj-multifile --with-ecj-jar=/usr/share/java/eclipse-ecj.jar

--disable-libjava-multilib --with-ppl --with-cloog --with-long-double-128

--with-cpu=ultrasparc --disable-multilib --build=sparc64-redhat-linux

Thread model: posix

gcc version 4.7.2 20121109 (Red Hat 4.7.2-8) (GCC) 



bash-4.2# ./a.out

we are able to write to stderr

Segmentation fault (core dumped)



Breakpoint 1, __cxxabiv1::__cxa_get_globals ()

at ../../../../libstdc++-v3/libsupc++/eh_globals.cc:63

63  { return get_global(); }

(gdb) disassemble

Dump of assembler code for function __cxxabiv1::__cxa_get_globals():

   0xf80100180960 +0: save  %sp, -176, %sp

   0xf80100180964 +4: sethi  %hi(0), %o0

   0xf80100180968 +8: sethi  %hi(0), %i0

   0xf8010018096c +12:sethi  %hi(0x18f400), %l7

   0xf80100180970 +16:call  0xf8010017db40

__sparc_get_pc_thunk.l7

   0xf80100180974 +20:add  %l7, 0x290, %l7! 0x18f690

= 0xf80100180978 +24:add  %o0, 8, %o0

   0xf8010018097c +28:xor  %i0, 0, %i0

   0xf80100180980 +32:call  0xf8010030a558

   0xf80100180984 +36:add  %l7, %o0, %o0

   0xf80100180988 +40:add  %o0, %i0, %i0

   0xf8010018098c +44:rett  %i7 + 8

   0xf80100180990 +48:nop 

End of assembler dump.

(gdb) stepi

0xf8010018097c  63  { return get_global(); }

(gdb) 

0xf80100180980  63  { return get_global(); }

(gdb) 

0xf80100180984  63  { return get_global(); }

(gdb) 

0xf8010030a558 in __frame_dummy_init_array_entry ()

   from /lib64/libstdc++.so.6

(gdb) 



Program received signal SIGSEGV, Segmentation fault.

0xf8010030a558 in __frame_dummy_init_array_entry ()

   from /lib64/libstdc++.so.6



again, no thread level support address actions.

Moving on to rebuild of gcc-trunk (4.7.3?)

[Bug target/55909] libtool test exposes what I think is some alignment issue in libstdc++

[ebotcazou at gcc dot gnu.org]

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



--- Comment #30 from Eric Botcazou ebotcazou at gcc dot gnu.org 2013-01-09 
15:45:35 UTC ---

 Program received signal SIGSEGV, Segmentation fault.

 0xf8010030a558 in __frame_dummy_init_array_entry ()

from /lib64/libstdc++.so.6



Is /lib64/libstdc++.so.6 really the rebuilt library?  Can you verify by running

readelf -S on it that it doesn't contain .init_array and .fini_array sections?

[Bug target/55909] libtool test exposes what I think is some alignment issue in libstdc++

[philip.copeland at oracle dot com]

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



--- Comment #31 from philip.copeland at oracle dot com 2013-01-09 16:00:56 UTC 
---

Hurm,...



bash-4.2# cd  /tmp

bash-4.2# mkdir expand

bash-4.2# cd  expand/

bash-4.2# rpm2cpio /builddir/build/RPMS/libstdc++-4.7.2-8.fc18.sparc64.rpm  |

cpio -id

bash-4.2# md5sum /tmp/expand/usr/lib64/libstdc++.so.6.0.17

/lib64/libstdc++.so.6

2b5b38c3e80e9739b1599df7e6ae84da  /tmp/expand/usr/lib64/libstdc++.so.6.0.17

2b5b38c3e80e9739b1599df7e6ae84da  /lib64/libstdc++.so.6



Well,.. it's definitely the rebuilt library and --enable-initfini-array is not

part of the passed options anymore, however readelf -S shows that those

sections still exist



  [18] .init_array   INIT_ARRAY   001e6558  000e6558

   0040    WA   0 0 8

  [19] .fini_array   FINI_ARRAY   001e6598  000e6598

   0008    WA   0 0 8

...

  [24] .plt  PROGBITS 001ecc00  000ecc00

   5820  0020 WAX   0 0 256



are there any of the options that I used that would reenable initfini-array?

[Bug target/55909] libtool test exposes what I think is some alignment issue in libstdc++

[paolo.carlini at oracle dot com]

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



--- Comment #32 from Paolo Carlini paolo.carlini at oracle dot com 2013-01-09 
16:07:19 UTC ---

Well, if you don't pass anything an autoconf test tries to figure out:



--enable-initfini-array

Force the use of sections .init_array and .fini_array (instead of .init and

.fini) for constructors and destructors. Option --disable-initfini-array has

the opposite effect. If neither option is specified, the configure script will

try to guess whether the .init_array and .fini_array sections are supported

and, if they are, use them.



I would quickly test passing an explicit --disable-initfini-array

[Bug fortran/55916] Alignment issues with real(16) on i686

[pinskia at gcc dot gnu.org]

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



--- Comment #5 from Andrew Pinski pinskia at gcc dot gnu.org 2013-01-09 
16:09:25 UTC ---

 As __float128 is outside of the scope of C/C++, this is not a bug on the C 
 library side.



It might be outside the scope of C/C++ but doesn't C99 allow some

implementation defined types?

[Bug bootstrap/55792] [4.8 Regression] Bad memory access with profiledbootstrap and LTO

[hjl.tools at gmail dot com]

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



--- Comment #19 from H.J. Lu hjl.tools at gmail dot com 2013-01-09 16:11:06 
UTC ---

The BLOCK tree node is cleared by



(gdb) bt

#0  0x00336b4882ee in __memset_sse2 () from /lib64/libc.so.6

#1  0x00545fdf in clear_marks ()

at /export/gnu/import/git/gcc/gcc/ggc-page.c:1815

#2  0x00546621 in ggc_collect ()

at /export/gnu/import/git/gcc/gcc/ggc-page.c:2086

#3  0x008ad816 in execute_todo (flags=2102)

at /export/gnu/import/git/gcc/gcc/passes.c:2023

#4  0x008ae175 in execute_one_pass (pass=0x17b9c70)

at /export/gnu/import/git/gcc/gcc/passes.c:2349

#5  0x008ae2da in execute_pass_list (pass=0x17b9c70)

at /export/gnu/import/git/gcc/gcc/passes.c:2383

#6  0x008ae30b in execute_pass_list (

pass=0x16d07e0 pass_all_optimizations)

at /export/gnu/import/git/gcc/gcc/passes.c:2384

#7  0x005da366 in expand_function (node=0x716f5378)

at /export/gnu/import/git/gcc/gcc/cgraphunit.c:1641

#8  0x005da821 in expand_all_functions ()

at /export/gnu/import/git/gcc/gcc/cgraphunit.c:1745

#9  0x005db2ab in compile ()

at /export/gnu/import/git/gcc/gcc/cgraphunit.c:2043

#10 0x0053c60a in lto_main ()

at /export/gnu/import/git/gcc/gcc/lto/lto.c:3390

#11 0x00999401 in compile_file ()

---Type return to continue, or q return to quit---

at /export/gnu/import/git/gcc/gcc/toplev.c:545

#12 0x0099b3e4 in do_compile ()

at /export/gnu/import/git/gcc/gcc/toplev.c:1878

#13 0x0099b54f in toplev_main (argc=28, argv=0x7fffdc78)

at /export/gnu/import/git/gcc/gcc/toplev.c:1954

#14 0x00fff958 in main (argc=28, argv=0x7fffdc78)

at /export/gnu/import/git/gcc/gcc/main.c:36

(gdb)



When we remap a block:

static void

remap_block (tree *block, copy_body_data *id)

{

  tree old_block;

  tree new_block;



  /* Make the new block.  */

  old_block = *block;

  new_block = make_node (BLOCK);

  TREE_USED (new_block) = TREE_USED (old_block);

  BLOCK_ABSTRACT_ORIGIN (new_block) = old_block;

  BLOCK_SOURCE_LOCATION (new_block) = BLOCK_SOURCE_LOCATION (old_block);

  BLOCK_NONLOCALIZED_VARS (new_block)

= vec_safe_copy (BLOCK_NONLOCALIZED_VARS (old_block));

  *block = new_block;



  /* Remap its variables.  */

  BLOCK_VARS (new_block) = remap_decls (BLOCK_VARS (old_block),

BLOCK_NONLOCALIZED_VARS (new_block),

id);



we didn't register it with GC root.

[Bug target/5372] [powerpc-*-eabi] -mno-eabi not working

[segher at gcc dot gnu.org]

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



Segher Boessenkool segher at gcc dot gnu.org changed:



   What|Removed |Added



 CC||segher at gcc dot gnu.org



--- Comment #6 from Segher Boessenkool segher at gcc dot gnu.org 2013-01-09 
16:14:11 UTC ---

Still happens with current mainline.

[Bug bootstrap/55915] fails to build lto-compress.c, zlib.h not found

[pinskia at gcc dot gnu.org]

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



Andrew Pinski pinskia at gcc dot gnu.org changed:



   What|Removed |Added



  Component|c   |bootstrap

Version|lto |4.8.0



--- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2013-01-09 
16:15:57 UTC ---

 --with-system-zlib 



You said zlib.h is included with the system but you don't update CXXFLAGS only

CFLAGS.

[Bug fortran/55758] LOGICAL and BIND(C): Reject kind=2/4/8/16 with -std=f2008, improve warning, switch to nonBOOLEAN_TYPE for those

[burnus at gcc dot gnu.org]

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



--- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2013-01-09 
16:20:42 UTC ---

Author: burnus

Date: Wed Jan  9 16:20:33 2013

New Revision: 195055



URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195055

Log:

2013-01-09  Tobias Burnus  bur...@net-b.de



PR fortran/55758

* resolve.c (resolve_symbol): Reject non-C_Bool logicals

in BIND(C) procedures with -std=f*.



2013-01-09  Tobias Burnus  bur...@net-b.de



PR fortran/55758

* gfortran.dg/bind_c_bool_1.f90: New.

* gfortran.dg/do_5.f90: Add dg-warning.





Added:

trunk/gcc/testsuite/gfortran.dg/bind_c_bool_1.f90

Modified:

trunk/gcc/fortran/ChangeLog

trunk/gcc/fortran/resolve.c

trunk/gcc/testsuite/ChangeLog

trunk/gcc/testsuite/gfortran.dg/do_5.f90

[Bug tree-optimization/55875] [4.8 Regression] IVopts caused miscompilation

[hubicka at ucw dot cz]

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



--- Comment #12 from Jan Hubicka hubicka at ucw dot cz 2013-01-09 16:29:21 
UTC ---

Shall we track the C testcase regression in 4.7 and earlier?



Honza

[Bug tree-optimization/55920] New: ICE in expand_debug_locations, at cfgexpand.c:3753

[rmansfield at qnx dot com]

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



 Bug #: 55920

   Summary: ICE in expand_debug_locations, at cfgexpand.c:3753

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: tree-optimization

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

ReportedBy: rmansfi...@qnx.com

CC: mjam...@suse.cz





Created attachment 29125

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

preprocessed src



gcc version 4.8.0 20130109 (experimental) [trunk revision 195054] (GCC) 



Using arm-unknown-linux-gnueabi



$ ./xgcc -B. -O2 -g ~/ice.i -c

/home/ryan/ice.i: In function 'state_panic':

/home/ryan/ice.i:32:6: warning: incompatible implicit declaration of built-in

function 'memcpy' [enabled by default]

  memcpy (from, client-active-address.iabuf, sizeof from);

  ^

/home/ryan/ice.i:25:7: internal compiler error: in expand_debug_locations, at

cfgexpand.c:3753

  void state_panic (cpp)  void *cpp;

   ^

0x5e3584 expand_debug_locations

../../gcc/cfgexpand.c:3749

0x5e3584 gimple_expand_cfg

../../gcc/cfgexpand.c:4606

Please submit a full bug report,

with preprocessed source if appropriate.

Please include the complete backtrace with any bug report.

See http://gcc.gnu.org/bugs.html for instructions.



Seems it was introduced in rev195015



http://gcc.gnu.org/viewcvs?view=revisionrevision=195015

[Bug bootstrap/55915] fails to build lto-compress.c, zlib.h not found

[alexpux at gmail dot com]

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



--- Comment #2 from Alexey Pavlov alexpux at gmail dot com 2013-01-09 
16:31:18 UTC ---

Do I need add include paths to CXXFLAGS?

But I successfully build gcc-4.6.3 and 4.7.2 without add zlib include path to

CXXFLAGS only to CFLAGS.

[Bug rtl-optimization/55829] [4.8 Regression] ICE: in curr_insn_transform, at lra-constraints.c:3069 with -msse3

[ubizjak at gmail dot com]

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



--- Comment #6 from Uros Bizjak ubizjak at gmail dot com 2013-01-09 16:33:02 
UTC ---

(In reply to comment #3)

 BTW, there is a slight inconsistency between the two patterns, the first

 pattern uses sselog1 type for both the unpckldp %0, %0 and %vmovddup %1, %0 
 and

 V2DFmode mode attribute, while the second pattern uses sselog type for both of

 those and DFmode mode attribute for the movddup case.



Actually, the sselog/sselog1 difference is OK, it makes difference only in the

calculation of memory attribute. By default, sselog looks at operand[2],

which is missing when the pattern has only two operands. So, sselog1 (and all

_1 types) looks at operand[1].



Regarding mode: length calculation depends on it, so for V2DF non-avx sse insns

prefix_data16 is added, and for DF non-avx sse insn prefix_rep is added. While

for sselog insns, V2DF vs. DF makes no difference in length, movddup uses

prefix_rex, so the correct mode for movddup is DF. I will submit a trivial

patch to change this inconsistency.

[Bug tree-optimization/55875] [4.8 Regression] IVopts caused miscompilation

[jakub at gcc dot gnu.org]

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



--- Comment #13 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-09 
16:35:13 UTC ---

Yes, but I'd say under a different PR.

[Bug middle-end/55921] New: Crash in verify_ssa for asm to side-steps complex pessimization

[amylaar at gcc dot gnu.org]

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



 Bug #: 55921

   Summary: Crash in verify_ssa for asm to side-steps complex

pessimization

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Keywords: ice-on-valid-code

  Severity: normal

  Priority: P3

 Component: middle-end

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

ReportedBy: amyl...@gcc.gnu.org





Created attachment 29126

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

testcase



verify_ssa crashes during expand for a simple testcase that uses a pair of

asms to avoid the tree pass pessimization of complex type data moves.



Observed with GCC 4.7.0 i686-pc-linux-gnu X epiphany-elf,

i686-pc-linux-gnu native Red Hat 4.7.2-2, and

i686-pc-linux-gnu native 4.8.0 20130109 (experimental) (revision 195054)



(gdb) run

Starting program: /ssd/fsf/inst/libexec/gcc/i686-pc-linux-gnu/4.8.0/cc1

-fpreprocessed tc3.i -quiet -dumpbase tc3.c -mtune=generic -march=pentiumpro

-auxbase tc3 -version -o tc3.s

GNU C (GCC) version 4.8.0 20130109 (experimental) (i686-pc-linux-gnu)

compiled by GNU C version 4.8.0 20130109 (experimental), GMP version

5.0.2, MPFR version 3.1.0, MPC version 0.9

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

GNU C (GCC) version 4.8.0 20130109 (experimental) (i686-pc-linux-gnu)

compiled by GNU C version 4.8.0 20130109 (experimental), GMP version

5.0.2, MPFR version 3.1.0, MPC version 0.9

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

Compiler executable checksum: 7fd55bd33553a03a09fb094c59fe563c



Program received signal SIGSEGV, Segmentation fault.

verify_ssa (check_modified_stmt=true) at ../../gcc/gcc/tree-ssa.c:942

942   if (!gimple_nop_p (stmt))

(gdb) bt

#0  verify_ssa (check_modified_stmt=true) at ../../gcc/gcc/tree-ssa.c:942

#1  0x084c6fbe in execute_function_todo (data=data@entry=0x8001c)

at ../../gcc/gcc/passes.c:1969

#2  0x084c7788 in do_per_function (

callback=0x84c6f20 execute_function_todo(void*), data=0x8001c)

at ../../gcc/gcc/passes.c:1703

#3  0x084c78ba in execute_todo (flags=524316) at ../../gcc/gcc/passes.c:2001

#4  0x084cabff in execute_one_pass (pass=pass@entry=0x8dced80)

at ../../gcc/gcc/passes.c:2321

#5  0x084cb035 in execute_pass_list (pass=0x8dced80)

at ../../gcc/gcc/passes.c:2383

#6  0x0826186e in expand_function (node=0xb7be93f0)

at ../../gcc/gcc/cgraphunit.c:1641

#7  0x08263bb4 in output_in_order () at ../../gcc/gcc/cgraphunit.c:1834

#8  compile () at ../../gcc/gcc/cgraphunit.c:2038

#9  0x08263f2a in finalize_compilation_unit ()

at ../../gcc/gcc/cgraphunit.c:2120

#10 0x08137e45 in c_write_global_declarations ()

at ../../gcc/gcc/c/c-decl.c:10120

#11 0x0856d85d in compile_file () at ../../gcc/gcc/toplev.c:559

#12 0x0856f82c in do_compile () at ../../gcc/gcc/toplev.c:1878

#13 toplev_main (argc=13, argv=0xbfffeda4) at ../../gcc/gcc/toplev.c:1954

#14 0x0811a2cb in main (argc=13, argv=0xbfffeda4) at ../../gcc/gcc/main.c:36

(gdb) frame 0

#0  verify_ssa (check_modified_stmt=true) at ../../gcc/gcc/tree-ssa.c:942

942   if (!gimple_nop_p (stmt))

(gdb) p stmt

$1 = (gimple_statement_d *) 0x0