[Bug c++/56291] ICE for C++11 in output_constructor_regular_field, at varasm.c:4821

[freddie_chopin at op dot pl]

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



Freddie Chopin  changed:



   What|Removed |Added



 CC||freddie_chopin at op dot pl



--- Comment #3 from Freddie Chopin  2013-02-12 
07:26:05 UTC ---

(In reply to comment #1)

> Current mainline and 4_7-branch work for me. The weird thing is, stock 4.7.2

> also works fine for me - I think this is essentially a duplicate of c++/54253.

> Are you sure you are using a stock FSF 4.7.2?



First of all, I've just noticed that in my example code the last newline is

missing, so a very important last line (that creates the object - without it

there's no problem too) got merged with the shell prompt. To be really sure,

I'm pasting the example again:



// starts here

class Base

{

public:

 constexpr Base() : v(1) {};

 int v;

};



class Derived : public Base

{

public:

 constexpr Derived() : Base() {};

 virtual void function();

};



Derived d;

// ends here



Sorry about that thing not being clearly stated in the first message. I've also

added an attachment this time, so there's no way to miss this last line.



As for your questions and suggestions. First of all this is not related to the

bug you mentioned - all three testcases attached there work for me without a

problem (I tested like this - g++ -std=c++11 -c  -o

), and from the description I think the problem was a

segfault, while I have a ICE report coming from gcc_assert(). Am I using a

vanilla GCC - that's a good question (; The bare-metal ARM compiler (the one I

work most of the time and on which I noticed the problem) comes directly from

/branches/ARM/embedded-4_7-branch and I have 2 versions of it (both fail). I

also have another ARM compiler that's probably from this branch too (but I'm

not sure), and it fails there too. A compiler from previous branch -

/branches/ARM/embedded-4_6-branch - also fails. As for the "g++" on Linux, I

have no idea whether this is vanilla or modified for Arch package - any way I

can check that (other than comparing source code (; )? I definetely reports

just as "4.7.2"... When I look at the source code for varasm.c in the 4.7

branch all I can tell is that at least the line of the report I'm seeing

matches the line in the code;



---



  /* Advance to offset of this element.

 Note no alignment needed in an array, since that is guaranteed

 if each element has the proper size.  */

  if ((local->field != NULL_TREE || local->index != NULL_TREE)

  && fieldpos != local->total_bytes)

{

  gcc_assert (fieldpos >= local->total_bytes); // this is line 4821 which

reports ICE

  assemble_zeros (fieldpos - local->total_bytes);

  local->total_bytes = fieldpos;

}



---



Is there anywhere I could download a "really stock package" of GCC in binary

form to check it (I'm not an expert, just a user, so compiling that myself is

rather hard...) - for Linux or Windows?

[Bug c++/56291] ICE for C++11 in output_constructor_regular_field, at varasm.c:4821

[freddie_chopin at op dot pl]

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



--- Comment #2 from Freddie Chopin  2013-02-12 
07:14:17 UTC ---

Created attachment 29421

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

failing test case

[Bug target/55431] Invalid auxv search in ppc linux-unwind code.

[bugdal at aerifal dot cx]

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



--- Comment #6 from Rich Felker  2013-02-12 07:08:14 
UTC ---

That sounds highly doubtful. The sigcontext is (necessarily) on the stack, so

the only way accessing past the end of sigcontext could fault is if the access

were so far beyond the end to go completely off the stack. The only way this

might be plausible is under sigaltstack.



In any case, why would this code be reading beyond the end? Does the kernel use

different incompatible sigcontext structures based on which vector registers

exist on the cpu?

[Bug sanitizer/55309] gcc's address-sanitizer 66% slower than clang's

[kcc at gcc dot gnu.org]

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



--- Comment #33 from Kostya Serebryany  2013-02-12 
07:02:40 UTC ---

(In reply to comment #31)

> If the mapping is so flexible, how can you detect mismatches?  Different scale

> or shadow offsets are ABI incompatible...

We don't detect mismatches. 

This has never been a problem for our users (who build everything from scratch)

but we do see it as a coming problem as asan is becoming more popular. 



(in reply to comment from another bug)

> Perhaps instead of global vars defined outside of libasan (which e.g. requires

> GOT accesses to those vars in libasan)



Accessing these vars was never a perf problem (we run asan with perf regularly)



> , it might be better to have the scale

> and offset as arguments of __asan_init?  



We did this in the very early version, but it did not work in general. 

Consider you are linking your program with a third-party object 

not built with asan. It may have constructor functions called before main and

before __asan_init, and those functions call malloc which has to 

call __asan_init, but can not pass arguments. 

In some cases we can use .preinit_array to call __asan_init there, but 

that is not always available (?). 



We were (and still are) thinking about encoding the abi version in the name

of the  init function, e.g. __asan_init_v_123. 

It will help us detect abi mismatches when two objects are instrumented with

different generations of asan. 

This doesn't solve the problem of using different offsets though. 







> Then you could easily test at runtime,

> whether all compilation units agree on the same offset/scale, and complain if

> they don't.  Then __asan_mapping_offset and __asan_mapping_scale or how are 
> the

> vars called could be hidden attribute, used with PC relative addressing and

> avoid one extra indirection, and more importantly have better runtime checking

> of mismatches.

[Bug sanitizer/55309] gcc's address-sanitizer 66% slower than clang's

[kcc at gcc dot gnu.org]

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



--- Comment #32 from Kostya Serebryany  2013-02-12 
06:47:56 UTC ---

Good news, 0x7fff8000 seems great: 



t0: orig

t1: short offset (0x7fff8000)

t2: zero offset + pie



  t0   t1 t1/t0   t2t2/t0  t2/t1

---

 400.perlbench, 1206.00, 1151.00, 0.95, 1192.00, 0.99, 1.04

 401.bzip2,  884.00,  842.00, 0.95,  821.00, 0.93, 0.98

   403.gcc,  738.00,  722.00, 0.98,  716.00, 0.97, 0.99

   429.mcf,  609.00,  596.00, 0.98,  586.00, 0.96, 0.98

 445.gobmk,  844.00,  804.00, 0.95,  809.00, 0.96, 1.01

 456.hmmer, 1304.00, 1223.00, 0.94, 1235.00, 0.95, 1.01

 458.sjeng,  916.00,  868.00, 0.95,  897.00, 0.98, 1.03

462.libquantum,  547.00,  535.00, 0.98,  534.00, 0.98, 1.00

   464.h264ref, 1328.00, 1313.00, 0.99, 1265.00, 0.95, 0.96

   471.omnetpp,  628.00,  601.00, 0.96,  596.00, 0.95, 0.99

 473.astar,  665.00,  646.00, 0.97,  657.00, 0.99, 1.02

 483.xalancbmk,  480.00,  449.00, 0.94,  445.00, 0.93, 0.99

  433.milc,  709.00,  655.00, 0.92,  656.00, 0.93, 1.00

  444.namd,  636.00,  594.00, 0.93,  593.00, 0.93, 1.00

447.dealII,  649.00,  615.00, 0.95,  637.00, 0.98, 1.04

450.soplex,  390.00,  374.00, 0.96,  370.00, 0.95, 0.99

453.povray,  452.00,  402.00, 0.89,  421.00, 0.93, 1.05

   470.lbm,  389.00,  378.00, 0.97,  387.00, 0.99, 1.02

   482.sphinx3,  980.00,  930.00, 0.95,  926.00, 0.94, 1.00



So, 0x7fff8000 seems to be a win, even compared to pie+zerobase. 

We'll do some more testing a flip the switch in clang. 



There is another suggestion (from dvyukov) to use -Wl,-Ttext-segment=0x4000

together with zerobase (pie is not required) which is worth investigating.

[Bug target/56263] [avr] Provide strict address-space checking

[demiurg_spb at freemail dot ru]

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



--- Comment #3 from demiurg_spb at freemail dot ru 2013-02-12 06:47:43 UTC ---

(In reply to comment #2)



> This cannot work because ISO/IEC TR18037 forces these literals into generic

> space.

> 



ISO/IEC TR18037

5.1.2 Address-space type qualifiers:



If the type of an object is qualified by an address space name, the

object is allocated in the specified address space; otherwise, the object is

allocated in the generic address space.





I just re-read the standard.

I could not find any reason not permitted to place the data in __flash address

space in that case:



const char __flash* const __flash names[] = {"flash_str1", "flash_str2"};



IAR compilers it does, and that hinders gcc do the same?

I think it's an easy misunderstanding, preventing common sense ...

[Bug target/55431] Invalid auxv search in ppc linux-unwind code.

[amodra at gmail dot com]

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



--- Comment #5 from Alan Modra  2013-02-12 03:04:28 
UTC ---

Created attachment 29420

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

use /proc/self/auxv



At the time the original code was being developed, linux-2.4.x was in

widespread use.  /proc/self/auxv was introduced with linux-2.6.0 in Dec 2003. 

I guess it's reasonable to rely on that nowadays.  BTW, it's not entirely an

optimization to condition reading of altivec regs on AT_HWCAP.  I believe it

may be possible to segv if the unwinder tries to dereference a location past

the end of struct sigcontext.

[Bug middle-end/56231] warning traces have bogus line information when using LTO

[matt at use dot net]

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



--- Comment #12 from Matt Hargett  2013-02-12 02:02:33 UTC 
---

looking at the patch for merging elsewhere, I noticed that



 location_t

 lto_input_location (struct bitpack_d *bp, struct data_in *data_in)

 {

+  static const char *current_file;

+  static int current_line;

+  static int current_col;

   bool file_change, line_change, column_change;

   unsigned len;

-  bool prev_file = data_in->current_file != NULL;

+  bool prev_file = current_file != NULL;





current_file is potentially of unknown value on the comparison in the last

line, right? or is there some static const initialization rule that implicitly

initializes it to 0?

[Bug middle-end/56231] warning traces have bogus line information when using LTO

[matt at use dot net]

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



--- Comment #11 from Matt Hargett  2013-02-12 01:55:28 UTC 
---

can you add the reduced test case you came up with to the testsuite? I've seen

these issues come and go at various points.

[Bug tree-optimization/56265] [4.8 Regression] ICE in ipa_make_edge_direct_to_target

[ppluzhnikov at google dot com]

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



--- Comment #3 from Paul Pluzhnikov  2013-02-12 
00:48:01 UTC ---

Thanks for the fix.



We've confirmed that this fix also fixes the crash in "irreducible" test case

from PR56262.

[Bug c++/56291] ICE for C++11 in output_constructor_regular_field, at varasm.c:4821

[paolo.carlini at oracle dot com]

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



Paolo Carlini  changed:



   What|Removed |Added



 CC|freddie_chopin at op dot pl |



--- Comment #1 from Paolo Carlini  2013-02-12 
00:45:09 UTC ---

Current mainline and 4_7-branch work for me. The weird thing is, stock 4.7.2

also works fine for me - I think this is essentially a duplicate of c++/54253.

Are you sure you are using a stock FSF 4.7.2?

[Bug inline-asm/56148] [4.8 Regression] inline asm matching constraint with different mode

[steven at gcc dot gnu.org]

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



--- Comment #6 from Steven Bosscher  2013-02-12 
00:14:47 UTC ---

In gcc 4.7.2, reload resolved this with a pair of moves.



>From the .197r.ira and 198r.reload dumps, with the asm_operands

split out and the insns before the asm condensed, for readability:



.197r.ira_gcc472 (.208r.ira_gcc480 is identical except for insn uids):

(insn 5 (set (reg:SI 67) (const_int -1)))

(insn 6 (set (reg/f:DI 68) // and clobber flags, irrelevant

(plus:DI (reg/f:DI 20 frame) (const_int -16)))

(insn 17 6 18 2 (set (reg:DI 65 [ d ]) (reg/f:DI 68)))  

(insn 18 (set (reg:SI 69) (const_int 4)))  // 128>>5

(insn 10 18 0 2 (parallel [

(set (reg:DI 63 [ a ])

(asm_operands/v:DI ("") ("=d") 0 ...))

(set (reg:DI 64 [ c ])

(asm_operands/v:DI ("") ("=&c") 1 ...))

(set (reg:DI 65 [ d ])

(asm_operands/v:DI ("") ("=&D") 2 ...))

(set (reg:DI 66 [ b ])

(asm_operands/v:DI ("") ("=&a") 3 ...))

(clobber (reg:QI 18 fpsr))

(clobber (reg:QI 17 flags))

]) t.c:6 -1)



asm output operands:

[   

(reg:SI 67)

(reg:DI 65 [ d ])

(reg:SI 69)

(reg:DI 65 [ d ])

(reg:SI 67)

]

asm input operands: 

[   

(asm_input:SI ("0") (null):0)

(asm_input:DI ("mr") (null):0)

(asm_input:SI ("1") (null):0)

(asm_input:DI ("2") (null):0)

(asm_input:SI ("3") (null):0)

]





.198r.reload_gcc472 (no gcc480 equivalent due to ICE):

(insn 5 (set (reg:SI 0 ax [67]) (const_int -1))) 

(insn 17 (set (reg:DI 5 di [orig:65 d] [65])

(plus:DI (reg/f:DI 7 sp) (const_int -24

(insn 18 (set (reg:SI 2 cx [69]) (const_int 4)))

(insn 21 (set (reg:SI 1 dx) (reg:SI 0 ax [67]))) // reload

(insn 22 (set (reg:DI 4 si) (reg:DI 5 di [orig:65 d] [65]))) // reload

(insn 10 22 19 2 (parallel [

(set (reg:DI 1 dx [orig:63 a] [63])

(asm_operands/v:DI ("") ("=d") 0 ...))

(set (reg:DI 2 cx [orig:64 c] [64])

(asm_operands/v:DI ("") ("=&c") 1 ...))

(set (reg:DI 5 di [orig:65 d] [65])

(asm_operands/v:DI ("") ("=&D") 2 ...))

(set (reg:DI 0 ax [orig:66 b] [66])

(asm_operands/v:DI ("") ("=&a") 3 ...))

(clobber (reg:QI 18 fpsr))

(clobber (reg:QI 17 flags))

]) t.c:6 -1)



asm output operands:

[

(reg:SI 1 dx)

(reg:DI 4 si)

(reg:SI 2 cx [69])

(reg:DI 5 di [orig:65 d ] [65])

(reg:SI 0 ax [67])

]

asm input operands: 

[

(asm_input:SI ("0") (null):0)

(asm_input:DI ("mr") (null):0)

(asm_input:SI ("1") (null):0)

(asm_input:DI ("2") (null):0)

(asm_input:SI ("3") (null):0)

]







LRA tries a *lot* more than just two moves:



Creates new registers:

 Choosing alt 0 in insn 10:  (0) =d  (1) =&c  (2) =&D  (3) =&a  (4) 0 

(5) mr  (6) 1  (7) 2  (8) 3

  Creating newreg=73 from oldreg=63, assigning class DREG to r73

  Creating newreg=74 from oldreg=65, assigning class DIREG to r74

  Creating newreg=75 from oldreg=66, assigning class AREG to r75

   10:

{r73:DI=asm_operands;r64:DI=asm_operands;r74:DI=asm_operands;r75:DI=asm_operands;clobber

fpsr:QI;clobber flags:QI;}

  REG_DEAD r69:SI

  REG_DEAD r67:SI

  REG_UNUSED r66:DI

  REG_UNUSED r65:DI

  REG_UNUSED r64:DI

  REG_UNUSED r63:DI

  REG_UNUSED fpsr:QI

  REG_UNUSED flags:QI

Inserting insn reload before:

   20: clobber r73:DI

   21: r73:DI#0=r67:SI

   22: r74:DI=r65:DI

   23: clobber r75:DI

   24: r75:DI#0=r67:SI



The sets to the subregs of r73 and r75 are the loads of -1U which

is in r67:SI as per insn 5.



The first two of the new registers could be the same moves that reload

attempts to make, but it's difficult to tell because of the slim RTL

dumps. GDB will tell... In any case, if r64 is created for the second

move from reload (insn 22), then LRA is trying DIREG for it while reload

uses SIREG.







Next LRA tries and fails with some inheritance attempts:

 Assigning to 73 (cl=DREG, orig=63, freq=3000, tfirst=73,

tfreq=3000)...

   Assign 1 to reload r73 (freq=3000)

 Assigning to 75 (cl=AREG, orig=66, freq=3000, tfirst=75,

tfreq=3000)...

 Trying 0: spill 67(freq=3000)   Now best 0(cost=-1000)

[Bug bootstrap/52887] Bootstrap on AIX failure: Undefined symbol: .std::function::function(std::function

[bkoz at gcc dot gnu.org]

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



Benjamin Kosnik  changed:



   What|Removed |Added



 CC||bkoz at gcc dot gnu.org,

   ||bkoz at redhat dot com



--- Comment #28 from Benjamin Kosnik  2013-02-11 
23:53:30 UTC ---



FWIW, I think the real fix here is to compile regex.cc with

-fimplicit-templates. I suspect that different things are being inlined on AIX

than on linux/ELF, there is an assumed implicit instantiation on AIX for this

symbol that is currently being supressed via -fno-implicit-templates.

[Bug middle-end/56290] [4.8 Regression] ICE building OpenFOAM in in ipa_make_edge_direct_to_target

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 CC||jakub at gcc dot gnu.org



--- Comment #2 from Jakub Jelinek  2013-02-11 
23:41:34 UTC ---

Likely dup of PR56265.

[Bug libitm/55693] [4.8 Regression] libitm.c++/eh-1.C execution test fails on darwin from r193271

[mrs at gcc dot gnu.org]

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



m...@gcc.gnu.org  changed:



   What|Removed |Added



 Status|NEW |RESOLVED

  Known to work||4.8.0

 Resolution||FIXED



--- Comment #52 from mrs at gcc dot gnu.org  2013-02-11 
23:36:32 UTC ---

Fixed.

[Bug middle-end/56290] [4.8 Regression] ICE building OpenFOAM in in ipa_make_edge_direct_to_target

[tkoenig at gcc dot gnu.org]

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



Thomas Koenig  changed:



   What|Removed |Added



   Keywords||ice-on-valid-code



--- Comment #1 from Thomas Koenig  2013-02-11 
23:35:52 UTC ---

I tried reporting this to OpenFOAM so they can

help track this down, but the bug reporting system

wouldn't let me (permission denied).

[Bug c++/56291] New: ICE for C++11 in output_constructor_regular_field, at varasm.c:4821

[freddie_chopin at op dot pl]

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



 Bug #: 56291

   Summary: ICE for C++11 in output_constructor_regular_field, at

varasm.c:4821

Classification: Unclassified

   Product: gcc

   Version: 4.7.2

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: c++

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

ReportedBy: freddie_cho...@op.pl





[freddie@arch ~]$ cat file.cpp

class Base

{

public:

 constexpr Base() : v(1) {};

 int v;

};



class Derived : public Base

{

public:

 constexpr Derived() : Base() {};

 virtual void function();

};



Derived d;[freddie@arch ~]$ g++ -std=c++11 -c file.cpp

file.cpp:15:10: internal compiler error: in output_constructor_regular_field,

at varasm.c:4821

Please submit a full bug report,

with preprocessed source if appropriate.

See  for instructions.

[freddie@arch ~]$ g++ -v

Using built-in specs.

COLLECT_GCC=g++

COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.2/lto-wrapper

Target: x86_64-unknown-linux-gnu

Configured with: /build/src/gcc-4.7.2/configure --prefix=/usr --libdir=/usr/lib

--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info

--with-bugurl=https://bugs.archlinux.org/

--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared

--enable-threads=posix --with-system-zlib --enable-__cxa_atexit

--disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch

--enable-libstdcxx-time --enable-gnu-unique-object --enable-linker-build-id

--with-ppl --enable-cloog-backend=isl --disable-ppl-version-check

--disable-cloog-version-check --enable-lto --enable-gold --enable-ld=default

--enable-plugin --with-plugin-ld=ld.gold --with-linker-hash-style=gnu

--enable-multilib --disable-libssp --disable-build-with-cxx

--disable-build-poststage1-with-cxx --enable-checking=release

Thread model: posix

gcc version 4.7.2 (GCC) 



---



Each of the listed things makes the problem go away:

- making function() non-virtual (or removing it)

- making both or at least Derived's constructor non-constexpr

- removing the member field "v" from Base (along with the initializer in the

constructor)



I've tested with g++, x86_64-w64-mingw32-g++, i686-w64-mingw32-g++ (all on

Linux), arm-none-eabi-g++, mingw32-g++ (both on Windows), all the toolchains I

have are 4.7.2 and in each of them the problem is identical. I've also have the

same error with 4.6.2 arm-none-eabi-g++.



Is anything more needed? Maybe this is already fixed (and/or reported)?



Thx in advance!

[Bug libitm/55693] [4.8 Regression] libitm.c++/eh-1.C execution test fails on darwin from r193271

[mrs at gcc dot gnu.org]

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



--- Comment #51 from mrs at gcc dot gnu.org  2013-02-11 
23:30:18 UTC ---

Author: mrs

Date: Mon Feb 11 23:30:10 2013

New Revision: 195960



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

Log:

/libgcc

2013-02-11  Iain Sandoe  

Jack Howarth  

Patrick Marlier  



PR libitm/55693

* config/darwin-crt-tm.c: Remove dummy functions hack.



/gcc

2013-02-11  Iain Sandoe  

Jack Howarth  

Patrick Marlier  



PR libitm/55693

* config/darwin.h: Replace ENDFILE_SPEC with TM_DESTRUCTOR and

define ENDFILE_SPEC as TM_DESTRUCTOR.

* config/i386/darwin.h (ENDFILE_SPEC): Use TM_DESTRUCTOR.



/libitm

2013-02-11  Iain Sandoe  

Jack Howarth  

Patrick Marlier  



PR libitm/55693

* alloc_cpp.cc: Enable function declarations on darwin.

* eh_cpp.cc: Likewise.



Modified:

trunk/gcc/ChangeLog

trunk/gcc/config/darwin.h

trunk/gcc/config/i386/darwin.h

trunk/libgcc/ChangeLog

trunk/libgcc/config/darwin-crt-tm.c

trunk/libitm/ChangeLog

trunk/libitm/alloc_cpp.cc

trunk/libitm/eh_cpp.cc

[Bug tree-optimization/56049] [4.8 Regression] Simplification to constants not done

[hubicka at gcc dot gnu.org]

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



--- Comment #5 from Jan Hubicka  2013-02-11 
22:55:44 UTC ---

Well, I think we should try to toamn fantasy of our optimizers here.  What

unroller sees at -O3 -fno-tree-vectorize is quite ugly:



  :

  a = {};



  :

  # i_1 = PHI <1(2), i_7(7)>

  # prephitmp_99 = PHI <0(2), pretmp_98(7)>

  # prephitmp_102 = PHI <0(2), pretmp_101(7)>

  # prephitmp_105 = PHI <0(2), pretmp_104(7)>

  # prephitmp_108 = PHI <0(2), pretmp_107(7)>

  # prephitmp_111 = PHI <0(2), pretmp_110(7)>

  # prephitmp_114 = PHI <0(2), pretmp_113(7)>

  # prephitmp_117 = PHI <0(2), pretmp_116(7)>

  # prephitmp_120 = PHI <0(2), pretmp_119(7)>

  # ivtmp_57 = PHI <1000(2), ivtmp_64(7)>



  :

  # S.0_90 = PHI 

  # prephitmp_126 = PHI 

  # prephitmp_129 = PHI 

  # prephitmp_132 = PHI 

  # prephitmp_135 = PHI 

  # prephitmp_138 = PHI 

  # prephitmp_141 = PHI 

  # prephitmp_144 = PHI 

  # prephitmp_147 = PHI 

  # ivtmp_43 = PHI 

  _29 = S.0_90 * 8;

  _42 = _29 + -8;

  _44 = prephitmp_126 + 1;

  b[_42] = _44;

  _49 = _29 + -7;

  _51 = prephitmp_129 + 1;

  b[_49] = _51;

  _56 = _29 + -6;

  _58 = prephitmp_132 + 1;

  b[_56] = _58;

  _63 = _29 + -5;

  _65 = prephitmp_135 + 1;

  b[_63] = _65;

  _70 = _29 + -4;

  b[_63] = _65;

  _70 = _29 + -4;

  _72 = prephitmp_138 + 1;

  b[_70] = _72;

  _77 = _29 + -3;

  _79 = prephitmp_141 + 1;

  b[_77] = _79;

  _84 = _29 + -2;

  _86 = prephitmp_144 + 1;

  b[_84] = _86;

  _91 = _29 + -1;

  _93 = prephitmp_147 + 1;

  b[_91] = _93;

  S.0_36 = S.0_90 + 1;

  ivtmp_50 = ivtmp_43 - 1;

  if (ivtmp_50 == 0)

goto ;

  else

goto ;



  :

  pretmp_122 = S.0_36 * 8;

  pretmp_124 = pretmp_122 + -8;

  pretmp_125 = a[pretmp_124];

  pretmp_127 = pretmp_122 + -7;

  pretmp_128 = a[pretmp_127];

  pretmp_130 = pretmp_122 + -6;

  pretmp_131 = a[pretmp_130];

  pretmp_133 = pretmp_122 + -5;

  pretmp_134 = a[pretmp_133];

  pretmp_136 = pretmp_122 + -4;

  pretmp_137 = a[pretmp_136];

  pretmp_139 = pretmp_122 + -3;

  pretmp_140 = a[pretmp_139];

  pretmp_142 = pretmp_122 + -2;

  pretmp_143 = a[pretmp_142];

  pretmp_145 = pretmp_122 + -1;

  pretmp_146 = a[pretmp_145];

  goto ;



With vectorization we actually unroll the inner loop but the outer one gets so

ugly that we don't do much about it...



So what about keeping it as enhancement request? I will try to poke about it,

but htere is but about PR overactivity of this type already, right?

[Bug target/55431] Invalid auxv search in ppc linux-unwind code.

[amodra at gmail dot com]

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



Alan Modra  changed:



   What|Removed |Added



 Status|NEW |ASSIGNED

 CC|amodra at gcc dot gnu.org   |amodra at gmail dot com

 AssignedTo|unassigned at gcc dot   |amodra at gmail dot com

   |gnu.org |

[Bug sanitizer/55617] static constructors are not being instrumented correctly on darwin

[mrs at gcc dot gnu.org]

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



--- Comment #54 from mrs at gcc dot gnu.org  2013-02-11 
22:36:28 UTC ---

Author: mrs

Date: Mon Feb 11 22:36:23 2013

New Revision: 195956



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

Log:

2013-02-11  Alexander Potapenko 

Jack Howarth  

Jakub Jelinek  



PR sanitizer/55617

* config/darwin.c (cdtor_record): Rename ctor_record.

(sort_cdtor_records): Rename sort_ctor_records.

(finalize_dtors): New routine to sort destructors by

priority before use in assemble_integer.

(machopic_asm_out_destructor): Use finalize_dtors if needed.



testsuite:

2013-02-11  Alexander Potapenko 

Jack Howarth  

Jakub Jelinek  



PR sanitizer/55617

* g++.dg/asan/pr55617.C: Run on all targets.



Modified:

trunk/gcc/ChangeLog

trunk/gcc/config/darwin.c

trunk/gcc/testsuite/ChangeLog

trunk/gcc/testsuite/g++.dg/asan/pr55617.C

[Bug tree-optimization/56049] [4.8 Regression] Simplification to constants not done

[aldyh at gcc dot gnu.org]

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



Aldy Hernandez  changed:



   What|Removed |Added



 CC||aldyh at gcc dot gnu.org



--- Comment #4 from Aldy Hernandez  2013-02-11 
22:02:02 UTC ---

Honza.  Are you interested in investigating this as Richard suggests, or can we

close this as WONTFIX?

[Bug middle-end/56290] New: [4.8 Regression] ICE building OpenFOAM in in ipa_make_edge_direct_to_target

[tkoenig at gcc dot gnu.org]

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

 Bug #: 56290
   Summary: [4.8 Regression] ICE building OpenFOAM in in
ipa_make_edge_direct_to_target
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: tkoe...@gcc.gnu.org


Building OpenFOAM with 4.8

ig25@linux-fd1f:~/Gcc/trunk/gcc> g++ -v
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/home/ig25/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/lto-wrapper
Ziel: x86_64-unknown-linux-gnu
Konfiguriert mit: ../trunk/configure --prefix=/home/ig25
--enable-languages=c,fortran --with-mpfr=/usr/local --with-gmp=/usr/local
--with-mpc=/usr/local
Thread-Modell: posix
gcc-Version 4.8.0 20130209 (experimental) (GCC) 

resulted in an ICE.  Compilation command was

SOURCE=fvMesh/fvMesh.C ;  g++ -m64 -Dlinux64 -DWM_DP -Wall -Wextra
-Wno-unused-parameter -Wold-style-cast -Wnon-virtual-dtor -O3  -DNoRepository
-ftemplate-depth-100
-I/home/ig25/OpenFOAM/OpenFOAM-2.1.1/src/triSurface/lnInclude
-I/home/ig25/OpenFOAM/OpenFOAM-2.1.1/src/meshTools/lnInclude -IlnInclude -I.
-I/home/ig25/OpenFOAM/OpenFOAM-2.1.1/src/OpenFOAM/lnInclude
-I/home/ig25/OpenFOAM/OpenFOAM-2.1.1/src/OSspecific/POSIX/lnInclude   -fPIC -c
$SOURCE -o Make/linux64GccDPOpt/fvMesh.o

Error was:

fvMesh/fvMesh.C: Im globalen Gültigkeitsbereich:
fvMesh/fvMesh.C:713:1: interner Compiler-Fehler: in
ipa_make_edge_direct_to_target, bei ipa-prop.c:2111
 }
 ^
0x95f5be ipa_make_edge_direct_to_target(cgraph_edge*, tree_node*)
../../trunk/gcc/ipa-prop.c:2111
0x95f7ae try_make_edge_direct_simple_call
../../trunk/gcc/ipa-prop.c:2182
0x95f7ae update_indirect_edges_after_inlining
../../trunk/gcc/ipa-prop.c:2274
0x95f7ae propagate_info_to_inlined_callees
../../trunk/gcc/ipa-prop.c:2333
0x95fbe3 ipa_propagate_indirect_call_infos(cgraph_edge*, vec*)
../../trunk/gcc/ipa-prop.c:2363
0xed8ae4 inline_call(cgraph_edge*, bool, vec*,
int*, bool)
../../trunk/gcc/ipa-inline-transform.c:255
0xed768d ipa_inline
../../trunk/gcc/ipa-inline.c:1850
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
make: *** [Make/linux64GccDPOpt/fvMesh.o] Fehler 1

Unfortunately, this seems to be a bit of a Heinsenbug; I could
not even repeat the error with a compilation command from the command line.

I am not really familiar with the OpenFOAM build process, so I have
little idea how to proceed further.

[Bug fortran/56284] [OOP] ICE with alternate return in type-bound procedure

[janus at gcc dot gnu.org]

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



--- Comment #8 from janus at gcc dot gnu.org 2013-02-11 19:46:15 UTC ---

(In reply to comment #7)

> I don't know if it is the RIGHT fix, but at least it works (tested with



Yes, that's fine. Or one could just disable the errors with



! { dg-options "-std=legacy" }



in all three cases. Thought I had posted that already ...

[Bug rtl-optimization/56275] ICE in simplify_subreg, at simplify-rtx.c:5261 with vector code.

[franxisco1988+gcc at gmail dot com]

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



--- Comment #9 from klondike  2013-02-11 
19:25:15 UTC ---

Thanks again Uros, it's amazing how fast you have fixed this :D

[Bug rtl-optimization/56275] ICE in simplify_subreg, at simplify-rtx.c:5261 with vector code.

[ubizjak at gmail dot com]

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



Uros Bizjak  changed:



   What|Removed |Added



 Status|ASSIGNED|RESOLVED

URL||http://gcc.gnu.org/ml/gcc-p

   ||atches/2013-02/msg00438.htm

   ||l

 Resolution||FIXED



--- Comment #8 from Uros Bizjak  2013-02-11 19:22:14 
UTC ---

Fixed everywhere.

[Bug go/56171] syscall FAILs on Solaris

[ian at airs dot com]

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



--- Comment #6 from Ian Lance Taylor  2013-02-11 19:16:41 
UTC ---

The two closes of file descriptor 4 that you show are actually normal and

expected for this test.  The first is the deferred close of the os.File that

wraps the file descriptor, created by a call to os.NewFile.  The second is the

deferred close of the file descriptor itself.  The second close is deferred to

make sure that it happens even if os.NewFile fails.



Both closes are happening after the WriteMsgUnix failure.



Note that this test case execs itself in a separate process, so when using

truss you need to trace both processes to see what is happening.  The

WriteMsgUnix failure is happening in the child process.  It indicates that

sendmsg is returning an EBADF errno value, but I don't know why.



One place to look would be the function UnixRights in syscall/sockcmsg_unix.go.

 Is that the right format for passing a file descriptor on Solaris?

[Bug fortran/56284] [OOP] ICE with alternate return in type-bound procedure

[dominiq at lps dot ens.fr]

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



--- Comment #7 from Dominique d'Humieres  2013-02-11 
19:06:10 UTC ---

> The combined patches of comment 4 and 5 yield the following testsuite 
> failures:

>

> FAIL: gfortran.dg/altreturn_2.f90  -O  (test for excess errors)

> FAIL: gfortran.dg/intrinsic_actual_3.f90  -O  (test for excess errors)

> FAIL: gfortran.dg/invalid_interface_assignment.f90  -O  (test for excess

> errors)



These tests are complied with -pedantic-errors and after the patch in comment

#5,

their compilation gives the corresponding warning:



Warning: Obsolescent feature: Alternate return argument at (1)



The tests pass with the following patch



--- /opt/gcc/_clean/gcc/testsuite/gfortran.dg/invalid_interface_assignment.f90 

  2010-02-10 17:54:15.0 +0100

+++ /opt/gcc/work/gcc/testsuite/gfortran.dg/invalid_interface_assignment.f90   

2013-02-11 19:57:39.0 +0100

@@ -12,8 +12,9 @@ MODULE TT

MODULE PROCEDURE set

  END INTERFACE

 CONTAINS

-  PURE SUBROUTINE set(x1,*) ! { dg-error "Alternate return cannot appear" }

+  PURE SUBROUTINE set(x1,*) ! { dg-warning "Obsolescent feature: Alternate

return argument" }

 TYPE(data_type), INTENT(OUT) :: x1

 x1%i=0

   END SUBROUTINE set

 END MODULE

+! { dg-error "Alternate return cannot appear" "" { target *-*-* } 15 }

--- /opt/gcc/_clean/gcc/testsuite/gfortran.dg/intrinsic_actual_3.f90   

2009-11-25 18:17:42.0 +0100

+++ /opt/gcc/work/gcc/testsuite/gfortran.dg/intrinsic_actual_3.f90   

2013-02-11 19:50:13.0 +0100

@@ -6,7 +6,7 @@

 !

 program ar1

 interface random_seed

-  subroutine x (a, *)

+  subroutine x (a, *) ! { dg-warning "Obsolescent feature: Alternate

return argument" }

 integer a

   end subroutine x

 end interface random_seed

--- /opt/gcc/_clean/gcc/testsuite/gfortran.dg/altreturn_2.f902009-11-25

18:17:47.0 +0100

+++ /opt/gcc/work/gcc/testsuite/gfortran.dg/altreturn_2.f902013-02-11

19:48:14.0 +0100

@@ -2,7 +2,7 @@

program altreturn_2

  call foo()  ! { dg-error "Missing alternate return" }

contains

- subroutine foo(*)

+ subroutine foo(*) ! { dg-warning "Obsolescent feature: Alternate

return argument" }

return

  end subroutine

end program



I don't know if it is the RIGHT fix, but at least it works (tested with



make -k check-gfortran RUNTESTFLAGS="dg.exp=invalid_interface_assignment.f90

--target_board=unix'{-m32,-m64}'"



and so on for the other two cases.

[Bug go/56171] syscall FAILs on Solaris

[ian at gcc dot gnu.org]

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



--- Comment #5 from ian at gcc dot gnu.org  2013-02-11 
19:03:09 UTC ---

Author: ian

Date: Mon Feb 11 19:03:04 2013

New Revision: 195950



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

Log:

PR go/56171

libgo: Solaris portability for syscall package.



>From Rainer Orth.



Modified:

trunk/libgo/Makefile.am

trunk/libgo/Makefile.in

trunk/libgo/configure

trunk/libgo/configure.ac

trunk/libgo/mksysinfo.sh

[Bug c++/56289] Bad unused value warning with comma operator

[pinskia at gcc dot gnu.org]

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



--- Comment #3 from Andrew Pinski  2013-02-11 
18:40:06 UTC ---

(In reply to comment #2)

> But x was used inside the comma operator.



It is complaining about the right hand side which is y.

[Bug c++/56289] Bad unused value warning with comma operator

[thomaseding at gmail dot com]

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



--- Comment #2 from Thomas  2013-02-11 18:35:29 
UTC ---

But x was used inside the comma operator.

[Bug c++/56289] Bad unused value warning with comma operator

[pinskia at gcc dot gnu.org]

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



--- Comment #1 from Andrew Pinski  2013-02-11 
18:32:58 UTC ---

 (void) x, y;

You are only casting x to void and not y.

[Bug target/55431] Invalid auxv search in ppc linux-unwind code.

[dje at gcc dot gnu.org]

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



David Edelsohn  changed:



   What|Removed |Added



 Target||powerpc*-*-linux

 Status|UNCONFIRMED |NEW

   Last reconfirmed||2013-02-11

 CC||amodra at gcc dot gnu.org

 Ever Confirmed|0   |1



--- Comment #4 from David Edelsohn  2013-02-11 18:17:03 
UTC ---

Confirmed.



__libc_stack_end is not part of the ABI.  The problem is Glibc makes it

difficult to access auxv, otherwise one could obtain the pointer passed to

_start by the kernel. One could read /proc/self/auxv .

[Bug c++/56289] New: Bad unused value warning with comma operator

[thomaseding at gmail dot com]

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



 Bug #: 56289

   Summary: Bad unused value warning with comma operator

Classification: Unclassified

   Product: gcc

   Version: 4.6.3

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: c++

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

ReportedBy: thomased...@gmail.com





Compile the following with -Wunused-value:



int main () {

int x = 0;

int y = 0;

(void) x, y; /* warning: right operand of comma operator has no effect

[-Wunused-value] */

return 0;

}





This is a bad warning, as casting to void should eliminate the warning for both

x and y.

[Bug libitm/55693] [4.8 Regression] libitm.c++/eh-1.C execution test fails on darwin from r193271

[howarth at nitro dot med.uc.edu]

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



--- Comment #50 from Jack Howarth  2013-02-11 
17:54:44 UTC ---

(In reply to comment #47)

> Created attachment 29396 [details]

> revised patch to revert r184293 while fixing PR55693

> 

> Bootstrap regtesting underway on ppc darwin9, x86_64 darwin10 with Xcode 4.2

> and x86_64 darwin12 with Xcode 4.6.



Iain confirmed off-list that the proposed patch to remove the dummy function

bootstraps on i686 drawin9 without regressions in the tm and libitm testsuite.

[Bug rtl-optimization/56275] ICE in simplify_subreg, at simplify-rtx.c:5261 with vector code.

[uros at gcc dot gnu.org]

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



--- Comment #7 from uros at gcc dot gnu.org 2013-02-11 17:30:06 UTC ---

Author: uros

Date: Mon Feb 11 17:29:53 2013

New Revision: 195947



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

Log:

Backport from mainline

2013-02-11  Uros Bizjak  



PR rtl-optimization/56275

* simplify-rtx.c (avoid_constant_pool_reference): Check that

offset is non-negative and less than cmode size before

calling simplify_subreg.



testsuite/ChangeLog



Backport from mainline

2013-02-11  Uros Bizjak  



PR rtl-optimization/56275

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





Added:

branches/gcc-4_6-branch/gcc/testsuite/gcc.dg/pr56275.c

Modified:

branches/gcc-4_6-branch/gcc/ChangeLog

branches/gcc-4_6-branch/gcc/simplify-rtx.c

branches/gcc-4_6-branch/gcc/testsuite/ChangeLog

[Bug c++/56268] [4.7/4.8 Regression] C++11 ICE with boost multi-precision and boost variant during assignment

[jason at gcc dot gnu.org]

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



Jason Merrill  changed:



   What|Removed |Added



 Status|ASSIGNED|RESOLVED

 Resolution||FIXED



--- Comment #7 from Jason Merrill  2013-02-11 
17:29:04 UTC ---

Fixed.

[Bug rtl-optimization/56275] ICE in simplify_subreg, at simplify-rtx.c:5261 with vector code.

[uros at gcc dot gnu.org]

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



--- Comment #6 from uros at gcc dot gnu.org 2013-02-11 17:27:39 UTC ---

Author: uros

Date: Mon Feb 11 17:27:30 2013

New Revision: 195946



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

Log:

Backport from mainline

2013-02-11  Uros Bizjak  



PR rtl-optimization/56275

* simplify-rtx.c (avoid_constant_pool_reference): Check that

offset is non-negative and less than cmode size before

calling simplify_subreg.



testsuite/ChangeLog:



Backport from mainline

2013-02-11  Uros Bizjak  



PR rtl-optimization/56275

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





Added:

branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/pr56275.c

Modified:

branches/gcc-4_7-branch/gcc/ChangeLog

branches/gcc-4_7-branch/gcc/simplify-rtx.c

branches/gcc-4_7-branch/gcc/testsuite/ChangeLog

[Bug c++/56268] [4.7/4.8 Regression] C++11 ICE with boost multi-precision and boost variant during assignment

[jason at gcc dot gnu.org]

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



--- Comment #6 from Jason Merrill  2013-02-11 
16:21:19 UTC ---

Author: jason

Date: Mon Feb 11 16:21:10 2013

New Revision: 195945



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

Log:

PR c++/56268

* semantics.c (classtype_has_nothrow_assign_or_copy_p): Call

maybe_instantiate_noexcept.



Added:

branches/gcc-4_7-branch/gcc/testsuite/g++.dg/ext/has_nothrow_copy-8.C

Modified:

branches/gcc-4_7-branch/gcc/cp/ChangeLog

branches/gcc-4_7-branch/gcc/cp/semantics.c

[Bug tree-optimization/56265] [4.8 Regression] ICE in ipa_make_edge_direct_to_target

[jakub at gcc dot gnu.org]

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



--- Comment #2 from Jakub Jelinek  2013-02-11 
16:20:24 UTC ---

--- gcc/ipa-inline.c.jj2013-01-11 09:02:48.0 +0100

+++ gcc/ipa-inline.c2013-02-11 17:16:04.951958702 +0100

@@ -1792,7 +1792,7 @@ ipa_inline (void)

 }



   inline_small_functions ();

-  symtab_remove_unreachable_nodes (false, dump_file);

+  symtab_remove_unreachable_nodes (true, dump_file);

   free (order);



   /* Inline functions with a property that after inlining into all callers the

@@ -1876,6 +1876,9 @@ ipa_inline (void)



   if (dump_file)

 dump_inline_summaries (dump_file);

+

+  symtab_remove_unreachable_nodes (false, dump_file);

+

   /* In WPA we use inline summaries for partitioning process.  */

   if (!flag_wpa)

 inline_free_summary ();



fixes this.



The gcc-patches post said:

"This is bug.  The cleanup is supposed to happen just before inlining functions

called once.  The patch also adds the cleanup to same place into

do_whole_program_analysis and updates cgraphclones.c so we do not ice when

removing offline copy of the function after inlining."



but clearly that is too early, as the testcase shows.

[Bug middle-end/56288] always true conditional expression in verify_ssa_name

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 Status|UNCONFIRMED |ASSIGNED

   Last reconfirmed||2013-02-11

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

   |gnu.org |

 Ever Confirmed|0   |1



--- Comment #1 from Richard Biener  2013-02-11 
16:11:53 UTC ---

Oops.  Mine.

[Bug rtl-optimization/56275] ICE in simplify_subreg, at simplify-rtx.c:5261 with vector code.

[franxisco1988+gcc at gmail dot com]

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



--- Comment #5 from klondike  2013-02-11 
16:10:49 UTC ---

Thanks Uros, for now I'll disable the code for gcc <= 4.6.3 if SSE2 is not

available to prevent the crash on older distros.

[Bug c++/56287] __do_global_ctors_aux() crashing when LTO enabled with flto-partition=none

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 CC||hubicka at gcc dot gnu.org



--- Comment #3 from Richard Biener  2013-02-11 
16:10:40 UTC ---

Yeah, they shouldn't have any .gnu.lto_* sections because we don't handle

constraints on .ctors/.dtors sections properly.



Which means you somehow ended up compiling them with -flto - don't.



Honza, I suppose there is no good way to ensure linker-command-line ordering

of decls with used attribute?  (__CTOR_END__ also seems to lack that attribute)

Supposedly CRTSTUFF_T_CFLAGS unconditionally should get -fno-lto (not sure

if anybody builds with CFLAGS_FOR_TARGET=-flto or CFLAGS=-flto).



I believe the fact that it works without -flto-partition=none is by luck

and not by design.

[Bug rtl-optimization/56275] ICE in simplify_subreg, at simplify-rtx.c:5261 with vector code.

[uros at gcc dot gnu.org]

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



--- Comment #4 from uros at gcc dot gnu.org 2013-02-11 16:05:51 UTC ---

Author: uros

Date: Mon Feb 11 16:05:44 2013

New Revision: 195944



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

Log:

PR rtl-optimization/56275

* simplify-rtx.c (avoid_constant_pool_reference): Check that

offset is non-negative and less than cmode size before

calling simplify_subreg.



testsuite/ChangeLog:



PR rtl-optimization/56275

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





Added:

trunk/gcc/testsuite/gcc.dg/pr56275.c

Modified:

trunk/gcc/ChangeLog

trunk/gcc/simplify-rtx.c

trunk/gcc/testsuite/ChangeLog

[Bug bootstrap/56128] [4.8 Regression] libsanitizer doesn't build with broken kernel headers

[jakub at gcc dot gnu.org]

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



--- Comment #13 from Jakub Jelinek  2013-02-11 
15:54:17 UTC ---

Perhaps instead of global vars defined outside of libasan (which e.g. requires

GOT accesses to those vars in libasan), it might be better to have the scale

and offset as arguments of __asan_init?  Then you could easily test at runtime,

whether all compilation units agree on the same offset/scale, and complain if

they don't.  Then __asan_mapping_offset and __asan_mapping_scale or how are the

vars called could be hidden attribute, used with PC relative addressing and

avoid one extra indirection, and more importantly have better runtime checking

of mismatches.

[Bug middle-end/56288] New: always true conditional expression in verify_ssa_name

[pageexec at freemail dot hu]

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



 Bug #: 56288

   Summary: always true conditional expression in verify_ssa_name

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: middle-end

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

ReportedBy: pagee...@freemail.hu





git commit ec11736b57986660deef21d6375d2f23edf290d2 introduced

SSA_NAME_IDENTIFIER in addition to SSA_NAME_VAR where the latter can now return

NULL_TREE. so far so good, all users have been adjusted for this new condition

except there is i think a mistake in gcc/tree-ssa.c:verify_ssa_name that had

this change:



-  if (TREE_TYPE (ssa_name) != TREE_TYPE (SSA_NAME_VAR (ssa_name)))

+  if (SSA_NAME_VAR (ssa_name) != NULL_TREE

+  && TREE_TYPE (ssa_name) != TREE_TYPE (ssa_name))



i think the intention was more like preserving the original check for TREE_TYPE

(ssa_name) != TREE_TYPE (SSA_NAME_VAR (ssa_name)) instead.

[Bug c++/56287] __do_global_ctors_aux() crashing when LTO enabled with flto-partition=none

[honyakeprt at centrum dot cz]

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



--- Comment #2 from Jan Keprt  2013-02-11 
15:48:01 UTC ---

(In reply to comment #1)

> Did the crt files somehow get LTO bytecode?  That shouldn't happen.  Please

> show objdump -h of the used crtbegin.o/crtend.o files.



Here it is:



$ ~/cross/bin/powerpc-unknown-eabi-objdump.exe -h crtbegin.o



crtbegin.o: file format elf32-powerpc



Sections:

Idx Name  Size  VMA   LMA   File off  Algn

  0 .text 0020      0034  2**0

  CONTENTS, ALLOC, LOAD, READONLY, CODE

  1 .data       0054  2**0

  CONTENTS, ALLOC, LOAD, DATA

  2 .bss        0054  2**0

  ALLOC

  3 .gnu.lto_.jmpfuncs.60ec31b70d4f2ad9 0110      0054

2**0

  CONTENTS, READONLY, EXCLUDE

  4 .gnu.lto_.inline.60ec31b70d4f2ad9 006f      0164 

2*

*0

  CONTENTS, READONLY, EXCLUDE

  5 .gnu.lto_.pureconst.60ec31b70d4f2ad9 0020      01d3

 2**0

  CONTENTS, READONLY, EXCLUDE

  6 .gnu.lto_deregister_tm_clones.60ec31b70d4f2ad9 0260    

 01f3  2**0

  CONTENTS, READONLY, EXCLUDE

  7 .gnu.lto_register_tm_clones.60ec31b70d4f2ad9 0293     

0

453  2**0

  CONTENTS, READONLY, EXCLUDE

  8 .gnu.lto___do_global_dtors_aux.60ec31b70d4f2ad9 03c3   



  06e6  2**0

  CONTENTS, READONLY, EXCLUDE

  9 .gnu.lto_call___do_global_dtors_aux.60ec31b70d4f2ad9 013c   

000

0  0aa9  2**0

  CONTENTS, READONLY, EXCLUDE

 10 .gnu.lto_frame_dummy.60ec31b70d4f2ad9 0285     

0be5

  2**0

  CONTENTS, READONLY, EXCLUDE

 11 .gnu.lto_call_frame_dummy.60ec31b70d4f2ad9 013b     

000

00e6a  2**0

  CONTENTS, READONLY, EXCLUDE

 12 .gnu.lto_.cgraph.60ec31b70d4f2ad9 00a4      0fa5 

2*

*0

  CONTENTS, READONLY, EXCLUDE

 13 .gnu.lto_.vars.60ec31b70d4f2ad9 003f      1049 

2**0



  CONTENTS, READONLY, EXCLUDE

 14 .gnu.lto_.refs.60ec31b70d4f2ad9 0037      1088 

2**0



  CONTENTS, READONLY, EXCLUDE

 15 .gnu.lto_.statics.60ec31b70d4f2ad9 0014      10bf 

2

**0

  CONTENTS, READONLY, EXCLUDE

 16 .gnu.lto_.decls.60ec31b70d4f2ad9 0bb0      10d3 

2**

0

  CONTENTS, READONLY, EXCLUDE

 17 .gnu.lto_.symtab.60ec31b70d4f2ad9 0116      1c83 

2*

*0

  CONTENTS, READONLY, EXCLUDE

 18 .gnu.lto_.opts 018a      1d99  2**0

  CONTENTS, READONLY, EXCLUDE

 19 .ctors0004      1f24  2**2

  CONTENTS, ALLOC, LOAD, DATA

 20 .dtors0004      1f28  2**2

  CONTENTS, ALLOC, LOAD, DATA

 21 .eh_frame       1f2c  2**2

  CONTENTS, ALLOC, LOAD, READONLY, DATA

 22 .jcr        1f2c  2**2

  CONTENTS, ALLOC, LOAD, DATA

 23 .tm_clone_table       1f2c  2**2

  CONTENTS, ALLOC, LOAD, DATA

 24 .text.deregister_tm_clones 0038      1f2c  2**2

  CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE

 25 .text.register_tm_clones 003c      1f64  2**2

  CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE

 26 .data.__dso_handle 0004      1fa0  2**2

  CONTENTS, ALLOC, LOAD, DATA

 27 .text.__do_global_dtors_aux 00c8      1fa4  2**2

  CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE

 28 .text.call___do_global_dtors_aux 000c      206c 

2**

2

  CONTENTS, ALLOC, LOAD, READONLY, CODE

 29 .fini 0004      2078  2**0

  CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE

 30 .text.frame_dummy 006c      207c  2**2

  CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE

 31 .text.call_frame_dummy 000c      20e8  2**2

  CONTENTS, ALLOC, LOAD, READONLY, CODE

 32 .init 0004      20f4  2**0

  CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE

 33 .bss.completed.3973 0001      20f8  2**0

  ALLOC

 34 .bss.dtor_idx.3975 0004      20f8  2**2

  ALLOC

 35 .bss.object.3988 0018      20

[Bug c++/56268] [4.7/4.8 Regression] C++11 ICE with boost multi-precision and boost variant during assignment

[jason at gcc dot gnu.org]

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



--- Comment #5 from Jason Merrill  2013-02-11 
15:47:56 UTC ---

Author: jason

Date: Mon Feb 11 15:47:46 2013

New Revision: 195943



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

Log:

PR c++/56268

* semantics.c (classtype_has_nothrow_assign_or_copy_p): Call

maybe_instantiate_noexcept.



Added:

trunk/gcc/testsuite/g++.dg/ext/has_nothrow_copy-8.C

Modified:

trunk/gcc/cp/ChangeLog

trunk/gcc/cp/semantics.c

[Bug c++/35688] template visibility not overridden by template arguments

[jason at gcc dot gnu.org]

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



--- Comment #15 from Jason Merrill  2013-02-11 
15:44:51 UTC ---

(In reply to comment #13)

> I don't understand why fully declared templates like Boost's shared_ptr have a

> visibility at all.



I'm not sure why they would.  Are you compiling with -fvisibility=hidden?  If

so, you need to explicitly give everything that you want to be exported the

appropriate visibility.



> Do I've to change my code or is this a regression or is it Boost's fault?



You might wrap the #includes in



#pragma GCC visibility push(default)

#pragma GCC visibility pop



to give the Boost library all default visibility.

[Bug rtl-optimization/56151] [4.8 Regression] Performance degradation after r194054 on x86 Atom.

[jakub at gcc dot gnu.org]

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



--- Comment #11 from Jakub Jelinek  2013-02-11 
15:42:12 UTC ---

Created attachment 29419

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

gcc48-pr56151.patch



Untested patch, done in add_equal_note, so that the code doesn't have to be

duplicated between expand_binop_directly and expand_unop_directly.

[Bug c++/56238] [4.7 regression] ICE in tree check: expected record_type or union_type or qual_union_type, have template_type_parm in lookup_conversions, at cp/search.c:2515

[jason at gcc dot gnu.org]

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



Jason Merrill  changed:



   What|Removed |Added



   Priority|P2  |P3

 Status|ASSIGNED|RESOLVED

Version|4.7.3   |unknown

 Resolution||FIXED

   Target Milestone|4.7.3   |4.8.0



--- Comment #4 from Jason Merrill  2013-02-11 
15:33:40 UTC ---

Bug only affects ENABLE_CHECKING builds, so no need to fix in 4.7.

[Bug c++/56268] [4.7/4.8 Regression] C++11 ICE with boost multi-precision and boost variant during assignment

[jason at gcc dot gnu.org]

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



Jason Merrill  changed:



   What|Removed |Added



 Status|NEW |ASSIGNED

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

   |gnu.org |

   Target Milestone|4.7.3   |---

[Bug c++/56287] __do_global_ctors_aux() crashing when LTO enabled with flto-partition=none

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 Target||powerpc-unknown-eabi

 Status|UNCONFIRMED |WAITING

   Last reconfirmed||2013-02-11

   Host||cygwin

 Ever Confirmed|0   |1



--- Comment #1 from Richard Biener  2013-02-11 
15:19:52 UTC ---

Did the crt files somehow get LTO bytecode?  That shouldn't happen.  Please

show objdump -h of the used crtbegin.o/crtend.o files.

[Bug target/56263] [avr] Provide strict address-space checking

[gjl at gcc dot gnu.org]

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



Georg-Johann Lay  changed:



   What|Removed |Added



 Status|ASSIGNED|SUSPENDED

[Bug target/56263] [avr] Provide strict address-space checking

[gjl at gcc dot gnu.org]

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



--- Comment #2 from Georg-Johann Lay  2013-02-11 
15:09:40 UTC ---

Created attachment 29418

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

draft patch



PR target/56263

* config/avr/avr.opt (-mstrict-addr-space-subsets): New option and...

(avr_strict_addr_space_subsets)... attached variable.

* config/avr/avr.c (avr_addr_space_subset_p): Use it to determine

whether of not an address spaces are subsets.

* doc/invoke.texi (AVR Options) <-mstrict-addr-space-subsets>:

Document it.





I had a look at this.



With strict address spaces, GCC will emit zeroes as result of casts across

address spaces.  This means that code like



char read_char (const char *address, int data_in_flash)

{

if (data_in_flash)

return *(const __flash char*) address;

else

return *address;

}



will no more operate correctly.  For the same reason, it is no more possible to

use PSTR from AVR-LibC with functions that get an address space pointer because

PSTR puts (and must put) the literal in generic space.



(In reply to comment #1)

> I think the next test case should also be considered.

> 

> const char __flash* const __flash names[] =

> {

> "flash_str1",

> "flash_str2"



This cannot work because ISO/IEC TR18037 forces these literals into generic

space.



> };

> 

> const char __flash* name1 = names[0]; // ok

> const char* name2 = names[1]; // error



Attached is the draft patch that I used.  This means that in order to make this

work, the compiler proper has to be extended and the feature cannot be

implemented in the avr backend alone.  Thus suspending for now and for an other

stage.

[Bug tree-optimization/56264] [4.8 Regression] ICE in check_loop_closed_ssa_use, at tree-ssa-loop-manip.c:557

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 Status|ASSIGNED|RESOLVED

 Resolution||FIXED



--- Comment #7 from Richard Biener  2013-02-11 
15:09:35 UTC ---

Fixed.

[Bug tree-optimization/56273] [4.8 regression] Bogus -Warray-bounds warning

[rguenth at gcc dot gnu.org]

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



--- Comment #8 from Richard Biener  2013-02-11 
15:09:02 UTC ---

Author: rguenth

Date: Mon Feb 11 15:08:51 2013

New Revision: 195942



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

Log:

2013-02-11  Richard Biener  



PR tree-optimization/56273

* gcc.dg/tree-ssa/vrp17.c: Disable tail-merging.



Modified:

trunk/gcc/testsuite/ChangeLog

trunk/gcc/testsuite/gcc.dg/tree-ssa/vrp17.c

[Bug tree-optimization/56264] [4.8 Regression] ICE in check_loop_closed_ssa_use, at tree-ssa-loop-manip.c:557

[rguenth at gcc dot gnu.org]

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



--- Comment #6 from Richard Biener  2013-02-11 
15:07:48 UTC ---

Author: rguenth

Date: Mon Feb 11 15:07:40 2013

New Revision: 195941



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

Log:

2013-02-11  Richard Biener  



PR tree-optimization/56264

* cfgloop.h (fix_loop_structure): Adjust prototype.

* loop-init.c (fix_loop_structure): Return the number of

newly discovered loops.

* tree-cfgcleanup.c (repair_loop_structures): When new loops

are discovered, do a full loop-closed SSA rewrite.



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



Added:

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

Modified:

trunk/gcc/ChangeLog

trunk/gcc/cfgloop.h

trunk/gcc/loop-init.c

trunk/gcc/testsuite/ChangeLog

trunk/gcc/tree-cfgcleanup.c

[Bug sanitizer/55309] gcc's address-sanitizer 66% slower than clang's

[jakub at gcc dot gnu.org]

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



--- Comment #31 from Jakub Jelinek  2013-02-11 
15:02:25 UTC ---

If the mapping is so flexible, how can you detect mismatches?  Different scale

or shadow offsets are ABI incompatible...

[Bug c++/56287] New: __do_global_ctors_aux() crashing when LTO enabled with flto-partition=none

[honyakeprt at centrum dot cz]

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



 Bug #: 56287

   Summary: __do_global_ctors_aux() crashing when LTO enabled with

flto-partition=none

Classification: Unclassified

   Product: gcc

   Version: 4.7.2

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: c++

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

ReportedBy: honyake...@centrum.cz





Hi,



I am using gcc 4.7.2 under cygwin

Using built-in specs.

COLLECT_GCC=./powerpc-unknown-eabi-gcc-4.7.2

COLLECT_LTO_WRAPPER=/home/JKe/cross/libexec/gcc/powerpc-unknown-eabi/4.7.2/lto-w

rapper.exe

Target: powerpc-unknown-eabi

Configured with: ...

Tmp/cross-toolchain-mpc8xx-eabi-tmp/gcc-4.7.2/configure

--enable-languages=c,c++ --config-cache --prefix=/h

ome/JKe/cross --target=powerpc-unknown-eabi --with-cpu=860 --without-fp

--with-f

loat=soft --disable-nls --disable-shared --disable-libssp --disable-libgomp

--di

sable-libmudflap --disable-libquadmath --disable-multilib

--disable-decimal-floa

t --disable-fixed-point --enable-threads=posix --with-newlib --with-gnu-ld

--wit

h-gnu-as --enable-lto

Thread model: posix

gcc version 4.7.2 (GCC)





when I enable compilation/linking with LTO partitioning NONE, the .ctors

constructor table gets somehow damaged. The symbol __CTOR_END__ points before

the __CTOR_LIST__!!! Therefore the __do_global_ctors_aux() function is

crashing.



Here is an example:

Compiler flags : -O2 -flto -fdata-sections -ffunction-sections

-mno-strict-align -g3 -Wall -Wpointer-arith -Wwrite-strings -Wunused-parameter

-Wextra -DHAVE_SNPRINTF  -Wformat -Wformat-security -fcheck-new

-Wnon-virtual-dtor -Wctor-dtor-privacy -mno-relocatable -mno-relocatable-lib

-mcpu=860 -meabi -msdata=sysv -fno-exceptions



A) Crashing configuration



Linker flags: -Wl,--gc-sections -Wl,-flto=jobserver -flto-partition=none -O2 

-static



.ctor table from .map file

**

.ctors  0x00186950   0x14

 *crtbegin.o(.ctors)

 *crtbegin?.o(.ctors)

 *(EXCLUDE_FILE(*crtend?.o *crtend.o) .ctors)

 .ctors 0x001869500x0

/home/JKe/cross/lib/gcc/powerpc-unknown-eabi/4.7.2/ecrti.o

0x00186950__CTOR_LIST__

 .ctors 0x001869500xc

/cygdrive/c/Users/JKe/AppData/Local/Temp/ccT7Msbu.lto.o

 .ctors 0x0018695c0x4

/home/JKe/cross/lib/gcc/powerpc-unknown-eabi/4.7.2/../../../../powerpc-unknown-eabi/lib/libstdc++.a(eh_alloc.o)

 .ctors 0x001869600x4

/home/JKe/cross/lib/gcc/powerpc-unknown-eabi/4.7.2/../../../../powerpc-unknown-eabi/lib/libstdc++.a(eh_globals.o)

 .ctors 0x001869640x0

/home/JKe/cross/lib/gcc/powerpc-unknown-eabi/4.7.2/ecrtn.o

0x00186964__CTOR_END__

 *(SORT(.ctors.*))

 *(.ctors)



__CTOR Symbols using objdump tool (note that local are used in reality)

*

00186958 l O .ctors0004 __CTOR_LIST__.1431

00186954 l O .ctors0004 __CTOR_END__.585871

00186950 g O .ctors __CTOR_LIST__

00186964 g O .ctors __CTOR_END__







B) Not crashing configuration (using default LTO partitioning)



Linker flags: -Wl,--gc-sections -Wl,-flto=jobserver -O2  -static



.ctor table from .map file

**

.ctors  0x00187a70   0x14

 *crtbegin.o(.ctors)

 *crtbegin?.o(.ctors)

 *(EXCLUDE_FILE(*crtend?.o *crtend.o) .ctors)

 .ctors 0x00187a700x0

/home/JKe/cross/lib/gcc/powerpc-unknown-eabi/4.7.2/ecrti.o

0x00187a70__CTOR_LIST__

 .ctors 0x00187a700x4

/cygdrive/c/Users/JKe/AppData/Local/Temp/ccYYi7V7.ltrans24.ltrans.o

 .ctors 0x00187a740x8

/cygdrive/c/Users/JKe/AppData/Local/Temp/ccYYi7V7.ltrans25.ltrans.o

 .ctors 0x00187a7c0x4

/home/JKe/cross/lib/gcc/powerpc-unknown-eabi/4.7.2/../../../../powerpc-unknown-eabi/lib/libstdc++.a(eh_alloc.o)

 .ctors 0x00187a800x4

/home/JKe/cross/lib/gcc/powerpc-unknown-eabi/4.7.2/../../../../powerpc-unknown-eabi/lib/libstdc++.a(eh_globals.o)

 .ctors 0x00187a840x0

/home/JKe/cross/lib/gcc/powerpc-unknown-eabi/4.7.2/ecrtn.o

0x00187a84__CTOR_END__

 *(SORT(.ctors.*))

 *(.ctors)



__CTOR Symbols using objdump tool (note that local are used in reality)

*

00187a70 l O .ctors0004 __CTOR_LIST__.1431.20271

00187a78 l O .ctors0004 __CTOR_END__.603481.26462

00187a70 g O .ctors __CTOR_LIST__

00187a84 g O .ctors __CTOR_END__

[Bug sanitizer/55309] gcc's address-sanitizer 66% slower than clang's

[kcc at gcc dot gnu.org]

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



--- Comment #30 from Kostya Serebryany  2013-02-11 
14:42:43 UTC ---

> Could we on x86_64 think about mem_to_shadow(x) (x >> 3) + 0x7fff8000



Committed http://llvm.org/viewvc/llvm-project?rev=174886&view=rev

which adds an optional flag -mllvm -asan-short-64bit-mapping-offset=1



On bzip2/train it gives us ~ 2/3 of the zero-base-offset benefits:

  orig  0x7fff8000zero  

401.bzip2,68.80,64.80,62.70



Measuring the rest. 



Note that with clang this did not require any change in the run-time

(since recently we switched to ASAN_FLEXIBLE_MAPPING_AND_OFFSET=1)

[Bug tree-optimization/56175] Issue with combine phase on x86.

[rguenth at gcc dot gnu.org]

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



--- Comment #6 from Richard Biener  2013-02-11 
14:38:37 UTC ---

(In reply to comment #5)

> This pattern is already recognized by simplify_bitwise_binary but only for

> usual int type, i.e. if we change all short types to the ordinary int (or

> unsigned) this simplification takes place (dump after 1st forwprop):

> 

>   :

>   x_8 = x_2(D) >> 1;

>   y_9 = y_4(D) >> 1;

>   _10 = x_8 & 1;

>   _11 = y_9 & 1;

>   _16 = x_8 ^ y_9;

>   z_12 = _16 & 1;

> 

> i.e. the issue is redundant type conversions:

> 

>   :

>   x_7 = x_2(D) >> 1;

>   y_8 = y_4(D) >> 1;

>   _13 = x_7 & 1;

>   _9 = (signed char) _13;

>   _14 = y_8 & 1;

>   _10 = (signed char) _14;

>   _11 = _9 ^ _10;

> 

> I assume that if we delete these redundant conversions the required

> simplification will happen.



Ah, well.  The issue is that we transformed (unsigned char)y & 1

to (unsigned char)(y & 1).

[Bug fortran/56284] [OOP] ICE with alternate return in type-bound procedure

[janus at gcc dot gnu.org]

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



--- Comment #6 from janus at gcc dot gnu.org 2013-02-11 13:57:36 UTC ---

The combined patches of comment 4 and 5 yield the following testsuite failures:



FAIL: gfortran.dg/altreturn_2.f90  -O  (test for excess errors)

FAIL: gfortran.dg/intrinsic_actual_3.f90  -O  (test for excess errors)

FAIL: gfortran.dg/invalid_interface_assignment.f90  -O  (test for excess

errors)



(all of them are clearly due to comment 5)

[Bug target/47333] [4.6, 4.8 regression] g++.dg/lto/20091219 FAILs on Solaris 2 with SUN as

[ro at CeBiTec dot Uni-Bielefeld.DE]

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



--- Comment #29 from ro at CeBiTec dot Uni-Bielefeld.DE  2013-02-11 13:47:21 UTC ---

The error can be reproduced on x86_64-unknown-linux-gnu with gas by

disabling weakref support, i.e. setting gcc_cv_as_weakref=no during the

build.  So again this has nothing to do with Solaris and Sun as in

particular, but just with this specific configuration.



Rainer

[Bug tree-optimization/56175] Issue with combine phase on x86.

[ysrumyan at gmail dot com]

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



--- Comment #5 from Yuri Rumyantsev  2013-02-11 
13:42:49 UTC ---

This pattern is already recognized by simplify_bitwise_binary but only for

usual int type, i.e. if we change all short types to the ordinary int (or

unsigned) this simplification takes place (dump after 1st forwprop):



  :

  x_8 = x_2(D) >> 1;

  y_9 = y_4(D) >> 1;

  _10 = x_8 & 1;

  _11 = y_9 & 1;

  _16 = x_8 ^ y_9;

  z_12 = _16 & 1;



i.e. the issue is redundant type conversions:



  :

  x_7 = x_2(D) >> 1;

  y_8 = y_4(D) >> 1;

  _13 = x_7 & 1;

  _9 = (signed char) _13;

  _14 = y_8 & 1;

  _10 = (signed char) _14;

  _11 = _9 ^ _10;



I assume that if we delete these redundant conversions the required

simplification will happen.

[Bug tree-optimization/56273] [4.8 regression] Bogus -Warray-bounds warning

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 Status|ASSIGNED|RESOLVED

 Resolution||FIXED



--- Comment #7 from Richard Biener  2013-02-11 
13:34:06 UTC ---

Fixed.

[Bug tree-optimization/56273] [4.8 regression] Bogus -Warray-bounds warning

[rguenth at gcc dot gnu.org]

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



--- Comment #6 from Richard Biener  2013-02-11 
13:33:29 UTC ---

Author: rguenth

Date: Mon Feb 11 13:33:19 2013

New Revision: 195940



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

Log:

2013-02-11  Richard Biener  



PR tree-optimization/56273

* tree-vrp.c (simplify_cond_using_ranges): Disable for the

first VRP run.

(check_array_ref): Fix missing newline in dumps.

(search_for_addr_array): Likewise.



* g++.dg/warn/Warray-bounds-6.C: New testcase.

* gcc.dg/tree-ssa/pr21559.c: Adjust.

* gcc.dg/tree-ssa/vrp17.c: Likewise.

* gcc.dg/tree-ssa/vrp18.c: Likewise.

* gcc.dg/tree-ssa/vrp23.c: Likewise.

* gcc.dg/tree-ssa/vrp24.c: Likewise.



Added:

trunk/gcc/testsuite/g++.dg/warn/Warray-bounds-6.C

Modified:

trunk/gcc/ChangeLog

trunk/gcc/testsuite/ChangeLog

trunk/gcc/testsuite/gcc.dg/tree-ssa/pr21559.c

trunk/gcc/testsuite/gcc.dg/tree-ssa/vrp17.c

trunk/gcc/testsuite/gcc.dg/tree-ssa/vrp18.c

trunk/gcc/testsuite/gcc.dg/tree-ssa/vrp23.c

trunk/gcc/testsuite/gcc.dg/tree-ssa/vrp24.c

trunk/gcc/tree-vrp.c

[Bug c++/56285] [C++11] Arguments to an inheriting constructor are not forwarded properly

[redi at gcc dot gnu.org]

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



Jonathan Wakely  changed:



   What|Removed |Added



   Keywords||rejects-valid

 Status|UNCONFIRMED |NEW

   Last reconfirmed||2013-02-11

 Ever Confirmed|0   |1



--- Comment #1 from Jonathan Wakely  2013-02-11 
13:14:42 UTC ---

[class.inhctor]/8 says bar should have an implicitly-defined constructor

equivalent to 



bar(int&& p) : foo(static_cast(p)) { }

[Bug bootstrap/56128] [4.8 Regression] libsanitizer doesn't build with broken kernel headers

[jakub at gcc dot gnu.org]

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



--- Comment #12 from Jakub Jelinek  2013-02-11 
13:13:14 UTC ---

(In reply to comment #11)

> > We need more than that.  E.g. ppc64 asan is very much broken in the gcc 
> > tree,

> > that is fixed in upstream libasan already, right?

> 

> Last time I tried, basic tests passed on ppc64 with 44 address space (did not

> checke with 46 AS). 



http://ppc.koji.fedoraproject.org/packages/gcc/4.8.0/0.10.fc19/data/logs/ppc64/build.log

shows lots of failures.  Guess it is possible those boxes use 46-bit AS.



> Ok, I'll do the merge after the scanf stuff is in. 



Thanks.



> > BTW, any progress with the 0x7fff8000 shadow offset for x86_64?  

> 

> Not yet. Hopefully will try it this week. 



Looking forward to those results.

> 

> > If it looks

> > good benchmark-wise, I think it would be better if we switched the ASAN 
> > x86_64

> > ABI for GCC sooner (read, before 4.8) than have one asan ABI for 4.8 built

> > objects and another one for 4.9 built objects (which is still possible that 
> > it

> > will happen, but it wouldn't hurt to avoid that).

> 

> Agree. How much time do we have?



Not too much time, I guess if the real change on the gcc + libsanitizer side

will be tweaking a few constants, it can be done within next few weeks, but

preferably in February.  A full libsanitizer merge should be this or next week,

so that we have time to handle with any fallout of that (but at that point

already just selective backports).

[Bug bootstrap/56128] [4.8 Regression] libsanitizer doesn't build with broken kernel headers

[kcc at gcc dot gnu.org]

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



--- Comment #11 from Kostya Serebryany  2013-02-11 
12:58:07 UTC ---

> We need more than that.  E.g. ppc64 asan is very much broken in the gcc tree,

> that is fixed in upstream libasan already, right?



Last time I tried, basic tests passed on ppc64 with 44 address space (did not

checke with 46 AS). 



> 

> I'd think we should just do one more llvm -> libsanitizer merge soon (after 
> the

> scanf stuff is resolved?).  



Ok, I'll do the merge after the scanf stuff is in. 



> A slight complication is that asan_test.cc got

> split into smaller tests, but even for GCC it will be worthwhile to have fewer

> smaller tests I guess, we'll just need to add the wrappers.

> 

> BTW, any progress with the 0x7fff8000 shadow offset for x86_64?  



Not yet. Hopefully will try it this week. 



> If it looks

> good benchmark-wise, I think it would be better if we switched the ASAN x86_64

> ABI for GCC sooner (read, before 4.8) than have one asan ABI for 4.8 built

> objects and another one for 4.9 built objects (which is still possible that it

> will happen, but it wouldn't hurt to avoid that).



Agree. How much time do we have?

[Bug tree-optimization/56286] vectorizer does not keep loop-closed SSA up-to-date

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



   Keywords||compile-time-hog,

   ||wrong-code

 Status|UNCONFIRMED |ASSIGNED

   Last reconfirmed||2013-02-11

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

   |gnu.org |

 Ever Confirmed|0   |1



--- Comment #1 from Richard Biener  2013-02-11 
12:55:06 UTC ---

This blocks fixing of tree-ssa-loop-manip.c:find_uses_to_rename



   /* ??? If CHANGED_BBS is empty we rewrite the whole function -- why?  */

   if (changed_bbs && !bitmap_empty_p (changed_bbs))

 {

   EXECUTE_IF_SET_IN_BITMAP (changed_bbs, 0, index, bi)



which can be a major resource hog.  Also relying on that bug is broken,

without checking we can end up generating wrong-code this way.



Incremental betterness can be achieved by



Index: gcc/tree-vect-stmts.c

===

--- gcc/tree-vect-stmts.c   (revision 195938)

+++ gcc/tree-vect-stmts.c   (working copy)

@@ -5834,46 +5834,6 @@ vect_transform_stmt (gimple stmt, gimple

}

 }



-  /* Handle inner-loop stmts whose DEF is used in the loop-nest that

- is being vectorized, but outside the immediately enclosing loop.  */

-  if (vec_stmt

...

-   }

-   }

-}

-

   /* Handle stmts whose DEF is used outside the loop-nest that is

  being vectorized.  */





But still



FAIL: gcc.dg/vect/no-scevccp-outer-22.c (internal compiler error)

FAIL: gcc.dg/vect/no-scevccp-outer-22.c (test for excess errors)

WARNING: gcc.dg/vect/no-scevccp-outer-22.c compilation failed to produce

executable

FAIL: gcc.dg/vect/no-scevccp-noreassoc-outer-4.c (internal compiler error)

FAIL: gcc.dg/vect/no-scevccp-noreassoc-outer-4.c (test for excess errors)

WARNING: gcc.dg/vect/no-scevccp-noreassoc-outer-4.c compilation failed to

produce executable

FAIL: gcc.dg/vect/no-scevccp-noreassoc-outer-4.c scan-tree-dump-times vect

"OUTER LOOP VECTORIZED." 1

[Bug tree-optimization/56286] New: vectorizer does not keep loop-closed SSA up-to-date

[rguenth at gcc dot gnu.org]

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



 Bug #: 56286

   Summary: vectorizer does not keep loop-closed SSA up-to-date

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: tree-optimization

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

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





The vectorizer relies on the bug that cfgcleaup for no changed bbs from

fix_loop_structure rewrites the whole function into loop-closed-SSA again.



Loop-closed PHI node creation in vect_create_epilog_for_reduction does

not handle outer loop uses of the reduction result properly (those uses

are not yet vectorized).  For example gcc.dg/pr50133.c.

[Bug fortran/56284] [OOP] ICE with alternate return in type-bound procedure

[janus at gcc dot gnu.org]

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



janus at gcc dot gnu.org changed:



   What|Removed |Added



 Status|NEW |ASSIGNED

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

   |gnu.org |



--- Comment #5 from janus at gcc dot gnu.org 2013-02-11 12:36:46 UTC ---

... and this adds a warning about the obsolescent alternate return argument

(with -std=f2003 or f2008):





Index: gcc/fortran/decl.c

===

--- gcc/fortran/decl.c(revision 195915)

+++ gcc/fortran/decl.c(working copy)

@@ -4487,7 +4487,15 @@ gfc_match_formal_arglist (gfc_symbol *progname, in

   for (;;)

 {

   if (gfc_match_char ('*') == MATCH_YES)

-sym = NULL;

+{

+  sym = NULL;

+  if (gfc_notify_std (GFC_STD_F95_OBS, "Alternate return argument "

+  "at %C") == FAILURE)

+{

+  m = MATCH_ERROR;

+  goto cleanup;

+}

+}

   else

 {

   m = gfc_match_name (name);





Also: Mine.

[Bug fortran/56284] [OOP] ICE with alternate return in type-bound procedure

[janus at gcc dot gnu.org]

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



janus at gcc dot gnu.org changed:



   What|Removed |Added



   Keywords||ice-on-valid-code



--- Comment #4 from janus at gcc dot gnu.org 2013-02-11 12:17:34 UTC ---

The following fixes the ICE:



Index: gcc/fortran/interface.c

===

--- gcc/fortran/interface.c(revision 195915)

+++ gcc/fortran/interface.c(working copy)

@@ -1023,6 +1023,9 @@ static gfc_try

 check_dummy_characteristics (gfc_symbol *s1, gfc_symbol *s2,

  bool type_must_agree, char *errmsg, int err_len)

 {

+  if (s1 == NULL || s2 == NULL)

+return s1 == s2 ? SUCCESS : FAILURE;

+

   /* Check type and rank.  */

   if (type_must_agree && !compare_type_rank (s2, s1))

 {

[Bug bootstrap/56128] [4.8 Regression] libsanitizer doesn't build with broken kernel headers

[jakub at gcc dot gnu.org]

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



--- Comment #10 from Jakub Jelinek  2013-02-11 
12:08:11 UTC ---

(In reply to comment #9)

> (In reply to comment #8)

> > Requires a merge as far as I can see.  Important enough build issue.

> 

> I am reluctant to do another full merge so close to 4.8 -- we have too many

> intrusive changes in upstream trunk. 

> 

> Jakub, WDYT? 

> Maybe we just apply http://llvm.org/viewvc/llvm-project?rev=173933&view=rev

> once 4.8 branches out? 

> (Not sure if the gcc development process works this way...)



We need more than that.  E.g. ppc64 asan is very much broken in the gcc tree,

that is fixed in upstream libasan already, right?



I'd think we should just do one more llvm -> libsanitizer merge soon (after the

scanf stuff is resolved?).  A slight complication is that asan_test.cc got

split into smaller tests, but even for GCC it will be worthwhile to have fewer

smaller tests I guess, we'll just need to add the wrappers.



BTW, any progress with the 0x7fff8000 shadow offset for x86_64?  If it looks

good benchmark-wise, I think it would be better if we switched the ASAN x86_64

ABI for GCC sooner (read, before 4.8) than have one asan ABI for 4.8 built

objects and another one for 4.9 built objects (which is still possible that it

will happen, but it wouldn't hurt to avoid that).

[Bug c++/56285] New: [C++11] Arguments to an inheriting constructor is not forwarded properly

[lucdanton at free dot fr]

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



 Bug #: 56285

   Summary: [C++11] Arguments to an inheriting constructor is not

forwarded properly

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: c++

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

ReportedBy: lucdan...@free.fr





Created attachment 29417

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

Minimal reproducible testcase



$ g++-snapshot --version

g++-snapshot (Debian 20130209-1) 4.8.0 20130209 (experimental) [trunk revision

195917]



$ cat main.cpp 

struct foo {

explicit foo(int&&) {}

};



struct bar: private foo {

using foo::foo;

};



int main()

{

bar b { 42 };

}



$ g++-snapshot -Wall -std=c++11 main.cpp 

main.cpp: In constructor 'bar::bar(int&&)':

main.cpp:6:16: error: cannot bind 'int' lvalue to 'int&&'

 using foo::foo;

^

main.cpp:2:14: error:   initializing argument 1 of 'foo::foo(int&&)'

 explicit foo(int&&) {}

  ^

main.cpp: In function 'int main()':

main.cpp:11:16: note: synthesized method 'bar::bar(int&&)' first required here 

 bar b { 42 };

[Bug bootstrap/56128] [4.8 Regression] libsanitizer doesn't build with broken kernel headers

[kcc at gcc dot gnu.org]

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



--- Comment #9 from Kostya Serebryany  2013-02-11 
11:54:46 UTC ---

(In reply to comment #8)

> Requires a merge as far as I can see.  Important enough build issue.



I am reluctant to do another full merge so close to 4.8 -- we have too many

intrusive changes in upstream trunk. 



Jakub, WDYT? 

Maybe we just apply http://llvm.org/viewvc/llvm-project?rev=173933&view=rev

once 4.8 branches out? 

(Not sure if the gcc development process works this way...)

[Bug libstdc++/56193] ios_base should replace operator void* with explicit operator bool in C++11 onwards.

[paolo.carlini at oracle dot com]

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



--- Comment #6 from Paolo Carlini  2013-02-11 
11:48:54 UTC ---

Indeed, thanks Jon.

[Bug target/56253] fp-contract does not work with SSE and AVX FMAs (neither FMA4 nor FMA3)

[rguenth at gcc dot gnu.org]

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



--- Comment #7 from Richard Biener  2013-02-11 
11:36:29 UTC ---

So to re-cap, for vector intrinsics we can use the vector GCC extensions

while for the scalar intrinsics we would have to use target builtin folding.

Not sure if it's worth the asymmetry (thus instead do everything with

target builtin folding).



Testcase that still needs to "work" (emit addsd) with -m32 -msse2

and without -mfpmath=sse:



#include 



double foo (double x)

{

  return _mm_cvtsd_f64 (_mm_add_sd (_mm_set_sd (x), _mm_set_sd (1.0)));

}



Exposing the intrinsics internals to the compiler also would cause us to

not "literally" emitting the code the user may have asked for (though

RTL optimization already might do that - but RTL for example never

re-associates FP, even with -ffast-math).

[Bug libstdc++/56193] ios_base should replace operator void* with explicit operator bool in C++11 onwards.

[redi at gcc dot gnu.org]

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



Jonathan Wakely  changed:



   What|Removed |Added



Version|unknown |4.8.0

   Target Milestone|4.8.0   |---



--- Comment #5 from Jonathan Wakely  2013-02-11 
11:22:53 UTC ---

PR 56282 has a patch that could serve as a starting point for the symbol

versions file

[Bug tree-optimization/56273] [4.8 regression] Bogus -Warray-bounds warning

[rguenth at gcc dot gnu.org]

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



--- Comment #5 from Richard Biener  2013-02-11 
10:52:39 UTC ---

One of the reasons this all happens is of course that after complete unrolling

we miss a pass that does full redundancy removal and const/copy propagation.

For the latter we abuse VRP (but cripple it), for the former we have DOM,

but that is scheduled after VRP.



I wonder if we should simply move VRP after DOM.  Like with



Index: gcc/passes.c

===

--- gcc/passes.c(revision 195938)

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

@@ -1488,7 +1488,6 @@ init_optimization_passes (void)

   NEXT_PASS (pass_lower_vector_ssa);

   NEXT_PASS (pass_cse_reciprocals);

   NEXT_PASS (pass_reassoc);

-  NEXT_PASS (pass_vrp);

   NEXT_PASS (pass_strength_reduction);

   NEXT_PASS (pass_dominator);

   /* The only const/copy propagation opportunities left after

@@ -1497,6 +1496,7 @@ init_optimization_passes (void)

 only examines PHIs to discover const/copy propagation

 opportunities.  */

   NEXT_PASS (pass_phi_only_cprop);

+  NEXT_PASS (pass_vrp);

   NEXT_PASS (pass_cd_dce);

   NEXT_PASS (pass_tracer);



as DOM also performs constant/copy propagation.  That doesn't fix the

warning but makes the IL that we feed into VRP2 much more suitable to

its working.



A patch to disable the < -> != transform fixes this bug and I am going

to test that.

[Bug c/56281] missed VRP optimization from undefined left shift in ISO C99

[vincent-gcc at vinc17 dot net]

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

Vincent Lefèvre  changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|DUPLICATE   |

--- Comment #3 from Vincent Lefèvre  2013-02-11 
10:38:27 UTC ---
Not the same request. Bug 31178 (VRP can infer a range for b in a >> b and a <<
b) is about a range for the second operand b (independent from the value of the
first operand, BTW). Here it is a range for the first operand and the result.
This is quite different due to the asymmetry of shift operators.

Concerning existing code, there was also much code assuming wrapping in case of
integer overflow for +. Code needs to be fixed or should not be compiled with
options like -std=c99.

[Bug libstdc++/56282] [4.8 regression] std::basic_ios broken with -std=c++11 (undefined reference)

[paolo.carlini at oracle dot com]

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



Paolo Carlini  changed:



   What|Removed |Added



 Status|ASSIGNED|RESOLVED

 Resolution||FIXED



--- Comment #6 from Paolo Carlini  2013-02-11 
10:32:55 UTC ---

Fixed.

[Bug libstdc++/56193] ios_base should replace operator void* with explicit operator bool in C++11 onwards.

[paolo.carlini at oracle dot com]

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



Paolo Carlini  changed:



   What|Removed |Added



 Status|RESOLVED|REOPENED

 Resolution|FIXED   |



--- Comment #4 from Paolo Carlini  2013-02-11 
10:32:25 UTC ---

Patch reverted. Better simply do this in the next ABI.

[Bug libstdc++/56193] ios_base should replace operator void* with explicit operator bool in C++11 onwards.

[paolo at gcc dot gnu.org]

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



--- Comment #3 from paolo at gcc dot gnu.org  
2013-02-11 10:30:50 UTC ---

Author: paolo

Date: Mon Feb 11 10:30:43 2013

New Revision: 195939



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

Log:

2013-02-11  Paolo Carlini  



PR libstdc++/56282

Revert:

2013-02-06  Edward Smith-Rowland  <3dw...@verizon.net>



PR libstdc++/56193

* include/bits/basic_ios.h: Replace operator void*() const

with explicit operator bool() const in C++11 and greater.

* testsuite/27_io/basic_ios/pr56193.cc: New file.



Removed:

trunk/libstdc++-v3/testsuite/27_io/basic_ios/pr56193.cc

Modified:

trunk/libstdc++-v3/ChangeLog

trunk/libstdc++-v3/include/bits/basic_ios.h

[Bug libstdc++/56282] [4.8 regression] std::basic_ios broken with -std=c++11 (undefined reference)

[paolo at gcc dot gnu.org]

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



--- Comment #5 from paolo at gcc dot gnu.org  
2013-02-11 10:30:50 UTC ---

Author: paolo

Date: Mon Feb 11 10:30:43 2013

New Revision: 195939



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

Log:

2013-02-11  Paolo Carlini  



PR libstdc++/56282

Revert:

2013-02-06  Edward Smith-Rowland  <3dw...@verizon.net>



PR libstdc++/56193

* include/bits/basic_ios.h: Replace operator void*() const

with explicit operator bool() const in C++11 and greater.

* testsuite/27_io/basic_ios/pr56193.cc: New file.



Removed:

trunk/libstdc++-v3/testsuite/27_io/basic_ios/pr56193.cc

Modified:

trunk/libstdc++-v3/ChangeLog

trunk/libstdc++-v3/include/bits/basic_ios.h

[Bug tree-optimization/56264] [4.8 Regression] ICE in check_loop_closed_ssa_use, at tree-ssa-loop-manip.c:557

[rguenth at gcc dot gnu.org]

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



--- Comment #5 from Richard Biener  2013-02-11 
10:27:56 UTC ---

I would guess that originally cfg-cleanup caused basic-blocks to leak

outside a loop, thus at most exposing new use sites.  With discovering

new loops we may both wreck that scheme (loop depth may not change but

blocks still leak) and fail to recognize use-blocks of defs that changed

loop ownership.



Fix_loop_structure could return the number of newly discovered loops,

indicating that the whole function needs to be re-scanned (still not accounting

for weird loop tree hierarchy changes, but those shouldn't be caused by

transformations cfgcleanup does).



Testing a patch.

[Bug fortran/56284] [OOP] ICE with alternate return in type-bound procedure

[janus at gcc dot gnu.org]

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



janus at gcc dot gnu.org changed:



   What|Removed |Added



Summary|[OOP] ICE with contained|[OOP] ICE with alternate

   |routine which   |return in type-bound

   |inappropriately compares a  |procedure

   |string and a number |



--- Comment #3 from janus at gcc dot gnu.org 2013-02-11 10:09:39 UTC ---

(In reply to comment #2)

> 

>   subroutine getRecord ( * )

>   end subroutine



Ok, I admit that I had to look up the asterisk thingy. It's called "alternate

return" and is a obsolescent feature since at least F95.



According to PR 40881, we should have a warning message for this, but it does

not seem to trigger for the test case here. Should be fixed I guess (just as

the ICE, although combining obsolescent features like alternate return with new

stuff such as type binding is surely not recommended).

[Bug libstdc++/56282] [4.8 regression] std::basic_ios broken with -std=c++11 (undefined reference)

[paolo.carlini at oracle dot com]

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



Paolo Carlini  changed:



   What|Removed |Added



 Status|NEW |ASSIGNED

 AssignedTo|unassigned at gcc dot   |paolo.carlini at oracle dot

   |gnu.org |com



--- Comment #4 from Paolo Carlini  2013-02-11 
10:09:05 UTC ---

Nahh, let's revert the whole thing.

[Bug libstdc++/56283] std::result_of does not gracefully SFINAE (not define ::type)

[redi at gcc dot gnu.org]

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



Jonathan Wakely  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||WORKSFORME

   Target Milestone|--- |4.8.0



--- Comment #3 from Jonathan Wakely  2013-02-11 
10:07:06 UTC ---

.

[Bug libstdc++/56283] std::result_of does not gracefully SFINAE (not define ::type)

[redi at gcc dot gnu.org]

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



--- Comment #2 from Jonathan Wakely  2013-02-11 
10:05:58 UTC ---

You're looking at a post-C++11 draft, not at the standard. The change was made

by http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3462.html and GCC

4.8 already implements the new behaviour, but 4.7 isn't going to.

[Bug libstdc++/56282] [4.8 regression] std::basic_ios broken with -std=c++11 (undefined reference)

[redi at gcc dot gnu.org]

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



Jonathan Wakely  changed:



   What|Removed |Added



  Attachment #29415|0   |1

is obsolete||



--- Comment #3 from Jonathan Wakely  2013-02-11 
10:03:31 UTC ---

Created attachment 29416

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

fix exports



I think this is right now

[Bug tree-optimization/56264] [4.8 Regression] ICE in check_loop_closed_ssa_use, at tree-ssa-loop-manip.c:557

[rguenth at gcc dot gnu.org]

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



--- Comment #4 from Richard Biener  2013-02-11 
10:00:18 UTC ---

unswitching makes the formerly irreducible inner loop reducible on one

path (cfgcleanup makes this loop appear).  As we are in the loop optimizer

block we are supposed to be in loop-closed SSA.  Now we only mark

a single block as changed (bb 7, the loop header of the newly recognized

inner loop).  rewrite_into_loop_closed_ssa functions in the way that

it only scans changed_bbs for out-of-def-loop _uses_.  I don't see how

that can catch all changes detected by (even former) fix_loop_structure

which marks blocks as changed whose loop depth changes (that is, if a

definition block changes its loop depth but the use block does not,

like in this case, we fail to fixup loop-closed SSA form).  Not sure if

"no new loops are discovered" excluded this possibility in the old scheme.



Now, the block with the use that needs a loop-closed PHI node at the exit

of the newly discovered loop isn't changed in any way (nor is the exit block).

That said - I still fail to see the logic of the old computation of

"changed-blocks" in fix_loop_structure.  I'd said we need to re-scan

all loop blocks of loops we exit to from loops that have 'changed blocks'.

And maybe all loop blocks we may exit from to a loop that has 'changed blocks'.



H.

[Bug libstdc++/56282] [4.8 regression] std::basic_ios broken with -std=c++11 (undefined reference)

[redi at gcc dot gnu.org]

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



--- Comment #2 from Jonathan Wakely  2013-02-11 
09:53:38 UTC ---

Created attachment 29415

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

Instantiate and export new operator



Something like this, although putting it in fstream-inst.cc is a bit of a hack,

it just happens to be compiled as C++11



I'm not sure the wildcard patterns are right yet though...

[Bug fortran/56284] [OOP] ICE with contained routine which inappropriately compares a string and a number

[janus at gcc dot gnu.org]

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



janus at gcc dot gnu.org changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2013-02-11

 CC||janus at gcc dot gnu.org

Summary|ICE with contained routine  |[OOP] ICE with contained

   |which inappropriately   |routine which

   |compares a string and a |inappropriately compares a

   |number  |string and a number

 Ever Confirmed|0   |1



--- Comment #2 from janus at gcc dot gnu.org 2013-02-11 09:51:39 UTC ---

Reduced test case:



module try_this

implicit none



type :: table_t

contains

procedure, nopass :: getRecord

end type



contains



  subroutine getRecord ( * )

  end subroutine



end module





ICEs with 4.6, 4.7 and trunk. Backtrace:



f951: internal compiler error: Segmentation fault

0xb0f2cd crash_signal

/home/jweil/gcc48/trunk/gcc/toplev.c:332

0x57d360 compare_type_rank

/home/jweil/gcc48/trunk/gcc/fortran/interface.c:522

0x57e327 check_dummy_characteristics

/home/jweil/gcc48/trunk/gcc/fortran/interface.c:1027

0x57f25d gfc_compare_interfaces(gfc_symbol*, gfc_symbol*, char const*, int,

int, char*, int, char const*, char const*)

/home/jweil/gcc48/trunk/gcc/fortran/interface.c:1424

0x5d7600 resolve_structure_cons

/home/jweil/gcc48/trunk/gcc/fortran/resolve.c:1221

0x5eb85f resolve_values

/home/jweil/gcc48/trunk/gcc/fortran/resolve.c:10461

0x611b53 do_traverse_symtree

/home/jweil/gcc48/trunk/gcc/fortran/symbol.c:3448

0x611c1f gfc_traverse_ns(gfc_namespace*, void (*)(gfc_symbol*))

/home/jweil/gcc48/trunk/gcc/fortran/symbol.c:3473

0x5f663c resolve_types

/home/jweil/gcc48/trunk/gcc/fortran/resolve.c:14913

0x5f69a0 gfc_resolve(gfc_namespace*)

/home/jweil/gcc48/trunk/gcc/fortran/resolve.c:14995

0x5ce423 gfc_parse_file()

/home/jweil/gcc48/trunk/gcc/fortran/parse.c:4608

0x61adcd gfc_be_parse_file

/home/jweil/gcc48/trunk/gcc/fortran/f95-lang.c:189

[Bug tree-optimization/56273] [4.8 regression] Bogus -Warray-bounds warning

[rguenth at gcc dot gnu.org]

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



--- Comment #4 from Richard Biener  2013-02-11 
09:32:31 UTC ---

(In reply to comment #2)

> The problem is a missing VRP.  Basically ivopts changes:

>   if (j_10 != 9)

> 

> Which works into:

> 

>   j_10 = ivtmp.12_56;

>   if (ivtmp.12_56 != 9)

> goto ;

>   else

> goto ;

> 

> 

> Which does not work as VRP cannot figure out j_10 will never be 9.

> I have some patches to VRP which improves this but I don't remember if it 
> fixes

> this case where there is an assignment which is used later on.



A similar case was PR55079 which was



   j_10 = ivtmp.12_56 + 1;

   if (ivtmp.12_56 == 5)

 ...



I handled already.  Extending this to copies should be easy.  If I do that

it still doesn't work.



That's because we warn for stuff[j_15] and j_15 is [9, 16] (we completely

peel the loop).  The access is guarded with



  :

  j_55 = ivtmp.12_56 + 8;

  j_72 = ivtmp.12_56 + 8;

  if (j_72 != 9)

goto ;

  else

goto ;



  :

  # j_15 = PHI 

  _12 = stuff[j_15].a;

  if (_12 != 0)



but j_72 is [9, 16] as well and ivtmp.12_56: [1, 9].  Improving VRP to

see that j_55 is != 9 in bb31 will only lead to [10, 16] which is also

out-of-bounds.



It might very well be that folding the < test to != in VRP1 causes most

of the issues.  Indeed -fdisable-tree-vrp1 "fixes" the testcase.  We

should probably delay that optimization to VRP2 only, thus don't do



Folding statement: if (i_1 <= 8)

Simplified relational if (i_1 <= 8)

 into if (i_1 != 9)



(simplify_cond_using_ranges).

[Bug target/55431] Invalid auxv search in ppc linux-unwind code.

[aldot at gcc dot gnu.org]

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



Bernhard Reutner-Fischer  changed:



   What|Removed |Added



 CC||aldot at gcc dot gnu.org,

   ||dje.gcc at gmail dot com,

   ||geoffk at geoffk dot org



--- Comment #3 from Bernhard Reutner-Fischer  
2013-02-11 09:12:11 UTC ---

CCing rs6000 maintainers

[Bug middle-end/56242] [4.8 Regression] libjava/classpath/gnu/javax/swing/text/html/parser/support/textPreProcessor.java:175:0: ICE: Segmentation fault

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 CC||jakub at gcc dot gnu.org



--- Comment #2 from Jakub Jelinek  2013-02-11 
09:10:12 UTC ---

I'd say if NOTE_INSN_BASIC_BLOCK has NULL BLOCK_FOR_INSN, rather than trying to

use NOTE_BASIC_BLOCK the code should just assume cfg has been freed and can't

be used.

[Bug ada/56274] [4.8 Regression] libada bootstrap failure on kfreebsd ("pthread_rwlock_t" not declared in "OS_Interface")

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



   Priority|P3  |P4

 CC||jakub at gcc dot gnu.org

[Bug libstdc++/56282] [4.8 regression] std::basic_ios broken with -std=c++11 (undefined reference)

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



   Priority|P3  |P1

 Status|UNCONFIRMED |NEW

   Last reconfirmed||2013-02-11

 CC||jakub at gcc dot gnu.org

 Ever Confirmed|0   |1



--- Comment #1 from Jakub Jelinek  2013-02-11 
09:04:00 UTC ---

Guess we need a new export and instantiate this operator from some C++11 source

too?