[Bug rtl-optimization/56847] [4.8/4.9 Regression] '-fpie' triggers - internal compiler error: in gen_add2_insn, at optabs.c:4705

[ubizjak at gmail dot com]

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



Uros Bizjak  changed:



   What|Removed |Added



   Keywords||ra

  Component|target  |rtl-optimization



--- Comment #6 from Uros Bizjak  2013-04-05 06:13:56 
UTC ---

The target part exposes underlying LRA problem.

[Bug target/56847] [4.8/4.9 Regression] '-fpie' triggers - internal compiler error: in gen_add2_insn, at optabs.c:4705

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 CC||jakub at gcc dot gnu.org,

   ||vmakarov at gcc dot gnu.org

   Target Milestone|4.9.0   |4.8.1

Summary|'-fpie' triggers - internal |[4.8/4.9 Regression]

   |compiler error: in  |'-fpie' triggers - internal

   |gen_add2_insn, at   |compiler error: in

   |optabs.c:4705   |gen_add2_insn, at

   ||optabs.c:4705



--- Comment #5 from Jakub Jelinek  2013-04-05 
06:11:37 UTC ---

Even more reduced:

/* PR target/56847 */

/* { dg-do compile { target pie } } */

/* { dg-options "-O2 -fpie" } */



struct S { long int a, b; } e;

__thread struct S s;



void

foo (void)

{

  s = e;

}

[Bug rtl-optimization/48188] ICE: SIGSEGV in remove_unnecessary_regions (ira-build.c:1855) with --param ira-max-loops-num=0 on basic code

[mpolacek at gcc dot gnu.org]

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



Marek Polacek  changed:



   What|Removed |Added



 CC||mpolacek at gcc dot gnu.org



--- Comment #2 from Marek Polacek  2013-04-05 
06:00:16 UTC ---

Broken only in 4.6.  I think WONTFIX...

[Bug target/56847] '-fpie' triggers - internal compiler error: in gen_add2_insn, at optabs.c:4705

[mpolacek at gcc dot gnu.org]

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



Marek Polacek  changed:



   What|Removed |Added



 CC||uros at gcc dot gnu.org



--- Comment #4 from Marek Polacek  2013-04-05 
05:54:31 UTC ---

Started with http://gcc.gnu.org/viewcvs/gcc?view=revision&revision=193671

[Bug target/56847] '-fpie' triggers - internal compiler error: in gen_add2_insn, at optabs.c:4705

[mpolacek at gcc dot gnu.org]

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



--- Comment #3 from Marek Polacek  2013-04-05 
05:28:21 UTC ---

Slightly reduced.

struct S { long int a, b; };

extern struct S e;



void

foo (void)

{

  static __thread struct S s = { 0, 0 };

  s = e;

}

[Bug rtl-optimization/56847] '-fpie' triggers - internal compiler error: in gen_add2_insn, at optabs.c:4705

[mpolacek at gcc dot gnu.org]

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



Marek Polacek  changed:



   What|Removed |Added



   Target Milestone|--- |4.9.0

[Bug rtl-optimization/56847] '-fpie' triggers - internal compiler error: in gen_add2_insn, at optabs.c:4705

[mpolacek at gcc dot gnu.org]

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



Marek Polacek  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2013-04-05

 CC||mpolacek at gcc dot gnu.org

  Component|target  |rtl-optimization

 Ever Confirmed|0   |1



--- Comment #2 from Marek Polacek  2013-04-05 
05:07:20 UTC ---

Confirmed.

[Bug rtl-optimization/38644] [4.6 Regression] Optimization flag -O1 -fschedule-insns2 causes wrong code

[pinskia at gcc dot gnu.org]

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



Andrew Pinski  changed:



   What|Removed |Added



 Status|NEW |RESOLVED

 Resolution||FIXED

   Target Milestone|4.6.4   |4.6.0



--- Comment #69 from Andrew Pinski  2013-04-05 
04:23:43 UTC ---

(In reply to comment #68)

> Is this problem resolved? The status is still set to "NEW" but "known to work"

> shows that it either has been resolved in v4.7.0 or that version is somehow 
> not

> affected.



It was resolved with the patch in comment #59 and comment #62.  In GCC 4.6.0.

[Bug rtl-optimization/38644] [4.6 Regression] Optimization flag -O1 -fschedule-insns2 causes wrong code

[peter at axium dot co.nz]

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



incrediball  changed:



   What|Removed |Added



 CC||peter at axium dot co.nz



--- Comment #68 from incrediball  2013-04-05 03:51:14 
UTC ---

Is this problem resolved? The status is still set to "NEW" but "known to work"

shows that it either has been resolved in v4.7.0 or that version is somehow not

affected.



I spent the best part of this week trying to track this problem down. It was

VERY hard to reproduce but I eventually found that the -fschedule-insns2

compile option caused the problem. The code that was affected is almost exactly

the same as the test case in comment #1.

[Bug rtl-optimization/56847] '-fpie' triggers - internal compiler error: in gen_add2_insn, at optabs.c:4705

[shenhan at google dot com]

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



--- Comment #1 from Han Shen  2013-04-04 23:31:02 
UTC ---

Created attachment 29807

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

test case

[Bug rtl-optimization/56847] New: '-fpie' triggers - internal compiler error: in gen_add2_insn, at optabs.c:4705

[shenhan at google dot com]

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

 Bug #: 56847
   Summary: '-fpie' triggers - internal compiler error: in
gen_add2_insn, at optabs.c:4705
Classification: Unclassified
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: shen...@google.com


System - Ubuntu 12.04 64 bit.
GCC configuration - configure --disable-bootstrap --enable-languages='c,c++'
How to reproduce - 
 gcc -fpie -c -O2 case.c

Error message I got -

case.c: In function ‘get_clock’:
case.c:20:1: internal compiler error: in gen_add2_insn, at optabs.c:4705
 }
 ^
0x735e4b gen_add2_insn(rtx_def*, rtx_def*)
../../gcc.svn/gcc-4_8-branch/gcc/optabs.c:4705
0x7037f5 lra_emit_add(rtx_def*, rtx_def*, rtx_def*)
../../gcc.svn/gcc-4_8-branch/gcc/lra.c:313
0x7119a5 curr_insn_transform
../../gcc.svn/gcc-4_8-branch/gcc/lra-constraints.c:3082
0x712224 lra_constraints(bool)
../../gcc.svn/gcc-4_8-branch/gcc/lra-constraints.c:3613
0x705a2a lra(_IO_FILE*)
../../gcc.svn/gcc-4_8-branch/gcc/lra.c:2278
0x6d0820 do_reload
../../gcc.svn/gcc-4_8-branch/gcc/ira.c:4619
0x6d0820 rest_of_handle_reload
../../gcc.svn/gcc-4_8-branch/gcc/ira.c:4731
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug fortran/56845] [OOP] _vptr not set to declared type for CLASS + SAVE

[janus at gcc dot gnu.org]

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



janus at gcc dot gnu.org changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2013-04-04

 Ever Confirmed|0   |1



--- Comment #3 from janus at gcc dot gnu.org 2013-04-04 21:24:12 UTC ---

(In reply to comment #2)

> (In reply to comment #1)

> > Also there is a piece of code in gfc_trans_deferred_vars (trans-decl.c) 
> > which

> > claims to do exactly this (AFAICS). No idea why it is not in effect.

> 

> That's easily answered: Because it is guarded by an "if (!sym->attr.save)".



Also it can not be used for SAVEd variables, because it would set the vptr on

each call of the subroutine (which is of course not what we want).

[Bug fortran/56845] [OOP] _vptr not set to declared type for CLASS + SAVE

[janus at gcc dot gnu.org]

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



--- Comment #2 from janus at gcc dot gnu.org 2013-04-04 21:01:19 UTC ---

(In reply to comment #1)

> Also there is a piece of code in gfc_trans_deferred_vars (trans-decl.c) which

> claims to do exactly this (AFAICS). No idea why it is not in effect.



That's easily answered: Because it is guarded by an "if (!sym->attr.save)".

[Bug fortran/56845] [OOP] _vptr not set to declared type for CLASS + SAVE

[janus at gcc dot gnu.org]

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



--- Comment #1 from janus at gcc dot gnu.org 2013-04-04 20:15:07 UTC ---

Huh, funny. I thought we were doing this already.



Also there is a piece of code in gfc_trans_deferred_vars (trans-decl.c) which

claims to do exactly this (AFAICS). No idea why it is not in effect.

[Bug libgcc/56846] New: _Unwind_Backtrace on ARM and noexcept

[npl at chello dot at]

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



 Bug #: 56846

   Summary: _Unwind_Backtrace on ARM and noexcept

Classification: Unclassified

   Product: gcc

   Version: 4.7.2

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: libgcc

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

ReportedBy: n...@chello.at





I want to inquire about the feasibility of using _Unwind_Backtrace on ARM,

particularly in combination with the noexcept keyword.

Since the backtrace depends on the unwind information, it seems the

_Unwind_Backtrace breaks down when encountering "noexcept" functions.

Whats even worse is, that instead of just stopping, _Unwind_Backtrace will just

infinitely report the last context (unless the the callback tells to stop).



So there are two points I guess, first that the _Unwind_Backtrace should stop

when it cant proceed further instead of looping forever. I suppose thats a bug.



Then I`d ask if its somehow possible to still backtrace through noexcept

functions, perhaps with a compiler switch that still generates the necessary

unwind tables and/or manual adjustment to the personality routine. (gdb can

generate the traces... so I guess it must be possible)



I am using an arm-none-eabi toolchain, of version 4.7.2. 



Using built-in specs.

COLLECT_GCC=arm-none-eabi-gcc

COLLECT_LTO_WRAPPER=/opt/hipase-imx28-v0/libexec/gcc/arm-none-eabi/4.7.2/lto-wrapper

Target: arm-none-eabi

Configured with: /opt/hipase-imx28-v0/src/gcc-4.7.2/configure

--prefix=/opt/hipase-imx28-v0 --target=arm-none-eabi --enable-languages=c,c++

--disable-libstdcxx-verbose --disable-libmudflap --disable-libssp

--disable-libstdcxx-pch --enable-multilib --disable-shared --disable-nls

--with-system-zlib --enable-tls --enable-gold --with-gnu-as --with-gnu-ld

--enable-lto --with-newlib

--with-gmp=/home/tcbuild/toolchain-make/build/ggcnativebuild/gmp-5.0.5

--with-mpfr=/home/tcbuild/toolchain-make/build/ggcnativebuild/mpfr-3.1.1

--with-mpc=/home/tcbuild/toolchain-make/build/ggcnativebuild/mpc-1.0.1

--with-cloog=/home/tcbuild/toolchain-make/build/ggcnativebuild/cloog-ppl-0.15.11

--with-ppl=/home/tcbuild/toolchain-make/build/ggcnativebuild/ppl-0.11

--with-host-libstdcxx='-Wl,-Bstatic,/usr/lib/gcc/i486-linux-gnu/4.4.5/libstdc++.a,/usr/lib/gcc/i486-linux-gnu/4.4.5/libsupc++.a,-Bdynamic

-lm'

Thread model: single

gcc version 4.7.2 (GCC)

[Bug fortran/40881] [F03] warn for obsolescent features

[janus at gcc dot gnu.org]

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



janus at gcc dot gnu.org changed:



   What|Removed |Added



 Status|ASSIGNED|NEW

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

   ||gnu.org



--- Comment #12 from janus at gcc dot gnu.org 2013-04-04 19:28:48 UTC ---

(In reply to comment #9)

> I think the only missing item is the following:

> 

> >(8) Fixed form source

> 

> (I think one should consider to add some flag to silence the fixed-form

> warning. At least I know a lot of code, which is in fixed form but otherwise

> warning free.)



I'm not really sure if it makes sense to add a warning for fixed source, but

I'm leaving this PR open, in case someone will consider it in the future.



For now, I certainly do not plan to work on it, therefore I'll unassign myself.

[Bug fortran/40881] [F03] warn for obsolescent features

[janus at gcc dot gnu.org]

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



--- Comment #11 from janus at gcc dot gnu.org 2013-04-04 19:23:26 UTC ---

http://gcc.gnu.org/viewcvs/gcc?view=revision&revision=197495





2013-04-04  Janus Weil  



PR fortran/40881

* match.c (gfc_match_return): Remove standard notification.

* primary.c (gfc_match_actual_arglist): Add standard notification.





2013-04-04  Janus Weil  



PR fortran/40881

* gfortran.dg/altreturn_1.f90: Add -std=gnu.

* gfortran.dg/altreturn_4.f90: Ditto.

* gfortran.dg/altreturn_3.f90: Replace -std=legacy by -std=gnu.

* gfortran.dg/altreturn_5.f90: Ditto.

* gfortran.dg/altreturn_6.f90: Ditto.

* gfortran.dg/altreturn_7.f90: Ditto.

[Bug fortran/56845] New: [OOP] _vptr not set to declared type for CLASS + SAVE

[burnus at gcc dot gnu.org]

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



 Bug #: 56845

   Summary: [OOP] _vptr not set to declared type for CLASS + SAVE

Classification: Unclassified

   Product: gcc

   Version: 4.9.0

Status: UNCONFIRMED

  Keywords: wrong-code

  Severity: normal

  Priority: P3

 Component: fortran

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

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

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





The program below fails at run time. Unallocated the class should match the

declared type - but it is never set with SAVE.





The dump of the following program shows:

  static struct __class_m_T_a y = {};

Expected:

  static struct __class_m_T_a y = { ._data = 0B, ._vptr = &__vtab_m_T};





module m

type t

integer ::a

end type t

contains

subroutine sub

  type(t), save, allocatable :: x

  class(t), save,allocatable :: y

  if (.not. same_type_as(x,y)) call abort()

end subroutine sub

subroutine sub2

  type(t), save, allocatable :: a(:)

  class(t), save,allocatable :: b(:)

  if (.not. same_type_as(a,b)) call abort()

end subroutine sub2

end module m



use m

call sub()

call sub2()

end

[Bug tree-optimization/56830] [4.8 regression] internal compiler error: verify_ssa failed

[dimhen at gmail dot com]

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



--- Comment #8 from Dmitry G. Dyachenko  2013-04-04 
18:50:49 UTC ---

You are right, sounds like PR34949

[Bug tree-optimization/56830] [4.8 regression] internal compiler error: verify_ssa failed

[dimhen at gmail dot com]

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

--- Comment #7 from Dmitry G. Dyachenko  2013-04-04 
18:45:56 UTC ---
strictly speaking this is 'pre-4.8.0' regression

gcc version 4.8.0 20130313 (experimental) [trunk revision 196628] (GCC)

$ /usr/local/gcc_current_196628/bin/g++  -Wall -O1 -fpreprocessed -c 56830.ii 
56830_O1.ii: In instantiation of ‘void H::add_suites() [with T = M]’:
56830_O1.ii:107:25:   required from here
56830_O1.ii:94:12: warning: unused variable ‘s’ [-Wunused-variable]
 T *s = new T;
^

[Bug tree-optimization/56830] [4.8 regression] internal compiler error: verify_ssa failed

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 CC||jakub at gcc dot gnu.org



--- Comment #6 from Jakub Jelinek  2013-04-04 
18:31:57 UTC ---

Why are you marking this 4.8 regression when you are clearly using trunk?

Anyway, sounds like dup or PR34949, I've just posted a fix for that to

gcc-patches.

[Bug c/56113] out of memory when compiling a function with many goto labels (50k > )

[aixer77 at gmail dot com]

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



--- Comment #32 from Kangkook  2013-04-04 18:31:19 
UTC ---

Hi, guys



I have a couple of questions regarding the case. 



i) What is the current status of the fix? is this fixed or still open? 



ii) If it is fixed, 

  - how many nodes now it can scale?

  - What version of gcc comes with the patch/fix applied?



Thanks a lot for your help!



/Kangkook

[Bug tree-optimization/56830] stl_vector.h:414:7: internal compiler error: verify_ssa failed

[dimhen at gmail dot com]

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

--- Comment #5 from Dmitry G. Dyachenko  2013-04-04 
18:27:23 UTC ---
Created attachment 29806
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29806
ICE with -O1 only

$ g++ -Wall -O1 -fpreprocessed -c 56830.ii
56830.ii: In instantiation of ‘void H::add_suites() [with T = M]’:
56830.ii:107:25:   required from here
56830.ii:94:12: warning: unused variable ‘s’ [-Wunused-variable]
 T *s = new T;
^
56830.ii: In function ‘int main()’:
56830.ii:104:5: error: definition in block 3 does not dominate use in block 7
 int main ()
 ^
for SSA_NAME: _8 in statement:
# .MEM_30 = VDEF <.MEM_15>
MEM[(struct F *)_8] ={v} {CLOBBER};
56830.ii:104:5: internal compiler error: verify_ssa failed
0xbe1b4c verify_ssa(bool)
/home/dimhen/src/gcc-current/gcc/tree-ssa.c:1046
0x9c4ca1 execute_function_todo
/home/dimhen/src/gcc-current/gcc/passes.c:1964
0x9c5537 execute_todo
/home/dimhen/src/gcc-current/gcc/passes.c:1996
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug tree-optimization/56812] Simple loop is not SLP-vectorized after r196872

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

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



--- Comment #10 from Andreas Schwab  2013-04-04 17:24:14 
UTC ---

Yes, that will skip the test.

[Bug c++/53786] [C++11] alias template - error on valid code

[jason at gcc dot gnu.org]

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



Jason Merrill  changed:



   What|Removed |Added



   Keywords||ice-on-invalid-code



--- Comment #7 from Jason Merrill  2013-04-04 
16:55:32 UTC ---

This looks like issue 1430:



  http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1430



As in the example in the issue description, here there is no way to express

tail_ in terms of list and types, so I think this will also be

ill-formed.  Other people on the committee seem to agree with me.



Of course, we shouldn't ICE.

[Bug lto/56840] a.out aborts instead of catching exception with -flto and -static-libstdc++

[ian at airs dot com]

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



Ian Lance Taylor  changed:



   What|Removed |Added



 Status|NEW |RESOLVED

 CC||ian at airs dot com

 Resolution||FIXED



--- Comment #3 from Ian Lance Taylor  2013-04-04 16:52:35 
UTC ---

Yes, it's a bug in gold in the handling of .eh_frame sections in archives when

using a plugin.  I just committed a patch to gold:

http://sourceware.org/ml/binutils/2013-04/msg00026.html .  Unfortunately this

patch probably won't be in a released version of the GNU binutils for a while.



I don't know why this worked with GCC 4.7.  I haven't looked into it.

[Bug regression/56844] Loop condition wrongly optimized from < to !=

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 CC||jakub at gcc dot gnu.org



--- Comment #3 from Jakub Jelinek  2013-04-04 
16:43:03 UTC ---

You can work around it in this case with -fno-aggressive-loop-optimizations,

though obviously it is much better to fix up the broken code.

The reason why we don't warn about this with -Waggressive-loop-optimizations is

that due to the && in the loop condition the loop doesn't have a single exit.

[Bug regression/56844] Loop condition wrongly optimized from < to !=

[pinskia at gcc dot gnu.org]

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



Andrew Pinski  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||INVALID



--- Comment #2 from Andrew Pinski  2013-04-04 
16:38:41 UTC ---

>( str[i] != '\0' ) && ( i < 16 )



You access str[16] which is undefined behavior.  Switch around the check for i

and str[i] will work correctly.



That is:

  for( i = 0;  ( i < 16 ) && ( str[i] != '\0' ); i++ );

[Bug regression/56844] Loop condition wrongly optimized from < to !=

[steven at gcc dot gnu.org]

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



--- Comment #1 from Steven Bosscher  2013-04-04 
16:33:50 UTC ---

Smells like http://blog.regehr.org/archives/918

[Bug regression/56844] New: Loop condition wrongly optimized from < to !=

[holger.hopp at sap dot com]

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



 Bug #: 56844

   Summary: Loop condition wrongly optimized from < to !=

Classification: Unclassified

   Product: gcc

   Version: 4.8.1

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: regression

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

ReportedBy: holger.h...@sap.com





Following code is optimized  wrong with gcc-4.8 -O2.

It works correct with gcc-4.8 -O1 and gcc-4.7 -O2.

Somehow the 'i < 16' condition of the second loop is optimized to 'i != 16'

(runs second loop until segfault / stack overflow).



[gcc-4_8-branch revision 197479, x86_64]



int printf (const char *format, ...);

char* strncpy (char * dest, const char * src, unsigned long n);



int main()

{

  int i;

  char str[16];



  strncpy( str, "abcdefghijklmnop", 16 );

  for( i = 0; ( str[i] != '\0' ) && ( i < 16 ); i++ );

  for( ; i < 16; i++ ) str[i] = ' ';

  printf ("str = \"%s\"\n", str);

  return 0;

}

[Bug c++/56838] GCC svn doesn't compile libreoffice 4.0.1.2

[mustrumr97 at gmail dot com]

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



--- Comment #2 from Hristo Venev  2013-04-04 
16:17:04 UTC ---

The candidate in /usr/include/boost/bind/bind.hpp:1478 a.cpp:92092 fails.

SFINAE so this candidate is skipped.

However the one in /usr/include/boost/bind/bind_cc.hpp:35 a.cpp:92176 would

instantiate successfully. I think this is the one called by gcc 4.8.0.

[Bug target/56843] PowerPC Newton-Raphson reciprocal estimates can be improved

[wschmidt at gcc dot gnu.org]

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



--- Comment #2 from Bill Schmidt  2013-04-04 
16:12:31 UTC ---

Regarding the last point, I found this in the user manual:



"The double-precision square root estimate instructions are not generated by

default on low-precision machines, since they do not provide an estimate that

converges after three steps."



That seems to indicate someone decided the libcall is better than a four-step

iteration.  That doesn't necessarily seem obvious to me.

[Bug driver/46501] Relocatable toolchains still search --prefix

[joe at oampo dot co.uk]

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



Joe Turner  changed:



   What|Removed |Added



 CC||joe at oampo dot co.uk



--- Comment #3 from Joe Turner  2013-04-04 16:03:46 UTC 
---

A quick note to confirm that this is still a problem.  It just caught me out

when building in a subfolder of my home directory, and relocating the build to

a server where access to /home is restricted.  This caused the compiler to

throw permission denied errors when searching the --prefix path.

[Bug libstdc++/56841] [4.9 Regression] ld: Unsatisfied symbol "__atomic_exchange_8" in file /test/gnu/gcc/objdir/prev-hppa64-hp-hpux11.11/libstdc++-v3/src/.libs/libstdc++.a[eh_terminate.o]

[dave.anglin at bell dot net]

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



--- Comment #2 from dave.anglin at bell dot net 2013-04-04 15:57:16 UTC ---

On 4-Apr-13, at 11:41 AM, redi at gcc dot gnu.org wrote:



> Drat, I completely forgot these still aren't available everywhere,  

> sorry.



There's some kind of implementation in libatomic but it hasn't been  

built

when the error occurs.



--

John David Anglindave.ang...@bell.net

[Bug tree-optimization/48186] ICE: SIGFPE (division by zero) in maybe_hot_frequency_p at predict.c:129 with --param hot-bb-frequency-fraction=0 on basic code

[mpolacek at gcc dot gnu.org]

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



Marek Polacek  changed:



   What|Removed |Added



 Status|ASSIGNED|RESOLVED

 Resolution||FIXED



--- Comment #6 from Marek Polacek  2013-04-04 
15:53:56 UTC ---

Fixed.

[Bug tree-optimization/48186] ICE: SIGFPE (division by zero) in maybe_hot_frequency_p at predict.c:129 with --param hot-bb-frequency-fraction=0 on basic code

[mpolacek at gcc dot gnu.org]

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



--- Comment #5 from Marek Polacek  2013-04-04 
15:53:25 UTC ---

Author: mpolacek

Date: Thu Apr  4 15:52:54 2013

New Revision: 197488



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

Log:

PR tree-optimization/48186

* predict.c (maybe_hot_frequency_p): Return false if

HOT_BB_FREQUENCY_FRACTION is 0.

(cgraph_maybe_hot_edge_p): Likewise.



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



Added:

branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/pr48186.c

Modified:

branches/gcc-4_8-branch/gcc/ChangeLog

branches/gcc-4_8-branch/gcc/predict.c

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

[Bug tree-optimization/48186] ICE: SIGFPE (division by zero) in maybe_hot_frequency_p at predict.c:129 with --param hot-bb-frequency-fraction=0 on basic code

[dominiq at lps dot ens.fr]

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



Dominique d'Humieres  changed:



   What|Removed |Added



 CC||dominiq at lps dot ens.fr



--- Comment #4 from Dominique d'Humieres  2013-04-04 
15:52:12 UTC ---

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

[Bug middle-end/40119] ICE with --param hot-bb-frequency-fraction=0

[dominiq at lps dot ens.fr]

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



Dominique d'Humieres  changed:



   What|Removed |Added



 Status|ASSIGNED|RESOLVED

 Resolution||DUPLICATE



--- Comment #4 from Dominique d'Humieres  2013-04-04 
15:52:12 UTC ---

Duplicate of 48186.



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

[Bug tree-optimization/48186] ICE: SIGFPE (division by zero) in maybe_hot_frequency_p at predict.c:129 with --param hot-bb-frequency-fraction=0 on basic code

[mpolacek at gcc dot gnu.org]

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



--- Comment #3 from Marek Polacek  2013-04-04 
15:49:00 UTC ---

Author: mpolacek

Date: Thu Apr  4 15:48:25 2013

New Revision: 197487



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

Log:

PR tree-optimization/48186

* predict.c (maybe_hot_frequency_p): Return false if

HOT_BB_FREQUENCY_FRACTION is 0.

(cgraph_maybe_hot_edge_p): Likewise.



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



Added:

trunk/gcc/testsuite/gcc.dg/pr48186.c

Modified:

trunk/gcc/ChangeLog

trunk/gcc/predict.c

trunk/gcc/testsuite/ChangeLog

[Bug libstdc++/56841] [4.9 Regression] ld: Unsatisfied symbol "__atomic_exchange_8" in file /test/gnu/gcc/objdir/prev-hppa64-hp-hpux11.11/libstdc++-v3/src/.libs/libstdc++.a[eh_terminate.o]

[redi at gcc dot gnu.org]

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



Jonathan Wakely  changed:



   What|Removed |Added



 Status|UNCONFIRMED |ASSIGNED

   Last reconfirmed||2013-04-04

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

   |gnu.org |

 Ever Confirmed|0   |1



--- Comment #1 from Jonathan Wakely  2013-04-04 
15:41:32 UTC ---

Drat, I completely forgot these still aren't available everywhere, sorry.



I'll fix it later today by keeping the accessors but making them fall back to

using locks when the atomic ops aren't supported.

[Bug target/56843] PowerPC Newton-Raphson reciprocal estimates can be improved

[dje at gcc dot gnu.org]

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



David Edelsohn  changed:



   What|Removed |Added



 Target|powerpc64-unknown-linux-gnu |powerpc*-*-*

 Status|UNCONFIRMED |NEW

   Last reconfirmed||2013-04-04

 CC||dje at gcc dot gnu.org

   Host|powerpc64-unknown-linux-gnu |powerpc*-*-*

   Target Milestone|--- |4.9.0

 Ever Confirmed|0   |1

  Build|powerpc64-unknown-linux-gnu |powerpc*-*-*



--- Comment #1 from David Edelsohn  2013-04-04 15:09:17 
UTC ---

Confirmed.

[Bug tree-optimization/56826] [4.9 Regression] Run-fail after r197189.

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 Status|ASSIGNED|RESOLVED

 Resolution||FIXED



--- Comment #5 from Richard Biener  2013-04-04 
15:07:00 UTC ---

Author: rguenth

Date: Thu Apr  4 15:06:44 2013

New Revision: 197486



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

Log:

2013-04-04  Richard Biener  



PR tree-optimization/56826

* tree-vect-slp.c (vect_build_slp_tree): Compute ncopies

more accurately.



* gcc.dg/vect/pr56826.c: New testcase.

* gcc.dg/vect/O3-pr36098.c: Adjust.



Added:

trunk/gcc/testsuite/gcc.dg/vect/pr56826.c

Modified:

trunk/gcc/ChangeLog

trunk/gcc/testsuite/ChangeLog

trunk/gcc/testsuite/gcc.dg/vect/O3-pr36098.c

trunk/gcc/tree-vect-slp.c

[Bug target/56843] New: PowerPC Newton-Raphson reciprocal estimates can be improved

[wschmidt at gcc dot gnu.org]

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



 Bug #: 56843

   Summary: PowerPC Newton-Raphson reciprocal estimates can be

improved

Classification: Unclassified

   Product: gcc

   Version: 4.9.0

Status: UNCONFIRMED

  Keywords: missed-optimization

  Severity: normal

  Priority: P3

 Component: target

AssignedTo: wschm...@gcc.gnu.org

ReportedBy: wschm...@gcc.gnu.org

  Host: powerpc64-unknown-linux-gnu

Target: powerpc64-unknown-linux-gnu

 Build: powerpc64-unknown-linux-gnu





It was recently brought to my attention that the number of Newton-Raphson

iterations for floating reciprocal-estimate and floating

recriprocal-sqrt-estimate can be tightened.  In particular, for 32-bit

floating-point values targeting processors having higher precision estimates, a

single iteration should suffice to produce maximum representable precision.  We

currently perform two.  We should verify that one is actually sufficient in

practice.



We should also investigate whether 3 iterations is sufficient for 64-bit

floating-point values when targeting processors having lower precision

estimates.  The theoretical math suggests 4 may be necessary, but this could be

too conservative in practice as this is derived from a general bound on the

method.

[Bug tree-optimization/48186] ICE: SIGFPE (division by zero) in maybe_hot_frequency_p at predict.c:129 with --param hot-bb-frequency-fraction=0 on basic code

[mpolacek at gcc dot gnu.org]

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



Marek Polacek  changed:



   What|Removed |Added



 Status|NEW |ASSIGNED

 CC||mpolacek at gcc dot gnu.org

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

   |gnu.org |



--- Comment #2 from Marek Polacek  2013-04-04 
14:51:20 UTC ---

I have a patch.

[Bug c++/56840] a.out aborts instead of catching exception with -flto and -static-libstdc++

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2013-04-04

 CC||iant at google dot com

   Host|CentOS release 6.4 (Final)  |

   |x86_64 GNU/Linux|

 Ever Confirmed|0   |1



--- Comment #2 from Richard Biener  2013-04-04 
14:39:30 UTC ---

Confirmed with using gold, works when using GNU ld (2.23.1).  This is probably

a linker issue then.



Ian?



gold:



1

t.o 16

165 46dc27f64f5c9b0d PREVAILING_DEF_IRONLY _ZN4MyExD2Ev

185 46dc27f64f5c9b0d PREVAILING_DEF_IRONLY _ZTV4MyEx

237 46dc27f64f5c9b0d PREVAILING_DEF_IRONLY _ZN4MyExD1Ev

246 46dc27f64f5c9b0d PREVAILING_DEF_IRONLY _ZN4MyExD0Ev

255 46dc27f64f5c9b0d PREVAILING_DEF_IRONLY _ZN4MyExC2Ev

261 46dc27f64f5c9b0d PREVAILING_DEF_IRONLY _ZN4MyExC1Ev

266 46dc27f64f5c9b0d PREVAILING_DEF main

209 46dc27f64f5c9b0d PREVAILING_DEF_IRONLY _ZTI4MyEx

232 46dc27f64f5c9b0d PREVAILING_DEF_IRONLY _ZTS4MyEx

269 46dc27f64f5c9b0d RESOLVED_EXEC __gxx_personality_v0

220 46dc27f64f5c9b0d RESOLVED_EXEC _ZTVN10__cxxabiv117__class_type_infoE

276 46dc27f64f5c9b0d RESOLVED_EXEC _ZdlPv

283 46dc27f64f5c9b0d RESOLVED_EXEC __cxa_end_catch

287 46dc27f64f5c9b0d RESOLVED_EXEC __cxa_begin_catch

293 46dc27f64f5c9b0d RESOLVED_EXEC __cxa_throw

301 46dc27f64f5c9b0d RESOLVED_EXEC __cxa_allocate_exception



bfd:



1

t.o 16

165 4ce296565b57ee97 PREVAILING_DEF_IRONLY _ZN4MyExD2Ev

185 4ce296565b57ee97 PREVAILING_DEF_IRONLY _ZTV4MyEx

237 4ce296565b57ee97 PREVAILING_DEF_IRONLY _ZN4MyExD1Ev

246 4ce296565b57ee97 PREVAILING_DEF_IRONLY _ZN4MyExD0Ev

255 4ce296565b57ee97 PREVAILING_DEF_IRONLY _ZN4MyExC2Ev

261 4ce296565b57ee97 PREVAILING_DEF_IRONLY _ZN4MyExC1Ev

266 4ce296565b57ee97 PREVAILING_DEF main

209 4ce296565b57ee97 PREVAILING_DEF_IRONLY _ZTI4MyEx

232 4ce296565b57ee97 PREVAILING_DEF_IRONLY _ZTS4MyEx

269 4ce296565b57ee97 RESOLVED_EXEC __gxx_personality_v0

220 4ce296565b57ee97 RESOLVED_EXEC _ZTVN10__cxxabiv117__class_type_infoE

276 4ce296565b57ee97 RESOLVED_EXEC _ZdlPv

283 4ce296565b57ee97 RESOLVED_EXEC __cxa_end_catch

287 4ce296565b57ee97 RESOLVED_EXEC __cxa_begin_catch

293 4ce296565b57ee97 RESOLVED_EXEC __cxa_throw

301 4ce296565b57ee97 RESOLVED_EXEC __cxa_allocate_exception



so we probably produce the same LTRANS units for the same link.

[Bug c++/56840] a.out aborts instead of catching exception with -flto and -static-libstdc++

[w...@trash-mail.com]

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



--- Comment #1 from Werner  2013-04-04 14:36:39 UTC ---

Created attachment 29805

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

generated with c++ -save-temps

[Bug c++/56842] New: Argument deduction failure note is empty for alias template

[redi at gcc dot gnu.org]

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



 Bug #: 56842

   Summary: Argument deduction failure note is empty for alias

template

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Keywords: diagnostic

  Severity: normal

  Priority: P3

 Component: c++

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

ReportedBy: r...@gcc.gnu.org





For this code:



#include 



struct Base { };



template

struct Constraint1

: std::enable_if::value>

{ };



template ::type>

void foo() { }



struct A { };



int main()

{

foo();

}



GCC gives an excellent diagnostic:



b.cc: In function 'int main()':

b.cc:18:12: error: no matching function for call to 'foo()'

 foo();

^

b.cc:18:12: note: candidate is:

b.cc:12:6: note: template void foo()

 void foo() { }

  ^

b.cc:12:6: note:   template argument deduction/substitution failed:

b.cc:11:10: error: no type named 'type' in 'struct Constraint1'

  typename Requires = typename Constraint1::type>

  ^



However after changing it to use an alias template, which makes the declaration

of bar() much easier to read:



#include 



struct Base { };



template

  using Constraint2

= typename std::enable_if::value>::type;



template >

void bar() { }



struct A { };



int main()

{

bar();

}



GCC produces a useless diagnostic:



b.cc: In function 'int main()':

b.cc:16:12: error: no matching function for call to 'bar()'

 bar();

^

b.cc:16:12: note: candidate is:

b.cc:10:6: note: template void bar()

 void bar() { }

  ^

b.cc:10:6: note:   template argument deduction/substitution failed:

[Bug libstdc++/56841] New: [4.9 Regression] ld: Unsatisfied symbol "__atomic_exchange_8" in file /test/gnu/gcc/objdir/prev-hppa64-hp-hpux11.11/libstdc++-v3/src/.libs/libstdc++.a[eh_terminate.o]

[danglin at gcc dot gnu.org]

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



 Bug #: 56841

   Summary: [4.9 Regression] ld: Unsatisfied symbol

"__atomic_exchange_8" in file

/test/gnu/gcc/objdir/prev-hppa64-hp-hpux11.11/libstdc+

+-v3/src/.libs/libstdc++.a[eh_terminate.o]

Classification: Unclassified

   Product: gcc

   Version: 4.9.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: libstdc++

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

ReportedBy: dang...@gcc.gnu.org

CC: r...@gcc.gnu.org

  Host: hppa64-hp-hpux11.11

Target: hppa64-hp-hpux11.11

 Build: hppa64-hp-hpux11.11





/test/gnu/gcc/objdir/./prev-gcc/xg++ -B/test/gnu/gcc/objdir/./prev-gcc/

-B/opt/g

nu64/gcc/gcc-4.8/hppa64-hp-hpux11.11/bin/ -nostdinc++

-B/test/gnu/gcc/objdir/prev-hppa64-hp-hpux11.11/libstdc++-v3/src/.libs

-B/test/gnu/gcc/objdir/prev-hppa64-

hp-hpux11.11/libstdc++-v3/libsupc++/.libs

-I/test/gnu/gcc/objdir/prev-hppa64-hp-hpux11.11/libstdc++-v3/include/hppa64-hp-hpux11.11

-I/test/gnu/gcc/objdir/prev-hppa64-hp-hpux11.11/libstdc++-v3/include

-I/test/gnu/gcc/gcc/libstdc++-v3/libsupc

++ -L/test/gnu/gcc/objdir/prev-hppa64-hp-hpux11.11/libstdc++-v3/src/.libs

-L/tes

t/gnu/gcc/objdir/prev-hppa64-hp-hpux11.11/libstdc++-v3/libsupc++/.libs   -g -O2

-DIN_GCC   -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall

-Wno-

narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic

-Wno-

long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common 

-DHA

VE_CONFIG_H -static-libstdc++ -static-libgcc  -o cpp gcc.o ggc-none.o \

  c-family/cppspec.o  libcommon-target.a \

   libcommon.a ../libcpp/libcpp.a  

../libbacktrace/.libs/libbacktrace.a

 ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a 

ld: Unsatisfied symbol "ld: Unsatisfied symbol "__atomic_exchange_8" in file

/te

st/gnu/gcc/objdir/prev-hppa64-hp-hpux11.11/libstdc++-v3/src/.libs/libstdc++.a[eh

_terminate.o]

1 errors.

__atomic_exchange_8" in file

/test/gnu/gcc/objdir/prev-hppa64-hp-hpux11.11/libst

dc++-v3/src/.libs/libstdc++.a[eh_terminate.o]

1 errors.

collect2: error: ld returned 1 exit status

collect2: error: ld returned 1 exit status

make[3]: *** [xgcc] Error 1

make[3]: *** Waiting for unfinished jobs

make[3]: *** [cpp] Error 1

rm cpp.pod gfdl.pod gcov.pod fsf-funding.pod gcc.pod

make[3]: Leaving directory `/test/gnu/gcc/objdir/gcc'

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

make[2]: Leaving directory `/test/gnu/gcc/objdir'

make[1]: *** [stage2-bubble] Error 2

make[1]: Leaving directory `/test/gnu/gcc/objdir'

make: *** [bootstrap] Error 2

Thu Apr  4 02:15:38 EDT 2013

[Bug c++/56840] New: a.out aborts instead of catching exception with -flto and -static-libstdc++

[w...@trash-mail.com]

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



 Bug #: 56840

   Summary: a.out aborts instead of catching exception with -flto

and -static-libstdc++

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: c++

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

ReportedBy: w...@trash-mail.com

  Host: CentOS release 6.4 (Final)  x86_64 GNU/Linux

Target: x86_64-unknown-linux-gnu





Created attachment 29804

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

c++ program to demonstrate misbehavior



$ c++ -v

Using built-in specs.

COLLECT_GCC=c++

COLLECT_LTO_WRAPPER=/usr/local64/gcc-4.8.0/libexec/gcc/x86_64-unknown-linux-gnu/4.8.0/lto-wrapper

Target: x86_64-unknown-linux-gnu

Configured with: ../gcc-4.8.0/configure --prefix=/usr/local64/gcc-4.8.0

--disable-nls --enable-threads=posix --enable-__cxa_atexit --enable-gold

--with-plugin-ld=ld.gold --enable-languages=c,c++,fortran

--with-arch-32=pentium-mmx

Thread model: posix

gcc version 4.8.0 (GCC)



GNU C (GCC) version 4.8.0 (x86_64-unknown-linux-gnu)

compiled by GNU C version 4.8.0, GMP version 5.1.1, MPFR version 3.1.2,

MPC version 1.0.1

GNU ld (GNU Binutils) 2.23.1



/**/

/*  otto407.c  /

#include 



class MyEx

{

 public:

MyEx() {}

virtual ~MyEx() {}

};



int main(void)

{

  try

  {

throw MyEx();

  }

  catch(MyEx&)

  {

printf("caught MyEx\n");

  }

  catch(...)

  {

printf("caught ...\n");

  }



  return 0;

}

/**/



$ c++ -flto otto407.c -static-libstdc++

$ ./a.out

terminate called after throwing an instance of 'MyEx'

terminate called recursively

Aborted (core dumped)



works as expected when omitting -flto or -static-libstdc++

works as expected with gcc-4.7.2 and gcc-4.5.4

[Bug c++/56838] GCC svn doesn't compile libreoffice 4.0.1.2

[jason at gcc dot gnu.org]

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



Jason Merrill  changed:



   What|Removed |Added



 CC||jason at gcc dot gnu.org



--- Comment #1 from Jason Merrill  2013-04-04 
13:46:04 UTC ---

GCC 4.8.0 also accepts this testcase.



The problem on the trunk is that G++ has started instantiating return types in

order to cause a substitution failure if the return type is an abstract class.



In this case, we've deduced template arguments for boost::bind(F, A1, A2) and

are substituting them in to produce a candidate; we haven't selected a

candidate yet.



During the substitution, we instantiate boost::_bi::bind_t to determine whether

it is abstract, and this leads to the error you're seeing.



This is new behavior for G++, but it seems to be what the standard requires. 

But perhaps that's a defect.  It certainly seems to be causing headaches.

[Bug tree-optimization/48304] ICE: SIGFPE (division by zero) in maybe_hot_count_p at predict.c:145 with --param hot-bb-count-fraction=0 -fprofile-use

[mpolacek at gcc dot gnu.org]

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



Marek Polacek  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2013-04-04

 CC||mpolacek at gcc dot gnu.org

 Ever Confirmed|0   |1

  Known to fail|4.7.0   |4.6.4, 4.7.3



--- Comment #1 from Marek Polacek  2013-04-04 
13:35:58 UTC ---

4.6/4.7 only; HOT_BB_COUNT_FRACTION parameter was removed in 4.8.

[Bug tree-optimization/56213] strided load vectorization is unnecessarily restricted

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 Status|ASSIGNED|RESOLVED

 Resolution||FIXED

   Target Milestone|--- |4.9.0



--- Comment #3 from Richard Biener  2013-04-04 
13:02:41 UTC ---

Author: rguenth

Date: Thu Apr  4 12:19:30 2013

New Revision: 197480



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

Log:

2013-04-04  Richard Biener  



PR tree-optimization/56213

* tree-vect-data-refs.c (vect_check_strided_load): Remove.

(vect_analyze_data_refs): Allow all non-nested loads as

strided loads.



* gcc.dg/vect/vect-123.c: New testcase.



Added:

trunk/gcc/testsuite/gcc.dg/vect/vect-123.c

Modified:

trunk/gcc/ChangeLog

trunk/gcc/testsuite/ChangeLog

trunk/gcc/tree-vect-data-refs.c

[Bug c++/34949] Dead code in empty destructors.

[jakub at gcc dot gnu.org]

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



--- Comment #31 from Jakub Jelinek  2013-04-04 
12:52:36 UTC ---

Created attachment 29803

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

gcc49-pr34949.patch



Untested fix (and enhancement too).

[Bug c++/56728] [4.8/4.9 Regression] ICE using constexpr initialization and arrays

[paolo.carlini at oracle dot com]

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



--- Comment #6 from Paolo Carlini  2013-04-04 
12:50:25 UTC ---

Thanks Jason. Damn, we badly need to restore svn commit logs going

automatically to Bugzilla.

[Bug c++/56728] [4.8/4.9 Regression] ICE using constexpr initialization and arrays

[jason at gcc dot gnu.org]

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



--- Comment #5 from Jason Merrill  2013-04-04 
12:28:49 UTC ---

(In reply to comment #4)

> If it's fixed for 4.8.1 it's obviously fixed in mainline too. We don't ICE

> anymore, we simply reject the snippet due to the reinterpret_cast from integer

> to pointer.



The change to reject the invalid constexpr function is only on the trunk; only

the ICE is fixed in 4.8.1.

[Bug middle-end/52436] BIT_FIELD_REF > should be canonicalized for non-bitfield accesses

[glisse at gcc dot gnu.org]

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



--- Comment #7 from Marc Glisse  2013-04-04 12:07:53 
UTC ---

For the rest of the discussion, see the thread starting here:

http://gcc.gnu.org/ml/gcc-patches/2013-04/msg00169.html



In particular, the folding should be done in gimple only (most likely

maybe_fold_reference) and test !is_gimple_reg().

[Bug tree-optimization/48184] ICE: SIGFPE (division by zero) in compute_alignments () at final.c:731 with --param align-threshold=0 on basic code

[mpolacek at gcc dot gnu.org]

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



Marek Polacek  changed:



   What|Removed |Added



 Status|NEW |ASSIGNED

 CC||mpolacek at gcc dot gnu.org

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

   |gnu.org |



--- Comment #2 from Marek Polacek  2013-04-04 
12:05:39 UTC ---

Mine.

[Bug sanitizer/56781] boostrap-asan failure: fixincl fails to link (missing -lasan)

[aldot at gcc dot gnu.org]

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



--- Comment #2 from Bernhard Reutner-Fischer  
2013-04-04 11:41:08 UTC ---

(In reply to comment #1)

> Please try

> 

> http://gcc.gnu.org/git/?p=gcc.git;a=commit;h=61be6ebfe22f9ce5799dac2679541911eb744a86

> http://gcc.gnu.org/git/?p=gcc.git;a=commit;h=6b526a34a0bc852461cb50636c6e757bf8e27faf



I don't think that the above is the correct thing to do;

Shouldn't the post-stage1 libs be built with and linked against asan?

Like (i know that this is a generated file) below which reinstates bootstrap:



diff --git a/Makefile.in b/Makefile.in

index 08049de..52249a0 100644

--- a/Makefile.in

+++ b/Makefile.in

@@ -7786,7 +7786,7 @@ configure-fixincludes:

s=`cd $(srcdir); ${PWD_COMMAND}`; export s; \

test ! -f $(HOST_SUBDIR)/fixincludes/Makefile || exit 0; \

$(SHELL) $(srcdir)/mkinstalldirs $(HOST_SUBDIR)/fixincludes ; \

-   $(HOST_EXPORTS)  \

+   $(POSTSTAGE1_HOST_EXPORTS)  \

echo Configuring in $(HOST_SUBDIR)/fixincludes; \

cd "$(HOST_SUBDIR)/fixincludes" || exit 1; \

case $(srcdir) in \

@@ -7818,7 +7818,7 @@ all-fixincludes: configure-fixincludes

@: $(MAKE); $(unstage)

@r=`${PWD_COMMAND}`; export r; \

s=`cd $(srcdir); ${PWD_COMMAND}`; export s; \

-   $(HOST_EXPORTS)  \

+   $(POSTSTAGE1_HOST_EXPORTS)  \

(cd $(HOST_SUBDIR)/fixincludes && \

  $(MAKE) $(BASE_FLAGS_TO_PASS) $(EXTRA_HOST_FLAGS)

$(STAGE1_FLAGS_TO_PASS)  \

$(TARGET-fixincludes))

@@ -7836,7 +7836,7 @@ check-fixincludes:

@: $(MAKE); $(unstage)

@r=`${PWD_COMMAND}`; export r; \

s=`cd $(srcdir); ${PWD_COMMAND}`; export s; \

-   $(HOST_EXPORTS) \

+   $(POSTSTAGE1_HOST_EXPORTS) \

(cd $(HOST_SUBDIR)/fixincludes && \

  $(MAKE) $(FLAGS_TO_PASS)  check)



@@ -7851,7 +7851,7 @@ install-fixincludes: installdirs

@: $(MAKE); $(unstage)

@r=`${PWD_COMMAND}`; export r; \

s=`cd $(srcdir); ${PWD_COMMAND}`; export s; \

-   $(HOST_EXPORTS) \

+   $(POSTSTAGE1_HOST_EXPORTS) \

(cd $(HOST_SUBDIR)/fixincludes && \

  $(MAKE) $(FLAGS_TO_PASS)  install)



@@ -7866,7 +7866,7 @@ install-strip-fixincludes: installdirs

@: $(MAKE); $(unstage)

@r=`${PWD_COMMAND}`; export r; \

s=`cd $(srcdir); ${PWD_COMMAND}`; export s; \

-   $(HOST_EXPORTS) \

+   $(POSTSTAGE1_HOST_EXPORTS) \

(cd $(HOST_SUBDIR)/fixincludes && \

  $(MAKE) $(FLAGS_TO_PASS)  install-strip)

[Bug tree-optimization/56826] [4.9 Regression] Run-fail after r197189.

[rguenth at gcc dot gnu.org]

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



--- Comment #4 from Richard Biener  2013-04-04 
11:41:03 UTC ---

Ok, the bug is that 'ncopies' in vect_build_slp_tree is not computed correctly.

I can trivially incrementally improve it but the ultimate fix is to delay

the checks done for vectorizing SLP loads / stores to after the whole SLP

tree is built and thus all types participating in the SLP are known and we

can compute the final unroll factor (in vect_make_slp_decision).



Thus, I'll push the trivial improvement for now, the real fix will follow

a SLP tree build re-org I am planning for next week anyway.

[Bug libfortran/56810] record-repeat fails kind check on complex read

[burnus at gcc dot gnu.org]

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



Tobias Burnus  changed:



   What|Removed |Added



 Status|NEW |RESOLVED

 Resolution||FIXED



--- Comment #3 from Tobias Burnus  2013-04-04 
11:25:21 UTC ---

FIXED on the trunk (= GCC 4.9).



Thanks for the report!

[Bug libfortran/56810] record-repeat fails kind check on complex read

[burnus at gcc dot gnu.org]

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



--- Comment #2 from Tobias Burnus  2013-04-04 
11:24:58 UTC ---

Author: burnus

Date: Thu Apr  4 11:24:15 2013

New Revision: 197479



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

Log:

2013-04-04  Tobias Burnus  



PR fortran/56810

* io/list_read.c (check_type): Fix kind checking for COMPLEX.



2013-04-04  Tobias Burnus  



PR fortran/56810

* gfortran.dg/read_repeat_2.f90: New.





Added:

trunk/gcc/testsuite/gfortran.dg/read_repeat_2.f90

Modified:

trunk/gcc/testsuite/ChangeLog

trunk/libgfortran/ChangeLog

trunk/libgfortran/io/list_read.c

[Bug tree-optimization/56826] [4.9 Regression] Run-fail after r197189.

[rguenth at gcc dot gnu.org]

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



--- Comment #3 from Richard Biener  2013-04-04 
11:12:56 UTC ---

Testcase:



extern void abort (void);



typedef struct {

int a[3];

int num;

} t1;

t1 B[100];

int A[300];



void __attribute__((noinline,noclone))

bar (int *A, t1 *B, int n)

{

  int i;

  int *a = A;

  for (i=0; i

[Bug tree-optimization/56826] [4.9 Regression] Run-fail after r197189.

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 Status|UNCONFIRMED |ASSIGNED

   Last reconfirmed||2013-04-04

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

   |gnu.org |

   Target Milestone|--- |4.9.0

Summary|Run-fail after r197189. |[4.9 Regression] Run-fail

   ||after r197189.

 Ever Confirmed|0   |1



--- Comment #2 from Richard Biener  2013-04-04 
11:06:58 UTC ---

Confirmed, mine.

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

[mpolacek at gcc dot gnu.org]

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



--- Comment #12 from Marek Polacek  2013-04-04 
11:05:08 UTC ---

Author: mpolacek

Date: Thu Apr  4 11:03:11 2013

New Revision: 197478



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

Log:

Backported from mainline

2013-01-09  Steven Bosscher  

Jakub Jelinek  



PR tree-optimization/48189

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

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



Added:

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

Modified:

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

branches/gcc-4_6-branch/gcc/predict.c

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

[Bug tree-optimization/56837] -ftree-loop-distribute-patterns generates incorrect code

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 Status|ASSIGNED|RESOLVED

 Resolution||FIXED



--- Comment #4 from Richard Biener  2013-04-04 
11:01:51 UTC ---

Author: rguenth

Date: Thu Apr  4 10:55:25 2013

New Revision: 197476



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

Log:

2013-04-04  Richard Biener  



PR tree-optimization/56837

* tree-loop-distribution.c (classify_partition): For non-zero

values require that the value has the same precision as its

mode to be useful as memset value.



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



Added:

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

Modified:

trunk/gcc/ChangeLog

trunk/gcc/testsuite/ChangeLog

trunk/gcc/tree-loop-distribution.c



Author: rguenth

Date: Thu Apr  4 11:00:45 2013

New Revision: 197477



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

Log:

2013-04-04  Richard Biener  



PR tree-optimization/56837

* tree-loop-distribution.c (classify_partition): For non-zero

values require that the value has the same precision as its

mode to be useful as memset value.



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



Added:

branches/gcc-4_8-branch/gcc/testsuite/g++.dg/torture/pr56837.C

Modified:

branches/gcc-4_8-branch/gcc/ChangeLog

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

branches/gcc-4_8-branch/gcc/tree-loop-distribution.c

[Bug tree-optimization/56213] strided load vectorization is unnecessarily restricted

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 Status|NEW |ASSIGNED

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

   |gnu.org |



--- Comment #2 from Richard Biener  2013-04-04 
10:56:32 UTC ---

Testing a patch.

[Bug go/56839] make check: FAIL: go/types

[mrcs.gcc at mailnull dot com]

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



--- Comment #2 from Markus  2013-04-04 10:50:02 
UTC ---

Build of gcc 4.8.0 with go support worked, but make check failed.

The test which failed is "go/types".

In the description is the relevant part of the output from make check.

[Bug go/56839] make check: FAIL: go/types

[mrcs.gcc at mailnull dot com]

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



Markus  changed:



   What|Removed |Added



   Keywords||build

 Target||Ubuntu Linux 12.10, kernel

   ||3.5.0, x86 32bit

   Host||Ubuntu Linux 12.10, kernel

   ||3.5.0, x86 32bit

  Build||Ubuntu Linux 12.10, kernel

   ||3.5.0, x86 32bit



--- Comment #1 from Markus  2013-04-04 10:43:05 
UTC ---

configuration used for buidling:



../gcc-4.8.0/configure \

 --prefix="$INSTALL_DIR" \

 --enable-languages=c,c++,go \

 --with-mpc="$INSTALL_DIR" \

 --with-mpfr="$INSTALL_DIR" \

 --with-gmp="$INSTALL_DIR" \

 --without-cloog \

 --without-isl \

 --without-ppl \

 --disable-cloog-version-check \

 --disable-ppl-version-check \

 --enable-lto \

 --disable-sjlj-exceptions \

 --enable-libgomp \

 --with-dwarf2 \

 --enable-libstdcxx-debug \

 --enable-concept-checks \

 --enable-version-specific-runtime-libs \

 --without-system-libunwind

[Bug libfortran/56737] [4.6/4.7/4.8/4.9 Regression] Wrong I/O result with format cache for Hollerith strings

[jonathan.hogg at stfc dot ac.uk]

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



--- Comment #12 from Jonathan Hogg  2013-04-04 
10:43:02 UTC ---

Thanks for fixing this. The code in question has been moved to use 'strings'

rather than Hollerith i/o - we aim for it to be F95 compliant anyway!



Jonathan.

[Bug go/56839] New: make check: FAIL: go/types

[mrcs.gcc at mailnull dot com]

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



 Bug #: 56839

   Summary: make check: FAIL: go/types

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: go

AssignedTo: i...@airs.com

ReportedBy: mrcs@mailnull.com





PASS: go/ast

PASS: go/doc

PASS: go/format

PASS: go/parser

PASS: go/printer

PASS: go/scanner

PASS: go/token

--- FAIL: TestGcImport (0.35 seconds)

gcimporter_test.go:63: testPath(./testdata/exports): 10.353ms

gcimporter_test.go:60: testPath(archive/tar): can't find import:

archive/tar

gcimporter_test.go:60: testPath(archive/zip): can't find import:

archive/zip

gcimporter_test.go:60: testPath(bufio): can't find import: bufio

gcimporter_test.go:60: testPath(bytes): can't find import: bytes

gcimporter_test.go:60: testPath(compress/bzip2): can't find import:

compress/bzip2

gcimporter_test.go:60: testPath(compress/flate): can't find import:

compress/flate

gcimporter_test.go:60: testPath(compress/gzip): can't find import:

compress/gzip

gcimporter_test.go:60: testPath(compress/lzw): can't find import:

compress/lzw

gcimporter_test.go:60: testPath(compress/zlib): can't find import:

compress/zlib

gcimporter_test.go:60: testPath(container/heap): can't find import:

container/heap

gcimporter_test.go:60: testPath(container/list): can't find import:

container/list

gcimporter_test.go:60: testPath(container/ring): can't find import:

container/ring

gcimporter_test.go:60: testPath(crypto/aes): can't find import: crypto/aes

gcimporter_test.go:60: testPath(crypto/cipher): can't find import:

crypto/cipher

gcimporter_test.go:60: testPath(crypto/des): can't find import: crypto/des

gcimporter_test.go:60: testPath(crypto/dsa): can't find import: crypto/dsa

gcimporter_test.go:60: testPath(crypto/ecdsa): can't find import:

crypto/ecdsa

gcimporter_test.go:60: testPath(crypto/elliptic): can't find import:

crypto/elliptic

gcimporter_test.go:60: testPath(crypto/hmac): can't find import:

crypto/hmac

gcimporter_test.go:60: testPath(crypto/md5): can't find import: crypto/md5

gcimporter_test.go:60: testPath(crypto/rand): can't find import:

crypto/rand

gcimporter_test.go:60: testPath(crypto/rc4): can't find import: crypto/rc4

gcimporter_test.go:60: testPath(crypto/rsa): can't find import: crypto/rsa

gcimporter_test.go:60: testPath(crypto/sha1): can't find import:

crypto/sha1

gcimporter_test.go:60: testPath(crypto/sha256): can't find import:

crypto/sha256

gcimporter_test.go:60: testPath(crypto/sha512): can't find import:

crypto/sha512

gcimporter_test.go:60: testPath(crypto/subtle): can't find import:

crypto/subtle

gcimporter_test.go:60: testPath(crypto/tls): can't find import: crypto/tls

gcimporter_test.go:60: testPath(crypto/x509/pkix): can't find import:

crypto/x509/pkix

gcimporter_test.go:60: testPath(crypto/x509): can't find import:

crypto/x509

gcimporter_test.go:60: testPath(crypto): can't find import: crypto

gcimporter_test.go:60: testPath(database/sql/driver): can't find import:

database/sql/driver

gcimporter_test.go:60: testPath(database/sql): can't find import:

database/sql

gcimporter_test.go:60: testPath(debug/dwarf): can't find import:

debug/dwarf

gcimporter_test.go:60: testPath(debug/elf): can't find import: debug/elf

gcimporter_test.go:60: testPath(debug/gosym): can't find import:

debug/gosym

gcimporter_test.go:60: testPath(debug/macho): can't find import:

debug/macho

gcimporter_test.go:60: testPath(debug/pe): can't find import: debug/pe

gcimporter_test.go:60: testPath(encoding/ascii85): can't find import:

encoding/ascii85

gcimporter_test.go:60: testPath(encoding/asn1): can't find import:

encoding/asn1

gcimporter_test.go:60: testPath(encoding/base32): can't find import:

encoding/base32

gcimporter_test.go:60: testPath(encoding/base64): can't find import:

encoding/base64

gcimporter_test.go:60: testPath(encoding/binary): can't find import:

encoding/binary

gcimporter_test.go:60: testPath(encoding/csv): can't find import:

encoding/csv

gcimporter_test.go:60: testPath(encoding/gob): can't find import:

encoding/gob

gcimporter_test.go:60: testPath(encoding/hex): can't find import:

encoding/hex

gcimporter_test.go:60: testPath(encoding/json): can't find import:

encoding/json

gcimporter_test.go:60: testPath(encoding/pem): can't find import:

encoding/pem

gcimporter_test.go:60: testPath(encoding/xml): can't find import:

encoding/xml

gcimporter_test.go:60: testPath(errors): can't find import: errors

gcimporter_test.go:60: testPath(expvar): can't find import: expvar

gcimporter_test.go:60: testPath(flag): can't find import: flag

gcimporter_test.g

[Bug c++/56815] void pointer arithmetic

[manu at gcc dot gnu.org]

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

--- Comment #22 from Manuel López-Ibáñez  2013-04-04 
10:38:06 UTC ---
(In reply to comment #21)
> Manuel, I'm adding the LangEnabledBy, to match the documentation. Thanks.
> 
> Now, I'm not sure to understand the existing lines (many):
> 
>   pedantic ? OPT_Wpedantic : OPT_Wpointer_arith
> 
> Do they imply that with -Wpedantic and -Wno-pointer-arith we emit such 
> warnings
> anyway? Is this intended?

I think that is a relic from the past, and it is a bug that -Wno-pointer-arith
does not disable the warning.

I think the intended meaning is that the warnings are controlled by
-Wpointer-arith and -Wpointer-arith is enabled by -Wpedantic, so the above
should simply be warning_at(loc, OPT_Wpointer_arith,) and the following should
work after adding the LangEnabledBy():

-Wpedantic -> warn
-Wpointer-arith -> warn
-Wpedantic -Wno-pointer-arith -> nothing
-Werror=pedantic  -> error
-Wpedantic -Werror=pointer-arith -> error
-Werror=pedantic -Wno-error=pointer-arith -> warn

The problem with warnings enabled by -Wpedantic (such as Wlong-long) is that
they have further special conditions that are not trivial to represent in the
.opt files. In this case, there is:

void
c_common_init_options_struct (struct gcc_options *opts)
{
  opts->x_flag_exceptions = c_dialect_cxx ();
  opts->x_warn_pointer_arith = c_dialect_cxx ();
  opts->x_warn_write_strings = c_dialect_cxx ();
  opts->x_flag_warn_unused_result = true;

  /* By default, C99-like requirements for complex multiply and divide.  */
  opts->x_flag_complex_method = 2;
}

so the warning seems to be enabled by default in C++ (which is not documented
in invoke.texi!). It would be nice to encode this initializations directly in
the .opt file but I guess it should work ok as it is right now (it depends when
this init is called, before or after setting the command-line flags).

[Bug c++/56815] void pointer arithmetic

[paolo.carlini at oracle dot com]

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



--- Comment #21 from Paolo Carlini  2013-04-04 
10:12:11 UTC ---

Manuel, I'm adding the LangEnabledBy, to match the documentation. Thanks.



Now, I'm not sure to understand the existing lines (many):



  pedantic ? OPT_Wpedantic : OPT_Wpointer_arith



Do they imply that with -Wpedantic and -Wno-pointer-arith we emit such warnings

anyway? Is this intended?

[Bug c++/53786] [C++11] alias template - error on valid code

[paolo.carlini at oracle dot com]

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



Paolo Carlini  changed:



   What|Removed |Added



 CC||jason at gcc dot gnu.org



--- Comment #6 from Paolo Carlini  2013-04-04 
10:06:44 UTC ---

All the testcases ICE mainline.

[Bug c++/53786] [C++11] alias template - error on valid code

[mustrumr97 at gmail dot com]

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

Hristo Venev  changed:

   What|Removed |Added

Version|4.7.1   |4.9.0
Summary|[C++11] alias template  |[C++11] alias template -
   |causes g++ segfault |error on valid code

--- Comment #5 from Hristo Venev  2013-04-04 
09:51:45 UTC ---
Now the compiler gives an error on the same code

fail.cpp: In substitution of ‘template using Tail =
List [with T = Ts ...; Ts = {Ts ...}]’:
fail.cpp:6:23:   required from here
fail.cpp:4:23: error: template argument 1 is invalid
 using Tail=List;
   ^
fail.cpp:7:9: error: expected type-specifier before ‘Tail2’
 using A=Tail2;

[Bug c++/56838] New: GCC svn doesn't compile libreoffice 4.0.1.2

[mustrumr97 at gmail dot com]

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

 Bug #: 56838
   Summary: GCC svn doesn't compile libreoffice 4.0.1.2
Classification: Unclassified
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mustrum...@gmail.com


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

This is the command line
x86_64-pc-linux-gnu-g++ -DCPPU_ENV=gcc3 -DENABLE_GRAPHITE -DENABLE_GTK -DGCC
-DHAVE_CXX11_PERFECT_FORWARDING -DHAVE_GCC_BUILTIN_ATOMIC
-DHAVE_THREADSAFE_STATICS -DLIBO_INTERNAL_ONLY -DLINUX -DNDEBUG -DOPTIMIZE
-DOSL_DEBUG_LEVEL=0 -DSOLAR_JAVA -DSUPD=400 -DUNIX -DUNX -DX86_64 -D_PTHREADS
-D_REENTRANT -DFORCE_SYSALLOC -DSAL_DLLIMPLEMENTATION -DRTL_OS="Linux"
-DRTL_ARCH="X86_64" -DHAVE_GCC_VISIBILITY_FEATURE -fvisibility=hidden -Wall
-Wendif-labels -Wextra -fmessage-length=0 -fno-common -pipe
-fvisibility-inlines-hidden -DLIBO_MERGELIBS -fPIC -Wshadow -Wsign-promo
-Woverloaded-virtual -Wnon-virtual-dtor -std=gnu++0x -DEXCEPTIONS_ON
-fexceptions -fno-enforce-eh-specs -O2 -pipe -c
/tmp/libreoffice-4.0.1.2/sal/osl/all/debugbase.cxx -o
/tmp/libreoffice-4.0.1.2/workdir/unxlngx6.pro/CxxObject/sal/osl/all/debugbase.o
-I/tmp/libreoffice-4.0.1.2/sal/osl/all/
-I/tmp/libreoffice-4.0.1.2/solver/unxlngx6.pro/inc/external
-I/tmp/libreoffice-4.0.1.2/solver/unxlngx6.pro/inc
-I/tmp/libreoffice-4.0.1.2/solenv/inc -I/opt/icedtea-bin-7.2.3.8/include
-I/opt/icedtea-bin-7.2.3.8/include/linux
-I/opt/icedtea-bin-7.2.3.8/include/native_threads/include
-I/tmp/libreoffice-4.0.1.2/config -I/tmp/libreoffice-4.0.1.2/sal/inc

Here is the error:
In file included from /usr/include/boost/bind.hpp:22:0,
 from /tmp/libreoffice-4.0.1.2/sal/osl/all/debugbase.cxx:26:
/usr/include/boost/bind/bind.hpp: In instantiation of ‘struct
boost::_bi::result_traits’:
/usr/include/boost/bind/bind_template.hpp:15:48:   required from ‘class
boost::_bi::bind_t, boost::arg<1>
> >’
/usr/include/boost/bind/bind.hpp:1480:5:   required by substitution of
‘template
boost::_bi::bind_t::type> boost::bind(F, A1, A2) [with F = bool
(*)(const char*, const rtl::OString&); A1 = const char*; A2 = boost::arg<1>]’
/tmp/libreoffice-4.0.1.2/sal/osl/all/debugbase.cxx:107:60:   required from here
/usr/include/boost/bind/bind.hpp:69:37: error: ‘bool (*)(const char*, const
rtl::OString&)’ is not a class, struct, or union type

gcc doesn't select the right function overload for boost::bind. clang compiles
this.

[Bug tree-optimization/56812] Simple loop is not SLP-vectorized after r196872

[rguenther at suse dot de]

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



--- Comment #9 from rguenther at suse dot de  
2013-04-04 09:45:27 UTC ---

On Thu, 4 Apr 2013, sch...@linux-m68k.org wrote:



> 

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

> 

> --- Comment #8 from Andreas Schwab  2013-04-04 
> 09:35:51 UTC ---

> The test is failing on ia64:

> 

> $ grep basic slp-pr56812.cc.115t.slp 

> /usr/local/gcc/gcc-20130404/gcc/testsuite/g++.dg/vect/slp-pr56812.cc:16: note:

> not vectorized: unsupported alignment in basic block.



Does adding



/* { dg-require-effective-target vect_hw_misalign } */



work?

[Bug libfortran/56737] [4.6/4.7/4.8/4.9 Regression] Wrong I/O result with format cache for Hollerith strings

[burnus at gcc dot gnu.org]

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



Tobias Burnus  changed:



   What|Removed |Added



 Status|ASSIGNED|RESOLVED

 Resolution||FIXED



--- Comment #11 from Tobias Burnus  2013-04-04 
09:38:53 UTC ---

FIXED on the 4.9 trunk - and on the 4.6, 4.7 and 4.8 branches.



The very soon to be released 4.7.3 and 4.6.4 will contain this fix. (As will

4.8.1, but that take still a while.)



Thanks for the bug report - and sorry for the regression.



You could either upgrade to one of those, e.g. Ubuntu might provide a 4.7.3 in

a few weeks via PPA, cf. http://gcc.gnu.org/wiki/GFortranDistros

Or you build it yourself or use an unofficial binary build, cf.

http://gcc.gnu.org/wiki/GFortranBinaries

Or you replace the H9Hollerith strings by "normal" 'strings' in I/O fmts.

[Bug tree-optimization/56812] Simple loop is not SLP-vectorized after r196872

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

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



--- Comment #8 from Andreas Schwab  2013-04-04 09:35:51 
UTC ---

The test is failing on ia64:



$ grep basic slp-pr56812.cc.115t.slp 

/usr/local/gcc/gcc-20130404/gcc/testsuite/g++.dg/vect/slp-pr56812.cc:16: note:

not vectorized: unsupported alignment in basic block.

[Bug c++/56728] [4.8/4.9 Regression] ICE using constexpr initialization and arrays

[paolo.carlini at oracle dot com]

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



--- Comment #4 from Paolo Carlini  2013-04-04 
09:34:58 UTC ---

If it's fixed for 4.8.1 it's obviously fixed in mainline too. We don't ICE

anymore, we simply reject the snippet due to the reinterpret_cast from integer

to pointer.

[Bug libfortran/56737] [4.6/4.7/4.8/4.9 Regression] Wrong I/O result with format cache for Hollerith strings

[burnus at gcc dot gnu.org]

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



--- Comment #10 from Tobias Burnus  2013-04-04 
09:32:14 UTC ---

Author: burnus

Date: Thu Apr  4 09:31:53 2013

New Revision: 197474



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

Log:

libgfortran/

2013-04-04  Tobias Burnus  



Backport from mainline:

2013-03-29  Tobias Burnus  



PR fortran/56737

* io/format.c (parse_format): With caching, copy

dtp->format string.

(save_parsed_format): Use dtp->format directly without

copying.



2012-03-29  Tobias Burnus  



PR fortran/56737

* io/format.c (parse_format_list): Also cache FMT_STRING.

(parse_format): Update call.



gcc/testsuite/

2013-04-04  Tobias Burnus  



Backport from mainline:

2013-03-29  Tobias Burnus  



PR fortran/56737

* testsuite/gfortran.dg/fmt_cache_3.f90: New.





Added:

branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/fmt_cache_3.f90

Modified:

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

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

branches/gcc-4_6-branch/libgfortran/io/format.c

[Bug c++/34949] Dead code in empty destructors.

[jakub at gcc dot gnu.org]

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



--- Comment #30 from Jakub Jelinek  2013-04-04 
09:20:36 UTC ---

Ah, I guess it is sink_clobbers, which would need to be tought to drop MEM_REF

clobbers instead of sinking them if the target bb is no longer dominated by the

bb with the SSA_NAME definition.

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

[mpolacek at gcc dot gnu.org]

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



Marek Polacek  changed:



   What|Removed |Added



 CC||mpolacek at gcc dot gnu.org

 AssignedTo|hubicka at gcc dot gnu.org  |mpolacek at gcc dot gnu.org



--- Comment #11 from Marek Polacek  2013-04-04 
09:15:55 UTC ---

I'll do the backports.

[Bug c++/56728] [4.8/4.9 Regression] ICE using constexpr initialization and arrays

[npl at chello dot at]

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



--- Comment #3 from npl at chello dot at 2013-04-04 09:13:16 UTC ---

(In reply to comment #2)

> Fixed for 4.8.1.



Is it already in trunk?

Fixed the ICE or disallowing the wrong constexpr - I guess I have a few of

these?

[Bug fortran/56735] [4.6/4.7/4.8/4.9 Regression] Namelist Read Error with question marks

[madawilliams at gmail dot com]

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



--- Comment #14 from Adam Williams  2013-04-04 
08:41:32 UTC ---

Thanks for all your help

[Bug fortran/56735] [4.6/4.7/4.8/4.9 Regression] Namelist Read Error with question marks

[burnus at gcc dot gnu.org]

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



Tobias Burnus  changed:



   What|Removed |Added



 Status|ASSIGNED|RESOLVED

 Resolution||FIXED



--- Comment #13 from Tobias Burnus  2013-04-04 
08:40:21 UTC ---

FIXED on the 4.9 trunk - and on the 4.6, 4.7 and 4.8 branches.



The very soon to be released 4.7.3 and 4.6.4 will contain this fix. (As will

4.8.1, but that take still a while.)



Thanks again for the bug report.

[Bug c++/56835] std::promise seems broken on 10.8 lion

[redi at gcc dot gnu.org]

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



Jonathan Wakely  changed:



   What|Removed |Added



 Status|UNCONFIRMED |WAITING

   Last reconfirmed||2013-04-04

 Ever Confirmed|0   |1



--- Comment #2 from Jonathan Wakely  2013-04-04 
08:39:23 UTC ---

You were asked to find where it crashes:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56822#c1



You were asked to read http://gcc.gnu.org/bugs and provide the requested

information, which is still missing e.g. the output of 'gcc -v'

[Bug fortran/56735] [4.6/4.7/4.8/4.9 Regression] Namelist Read Error with question marks

[burnus at gcc dot gnu.org]

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



--- Comment #12 from Tobias Burnus  2013-04-04 
08:38:00 UTC ---

2013-04-04  Tobias Burnus  



Backport from mainline:

2013-03-28  Tobias Burnus  



PR fortran/56735

* io/list_read.c (nml_query): Only abort when

an error occured.

(namelist_read): Add goto instead of falling through.



2013-04-04  Tobias Burnus  



Backport from mainline:

2013-03-28  Tobias Burnus  



PR fortran/56735

* gfortran.dg/namelist_80.f90: New.





Added:

branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/namelist_80.f90

Modified:

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

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

branches/gcc-4_6-branch/libgfortran/io/list_read.c

[Bug libstdc++/56822] std::promise seems broken on 10.8 lion

[redi at gcc dot gnu.org]

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



--- Comment #5 from Jonathan Wakely  2013-04-04 
08:36:52 UTC ---

You could have simply updated this report instead of creating a new one.

[Bug tree-optimization/56837] -ftree-loop-distribute-patterns generates incorrect code

[rguenth at gcc dot gnu.org]

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



--- Comment #3 from Richard Biener  2013-04-04 
08:32:35 UTC ---

Testcase



extern "C" void abort (void);

extern "C" int memcmp (const void *, const void *, __SIZE_TYPE__);



bool b1[8];

bool b2[8] = { true, true, true, true, true, true, true, true };



int main()

{

  unsigned int i;

  for(i=0 ; i < 8; i++)

b1[i] = true;



  if (memcmp (b1, b2, 8) != 0)

abort ();



  return 0;

}



I have a patch.

[Bug c++/34949] Dead code in empty destructors.

[jakub at gcc dot gnu.org]

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



--- Comment #29 from Jakub Jelinek  2013-04-04 
08:25:08 UTC ---

Reduced testcase for -O3:



struct E {};

struct A

{

  virtual void a (void *) = 0;

};

struct B

{

  virtual ~B () {};

  unsigned int b1;

  E **b2;

  A *b3;

};

struct C : public B

{

  ~C ();

};

C::~C ()

{

  for (unsigned int i = 0; i < b1; i++)

b3->a (b2);

}

struct D

{

  ~D () {}

  C d;

};

struct F { virtual ~F () {}; };

struct G { void g (); };

struct H : public F

{

  virtual ~H ();

  D *h1;

  G *h2;

};

H::~H ()

{

  h2->g ();

  delete h1;

}

[Bug tree-optimization/56837] -ftree-loop-distribute-patterns generates incorrect code

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 Status|UNCONFIRMED |ASSIGNED

   Last reconfirmed||2013-04-04

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

   |gnu.org |

 Ever Confirmed|0   |1



--- Comment #2 from Richard Biener  2013-04-04 
07:58:19 UTC ---

Eh.  Mine.

[Bug tree-optimization/56837] -ftree-loop-distribute-patterns generates incorrect code

[mpolacek at gcc dot gnu.org]

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



Marek Polacek  changed:



   What|Removed |Added



 CC||mpolacek at gcc dot gnu.org



--- Comment #1 from Marek Polacek  2013-04-04 
07:57:14 UTC ---

That's because .ldist substitutes the first loop with __builtin_memset (b_7,

-1, 5);

[Bug fortran/50269] Wrongly rejects element of assumed-shape array in C_LOC

[burnus at gcc dot gnu.org]

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



Tobias Burnus  changed:



   What|Removed |Added



 Status|NEW |RESOLVED

 Resolution||FIXED



--- Comment #10 from Tobias Burnus  2013-04-04 
07:41:20 UTC ---

FIXED on the 4.9 trunk.



I have now updated some constraint checks, hopefully, -std=f2003/f2008/f2008ts

are now handled correctly.





Missing is a check whether the argument is not contiguous. But that's tracked

elsewhere. (Note: The standard does not demand simply contiguous but only

contiguous arrays - thus, the compiler can only reject simple-to-detect

noncontiguous arrays.)

[Bug tree-optimization/56837] -ftree-loop-distribute-patterns generates incorrect code

[pinskia at gcc dot gnu.org]

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



Andrew Pinski  changed:



   What|Removed |Added



   Keywords||wrong-code

   Severity|major   |normal

[Bug tree-optimization/56830] stl_vector.h:414:7: internal compiler error: verify_ssa failed

[dimhen at gmail dot com]

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



--- Comment #4 from Dmitry G. Dyachenko  2013-04-04 
07:40:15 UTC ---

197374 PASS

197375 FAIL

[Bug tree-optimization/56837] New: -ftree-loop-distribute-patterns generates incorrect code

[pmblakely at googlemail dot com]

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



 Bug #: 56837

   Summary: -ftree-loop-distribute-patterns generates incorrect

code

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: major

  Priority: P3

 Component: tree-optimization

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

ReportedBy: pmblak...@googlemail.com





Created attachment 29801

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

Compilation output from adding -v -save-temps



With gcc-4.8.0 release, and up to and including gcc-4.8-20130328,

-ftree-loop-distribute-patterns can give incorrect results:



Minimal test-case (named OptBug-4.8.C):



extern int __builtin_printf (__const char *__restrict __format, ...);



int main(void)

{

  bool* b = new bool[5];

  for(unsigned int i=0 ; i < 5 ; i++)

  {

b[i] = true;

  }



  for(unsigned int i=0 ; i < 5 ; i++)

  {

__builtin_printf("%d\n", b[i]);

  }



  return 0;

}



Compilation command: g++-4.8-20130328 OptBug-4.8.C -o OptBug-4.8 -O1

-ftree-loop-distribute-patterns



Expected output:

1

1

1

1

1



Actual output:

255

255

255

255

255



The expected output is produced if the -ftree-loop-distribute-patterns flag is

removed.

The incorrect behaviour is not exhibited by gcc-4.7.2.

[Bug fortran/50269] Wrongly rejects element of assumed-shape array in C_LOC

[burnus at gcc dot gnu.org]

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



--- Comment #9 from Tobias Burnus  2013-04-04 
07:37:01 UTC ---

Author: burnus

Date: Thu Apr  4 07:22:24 2013

New Revision: 197468



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

Log:

2013-04-04  Tobias Burnus  



PR fortran/50269

* gcc/fortran/check.c (is_c_interoperable,

gfc_check_c_loc): Correct c_loc array checking

for Fortran 2003 and Fortran 2008.



2013-04-04  Tobias Burnus  



PR fortran/50269

* gfortran.dg/c_loc_test_21.f90: New.

* gfortran.dg/c_loc_test_19.f90: Update dg-error.

* gfortran.dg/c_loc_tests_10.f03: Update dg-error.

* gfortran.dg/c_loc_tests_11.f03: Update dg-error.

* gfortran.dg/c_loc_tests_4.f03: Update dg-error.

* gfortran.dg/c_loc_tests_16.f90:  Update dg-error.





Added:

trunk/gcc/testsuite/gfortran.dg/c_loc_test_21.f90

Modified:

trunk/gcc/fortran/ChangeLog

trunk/gcc/fortran/check.c

trunk/gcc/testsuite/ChangeLog

trunk/gcc/testsuite/gfortran.dg/c_loc_test_19.f90

trunk/gcc/testsuite/gfortran.dg/c_loc_tests_10.f03

trunk/gcc/testsuite/gfortran.dg/c_loc_tests_11.f03

trunk/gcc/testsuite/gfortran.dg/c_loc_tests_16.f90

trunk/gcc/testsuite/gfortran.dg/c_loc_tests_4.f03

[Bug c++/34949] Dead code in empty destructors.

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 Status|RESOLVED|REOPENED

 Resolution|FIXED   |



--- Comment #28 from Jakub Jelinek  2013-04-04 
07:31:58 UTC ---

Yeah, I can reproduce, reducing now.

[Bug c++/34949] Dead code in empty destructors.

[izamyatin at gmail dot com]

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



Igor Zamyatin  changed:



   What|Removed |Added



 CC||izamyatin at gmail dot com



--- Comment #27 from Igor Zamyatin  2013-04-04 
07:18:07 UTC ---

Still, I see that r197375 breaks spec2006/483.xalancbmk compilation:



g++ -mavx  -static -c -o DOMDocumentImpl.o -DSPEC_CPU -DNDEBUG 

-DAPP_NO_THREADS -DXALAN_INMEM_MSG_LOADER -I. -Ixercesc -Ixercesc/dom

-Ixercesc/dom/impl -Ixercesc/sax -Ixercesc/util/MsgLoaders/InMemory

-Ixercesc/util/Transcoders/Iconv -Ixalanc/include -DPROJ_XMLPARSER

-DPROJ_XMLUTIL -DPROJ_PARSERS -DPROJ_SAX4C -DPROJ_SAX2 -DPROJ_DOM

-DPROJ_VALIDATORS -DXML_USE_NATIVE_TRANSCODER -DXML_USE_INMEM_MESSAGELOADER -O3

-funroll-loops -ffast-math -march=corei7   -DSPEC_CPU_LP64  -DSPEC_CPU_LINUX   

 DOMDocumentImpl.cpp



DOMDocumentImpl.cpp: In destructor

'xercesc_2_5::DOMDocumentImpl::~DOMDocumentImpl()':

DOMDocumentImpl.cpp:207:1: error: definition in block 47 does not dominate use

in block 92

 DOMDocumentImpl::~DOMDocumentImpl()

 ^

for SSA_NAME: _36 in statement:

# .MEM_250 = VDEF <.MEM_8>

MEM[(struct BaseRefVectorOf *)_36 + 8B] ={v} {CLOBBER};

DOMDocumentImpl.cpp:207:1: internal compiler error: verify_ssa failed

0xc06b54 verify_ssa(bool)

../../gcc/tree-ssa.c:1046

0x9e6662 execute_function_todo

../../gcc/passes.c:1964

0x9e704d execute_todo

../../gcc/passes.c:1996

[Bug middle-end/50200] ICE: SIGSEGV in df_insn_refs_collect (df-scan.c:3405)

[mpolacek at gcc dot gnu.org]

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



Marek Polacek  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 CC||mpolacek at gcc dot gnu.org

 Resolution||FIXED



--- Comment #4 from Marek Polacek  2013-04-04 
07:03:53 UTC ---

This one should be fixed as well (4.6/4.7/4.8/trunk).