[Bug fortran/54725] cross gfortran always searches host paths (e.g. /usr/include)

[burnus at gcc dot gnu.org]

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



Tobias Burnus  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2012-10-19

 Ever Confirmed|0   |1



--- Comment #7 from Tobias Burnus  2012-10-19 
08:23:21 UTC ---

Can you check whether the following patch works for you?



http://gcc.gnu.org/ml/gcc-patches/2012-10/msg01780.html

[Bug tree-optimization/54965] [4.6 Regression] sorry, unimplemented: inlining failed in call to 'foo': function not considered for inlining

[rguenth at gcc dot gnu.org]

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



--- Comment #6 from Richard Biener  2012-10-19 
08:36:06 UTC ---

(In reply to comment #5)

> (In reply to comment #4)

> > In the above case you probably want big_function_a to have all

> > calls inlined.  You can then conveniently use the flatten attribute:

> > 

> > void __attribute__((flatten)) big_function_b (...)

> > {

> >   big_function_template(..., per_pixel_operation_b);

> > }

> > 

> > GCC will then inline all calls in that function but not ICE

> > when it fails to inline one case for some weird reason.

> 

> That's nice, but "flatten" attribute does not seem to be widely supported by

> the compilers. For example, clang-3.1 does not support it yet and the

> enhancement request is still open since 2010 -

> http://llvm.org/bugs/show_bug.cgi?id=7559

> 

> As far as I know, a few different compilers are currently in real use for

> building pixman for various systems: GCC, Clang, Solaris Studio and MSVC. All

> of them have some sort of "always_inline" attribute support, which makes it

> more universal than "flatten".

> 

> > Don't use always-inline or don't use indirect function calls to

> > always-inline functions.  It makes always-inline function calls

> > survive until IPA inlining where we seem to honor limits even

> > though we say we should disregard them.

> 

> Is it too intrusive to fix GCC so that it would disregard limits in this case?

> Or maybe introduce one more attribute which would be a strong inlining hint,

> but still not cause compilation failure if some function can't be really

> inlined?



I think the particular case is a bug in GCC, I was just mentioning that

using indirect function calls to always-inline functions is always prone

to this kind of error.

[Bug lto/54966] Does LTO requires a larger inline-unit-growth?

[vincenzo.innocente at cern dot ch]

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



--- Comment #3 from vincenzo Innocente  
2012-10-19 08:36:20 UTC ---

the patch fails w.r.t. 4.7 



patch -p0 < ../../inline.patch 

patching file ipa-inline.c

Hunk #1 FAILED at 473.

Hunk #2 FAILED at 491.

Hunk #3 FAILED at 545.

3 out of 3 hunks FAILED -- saving rejects to file ipa-inline.c.rej



we are not ready to upgrade to 4.8

[Bug tree-optimization/54981] [4.8 Regression] Different code generated with / without `-g'

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 Status|UNCONFIRMED |ASSIGNED

   Last reconfirmed||2012-10-19

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

   |gnu.org |

   Target Milestone|--- |4.8.0

 Ever Confirmed|0   |1



--- Comment #1 from Richard Biener  2012-10-19 
08:36:58 UTC ---

Mine.

[Bug lto/54980] [4.8 regression] gimple check: expected gimple_cond(error_mark), have gimple_call() in gimple_cond_set_lhs, at gimple.h:2578

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2012-10-19

 CC||hubicka at gcc dot gnu.org

   Target Milestone|--- |4.8.0

 Ever Confirmed|0   |1



--- Comment #4 from Richard Biener  2012-10-19 
08:38:24 UTC ---

Honza, this is yours.

[Bug tree-optimization/54937] Invalid loop bound estimate

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



   Keywords||wrong-code

 Status|UNCONFIRMED |NEW

   Last reconfirmed||2012-10-19

 Ever Confirmed|0   |1



--- Comment #1 from Richard Biener  2012-10-19 
08:38:40 UTC ---

Confirmed.

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

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 CC|hubicka at ucw dot cz,  |hubicka at gcc dot gnu.org

   |rguenth at gcc dot gnu.org  |

   Target Milestone|--- |4.8.0



--- Comment #5 from Richard Biener  2012-10-19 
08:39:17 UTC ---

Honza, that's yours.

[Bug fortran/48636] Enable more inlining with -O2 and higher

[vincenzo.innocente at cern dot ch]

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



--- Comment #26 from vincenzo Innocente  
2012-10-19 08:45:03 UTC ---

I'm interested to test the patch on our large application currently compiled

with 4.7.2.

would it be possible to get the same patch against gcc-4_7-branch?

thanks

[Bug tree-optimization/54978] Add ability to provide vectorized functions

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2012-10-19

 Ever Confirmed|0   |1



--- Comment #1 from Richard Biener  2012-10-19 
08:45:27 UTC ---

Note that the Cilk+ people have something like this in mind (with an

'elemental' attribute).  The ABI (and thus the mangling) would be static,

thus C++ overloading would not work (but the vectorized function name

would be constructed similar to those of the intrinsics for -mveclibabi).

To adjust your example:



double fx (double) __attribute__((vector));



would tell GCC that a function named (for example) fx_v2df is available,

as well as a function named fx_v4df in case AVX is enabled (and a gazillion

more variants dependent on the target capabilities ...).



Another proposal was that GCC builds those variants itself as needed

(obviously only if it can see the function body).  This is what Cilk+

people designed:



double fx (double x) __attribute__((elemental))

{

  ...

}



would mean the function has to be necessarily 'const' (the return value

is only dependent on arguments, it does not read from memory or has

any side-effects) and the compiler can substitute all double types by

appropriate vector types.

[Bug tree-optimization/54976] FAIL: gcc.dg/torture/pr47975.c (internal compiler error)

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 Status|UNCONFIRMED |ASSIGNED

   Last reconfirmed||2012-10-19

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

   |gnu.org |

 Ever Confirmed|0   |1



--- Comment #1 from Richard Biener  2012-10-19 
09:00:45 UTC ---

Hm, we are calling get_vectype_for_scalar_type with a vector type argument

which has OImode (thus type_for_mode fails).



We can robustify get_vectype_for_scalar_type a bit, but maybe we should

fix the caller (BB vectorization) as well.  Not sure though, it might

still vectorize v2si operations to v2di ones for example.



Mine.

[Bug tree-optimization/54977] example3 not vectorized

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 CC||jakub at gcc dot gnu.org

 Resolution||FIXED

   Target Milestone|--- |4.8.0



--- Comment #1 from Jakub Jelinek  2012-10-19 
09:10:02 UTC ---

That is due to the overaligned type.  For GCC 4.7 and above, just use

__builtin_assume_aligned instead to hint the compiler about alignment.

void

foo (int n, int * __restrict px, int * __restrict qx)

{

  int *__restrict p = __builtin_assume_aligned (px, 16);

  int *__restrict q = __builtin_assume_aligned (qx, 16);

  while (n--)

*p++ = *q++;

}



BTW, GCC 4.8 turns the testcase into memcpy (and with *q++ + 1 or similar to

avoid the memcpy it is vectorized since PR54894).



I don't think we want to change anything here for gcc 4.7.

[Bug target/54892] [4.7/4.8 Regression], ICE in extract_insn, at recog.c:2123

[xguo at gcc dot gnu.org]

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



--- Comment #3 from xuepeng guo  2012-10-19 09:24:48 
UTC ---

Author: xguo

Date: Fri Oct 19 09:24:39 2012

New Revision: 192609



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

Log:

gcc/ChangeLog

PR target/54892

* config/arm/arm.c (arm_expand_compare_and_swap): Use SImode to make

sure the mode is correct when falling through from above cases.



gcc/testsuite/ChangeLog

PR target/54892

* gcc.target/arm/pr54892.c: New.



Added:

trunk/gcc/testsuite/gcc.target/arm/pr54892.c

Modified:

trunk/gcc/ChangeLog

trunk/gcc/config/arm/arm.c

trunk/gcc/testsuite/ChangeLog

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

[hubicka at ucw dot cz]

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



--- Comment #6 from Jan Hubicka  2012-10-19 09:35:37 UTC 
---

Looking into it. Obviously complette unroling ought not affect loop closedness

:)



Honza

[Bug target/54892] [4.7/4.8 Regression], ICE in extract_insn, at recog.c:2123

[xguo at gcc dot gnu.org]

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



--- Comment #4 from xuepeng guo  2012-10-19 09:39:20 
UTC ---

Author: xguo

Date: Fri Oct 19 09:39:13 2012

New Revision: 192610



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

Log:

gcc/ChangeLog

Backported from mainline

2012-10-19  Zhenqiang Chen 



PR target/54892

* config/arm/arm.c (arm_expand_compare_and_swap): Use SImode to make

sure the mode is correct when falling through from above cases.



gcc/testsuite/ChangeLog

Backported from mainline

2012-10-19  Zhenqiang Chen 



PR target/54892

* gcc.target/arm/pr54892.c: New.



Added:

branches/gcc-4_7-branch/gcc/testsuite/gcc.target/arm/pr54892.c

Modified:

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

branches/gcc-4_7-branch/gcc/config/arm/arm.c

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

[Bug tree-optimization/54978] Add ability to provide vectorized functions

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 CC||jakub at gcc dot gnu.org



--- Comment #2 from Jakub Jelinek  2012-10-19 
10:00:52 UTC ---

Why can't the elemental function be pure?  If it just reads some memory, the

vectorized version can use that memory value broadcasted to a vector.

[Bug c++/3187] gcc lays down two copies of constructors

[jakub at gcc dot gnu.org]

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



--- Comment #41 from Jakub Jelinek  2012-10-19 
10:05:55 UTC ---

The reason why this hasn't been closed is that we only use an alias of one kind

of ctor (resp. dtor) to the other one if they are the same (and for deleting

dtor just always call the other dtor).  If they are different, then they can't

be aliased together, what we could do (perhaps as an option) is to emit another

function, which would take an argument what kind of ctor resp. dtor it is, and

behave differently depending on that argument, then have both kinds of ctor

resp. dtor to tail call (or if not possible, just call) the other function.

I guess it could have ABI consequences though (in which comdat section to place

it).

[Bug fortran/54884] [4.8 Regression] Externally used PRIVATE module procedure wrongly marked as TREE_PUBLIC()=0

[burnus at gcc dot gnu.org]

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



Tobias Burnus  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||FIXED



--- Comment #6 from Tobias Burnus  2012-10-19 
10:07:23 UTC ---

FIXED on the 4.8 trunk.



Thanks Andrew for the bug report!

[Bug lto/54980] [4.8 regression] gimple check: expected gimple_cond(error_mark), have gimple_call() in gimple_cond_set_lhs, at gimple.h:2578

[dimhen at gmail dot com]

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



--- Comment #5 from Dmitry G. Dyachenko  2012-10-19 
10:26:35 UTC ---

192517 OK

192548 FAIL

[Bug tree-optimization/54976] FAIL: gcc.dg/torture/pr47975.c (internal compiler error)

[rguenth at gcc dot gnu.org]

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



--- Comment #2 from Richard Biener  2012-10-19 
10:32:37 UTC ---

Author: rguenth

Date: Fri Oct 19 10:32:29 2012

New Revision: 192611



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

Log:

2012-10-19  Richard Biener  



PR tree-optimization/54976

* tree-vect-stmts.c (get_vectype_for_scalar_type_and_size):

Robustify against odd inner_mode inputs.



Modified:

trunk/gcc/ChangeLog

trunk/gcc/tree-vect-stmts.c

[Bug c++/3187] gcc lays down two copies of constructors

[ararunprasad at gmail dot com]

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



--- Comment #42 from Arunprasad  2012-10-19 
10:34:11 UTC ---

So I'm assuming like the issue still exists in gcc family of tool-chains. Fix

has been temporarily suspended due to ABI compatibility.

[Bug tree-optimization/54976] [4.8 Regression] FAIL: gcc.dg/torture/pr47975.c (internal compiler error)

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 Status|ASSIGNED|RESOLVED

 Resolution||FIXED

   Target Milestone|--- |4.8.0

Summary|FAIL:   |[4.8 Regression] FAIL:

   |gcc.dg/torture/pr47975.c|gcc.dg/torture/pr47975.c

   |(internal compiler error)   |(internal compiler error)



--- Comment #3 from Richard Biener  2012-10-19 
10:36:51 UTC ---

Fixed.

[Bug tree-optimization/54894] [4.6/4.7 Regression] internal compiler error: in vect_get_vec_def_for_operand, at tree-vect-stmts.c:1286

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 Depends on||54976



--- Comment #7 from Richard Biener  2012-10-19 
10:37:46 UTC ---

Requires the fix for PR54976 on backport.

[Bug c/54983] New: ARM gcc creates invalid assembly: bad immediate value for 8-bit offset (1024)

[hechtb at gmail dot com]

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



 Bug #: 54983

   Summary: ARM gcc creates invalid assembly: bad immediate value

for 8-bit offset (1024)

Classification: Unclassified

   Product: gcc

   Version: 4.6.3

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: c

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

ReportedBy: hec...@gmail.com





Created attachment 28488

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

Includes a .config to build the v3.7-rc1 kernel and the --save-temps file



The bug appeared on new linux ARM kernel versions and I cite here a kernel

maintainer responding to my patch submission:



"Hi, I used to be able to compile MTD stuff for mackerel board with the

defconfig attached, but now it fails with 3.7-rc1 with as error:



/tmp/cc2Nr7AN.s: Error: bad immediate value for 8-bit offset (1024)



It fails for dogc4.c, but if I disable DOCG4, it fails for other drivers

with a similar error.



I've tried (arm) gcc 4.6.3 and the latest Linaro 4.7 build."



In order to reproduce the bug, please get a repository of the kernel and

checkout "v3.7-rc1" and use the attached .config. The bug happens when building

the modules. I'm sorry but I see no way figuring out all the dependencies of a

kernel build to supply a more compact way to test this. I used 



make -j16 ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- modules



and get the error:



/tmp/ccwLMdCy.s: Assembler messages:

/tmp/ccwLMdCy.s: Error: bad immediate value for 8-bit offset (2048)

make[3]: *** [drivers/mtd/nand/docg4.o] Error 1



# arm-linux-gnueabi-gcc -v

Using built-in specs.

COLLECT_GCC=arm-linux-gnueabi-gcc

COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabi/4.6/lto-wrapper

Target: arm-linux-gnueabi

Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro

4.6.3-1ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs

--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr

--program-suffix=-4.6 --enable-shared --enable-linker-build-id

--with-system-zlib --libexecdir=/usr/lib --without-included-gettext

--enable-threads=posix

--with-gxx-include-dir=/usr/arm-linux-gnueabi/include/c++/4.6.3

--libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug

--enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin

--enable-objc-gc --enable-multilib --disable-sjlj-exceptions

--with-arch=armv7-a --with-float=softfp --with-fpu=vfpv3-d16 --with-mode=thumb

--disable-werror --enable-checking=release --build=x86_64-linux-gnu

--host=x86_64-linux-gnu --target=arm-linux-gnueabi

--program-prefix=arm-linux-gnueabi- --includedir=/usr/arm-linux-gnueabi/include

--with-headers=/usr/arm-linux-gnueabi/include

--with-libs=/usr/arm-linux-gnueabi/lib

Thread model: posix

gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)



Best,



 Bastian Hecht

[Bug c++/54984] New: Array allocated with new in a template class is default initialised

[malcolm.parsons at gmail dot com]

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



 Bug #: 54984

   Summary: Array allocated with new in a template class is

default initialised

Classification: Unclassified

   Product: gcc

   Version: 4.6.3

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: c++

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

ReportedBy: malcolm.pars...@gmail.com





$ cat a.cpp 

#include 



struct Foo {

Foo(size_t size) : x(new char[size]) {}

char *x;

};



int main(int argc, char* argv[])

{

size_t size = 10;

Foo foo(size);

return(0);

}



$ cat b.cpp 

#include 



template 

struct Foo {

Foo(size_t size) : x(new char[size]) {}

char *x;

};



int main(int argc, char* argv[])

{

size_t size = 10;

Foo foo(size);

return(0);

}



gcc 4.6.3 decides that the array in the templated class needs to be initialised

to 0.



$ g++ -v

Using built-in specs.

COLLECT_GCC=g++

COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-linux-gnu/4.6/lto-wrapper

Target: i686-linux-gnu

Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro

4.6.3-1ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs

--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr

--program-suffix=-4.6 --enable-shared --enable-linker-build-id

--with-system-zlib --libexecdir=/usr/lib --without-included-gettext

--enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6

--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu

--enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object

--enable-plugin --enable-objc-gc --enable-targets=all --disable-werror

--with-arch-32=i686 --with-tune=generic --enable-checking=release

--build=i686-linux-gnu --host=i686-linux-gnu --target=i686-linux-gnu

Thread model: posix

gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)

$ g++ -O2 a.cpp -o a

$ g++ -O2 b.cpp -o b

$ time ./a



real0m0.006s

user0m0.000s

sys0m0.004s

$ time ./b



real0m4.732s

user0m2.676s

sys0m1.976s

$ g++ -O2 -S a.cpp

$ g++ -O2 -S b.cpp

$ diff -u a.s b.s

--- a.s2012-10-19 11:37:35.280151921 +0100

+++ b.s2012-10-19 11:37:13.803790575 +0100

@@ -1,10 +1,10 @@

-.file"a.cpp"

+.file"b.cpp"

 .section.text.startup,"ax",@progbits

 .p2align 4,,15

 .globlmain

 .typemain, @function

 main:

-.LFB15:

+.LFB13:

 .cfi_startproc

 pushl%ebp

 .cfi_def_cfa_offset 8

@@ -15,13 +15,21 @@

 subl$16, %esp

 movl$10, (%esp)

 call_Znaj

+leal10(%eax), %edx

+.p2align 4,,7

+.p2align 3

+.L2:

+movb$0, (%eax)

+addl$1, %eax

+cmpl%edx, %eax

+jne.L2

 xorl%eax, %eax

 leave

 .cfi_restore 5

 .cfi_def_cfa 4, 4

 ret

 .cfi_endproc

-.LFE15:

+.LFE13:

 .sizemain, .-main

 .ident"GCC: (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3"

 .section.note.GNU-stack,"",@progbits







gcc 4.4.3 did not initialise the array in either class.



$ g++ -v

Using built-in specs.

Target: x86_64-linux-gnu

Configured with: ../src/configure -v --with-pkgversion='Ubuntu

4.4.3-4ubuntu5.1' --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs

--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared

--enable-multiarch --enable-linker-build-id --with-system-zlib

--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix

--with-gxx-include-dir=/usr/include/c++/4.4 --program-suffix=-4.4 --enable-nls

--enable-clocale=gnu --enable-libstdcxx-debug --enable-plugin --enable-objc-gc

--disable-werror --with-arch-32=i486 --with-tune=generic

--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu

--target=x86_64-linux-gnu

Thread model: posix

gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5.1) 

$ g++ -O2 a.cpp -o a

$ g++ -O2 b.cpp -o b

$ time ./a



real0m0.003s

user0m0.004s

sys0m0.000s

$ time ./b



real0m0.003s

user0m0.000s

sys0m0.000s





I don't expect the array to be initialised unless requested by adding "()": new

char[size]()

[Bug middle-end/54985] New: Dom optimization erroneous remove conditional goto.

[vbyakovl23 at gmail dot com]

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

 Bug #: 54985
   Summary: Dom optimization erroneous remove conditional goto.
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: vbyakov...@gmail.com


Attached test case fails if compiled with -O1 and higher.

gcc -O0 -m32  q.c qm.c  ; ./a.out && echo "pass" || echo "FAIL" 
pass
gcc -g3 -O1 -m32  q.c qm.c  ; ./a.out && echo "pass" || echo "FAIL" 
FAIL

gcc -v
Using built-in specs.
COLLECT_GCC=/export/users/vbyakovl/workspaces/gcc/install-ref/bin/gcc
COLLECT_LTO_WRAPPER=/export/users/vbyakovl/workspaces/gcc/install-ref/libexec/gcc/x86_64-unknown-linux-gnu/4.8.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc/configure CFLAGS='-O0 -g3'
--prefix=/export/users/vbyakovl/workspaces/gcc/install-ref --disable-bootstrap
--enable-languages=c,c++,fortran,lto CXXFLAGS='-O0 -g3' : (reconfigured)
../gcc/configure CFLAGS='-O0 -g3'
--prefix=/export/users/vbyakovl/workspaces/gcc/install-ref --disable-bootstrap
CXXFLAGS='-O0 -g3' --enable-languages=c,c++,fortran,lto --no-create
--no-recursion : (reconfigured) ../gcc/configure CFLAGS='-O0 -g3'
--prefix=/export/users/vbyakovl/workspaces/gcc/install-ref --disable-bootstrap
CXXFLAGS='-O0 -g3' --enable-languages=c,c++,fortran,lto --no-create
--no-recursion
Thread model: posix
gcc version 4.8.0 20121015 (experimental) (GCC)

Wrong compilation of a routine

int foo(ST *s, int c)
{
int first = 1;
int count = c;
ST *item = s;
int a = s->a;
int x;

while (count--)
{  
x = item->a;
if (first)
first = 0;
else if (x >= a)
return 1;
a = x;
item++;
}
return 0;
}

Compiler sets equivalence between ‘x’ and ‘a’ (routine tree-ssa-threadedge.c
/record_temporary_equivalences_from_phis() ) and folds comparison x >= a to
true.

[Bug middle-end/54985] Dom optimization erroneous remove conditional goto.

[vbyakovl23 at gmail dot com]

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



--- Comment #1 from Vladimir Yakovlev  2012-10-19 
10:58:26 UTC ---

Created attachment 28489

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

Test case

[Bug middle-end/54985] Dom optimization erroneous remove conditional goto.

[vbyakovl23 at gmail dot com]

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



--- Comment #2 from Vladimir Yakovlev  2012-10-19 
10:59:15 UTC ---

Created attachment 28490

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

Main routine

[Bug target/54983] ARM gcc creates invalid assembly: bad immediate value for 8-bit offset (1024)

[pinskia at gcc dot gnu.org]

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



--- Comment #1 from Andrew Pinski  2012-10-19 
11:01:13 UTC ---

I think there might be an issue with some of the inline-asm in asm/io.h:

static inline __attribute__((always_inline))

__attribute__((no_instrument_function)) void __raw_writew(u16 val, volatile

void *addr)

{

 asm volatile("strh %1, %0"

   : "+Qo" (*(volatile u16 *)addr)

   : "r" (val));





Also what options are being passed to the gcc?

[Bug tree-optimization/54981] [4.8 Regression] Different code generated with / without `-g'

[rguenth at gcc dot gnu.org]

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



--- Comment #2 from Richard Biener  2012-10-19 
11:06:16 UTC ---

+not generating builtin, partition has scalar uses outside of the loop



that check is confused by debug stmts.



I have a simple patch, let's watch for the fallout (the issue is surely

latent on the branches).

[Bug c++/54569] Compiling code with -O3 results to segfault in MAME/MESS binary

[l.gronning at gmail dot com]

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



Lars  changed:



   What|Removed |Added



 CC||l.gronning at gmail dot com



--- Comment #1 from Lars  2012-10-19 11:16:32 UTC 
---

I am also experienced something that seems like the same bug using mingw

cross-compiler 4.7.2 and 4.7.0. After removing the -fipa-cp-clone flag all

seems to work.

[Bug tree-optimization/54985] [4.7/4.8 Regression] dom optimization erroneous remove conditional goto.

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

  Known to work||4.6.3

   Keywords||wrong-code

   Last reconfirmed||2012-10-19

  Component|middle-end  |tree-optimization

 Ever Confirmed|0   |1

Summary|Dom optimization erroneous  |[4.7/4.8 Regression] dom

   |remove conditional goto.|optimization erroneous

   ||remove conditional goto.

   Target Milestone|--- |4.7.3

  Known to fail||4.7.2, 4.8.0



--- Comment #3 from Richard Biener  2012-10-19 
11:19:38 UTC ---

Confirmed.  Single-file testcase, fails with 4.7 and 4.8.



typedef struct st {

int a;

} ST;



int __attribute__((noinline,noclone))

foo(ST *s, int c)

{

  int first = 1;

  int count = c;

  ST *item = s;

  int a = s->a;

  int x;



  while (count--)

{

  x = item->a;

  if (first)

first = 0;

  else if (x >= a)

return 1;

  a = x;

  item++;

}

  return 0;

}



extern void abort (void);



int main ()

{

  ST _1[2] = {{2}, {1}};

  if (foo(_1, 2) != 0)

abort ();

  return 0;

}

[Bug tree-optimization/54985] [4.7/4.8 Regression] dom optimization erroneous remove conditional goto.

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 CC||law at gcc dot gnu.org



--- Comment #4 from Richard Biener  2012-10-19 
11:26:15 UTC ---

Jeff - you updated jump-threading code in DOM quite a bit for 4.7.

[Bug c++/54986] New: Internal Error: segmentation fault

[vanicat at debian dot org]

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

 Bug #: 54986
   Summary: Internal Error: segmentation fault
Classification: Unclassified
   Product: gcc
   Version: 4.7.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: vani...@debian.org


When compiling giac, I've an Internal error: Segmentation fault with
gcc-4.7 and -O2. Using some newer version of some library solved this, but I
believe a SEGV in gcc is alway a bug. Compiling without -O2 is successful.

The error:

$ g++-4.7 -O2 -c foo-4.7.cc
prog.cc: In function ‘bool giac::is_return(const giac::gen&, giac::gen&)’:
prog.cc:8046:1: internal compiler error: Erreur de segmentation
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
Preprocessed source stored into /tmp/cc4J9upy.out file, please attach this to
your bugreport.
$ g++-4.7  -c foo-4.7.cc
$

[Bug c/54983] ARM gcc creates invalid assembly: bad immediate value for 8-bit offset (1024)

[hechtb at gmail dot com]

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



Bastian Hecht  changed:



   What|Removed |Added



  Component|target  |c



--- Comment #2 from Bastian Hecht  2012-10-19 11:55:37 
UTC ---

I'm afraid I don't have the knowledge to comment the inline assembly. The

command line is:



arm-linux-gnueabi-gcc -Wp,-MD,drivers/mtd/nand/.docg4.o.d  -nostdinc

-isystem /usr/lib/gcc/arm-linux-gnueabi/4.6/include

-I$KERNEL_DIR/arch/arm/include -Iarch/arm/include/generated  -Iinclude

-I$KERNEL_DIR/arch/arm/include/uapi -Iarch/arm/include/generated/uapi

-I$KERNEL_DIR/include/uapi -Iinclude/generated/uapi -include

$KERNEL_DIR/include/linux/kconfig.h -D__KERNEL__ -mlittle-endian

-Iarch/arm/mach-shmobile/include -Wall -Wundef -Wstrict-prototypes

-Wno-trigraphs -fno-strict-aliasing -fno-common

-Werror-implicit-function-declaration -Wno-format-security

-fno-delete-null-pointer-checks -O2 -marm -fno-dwarf2-cfi-asm

-fno-omit-frame-pointer -mapcs -mno-sched-prolog -mabi=aapcs-linux

-mno-thumb-interwork -D__LINUX_ARM_ARCH__=7 -march=armv7-a

-msoft-float -Uarm -Wframe-larger-than=1024 -fno-stack-protector

-Wno-unused-but-set-variable -fno-omit-frame-pointer

-fno-optimize-sibling-calls -Wdeclaration-after-statement

-Wno-pointer-sign -fno-strict-overflow -fconserve-stack  -DMODULE

-D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(docg4)"

-D"KBUILD_MODNAME=KBUILD_STR(docg4)" --save-temps -c -o

drivers/mtd/nand/docg4.o drivers/mtd/nand/docg4.c

[Bug c++/54986] Internal Error: segmentation fault

[vanicat at debian dot org]

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

--- Comment #1 from Rémi Vanicat  2012-10-19 
12:06:30 UTC ---
I forgot to give you the version:
I'm using debian unstable gcc: 

g++-4.7 (Debian 4.7.2-4) 4.7.2
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

The attached failing file was too big, I will upload it somewhere soon.

[Bug target/54974] [4.8 Regression] [ARM] Incorrect placement of constant pools

[doko at gcc dot gnu.org]

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



Matthias Klose  changed:



   What|Removed |Added



  Known to work|4.7.2   |4.6.3

  Known to fail||4.7.2



--- Comment #5 from Matthias Klose  2012-10-19 
12:23:57 UTC ---

this patch is now on the 4.7 branch too.

[Bug debug/54693] VTA guality issues with loops

[jakub at gcc dot gnu.org]

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



--- Comment #4 from Jakub Jelinek  2012-10-19 
12:34:14 UTC ---

Thanks, the threadedge patch looks reasonable (I think gimple_location on debug

stmts is ignored, so we don't need to drop it).



As for ivopts, there is no use in these cases.  We'd either need to add debug

uses of IVs as a special set of uses (perhaps in a different vector), that

wouldn't be used for decision of which IVs to keep/use, but just for

computation of the best candidate for it (where for debug info best is

something very different from best for code, for debug info smaller cost is as

small as possible expression, as few address expressions in it as possible, as

few SSA_NAMEs as possible).

Or I guess another alternative for unused IVs used in debug stmts is do what

your loop does (but drop the PHI check and do it for all unused IVs?; in the

particular testcase before your threadedge change the DEBUG stmts use i_10,

which is i_16 + 1 (where i_16 is set in PHI ), so it wouldn't do

anything).  You can build an artificial temporary use object,

get_computation_at

only uses the iv field of it (so just struct iv_use use; memset (&use, 0,

sizeof (use)); use.iv = info->iv;, for stmt I'd use for PHI setters

gsi_after_labels stmt, for normal assignments next stmt after the setter it if

any.  And for cand perhaps go through all of the (or just a subsect of)

iv_cands that are

iv_use (data, i)->selected for some i.  Perhaps we can first search for a

cand->iv with equal step to the unused iv if any (and prefer integer bases over

more complex ones, on this testcase the removed iv used by some DEBUG stmts is:

ssa name i_10

  type int

  base 1

  step 1

  is a biv

and iv_cands that are selected by any uses are:

  type unsigned long

  base (unsigned long) &arr

  step 1

  base object (void *) &arr

and

  type unsigned int

  base 48

  step 1

where better is to use the second one, both because it has an integer base, and

because TYPE_MODE of its type is identical to TYPE_MODE of the iv (so no

extension/truncation is needed).  get_computation_at returns possibly large

tree, so we need to gimplify it into perhaps series of debug temps, finally

assign to a debug temp after the setter stmt, then rewrite all the debug stmt

uses to use this debug temp.

[Bug c++/54984] [4.6/4.7/4.8 Regression] Array allocated with new in a template class is default initialised

[redi at gcc dot gnu.org]

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



Jonathan Wakely  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2012-10-19

  Known to work||4.4.7

Summary|Array allocated with new in |[4.6/4.7/4.8 Regression]

   |a template class is default |Array allocated with new in

   |initialised |a template class is default

   ||initialised

 Ever Confirmed|0   |1

  Known to fail||4.6.3, 4.8.0



--- Comment #1 from Jonathan Wakely  2012-10-19 
12:44:32 UTC ---

Confirmed, it's a regression since 4.4

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

[hubicka at gcc dot gnu.org]

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



--- Comment #7 from Jan Hubicka  2012-10-19 
12:50:57 UTC ---

OK,

the problem is that unloop is shuffling a basic block out of the outer loop:

   DO m=1,6

after unrolling the inner loop:

   DO j=1,2

12 times.



So here are several problems

1) I need to work out what to do when unloop moves basic blocks out of the loop

and why it happens in this case

2) array bound is based on array access

  n_29 = n_5 + 1;

  _45 = (integer(kind=8)) n_29;

  _58 = _45 + -1;

  c_map_mat[_58] = m_1;

and it is 12 instead of 2 because we lose track of the fact that the array is 2

dimensional with known bounds.

Somehow we should keep track of this.

3) tree-ssa-loop-niter ought to take into account known bounds on IV variables

of the outer loop when computing the inner loop.



Honza

[Bug tree-optimization/54981] [4.8 Regression] Different code generated with / without `-g'

[rguenth at gcc dot gnu.org]

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



--- Comment #3 from Richard Biener  2012-10-19 
13:05:45 UTC ---

Author: rguenth

Date: Fri Oct 19 13:05:40 2012

New Revision: 192612



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

Log:

2012-10-19  Richard Guenther  



PR tree-optimization/54981

* tree-loop-distribution.c (ssa_name_has_uses_outside_loop_p):

Do not consider debug stmts as uses.



* gcc.dg/pr54981.c: New testcase.



Added:

trunk/gcc/testsuite/gcc.dg/pr54981.c

Modified:

trunk/gcc/ChangeLog

trunk/gcc/testsuite/ChangeLog

trunk/gcc/tree-loop-distribution.c

[Bug tree-optimization/54981] [4.8 Regression] Different code generated with / without `-g'

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 Status|ASSIGNED|RESOLVED

 Resolution||FIXED



--- Comment #4 from Richard Biener  2012-10-19 
13:06:07 UTC ---

Fixed.

[Bug c++/54987] New: missed ambiguity in template function call

[afalin at xakep dot ru]

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



 Bug #: 54987

   Summary: missed ambiguity in template function call

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: c++

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

ReportedBy: afa...@xakep.ru





Created attachment 28491

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

minimal test-case



Call to 'foo' is really ambiguous, both versions need for cast.



Tested with:

1) gcc-4.4.7, gcc-4.6.3, gcc-4.8.0 (r192610) - no errors or warnings

2) clang-3.1, MS C compiler 8.0 - "error: call to 'foo' is ambiguous"



If make_type is not template - gcc error's with ambiguity.

[Bug middle-end/54945] Too strong non-aliasing analysis?

[matz at gcc dot gnu.org]

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



--- Comment #13 from Michael Matz  2012-10-19 13:12:35 
UTC ---

(In reply to comment #12)

> What do you mean by invalid? It is certainly not undefined behavior.



No, but the expectation implicitely coded into the return code is invalid.

Sorry for sloppy use of words.  The outcome depends on GCC putting both

objects next to each other which noone guarantees.  The testcase can yield 0

or 1 depending on the moon phase.

[Bug middle-end/54945] Too strong non-aliasing analysis?

[mpolacek at gcc dot gnu.org]

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



--- Comment #14 from Marek Polacek  2012-10-19 
13:18:12 UTC ---

I agree and do not plan to work on "fixing" that.  (The intptr_t change is

already approved and will be comitted shortly though.)

[Bug tree-optimization/54985] [4.7/4.8 Regression] dom optimization erroneous remove conditional goto.

[law at redhat dot com]

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



Jeffrey A. Law  changed:



   What|Removed |Added



 CC||law at redhat dot com



--- Comment #5 from Jeffrey A. Law  2012-10-19 13:27:02 
UTC ---

Thanks.  I'll take a looksie.

[Bug debug/54693] VTA guality issues with loops

[jakub at gcc dot gnu.org]

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



--- Comment #5 from Jakub Jelinek  2012-10-19 
13:49:03 UTC ---

What I had in mind for ivopts is roughly this.  Not sure about the last

argument to get_computation_at.  For normal statements I'd hope it shouldn't

make a difference, the stmt that initializes the unused iv should hopefully not

be in any way related to the place where increment of the new iv will happen,

for phis it needs more investigation.



And I don't see any infrastructure to gimplify a larger expression into several

debug temporaries with simpler expressions.



--- gcc/tree-ssa-loop-ivopts.c.jj2012-09-12 10:57:02.629762526 +0200

+++ gcc/tree-ssa-loop-ivopts.c2012-10-19 15:35:19.631230006 +0200

@@ -6422,7 +6422,76 @@ remove_unused_ivs (struct ivopts_data *d

   && !info->inv_id

   && !info->iv->have_use_for

   && !info->preserve_biv)

-bitmap_set_bit (toremove, SSA_NAME_VERSION (info->iv->ssa_name));

+{

+  bitmap_set_bit (toremove, SSA_NAME_VERSION (info->iv->ssa_name));

+

+  if (MAY_HAVE_DEBUG_STMTS

+  && SSA_NAME_DEF_STMT (info->iv->ssa_name))

+{

+  tree comp = NULL_TREE;

+  imm_use_iterator imm_iter;

+  use_operand_p use_p;

+  gimple stmt;

+

+  FOR_EACH_IMM_USE_STMT (stmt, imm_iter, info->iv->ssa_name)

+{

+  if (!gimple_debug_bind_p (stmt))

+continue;

+

+  if (comp == NULL_TREE)

+{

+  struct iv_use dummy_use;

+  struct iv_cand *best_cand = NULL, *cand;

+  unsigned i, best_pref = 0, cand_pref;

+

+  memset (&dummy_use, 0, sizeof (dummy_use));

+  dummy_use.iv = info->iv;

+  for (i = 0; i < n_iv_uses (data) && i < 64; i++)

+{

+  cand = iv_use (data, i)->selected;

+  if (cand == best_cand)

+continue;

+  cand_pref = operand_equal_p (cand->iv->step,

+   info->iv->step, 0)

+  ? 4 : 0;

+  cand_pref

++= TYPE_MODE (TREE_TYPE (cand->iv->base))

+   == TYPE_MODE (TREE_TYPE (info->iv->base))

+   ? 2 : 0;

+  cand_pref

++= TREE_CODE (cand->iv->base) == INTEGER_CST

+   ? 1 : 0;

+  if (best_cand == NULL || best_pref < cand_pref)

+{

+  best_cand = cand;

+  best_pref = cand_pref;

+}

+}

+  if (best_cand == NULL)

+BREAK_FROM_IMM_USE_STMT (imm_iter);

+

+  comp = get_computation_at (data->current_loop,

+ &dummy_use, best_cand,

+ SSA_NAME_DEF_STMT (info->iv->ssa_name));

+  if (comp == NULL_TREE)

+BREAK_FROM_IMM_USE_STMT (imm_iter);

+  /* "gimplify" into DEBUG temporaries expression comp,

+ insert immediately after

+ SSA_NAME_DEF_STMT (info->iv->ssa_name).

+ Set comp to the final DEBUG_EXPR_DECL.  */

+#if 1

+  (void) comp;

+  BREAK_FROM_IMM_USE_STMT (imm_iter);

+#endif

+}

+

+  FOR_EACH_IMM_USE_ON_STMT (use_p, imm_iter)

+SET_USE (use_p, comp);

+

+  update_stmt (stmt);

+}

+}

+}

 }



   release_defs_bitset (toremove);

[Bug c++/54986] Internal Error: segmentation fault

[vanicat at debian dot org]

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

--- Comment #2 from Rémi Vanicat  2012-10-19 
14:13:21 UTC ---
Created attachment 28492
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28492
Small test case

I've isolated the bug to a relatively small file (140 line, with no #include),
here it is.

[Bug c++/54986] Internal Error: segmentation fault

[markus at trippelsdorf dot de]

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



Markus Trippelsdorf  changed:



   What|Removed |Added



 CC||markus at trippelsdorf dot

   ||de



--- Comment #3 from Markus Trippelsdorf  
2012-10-19 14:34:09 UTC ---

A little bit further reduced:



struct A;

struct B

{

  int *_ptr;

  bool operator==(B *p1)

  {

return p1->_ptr;

  }

};

struct C {

  A* ref_SYMBptr();

};

struct A

{

  B sommet;

};

typedef C *gen_op_context;

struct D

{

  D(gen_op_context) {}

};



D c(0);

const long d = (long)&c;

B *const   e = (B *)&d;



static bool

fn1(C& p1)

{

  return p1.ref_SYMBptr()->sommet == e;

}



void

fn2()

{

  C b;

  fn1(b);

}

[Bug target/54988] New: fpmath=sse target pragma causes inlining failure because of target specific option mismatch

[gcc at blino dot org]

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



 Bug #: 54988

   Summary: fpmath=sse target pragma causes inlining failure

because of target specific option mismatch

Classification: Unclassified

   Product: gcc

   Version: 4.7.2

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: target

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

ReportedBy: g...@blino.org

CC: loic.yh...@gmail.com, thi...@kde.org





#pragma GCC target "fpmath=sse"



static inline __attribute__((always_inline)) int a(int x) { return x; }



int b(int src)

{

return a(src);

}



$ gcc -O1 ./qdrawhelper_test.cpp -c

./qdrawhelper_test.cpp: In function 'int b(int)':

./qdrawhelper_test.cpp:3:50: error: inlining failed in call to always_inline

'int a(int)': target specific option mismatch

./qdrawhelper_test.cpp:7:17: error: called from here



I have the patch from bug 33763 applied in this gcc 4.7.2 build, if that

matters.



This bug initially happened when building Qt5 with gcc -m32 on a x86_64 host

(gcc being configured without any --with-arch_32 option), in

qt5/qtbase/src/gui/painting/qdrawhelper.cpp:

In file included from

../../include/QtGui/5.0.0/QtGui/private/qdrawhelper_p.h:1:0,

 from

/home/sah0146/dev/workspaces/pc32/stb/opensource/LGPL/qt/vendor/qt.gitorious.org/MAIN/qt5/qtbase/src/gui/painting/qdrawhelper.cpp:54:

../../include/QtGui/5.0.0/QtGui/private/../../../../../../../qt5/qtbase/src/gui/painting/qdrawhelper_p.h:

In function 'int multiply_op(int, int, int, int)':

../../include/QtGui/5.0.0/QtGui/private/../../../../../../../qt5/qtbase/src/gui/painting/qdrawhelper_p.h:797:30:

error: inlining failed in call to always_inline 'int qt_div_255(int)': target

specific option mismatch

/home/sah0146/dev/workspaces/pc32/stb/opensource/LGPL/qt/vendor/qt.gitorious.org/MAIN/qt5/qtbase/src/gui/painting/qdrawhelper.cpp:2498:70:

error: called from here



Bug 41201 might be related, even if it mentions C++ only.

[Bug debug/54971] SRA pessimizes debug info by not creating debug stmts for fields without replacements

[jamborm at gcc dot gnu.org]

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



--- Comment #3 from Martin Jambor  2012-10-19 
16:01:20 UTC ---

Created attachment 28493

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

Untested patch



I'm currently bootstrapping and testing this patch.

[Bug tree-optimization/54978] Add ability to provide vectorized functions

[ddesics at gmail dot com]

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



--- Comment #3 from Daniel Davis  2012-10-19 16:14:36 
UTC ---

Obviously, it would be nice if gcc can build the functions if they are pure

functions.  But that would require somehow knowing that those functions should

be built and having access to the code, which may not be the case for something

like a library.  



On second thought, the attribute would best go with declaration of the

vectorized function.  So, to rewrite my example, 



double fx(double x); 

v2df fx_v2df(v2df x) __attribute__((vectorized_alias(fx,double,16))); 

v4df fx_v4df(v4df x) __attribute__((vectorized_alias(fx,double,32)));



That would let the compiler know exactly what could be replaced, although it

should be able to figure out the argument types from the declarations.



So I see two potential optimizations here.  The first is a way to let the

compiler know that vectorized functions are available.  The second would be to

let the auto-vectorizer create vectorized forms of functions.

[Bug middle-end/54885] [4.8 Regression] lto/profiledbootstrap broken

[markus at trippelsdorf dot de]

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



Markus Trippelsdorf  changed:



   What|Removed |Added



 Status|NEW |RESOLVED

 Resolution||FIXED



--- Comment #5 from Markus Trippelsdorf  
2012-10-19 16:24:24 UTC ---

Fixed by r192526.

[Bug target/54989] New: FAIL: gcc.dg/hoist-register-pressure.c scan-rtl-dump hoist "PRE/HOIST: end of bb .* copying expression" on darwin

[howarth at nitro dot med.uc.edu]

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



 Bug #: 54989

   Summary: FAIL: gcc.dg/hoist-register-pressure.c scan-rtl-dump

hoist "PRE/HOIST: end of bb .* copying expression" on

darwin

Classification: Unclassified

   Product: gcc

   Version: 4.7.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: target

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

ReportedBy: howa...@nitro.med.uc.edu





Created attachment 28494

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

assembly file for gcc.dg/hoist-register-pressure.c  on x86_64-apple-darwin12 at

-m32



On x86_64-apple-darwin12, the new testcase for hoisting fails as...



FAIL: gcc.dg/hoist-register-pressure.c scan-rtl-dump hoist "PRE/HOIST: end of

bb .* copying expression"



at -m32 and r192611. The test passes at -m64.



Using built-in specs.

COLLECT_GCC=gcc-fsf-4.8

COLLECT_LTO_WRAPPER=/sw/lib/gcc4.8/libexec/gcc/x86_64-apple-darwin12.2.0/4.8.0/lto-wrapper

Target: x86_64-apple-darwin12.2.0

Configured with: ../gcc-4.8-20121019/configure --prefix=/sw

--prefix=/sw/lib/gcc4.8 --mandir=/sw/share/man --infodir=/sw/lib/gcc4.8/info

--enable-languages=c,c++,fortran,lto,objc,obj-c++,java --with-gmp=/sw

--with-libiconv-prefix=/sw --with-isl=/sw --with-cloog=/sw --with-mpc=/sw

--with-system-zlib --enable-checking=yes --x-includes=/usr/X11R6/include

--x-libraries=/usr/X11R6/lib --program-suffix=-fsf-4.8

Thread model: posix

gcc version 4.8.0 20121019 (experimental) (GCC)

[Bug c/54983] ARM gcc creates invalid assembly: bad immediate value for 8-bit offset (1024)

[rearnsha at gcc dot gnu.org]

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



Richard Earnshaw  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||INVALID



--- Comment #3 from Richard Earnshaw  2012-10-19 
16:54:41 UTC ---

The 'o' in "+Qo" is invalid for this instruction.  There is, unfortunately, no

way to specify in inline assembly instructions the precise addressing range of

strh.



I think your safest bet is to use "Q".

[Bug middle-end/54945] Too strong non-aliasing analysis?

[mpolacek at gcc dot gnu.org]

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



--- Comment #15 from Marek Polacek  2012-10-19 
16:55:13 UTC ---

Author: mpolacek

Date: Fri Oct 19 16:53:39 2012

New Revision: 192617



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

Log:

PR54945



Modified:

trunk/gcc/ChangeLog

trunk/gcc/fold-const.c

[Bug middle-end/54945] Too strong non-aliasing analysis?

[mpolacek at gcc dot gnu.org]

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



--- Comment #16 from Marek Polacek  2012-10-19 
17:01:37 UTC ---

Author: mpolacek

Date: Fri Oct 19 17:00:50 2012

New Revision: 192618



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

Log:

PR54945



Modified:

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

branches/gcc-4_7-branch/gcc/fold-const.c

[Bug middle-end/54945] Too strong non-aliasing analysis?

[mpolacek at gcc dot gnu.org]

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



--- Comment #17 from Marek Polacek  2012-10-19 
17:03:40 UTC ---

Author: mpolacek

Date: Fri Oct 19 17:03:07 2012

New Revision: 192619



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

Log:

PR54945



Modified:

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

branches/gcc-4_6-branch/gcc/fold-const.c

[Bug middle-end/54945] Too strong non-aliasing analysis?

[mpolacek at gcc dot gnu.org]

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



Marek Polacek  changed:



   What|Removed |Added



 Status|ASSIGNED|RESOLVED

 Resolution||FIXED



--- Comment #18 from Marek Polacek  2012-10-19 
17:04:04 UTC ---

Fixed.

[Bug fortran/54990] New: [4.8 Regression] [OOP] ICE in tree_operand_check on SELECT TYPE

[janus at gcc dot gnu.org]

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

 Bug #: 54990
   Summary: [4.8 Regression] [OOP] ICE in tree_operand_check on
SELECT TYPE
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ja...@gcc.gnu.org
CC: abenso...@gmail.com


Reported by Andrew Benson at
http://gcc.gnu.org/ml/fortran/2012-10/msg00094.html. Reduced test case:


program test
  implicit none

  type :: ncBhStd
  end type

  type :: tn
class (ncBhStd), allocatable, dimension(:) :: cBh
  end type

  type(tn), target :: a

  select type (q => a%cBh(1))
  end select

end


Compiles cleanly with 4.7, but trunk gives the following ICE:


internal compiler error: tree check: expected class ‘expression’, have
‘declaration’ (var_decl) in tree_operand_check, at tree.h:4109
 program test
 ^
linux-vdso.so.1: No such file or directory
0xcf07be tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
/home/jweil/gcc48/trunk/gcc/tree.c:8947
0x62d6a8 expr_check
/home/jweil/gcc48/trunk/gcc/tree.h:3845
0x62d6a8 tree_operand_check
/home/jweil/gcc48/trunk/gcc/tree.h:4109
0x62d6a8 gfc_get_vptr_from_expr(tree_node*)
/home/jweil/gcc48/trunk/gcc/fortran/trans-expr.c:199
0x667411 trans_associate_var
/home/jweil/gcc48/trunk/gcc/fortran/trans-stmt.c:1256
0x66771c gfc_trans_block_construct(gfc_code*)
/home/jweil/gcc48/trunk/gcc/fortran/trans-stmt.c:1319
0x5fb900 trans_code
/home/jweil/gcc48/trunk/gcc/fortran/trans.c:1412
0x5fbc62 gfc_trans_code(gfc_code*)
/home/jweil/gcc48/trunk/gcc/fortran/trans.c:1573
0x62add7 gfc_generate_function_code(gfc_namespace*)
/home/jweil/gcc48/trunk/gcc/fortran/trans-decl.c:5353
0x5fbca6 gfc_generate_code(gfc_namespace*)
/home/jweil/gcc48/trunk/gcc/fortran/trans.c:1590
0x59d211 translate_all_program_units
/home/jweil/gcc48/trunk/gcc/fortran/parse.c:4467
0x59d877 gfc_parse_file()
/home/jweil/gcc48/trunk/gcc/fortran/parse.c:4681
0x5e8900 gfc_be_parse_file
/home/jweil/gcc48/trunk/gcc/fortran/f95-lang.c:191

[Bug fortran/54224] [4.8 Regression] Bogus -Wunused-function warning with static function

[janus at gcc dot gnu.org]

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



--- Comment #11 from janus at gcc dot gnu.org 2012-10-19 17:15:01 UTC ---

Author: janus

Date: Fri Oct 19 17:14:46 2012

New Revision: 192620



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

Log:

2012-10-19  Janus Weil  



PR fortran/54224

* trans-expr.c (conv_function_val): Set TREE_USED.



2012-10-19  Janus Weil  



PR fortran/54224

* gfortran.dg/warn_unused_function.f90: New.



Added:

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

Modified:

trunk/gcc/fortran/ChangeLog

trunk/gcc/fortran/trans-expr.c

trunk/gcc/testsuite/ChangeLog

[Bug fortran/54224] [4.8 Regression] Bogus -Wunused-function warning with static function

[janus at gcc dot gnu.org]

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



--- Comment #12 from janus at gcc dot gnu.org 2012-10-19 17:22:44 UTC ---

r192620 fixes the bogus warning on comment 0, which was a 4.8 regression.



Leftover things to check/fix:

 * unused-warnings for internal procedues

 * unused-warnings for module variables

 * ... ?

[Bug fortran/54224] [4.8 Regression] Bogus -Wunused-function warning with static function

[janus at gcc dot gnu.org]

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



--- Comment #13 from janus at gcc dot gnu.org 2012-10-19 17:48:50 UTC ---

(In reply to comment #12)

> Leftover things to check/fix:

>  * unused-warnings for internal procedues



Test case:



module m

private

contains

 subroutine s1

 contains

   subroutine s2

   end subroutine

 end subroutine

end module



program test

contains

  subroutine s3

  end subroutine

end





With -Wunused-function, gfortran currently only warns for s1, but not for s2

and s3. (With 4.7, no warning is thrown at all.)

[Bug fortran/54224] Warn for unused (private) module variables and internal procedures

[janus at gcc dot gnu.org]

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



janus at gcc dot gnu.org changed:



   What|Removed |Added



Summary|[4.8 Regression] Bogus  |Warn for unused (private)

   |-Wunused-function warning   |module variables and

   |with static function|internal procedures



--- Comment #14 from janus at gcc dot gnu.org 2012-10-19 17:54:24 UTC ---

(In reply to comment #12)

>  * unused-warnings for module variables



Test case:





module m

 integer :: j

 integer, private :: k

end module



program test

  integer :: i

end





With -Wunused-variable, gfortran warns for i, but should also warn for k (not

for j).



(adjusting title for leftover issues ...)

[Bug rtl-optimization/54991] New: [LRA] internal compiler error: in lra_assign, at lra-assigns.c:1361

[Joost.VandeVondele at mat dot ethz.ch]

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



 Bug #: 54991

   Summary: [LRA] internal compiler error: in lra_assign, at

lra-assigns.c:1361

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: rtl-optimization

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

ReportedBy: joost.vandevond...@mat.ethz.ch





I have tested LRA (20121014 (experimental) [lra revision 192621]) on CP2K and

find the following ICE:



/data/vjoost/gnu/cp2k/cp2k/makefiles/../src/dbcsr_lib/dbcsr_operations.F:4471:0:

internal compiler error: in lra_assign, at lra-assigns.c:1361

   END SUBROUTINE dbcsr_lanczos_extremal_eig

 ^

0x8621b2 lra_assign()

../../gcc/gcc/lra-assigns.c:1361

0x85e2f2 lra(_IO_FILE*)

../../gcc/gcc/lra.c:2309

0x826696 do_reload

../../gcc/gcc/ira.c:4613

0x826696 rest_of_handle_reload

../../gcc/gcc/ira.c:4719

Please submit a full bug report,

with preprocessed source if appropriate.

Please include the complete backtrace with any bug report.

See  for instructions.

make[1]: *** [dbcsr_operations.o] Error 1

make[1]: Leaving directory

`/data/vjoost/gnu/cp2k/cp2k/obj/gfortran-test28/sopt'

make: *** [build] Error 2



Unfortunately, I don't know how to produce a small testcase, as this is

happening only for a compilation with '-fprofile-use'. I could tar the needed

mod files and .gdca if that is an option.



This is happening on x86_64:

-march=corei7 -mcx16 -msahf -mno-movbe -mno-aes -mno-pclmul -mpopcnt -mno-abm

-mno-lwp -mno-fma -mno-fma4 -mno-xop -mno-bmi -mno-bmi2 -mno-tbm -mno-avx

-mno-avx2 -msse4.2 -msse4.1 -mno-lzcnt -mno-rtm -mno-hle -mno-rdrnd -mno-f16c

-mno-fsgsbase -mno-rdseed -mno-prfchw -mno-adx --param l1-cache-size=32 --param

l1-cache-line-size=64 --param l2-cache-size=24576 -mtune=corei7

[Bug rtl-optimization/54850] [4.8 Regression] FAIL: gcc.c-torture/execute/20041113-1.c execution, -Os

[dave.anglin at bell dot net]

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



--- Comment #10 from dave.anglin at bell dot net 2012-10-19 18:33:27 UTC ---

I'm not seeing the fail with the candidate patch.

[Bug c++/54987] missed ambiguity in template function call

[pinskia at gcc dot gnu.org]

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



--- Comment #1 from Andrew Pinski  2012-10-19 
18:46:26 UTC ---

Comeau C/C++ 4.3.10.1 (Oct  6 2008 11:28:09) for ONLINE_EVALUATION_BETA2

Copyright 1988-2008 Comeau Computing.  All rights reserved.

MODE:strict errors C++ C++0x_extensions



"ComeauTest.c", line 47: error: more than one instance of overloaded function

"foo"

  matches the argument list, the choices that match are:

function template "void foo(T, Template1::type>)"

function template "void foo(T, Template2::type>)"

The argument types that you used are: (Argument1,

Template1)

foo( a, t );

^

[Bug rtl-optimization/54991] [LRA] internal compiler error: in lra_assign, at lra-assigns.c:1361

[Joost.VandeVondele at mat dot ethz.ch]

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



--- Comment #1 from Joost VandeVondele  
2012-10-19 18:58:31 UTC ---

Created attachment 28495

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

testcase, including source, .mod and .gcda files needed. README gives

compilation command needed

[Bug fortran/54992] New: [OOP] Wrong offset in the array offset calculation when using nonclass%class(index)%nonclass

[burnus at gcc dot gnu.org]

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



 Bug #: 54992

   Summary: [OOP] Wrong offset in the array offset calculation

when using nonclass%class(index)%nonclass

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Keywords: wrong-code

  Severity: normal

  Priority: P3

 Component: fortran

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

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

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





As reported by Andrew Benson in the thread starting at

http://gcc.gnu.org/ml/fortran/2012-10/msg00087.html



The problem is that gfortran generates the wrong code for:



targetNode%cBh(2)%hostNode => targetNode



where "cBh" is a polymorphic array. The offset is calculated as



  ((base_type *)targetNode->_data->cBh->_data)[ index ].host





Instead of the proper:



  targetNode->_data->cBh->_data.data

   + (index * targetNode->_data->cBh->_vptr_size)





Test case:  http://gcc.gnu.org/ml/fortran/2012-10/msg00100.html



Analysis:   http://gcc.gnu.org/ml/fortran/2012-10/msg00101.html

[Bug fortran/54992] [4.8 Regression] [OOP] Wrong offset in the array offset calculation when using nonclass%class(index)%nonclass

[janus at gcc dot gnu.org]

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



janus at gcc dot gnu.org changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2012-10-19

Summary|[OOP] Wrong offset in the   |[4.8 Regression] [OOP]

   |array offset calculation|Wrong offset in the array

   |when using  |offset calculation when

   |nonclass%class(index)%noncl |using

   |ass |nonclass%class(index)%noncl

   ||ass

 Ever Confirmed|0   |1



--- Comment #1 from janus at gcc dot gnu.org 2012-10-19 21:23:36 UTC ---

(In reply to comment #0)

> Test case:  http://gcc.gnu.org/ml/fortran/2012-10/msg00100.html



Note: While this test case fails with trunk, it seems to work with 4.7.

[Bug fortran/54992] [4.8 Regression] [OOP] Wrong offset in the array offset calculation when using nonclass%class(index)%nonclass

[dominiq at lps dot ens.fr]

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



--- Comment #2 from Dominique d'Humieres  2012-10-19 
21:37:08 UTC ---

Revision 187190 is OK, revision 187198 is not -> likely r187192.

[Bug rtl-optimization/54993] New: [4.8 regression] PIC register not marked as live

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

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



 Bug #: 54993

   Summary: [4.8 regression] PIC register not marked as live

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Keywords: wrong-code

  Severity: normal

  Priority: P3

 Component: rtl-optimization

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

ReportedBy: sch...@linux-m68k.org

CC: ste...@gcc.gnu.org

Target: m68k-*-*





Created attachment 28496

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

preprocessed from libstdc++-v3/testsuite/30_threads/future/members/wait.cc



The patch for bug 38711 is causing the PIC register not being marked as live.



Compiled with -O2 -std=gnu++0x.



@@ -1668,17 +1663,16 @@

.cfi_startproc

.cfi_personality 0,__gxx_personality_v0

.cfi_lsda 0,.LLSDA2633

-   link.w %fp,#-72

+   link.w %fp,#-68

.cfi_offset 14, -8

.cfi_def_cfa 14, 8

movem.l #12348,-(%sp)

-   .cfi_offset 2, -104

-   .cfi_offset 3, -100

-   .cfi_offset 10, -96

-   .cfi_offset 11, -92

-   .cfi_offset 12, -88

-   .cfi_offset 13, -84

-   lea (%pc, _GLOBAL_OFFSET_TABLE_@GOTPC), %a5

+   .cfi_offset 2, -100

+   .cfi_offset 3, -96

+   .cfi_offset 10, -92

+   .cfi_offset 11, -88

+   .cfi_offset 12, -84

+   .cfi_offset 13, -80

clr.l -48(%fp)

clr.l -44(%fp)

pea 104.w

[Bug middle-end/54961] [4.8 Regression] FAIL: gfortran.dg/pr48757.f -O (internal compiler error) after revision 192440

[steven at gcc dot gnu.org]

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



--- Comment #2 from Steven Bosscher  2012-10-19 
21:57:54 UTC ---

Something I'm going to test:



Index: ira-lives.c

===

--- ira-lives.c (revision 192571)

+++ ira-lives.c (working copy)

@@ -1373,6 +1373,19 @@ process_bb_node_lives (ira_loop_tree_nod

   if (bb_has_abnormal_pred (bb))

{

 #ifdef STACK_REGS

+ /* Mark all stack mode registers and stack hard registers live

+so that they will conflict and allocation across the abnormal

+edge is impossible.

+Stack registers must be treated as live in the traditional,

+DF_LR-like sense, because compensation code may have to be

+introduced on edges.  The register allocator treats the stack

+registers like all other, non-stack registers.  It doesn't

+know that stack shuffling may be required and may allocate

+a partially available stack reg in ways that result in the

+need for compensation code on abnormal edges.  See PR54961.  */

+ EXECUTE_IF_SET_IN_BITMAP (DF_LR_IN (bb), FIRST_PSEUDO_REGISTER, j,

bi)

+   if (IS_STACK_MODE (GET_MODE (regno_reg_rtx[j])))

+ mark_pseudo_regno_live (j);

  EXECUTE_IF_SET_IN_SPARSESET (objects_live, px)

{ 

  ira_allocno_t a = OBJECT_ALLOCNO (ira_object_id_map[px]);

[Bug tree-optimization/54985] [4.7/4.8 Regression] dom optimization erroneous remove conditional goto.

[law at redhat dot com]

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



--- Comment #6 from Jeffrey A. Law  2012-10-19 22:00:45 
UTC ---

This is definitely something introduced when I extended the threading code last

year.



When threading across a backedge in the CFG we run the risk of simplifying a

conditional using equivalences which are valid for one loop iteration, but not

the next iteration.



There's a bit of special casing done to handle this. We either need to add

another case or actually invalidate the temporary equivalences we made for the

statements in the loop.  The first is pretty trivial, but I want to ponder the

special case code over the weekend for it's overall safety/correctness.



I don't see any difficulty wrapping this up early next week.



Jeff

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

[dominiq at lps dot ens.fr]

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



--- Comment #8 from Dominique d'Humieres  2012-10-19 
22:15:09 UTC ---

The test libgomp.graphite/force-parallel-6.c fails to execute with a bus error

on x86_64-apple-darwin10 at revision 192538. Is it related to this PR or should

I open a new one?

[Bug middle-end/54961] [4.8 Regression] FAIL: gfortran.dg/pr48757.f -O (internal compiler error) after revision 192440

[dominiq at lps dot ens.fr]

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



--- Comment #3 from Dominique d'Humieres  2012-10-19 
23:18:39 UTC ---

> Something I'm going to test:



It does not fix the ICE, at least on x86_64-apple-darwin10.

[Bug c++/54994] New: [4.8 regression] New ICE in tsubst_copy

[bangerth at gmail dot com]

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



 Bug #: 54994

   Summary: [4.8 regression] New ICE in tsubst_copy

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: c++

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

ReportedBy: bange...@gmail.com





May or may not be related to PR 54844:



This little piece of code has recently started to produce an ICE on mainline:

..

template  class X {};



template  struct A {

X<(sizeof(T) x;

};



A a;

..



> c++ -c numerics/a.cc 

numerics/a.cc: In instantiation of 'struct A':

numerics/a.cc:7:8:   required from here

numerics/a.cc:4:24: internal compiler error: in tsubst_copy, at cp/pt.c:12387

 X<(sizeof(T) x;

^

linux-vdso.so.1: No such file or directory

0x596d03 tsubst_copy

../../mainline/gcc/cp/pt.c:12387

0x586762 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,

bool)

../../mainline/gcc/cp/pt.c:13514

0x585b81 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,

bool)

../../mainline/gcc/cp/pt.c:13539

0x585602 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,

bool)

../../mainline/gcc/cp/pt.c:13494

0x58e6a4 tsubst_expr

../../mainline/gcc/cp/pt.c:13194

0x5a1002 tsubst_template_arg

../../mainline/gcc/cp/pt.c:9039

0x5a75e2 tsubst_template_args

../../mainline/gcc/cp/pt.c:9489

0x5add71 tsubst_aggr_type

../../mainline/gcc/cp/pt.c:9686

0x59e773 tsubst(tree_node*, tree_node*, int, tree_node*)

../../mainline/gcc/cp/pt.c:11039

0x599216 tsubst_decl

../../mainline/gcc/cp/pt.c:10329

0x59eb8c tsubst(tree_node*, tree_node*, int, tree_node*)

../../mainline/gcc/cp/pt.c:10965

0x5c4a5c instantiate_class_template_1

../../mainline/gcc/cp/pt.c:8778

0x5c4a5c instantiate_class_template(tree_node*)

../../mainline/gcc/cp/pt.c:9020

0x64eb2b complete_type(tree_node*)

../../mainline/gcc/cp/typeck.c:134

0x54b548 start_decl_1(tree_node*, bool)

../../mainline/gcc/cp/decl.c:4621

0x5675e1 start_decl(cp_declarator const*, cp_decl_specifier_seq*, int,

tree_node*, tree_node*, tree_node**)

../../mainline/gcc/cp/decl.c:4584

0x6415dc cp_parser_init_declarator

../../mainline/gcc/cp/parser.c:15887

0x641f6f cp_parser_simple_declaration

../../mainline/gcc/cp/parser.c:10560

0x63ce27 cp_parser_block_declaration

../../mainline/gcc/cp/parser.c:10441

0x647f3b cp_parser_declaration

../../mainline/gcc/cp/parser.c:10338

Please submit a full bug report,

with preprocessed source if appropriate.

Please include the complete backtrace with any bug report.

See  for instructions.





Best

 W.

[Bug c++/54844] [4.8 Regression] ice tsubst_copy, at cp/pt.c:12352

[bangerth at gmail dot com]

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



Wolfgang Bangerth  changed:



   What|Removed |Added



 CC||bangerth at gmail dot com



--- Comment #7 from Wolfgang Bangerth  2012-10-20 
02:23:30 UTC ---

May be related to PR 54994.

This Company featured in our Newest "Explode Report"

[Clare Lott]

Morning Day Traders!!!
T_LP C is making ripples! Top Queried Stock On Board Central This 
Morning! Get Your Orders In Pronto!!!


Trade Date: Oct, 22nd
Company Name: TELPAC INDUSTRIES, INC.
Ticker: T_LP C
Price: .32
Long Term Target: 2.50

T_LP C has hired established mobile application developers Revolution 
Games, Inc. to make 2 sports games that will contain graphics intense, 
multi-player gaming. Instead of charging consumers a set cost to buy the 
game, T_LP C utilize the micro payment system pioneered by developers 
like Microsoft. Micro Payments urge gamers to purchase in-game items to 
gain an upper hand over other gamers. Both videogames will be released 
in Q4 for the 100ml+ users on the Android Market and Apple App Store.

[Bug target/54989] FAIL: gcc.dg/hoist-register-pressure.c scan-rtl-dump hoist "PRE/HOIST: end of bb .* copying expression" on darwin

[amker.cheng at gmail dot com]

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



bin.cheng  changed:



   What|Removed |Added



 CC||amker.cheng at gmail dot

   ||com



--- Comment #1 from bin.cheng  2012-10-20 
05:40:08 UTC ---

The failure is caused by higher register pressure in the THEN branch of the

case, though I am not sure why the register pressure is higher than x86-linux.



This can be fixed by simplifying test case as below:



/* { dg-options "-Os -fdump-rtl-hoist" }  */

/* { dg-final { scan-rtl-dump "PRE/HOIST: end of bb .* copying expression"

"hoist" } } */



#define BUF 100

int a[BUF];



void com (int);

void bar (int);



int foo (int x, int y, int z)

{

  /* "x+y" won't be hoisted if "-fira-hoist-pressure" is disabled,

 because its rtx_cost is too small.  */

  if (z)

{

  a[1] = a[0];

  a[2] = a[1];

  a[3] = a[2];

  a[4] = a[3];

  a[5] = a[4];

  a[6] = a[5];

  a[7] = a[6];

  com (x+y);

}

  else

{

  bar (x+y);

}



  return 0;

}



I will send a patch fixing this.

[Bug c++/54995] New: Converting lambda to C-style functions when there is template

[temtaime at gmail dot com]

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



 Bug #: 54995

   Summary: Converting lambda to C-style functions when there is

template

Classification: Unclassified

   Product: gcc

   Version: unknown

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: c++

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

ReportedBy: temta...@gmail.com





This code is okay(gets a error):

http://liveworkspace.org/code/1110068f996076a08d835ab18789c034



App crash:

http://liveworkspace.org/code/3d5e51c9059ea4f37ce2d0d23739d374



Minimal testcase:

http://liveworkspace.org/code/30fd3222a9650d68b7f9746754e86f03

[Bug target/54963] [4.8 Regression] Wrong code generated for libgfortran/generated/eoshift3_8.c on SH

[kkojima at gcc dot gnu.org]

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



Kazumoto Kojima  changed:



   What|Removed |Added



 CC||olegendo at gcc dot gnu.org

  Component|middle-end  |target

Summary|Wrong code generated for|[4.8 Regression] Wrong code

   |libgfortran/generated/eoshi |generated for

   |ft3_8.c on SH   |libgfortran/generated/eoshi

   ||ft3_8.c on SH



--- Comment #1 from Kazumoto Kojima  2012-10-20 
06:33:06 UTC ---

It looks that the problematic code run through a wrong flow

and the above was misleading.  It seems that the change



r184829 | olegendo | 2012-03-03 06:21:13 +0900 (Sat, 03 Mar 2012) | 8 lines



PR target/49486

* config/sh/sh.md (negdi2): Add TARGET_SH1 condition.

(absdi2): New expander.

(*absdi2, *negabsdi2, negdi_cond): New insns and splits.

* gcc.target/sh/pr49468-si.c: Skip unsupported test for SH64.

* gcc.target/sh/pr49468-di.c: New.



causes this.  After reload, there is an insn for abs(sh):



(insn 432 431 1393 39 (set (reg:DI 2 r2)

(abs:DI (reg:DI 1 r1))) eoshift.c:167 189 {*absdi2}

 (nil))



which is splitted into



(insn 1607 431 1609 39 (set (reg:SI 147 t)

(ge:SI (reg:SI 2 r2 [+4 ])

(const_int 0 [0]))) eoshift.c:167 13 {cmpgesi_t}

 (nil))

(insn 1609 1607 1610 39 (set (reg:SI 2 r2)

(reg:SI 1 r1)) eoshift.c:167 234 {movsi_ie}

 (nil))

(insn 1610 1609 1611 39 (set (reg:SI 3 r3 [+4 ])

(reg:SI 2 r2 [+4 ])) eoshift.c:167 234 {movsi_ie}

 (nil))

(jump_insn 1611 1610 1626 39 (set (pc)

(if_then_else (ne (reg:SI 147 t)

(const_int 0 [0]))

...



The insn 1609 changes r2 before its original value is used.

[Bug c++/54994] [4.8 regression] New ICE in tsubst_copy

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 CC||jakub at gcc dot gnu.org

 Resolution||DUPLICATE



--- Comment #1 from Jakub Jelinek  2012-10-20 
06:55:45 UTC ---

Dup.



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

[Bug c++/54844] [4.8 Regression] ice tsubst_copy, at cp/pt.c:12352

[jakub at gcc dot gnu.org]

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



--- Comment #8 from Jakub Jelinek  2012-10-20 
06:55:45 UTC ---

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