[Bug target/54815] [avr] missed optimization with operations with constant operands

[gjl at gcc dot gnu.org]

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



Georg-Johann Lay  changed:



   What|Removed |Added



   Priority|P3  |P4

 Status|UNCONFIRMED |RESOLVED

  Component|other   |target

 Resolution||FIXED

   Target Milestone|--- |4.8.0



--- Comment #2 from Georg-Johann Lay  2012-10-13 
06:38:07 UTC ---

fixed

[Bug go/54918] New: libgo.so.0 is not runtime compatible between gcc-4.6.2 and gcc-4.7.x

[gafton at gmail dot com]

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



 Bug #: 54918

   Summary: libgo.so.0 is not runtime compatible between gcc-4.6.2

and gcc-4.7.x

Classification: Unclassified

   Product: gcc

   Version: 4.7.2

Status: UNCONFIRMED

  Severity: major

  Priority: P3

 Component: go

AssignedTo: i...@airs.com

ReportedBy: gaf...@gmail.com





gcc-4.6.2 shipped a libgo.so.0.0.0 runtime library.



Compiling a simple hello world binary against that libgo worked okay:



bash$ cat hello.go

package main

import "fmt"

func main() {

  fmt.Println("Hello, world")

}

bash$ gccgo -o hello hello.go

bash$ ./hello

Hello, world



When  the gcc runtime is updated on the system to gcc-4.7.2, the previouslt

compiled binary against the gcc-4.6.2 libgo.so.0 no longer works:



bash$ ./hello

./hello: symbol lookup error: ./hello: undefined symbol: libgo_os.os.Envs



Clearly the two libgo.so.0.0.0 libraries are not compatible between gcc-4.6.x

and gcc-4.7.x - as such, the soname versioning should reflect that.

[Bug c++/54913] [4.8 Regression] '#'indirect_ref' not supported by dump_decl#' is not a member of 'E'

[redi at gcc dot gnu.org]

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



--- Comment #3 from Jonathan Wakely  2012-10-13 
00:00:00 UTC ---

I'll bisect ...

[Bug target/54602] [SH] Register pop insn not put in rts delay slot

[olegendo at gcc dot gnu.org]

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



--- Comment #7 from Oleg Endo  2012-10-12 23:22:52 
UTC ---

Author: olegendo

Date: Fri Oct 12 23:22:48 2012

New Revision: 192417



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

Log:

PR target/54602

* config/sh/sh.md: Correct define_delay for return insns.

(*movsi_pop): Delete.



PR target/54602

* gcc.target/sh/pr54602-1.c: New.

* gcc.target/sh/pr54602-2.c: New.

* gcc.target/sh/pr54602-3.c: New.

* gcc.target/sh/pr54602-4.c: New.





Added:

trunk/gcc/testsuite/gcc.target/sh/pr54602-1.c

trunk/gcc/testsuite/gcc.target/sh/pr54602-2.c

trunk/gcc/testsuite/gcc.target/sh/pr54602-3.c

trunk/gcc/testsuite/gcc.target/sh/pr54602-4.c

Modified:

trunk/gcc/ChangeLog

trunk/gcc/config/sh/sh.md

trunk/gcc/testsuite/ChangeLog

[Bug target/54680] [SH] Unnecessary int-float-int conversion of fsca fixed point input

[olegendo at gcc dot gnu.org]

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



--- Comment #2 from Oleg Endo  2012-10-12 23:19:32 
UTC ---

Author: olegendo

Date: Fri Oct 12 23:19:27 2012

New Revision: 192416



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

Log:

PR target/54680

* config/sh/sh.c (sh_fsca_sf2int, sh_fsca_int2sf): Fix swapped

comments.

* config/sh/predicates.md (fpul_operand): Add comment.

(fpul_fsca_operand, fsca_scale_factor): New predicates.

* config/sh/sh.md (fsca): Move below sincossf3 expander.  Convert to

insn_and_split.  Use fpul_fsca_operand and fsca_scale_factor predicates.

Simplify fpul operand in splitter.



PR target/54680

* gcc.target/sh/pr54680.c: New.





Added:

trunk/gcc/testsuite/gcc.target/sh/pr54680.c

Modified:

trunk/gcc/ChangeLog

trunk/gcc/config/sh/predicates.md

trunk/gcc/config/sh/sh.c

trunk/gcc/config/sh/sh.md

trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/38711] ira should not be using df-lr except at -O1.

[steven at gcc dot gnu.org]

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



--- Comment #1 from Steven Bosscher  2012-10-12 
22:34:49 UTC ---

Created attachment 28438

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

Use DF_LIVE where possible in IRA



Only in reload1.c should we continue to use DF_LR

Bootstrapped on x86_64-unknown-linux-gnu.

[Bug fortran/54917] [4.7/4.8 Regression] [OOP] TRANSFER on polymorphic variable causes ICE

[dominiq at lps dot ens.fr]

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



Dominique d'Humieres  changed:



   What|Removed |Added



 CC||tkoenig at gcc dot gnu.org



--- Comment #3 from Dominique d'Humieres  2012-10-12 
22:06:44 UTC ---

It could be r177486 or 177486?

[Bug fortran/54917] [4.7/4.8 Regression] [OOP] TRANSFER on polymorphic variable causes ICE

[dominiq at lps dot ens.fr]

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



Dominique d'Humieres  changed:



   What|Removed |Added



Summary|[OOP] TRANSFER on   |[4.7/4.8 Regression] [OOP]

   |polymorphic variable causes |TRANSFER on polymorphic

   |ICE |variable causes ICE



--- Comment #2 from Dominique d'Humieres  2012-10-12 
21:56:30 UTC ---

Revision 176696 (2011-07-23) is OK; revision 177649 (2011-08-11) is not.

[Bug fortran/54871] [4.8 regression] gfortran.dg/vector_subscript_1.f90 FAILs

[ebotcazou at gcc dot gnu.org]

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



Eric Botcazou  changed:



   What|Removed |Added



 Status|NEW |ASSIGNED

 AssignedTo|unassigned at gcc dot   |ebotcazou at gcc dot

   |gnu.org |gnu.org



--- Comment #4 from Eric Botcazou  2012-10-12 
21:37:35 UTC ---

Created attachment 28437

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

Reduced testcase



The loop2_unroll dump reads:



Loop 3 is simple:

  simple exit 10 -> 12

  number of iterations: (const_int -1 [0x])

  upper bound: 1073741823

  realistic bound: -1



The number of iterations is of course bogus.

[Bug fortran/54917] [OOP] TRANSFER on polymorphic variable causes ICE

[janus at gcc dot gnu.org]

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



janus at gcc dot gnu.org changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Keywords||ice-on-valid-code

   Last reconfirmed||2012-10-12

 CC||janus at gcc dot gnu.org

 Ever Confirmed|0   |1

Summary|transfer on polymorphic |[OOP] TRANSFER on

   |variable causes ICE |polymorphic variable causes

   |(gfc_target_expr_size)  |ICE



--- Comment #1 from janus at gcc dot gnu.org 2012-10-12 21:31:15 UTC ---

Thanks for reporting this. The following should already be enough to fix the

ICE on -Wsurprising:



Index: gcc/fortran/target-memory.c

===

--- gcc/fortran/target-memory.c (revision 192392)

+++ gcc/fortran/target-memory.c (working copy)

@@ -121,6 +121,7 @@ gfc_target_expr_size (gfc_expr *e)

 case BT_HOLLERITH:

   return e->representation.length;

 case BT_DERIVED:

+case BT_CLASS:

   {

/* Determine type size without clobbering the typespec for ISO C

   binding types.  */





But certainly some more modifications will be needed. I think our

implementation of TRANSFER is not really fit for handling polymorphic arguments

yet.

[Bug fortran/49111] Unnecessary warning for private interfaces having the BIND(C) attribute

[craig.powers at gmail dot com]

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



Craig Powers  changed:



   What|Removed |Added



 CC||craig.powers at gmail dot

   ||com



--- Comment #3 from Craig Powers  2012-10-12 
20:53:53 UTC ---

I see the accessibility denoted by PRIVATE/PUBLIC as conceptually different

from the accessibility denoted by BIND(C).  In addition to the fact that

BIND(C) does not distinguish an import from an export, there is also the

consideration that one might wish to hide the C-callable routine (marked with

BIND(C)) from other Fortran code by also marking it PRIVATE.



I'm in the process of producing a Fortran interface to a C library, and I find

that there are some instances where I want to declare the import as PRIVATE and

then provide a wrapper routine to take care of the Fortran-to-C stuff that is

mechanical e.g. converting a Fortran array.



Because my Fortran is a little rusty, and this is my first time making any

extended use of the BIND(C) features, the warning made me concerned that I

hadn't accomplished what I intended to accomplish.



I see this warning as far more likely to be a spurious complaint about valid

and intended usage than to be a useful hint about something unintended.

[Bug tree-optimization/54886] [4.8 Regression] FAIL: gcc.dg/graphite/pr(42521|42771).c (internal compiler error) due to revision 192219

[dominiq at lps dot ens.fr]

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



--- Comment #4 from Dominique d'Humieres  2012-10-12 
20:11:26 UTC ---

> Is r192219 the exact commit causing this regression?



r192218 is OK, r192219 is not. As usual, this does not rule out that r192219

only exposes a latent bug.

[Bug tree-optimization/54886] [4.8 Regression] FAIL: gcc.dg/graphite/pr(42521|42771).c (internal compiler error) due to revision 192219

[howarth at nitro dot med.uc.edu]

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



--- Comment #3 from Jack Howarth  2012-10-12 
20:04:05 UTC ---

Is r192219 the exact commit causing this regression?

[Bug libfortran/54736] GFORTRAN_CONVERT_UNIT causes malloc error on several platforms

[tkoenig at gcc dot gnu.org]

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

--- Comment #9 from Thomas Koenig  2012-10-12 
19:38:09 UTC ---
Author: tkoenig
Date: Fri Oct 12 19:38:04 2012
New Revision: 192411

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=192411
Log:
2012-10-12  Thomas König  

PR libfortran/54736
libgfortran/Changelog:  Fix date of last commit.

Modified:
branches/gcc-4_7-branch/libgfortran/ChangeLog

[Bug target/54723] test gcc.target/arm/div64-unwinding.c fails for GNU/Linux target

[janis at gcc dot gnu.org]

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



Janis Johnson  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||INVALID



--- Comment #1 from Janis Johnson  2012-10-12 
19:27:49 UTC ---

I'm declaring this Not a Bug based on this response from Richard Earnshaw in

:



I don't believe there's a bug here.   The ARM EABI defines __aeabi_idiv0 

as a hook that will be called if division by zero occurs.  While the 

default implementation simply raises SIGFPE on linux, it is perfectly 

possible to provide your own definition of this hook and then throw() a 

C++ exception.  In order to do that you'd need unwind information in the 

divdi implementation ([u]divsi tailcalls the hook).



Technically you could argue the same for bare metal, but in that case 

the arguments against the code bloat outweigh this very small corner 

case and users wanting this will have to rebuild their support code.



On linux, I think the presence of the unwind information is correct, 

since the code bloat problem is very much a secondary concern.

[Bug fortran/54917] New: transfer on polymorphic variable causes ICE (gfc_target_expr_size)

[quantheory at gmail dot com]

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



 Bug #: 54917

   Summary: transfer on polymorphic variable causes ICE

(gfc_target_expr_size)

Classification: Unclassified

   Product: gcc

   Version: 4.7.3

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: fortran

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

ReportedBy: quanthe...@gmail.com





Created attachment 28436

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

Short program that causes the bug



When compiling a routine that uses transfer on a polymorphic variable, the

following command fails:



gfortran -c -Wsurprising test_module.F90



The error message is:







test_module.F90:18.22:



end module test_module

  1

Internal Error at (1):

Invalid expression in gfc_target_expr_size.







This error does not occur if -Wsurprising is off and the polymorphic variable

is the "source". It does occur if the polymorphic variable is the "mold", even

with no warnings on.





Obviously, you would rarely-or-never want to actually do such a transfer, but I

did notice this problem because I have been using the following macro to turn

off warnings about unused arguments:



#define UNUSED_VAR(arg) if (.false.) write(*,*) transfer(arg,1)



A bit hack-ish, but gets the job done in impure routines. In any case, even if

gfortran rejects this, getting a specific error message rather than an internal

error would be nice.





I'm in a somewhat limited environment right now, so I can't tell for sure

whether this is an old problem or a regression. This has happened with one of

the 4.7.3 unofficial prerelease builds:



gcc-4.7 -v

Using built-in specs.

COLLECT_GCC=gcc-4.7

COLLECT_LTO_WRAPPER=/home/santos/gcc-4.7/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.7.3/lto-wrapper

Target: x86_64-unknown-linux-gnu

Configured with: ../gcc-4.7-source/gcc-4.7-20120929/configure

--enable-languages=c,c++,fortran --enable-checking=release --disable-bootstrap

--disable-libmudflap --enable-libgomp --enable-lto --enable-gold

--with-plugin-ld=/usr/bin/gold --prefix=/usr/local/gcc-4.7

Thread model: posix

[Bug tree-optimization/54916] New: [4.8 Regression] wrong code with -O2 -funroll-loops -fno-rerun-cse-after-loop

[zsojka at seznam dot cz]

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



 Bug #: 54916

   Summary: [4.8 Regression] wrong code with -O2 -funroll-loops

-fno-rerun-cse-after-loop

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: tree-optimization

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

ReportedBy: zso...@seznam.cz





Created attachment 28435

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

testcase (gcc.dg/pr39794.c)



Output:

$ gcc -O2 -funroll-loops -fno-rerun-cse-after-loop pr39794.i

$ ./a.out 

Aborted



(gdb) p a

$1 = {0, 1, 4, 2, 10, 12, 24, 44, 36, 136, 160, 344, 592, 1008, 1872, 1600}

(gdb) p ref

$2 = {0, 1, 4, 2, 10, 12, 24, 44, 72, 136, 232, 416, 736, 1296, 2304, 2032}



Binary is fine when compiled without -fno-rerun-cse-after-loop



Tested revisions:

r192388 - fail

r191586 - fail

4.7 r191640 - OK

[Bug libfortran/54736] GFORTRAN_CONVERT_UNIT causes malloc error on several platforms

[tkoenig at gcc dot gnu.org]

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

--- Comment #8 from Thomas Koenig  2012-10-12 
18:56:23 UTC ---
Author: tkoenig
Date: Fri Oct 12 18:56:16 2012
New Revision: 192408

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=192408
Log:
2012-10-06  Thomas König  

PR libfortran/54736
Backport from trunk
* runtime/environ.c (search_unit):  Correct logic
for binary search.
(mark_single):  Fix index errors.


Modified:
branches/gcc-4_7-branch/libgfortran/ChangeLog
branches/gcc-4_7-branch/libgfortran/runtime/environ.c

[Bug target/54908] misc regressions on emutls targets remain from dynamic initialization of non-function-local TLS variables

[dominiq at lps dot ens.fr]

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



Dominique d'Humieres  changed:



   What|Removed |Added



 Target|x86_64-apple-darwin12   |*-apple-darwin*

   Host|x86_64-apple-darwin12   |*-apple-darwin*

  Build|x86_64-apple-darwin12   |*-apple-darwin*



--- Comment #5 from Dominique d'Humieres  2012-10-12 
18:50:43 UTC ---

AFAICT 



(1) the failures for libgomp.c++/pr24455.C are (at least for

x86_64-apple-darwin10)



FAIL: libgomp.c++/pr24455.C  -O*  (test for excess errors)

Excess errors:

Undefined symbols:

  "TLS init function for i", referenced from:

  TLS wrapper function for i in ccoTk54U.o

  __ZTH1i$non_lazy_ptr in ccoTk54U.o

 (maybe you meant: __ZTH1i$non_lazy_ptr)

ld: symbol(s) not found



(2) The error "... dynamic initialization of non-function-local ..." comes from

gcc/cp/decl2.c if ASM_OUTPUT_DEF is not defined. I see in gcc/config/darwin.c



/* The Darwin's implementation of TARGET_ASM_OUTPUT_ANCHOR.  Define the

   anchor relative to ".", the current section position.  We cannot use

   the default one because ASM_OUTPUT_DEF is wrong for Darwin.  */

[Bug other/54691] [4.8 Regression] --enable-checking=valgrind doesn't build

[markus at trippelsdorf dot de]

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



--- Comment #6 from Markus Trippelsdorf  
2012-10-12 18:46:14 UTC ---

(In reply to comment #4)

> Please try git hjl/valgrind branch:

> 

> http://gcc.gnu.org/git/?p=gcc.git;a=shortlog;h=refs/heads/hjl/valgrind



It builds fine now. Thank you.

[Bug middle-end/54915] [4.8 Regression] ICE: verify_gimple failed: type mismatch in vector permute expression

[glisse at gcc dot gnu.org]

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



Marc Glisse  changed:



   What|Removed |Added



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

   |gnu.org |



--- Comment #2 from Marc Glisse  2012-10-12 18:42:50 
UTC ---

Uh, it does look like I am not checking the size of the RHS anywhere :-(



Sorry about that, I'll fix it ASAP.

[Bug target/54908] misc regressions on emutls targets remain from dynamic initialization of non-function-local TLS variables

[jason at gcc dot gnu.org]

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



Jason Merrill  changed:



   What|Removed |Added



 Status|UNCONFIRMED |ASSIGNED

   Last reconfirmed||2012-10-12

 CC||jason at gcc dot gnu.org

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

   |gnu.org |

 Ever Confirmed|0   |1



--- Comment #4 from Jason Merrill  2012-10-12 
18:38:06 UTC ---

I think the right fix is to use pthread TLS rather than thread_local in

atexit_thread.cc, so that it doesn't matter when emutls frees its storage.

[Bug middle-end/54915] [4.8 Regression] ICE: verify_gimple failed: type mismatch in vector permute expression

[dominiq at lps dot ens.fr]

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



Dominique d'Humieres  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2012-10-12

 Ever Confirmed|0   |1



--- Comment #1 from Dominique d'Humieres  2012-10-12 
18:37:55 UTC ---

Revision 191175, 2012-09-11, is OK; revision 191247, 2012-09-13 (configured

with --enable-checking=release) gives



pr54915.c:4:6: internal compiler error: in fold_convert_loc, at

fold-const.c:1990



Candidate revision 191198?

[Bug c/54381] -Wsizeof-pointer-memaccess refers to "destination" for strncmp

[jakub at gcc dot gnu.org]

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



--- Comment #1 from Jakub Jelinek  2012-10-12 
18:23:13 UTC ---

Author: jakub

Date: Fri Oct 12 18:23:03 2012

New Revision: 192406



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

Log:

PR c/54381

* c-common.h (sizeof_pointer_memaccess_warning): Adjust prototype.

* c-common.c (sizeof_pointer_memaccess_warning): Take array of 3

locs and array of 3 trees instead of just single loc and single

sizeof_arg tree.  Handle __builtin___*_chk builtins too, and

also stpncpy, bcopy, bcmp, bzero, snprintf and vsnprintf builtins.

For *cmp* builtins that take two sources strings report warnings

about first and second source, not about destination and source.



* c-parser.c (struct c_tree_loc_pair): Removed.

(c_parser_expr_list): Remove struct c_tree_loc_pair * argument,

add location_t * and tree * arguments, fill in array of 3

sizeof_arg trees and corresponding locs.

(c_parser_attributes, c_parser_objc_keywordexpr): Adjust

c_parser_expr_list callers.

(c_parser_postfix_expression_after_primary): Likewise.  Pass

array of 3 sizeof_arg trees and locs (corresponding to first

3 arguments) to sizeof_pointer_memaccess_warning.



* semantics.c (finish_call_expr): Pass array of 3 sizeof_arg

trees and locs (corresponding to first 3 arguments) to

sizeof_pointer_memaccess_warning.



* c-c++-common/Wsizeof-pointer-memaccess1.c: New test.

* c-c++-common/Wsizeof-pointer-memaccess2.c: New test.

* gcc.dg/Wsizeof-pointer-memaccess1.c: New test.

* gcc.dg/torture/Wsizeof-pointer-memaccess1.c: Test also stpncpy.

Adjust expected wording of warnings for *cmp* builtins.

* g++.dg/torture/Wsizeof-pointer-memaccess1.C: Likewise.

* g++.dg/torture/Wsizeof-pointer-memaccess2.C: Likewise.



Added:

trunk/gcc/testsuite/c-c++-common/Wsizeof-pointer-memaccess1.c

trunk/gcc/testsuite/c-c++-common/Wsizeof-pointer-memaccess2.c

trunk/gcc/testsuite/gcc.dg/Wsizeof-pointer-memaccess1.c

Modified:

trunk/gcc/c-family/ChangeLog

trunk/gcc/c-family/c-common.c

trunk/gcc/c-family/c-common.h

trunk/gcc/c/ChangeLog

trunk/gcc/c/c-parser.c

trunk/gcc/cp/ChangeLog

trunk/gcc/cp/semantics.c

trunk/gcc/testsuite/ChangeLog

trunk/gcc/testsuite/g++.dg/torture/Wsizeof-pointer-memaccess1.C

trunk/gcc/testsuite/g++.dg/torture/Wsizeof-pointer-memaccess2.C

trunk/gcc/testsuite/gcc.dg/torture/Wsizeof-pointer-memaccess1.c

[Bug tree-optimization/54886] [4.8 Regression] FAIL: gcc.dg/graphite/pr(42521|42771).c (internal compiler error) due to revision 192219

[dominiq at lps dot ens.fr]

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



Dominique d'Humieres  changed:



   What|Removed |Added



 CC||howarth at nitro dot

   ||med.uc.edu



--- Comment #2 from Dominique d'Humieres  2012-10-12 
18:22:44 UTC ---

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

[Bug middle-end/54914] gcc.dg/graphite/pr42521.c regressed in gcc trunk

[dominiq at lps dot ens.fr]

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



Dominique d'Humieres  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||DUPLICATE



--- Comment #3 from Dominique d'Humieres  2012-10-12 
18:22:44 UTC ---

Duplicate of pr54886.



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

[Bug middle-end/54915] New: [4.8 Regression] ICE: verify_gimple failed: type mismatch in vector permute expression

[zsojka at seznam dot cz]

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



 Bug #: 54915

   Summary: [4.8 Regression] ICE: verify_gimple failed: type

mismatch in vector permute expression

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: middle-end

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

ReportedBy: zso...@seznam.cz





Created attachment 28434

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

reduced testcase (from gcc.target/i386/vect-rebuild.c)



Compiler output:

$ gcc -O testcase.c

testcase.c: In function 'h':

testcase.c:4:6: note: The ABI for passing parameters with 32-byte alignment has

changed in GCC 4.6

 v2df h (v4df x)

  ^

testcase.c:8:1: error: type mismatch in vector permute expression

 }

 ^

v2df

v4df

v4df

vector(2) unsigned long

xx_4 = VEC_PERM_EXPR ;



testcase.c:8:1: internal compiler error: verify_gimple failed

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

0xa07e1c verify_gimple_in_cfg(function*)

/mnt/svn/gcc-trunk/gcc/tree-cfg.c:4727

0x8ff5c8 execute_function_todo

/mnt/svn/gcc-trunk/gcc/passes.c:1956

0x90030d execute_todo

/mnt/svn/gcc-trunk/gcc/passes.c:1989

Please submit a full bug report,

with preprocessed source if appropriate.

Please include the complete backtrace with any bug report.

See  for instructions.



Tested revisions:

r192388 - crash

r191586 - crash

4.7 r191640 - OK

[Bug tree-optimization/54855] Unnecessary duplication when performing scalar operation on vector element

[glisse at gcc dot gnu.org]

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



--- Comment #5 from Marc Glisse  2012-10-12 18:08:45 
UTC ---

Doing the optimization that late is a bit fragile though. For instance:

v[0] += 3.0;

v[0] -= 1.0;

is back to decomposing the vector, doing the operations and reconstructing it

(I didn't use -fassociative-math so it couldn't turn that into += 2.0). But

doing more looks too complicated.

[Bug middle-end/54914] gcc.dg/graphite/pr42521.c regressed in gcc trunk

[howarth at nitro dot med.uc.edu]

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



--- Comment #2 from Jack Howarth  2012-10-12 
17:36:44 UTC ---

The backtrace in gdb is...





(gdb) r -quiet -v -imultilib i386 -iprefix

/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/gcc/../lib/gcc/x86_64-apple-darwin12.2.0/4.8.0/

-isystem /sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/gcc/include -isystem

/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/gcc/include-fixed

-D__DYNAMIC__

/sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20121011/gcc/testsuite/gcc.dg/graphite/pr42521.c

-fPIC -quiet -dumpbase pr42521.c -mmacosx-version-min=10.8.2 -m32 -mtune=core2

-auxbase-strip pr42521.s -O3 -version -fno-diagnostics-show-caret

-fgraphite-identity -o pr42521.s

Starting program: /sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/gcc/cc1

-quiet -v -imultilib i386 -iprefix

/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/gcc/../lib/gcc/x86_64-apple-darwin12.2.0/4.8.0/

-isystem /sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/gcc/include -isystem

/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/gcc/include-fixed

-D__DYNAMIC__

/sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20121011/gcc/testsuite/gcc.dg/graphite/pr42521.c

-fPIC -quiet -dumpbase pr42521.c -mmacosx-version-min=10.8.2 -m32 -mtune=core2

-auxbase-strip pr42521.s -O3 -version -fno-diagnostics-show-caret

-fgraphite-identity -o pr42521.s





Program received signal SIGABRT, Aborted.

0x7fff90231212 in __pthread_kill ()

(gdb) bt

#0  0x7fff90231212 in __pthread_kill ()

#1  0x7fff94c23af4 in pthread_kill ()

#2  0x7fff94c67dce in abort ()

#3  0x00014158099b in isl_ctx_free ()

#4  0x0001004cd31f in graphite_transform_loops () at

../../gcc-4.8-20121011/gcc/graphite.c:299

Previous frame inner to this frame (gdb could not unwind past this frame)

[Bug tree-optimization/54855] Unnecessary duplication when performing scalar operation on vector element

[glisse at gcc dot gnu.org]

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



--- Comment #4 from Marc Glisse  2012-10-12 17:33:53 
UTC ---

Note that a V4SF version should be doable, since it is 3 insn there as well,

although the pattern is different.



(insn 34 61 36 4 (set (reg:SF 103 [ D.2551 ])

(vec_select:SF (reg/v:V4SF 87 [ v ])

(parallel [

(const_int 0 [0])

]))) d.c:13 1380 {*vec_extractv4sf_0}

 (nil))

(insn 36 34 37 4 (set (reg:SF 104 [ D.2551 ])

(minus:SF (reg:SF 103 [ D.2551 ])

(reg:SF 106))) d.c:13 759 {*fop_sf_1_sse}

 (expr_list:REG_DEAD (reg:SF 103 [ D.2551 ])

(nil)))

(insn 37 36 38 4 (set (reg/v:V4SF 87 [ v ])

(vec_merge:V4SF (vec_duplicate:V4SF (reg:SF 104 [ D.2551 ]))

(reg/v:V4SF 87 [ v ])

(const_int 1 [0x1]))) d.c:13 1377 {vec_setv4sf_0}

 (expr_list:REG_DEAD (reg:SF 104 [ D.2551 ])

(nil)))

[Bug middle-end/54914] gcc.dg/graphite/pr42521.c regressed in gcc trunk

[howarth at nitro dot med.uc.edu]

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



Jack Howarth  changed:



   What|Removed |Added



 Target||x86_64-apple-darwin12

   Host||x86_64-apple-darwin12

  Build||x86_64-apple-darwin12



--- Comment #1 from Jack Howarth  2012-10-12 
17:30:02 UTC ---

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-20121011/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 20121011 (experimental) (GCC)

[Bug middle-end/54914] New: gcc.dg/graphite/pr42521.c regressed in gcc trunk

[howarth at nitro dot med.uc.edu]

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



 Bug #: 54914

   Summary: gcc.dg/graphite/pr42521.c regressed in gcc trunk

Classification: Unclassified

   Product: gcc

   Version: 4.7.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: middle-end

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

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





Somewhere between r192044, which doesn't show the regression and r192251, which

does, the failures...



FAIL: gcc.dg/graphite/pr42521.c (internal compiler error)

FAIL: gcc.dg/graphite/pr42521.c (test for excess errors)



were introduced. These appear on x86_64-apple-darwin12 as...



Executing on host: /sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/gcc/xgcc

-B/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/gcc/

/sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20121011/gcc/testsuite/gcc.dg/graphite/pr42521.c

 -fno-diagnostics-show-caret   -O3 -fgraphite-identity -S  -m32 -o pr42521.s   

(timeout = 300)

isl_ctx.c:158: isl_ctx freed, but some objects still reference it^M

/sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20121011/gcc/testsuite/gcc.dg/graphite/pr42521.c:

In function 'foo':^M

/sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20121011/gcc/testsuite/gcc.dg/graphite/pr42521.c:6:6:

internal compiler error: Abort trap: 6^M

xgcc: internal compiler error: Abort trap: 6 (program cc1)^M

compiler exited with status 1

output is:

isl_ctx.c:158: isl_ctx freed, but some objects still reference it^M

/sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20121011/gcc/testsuite/gcc.dg/graphite/pr42521.c:

In function 'foo':^M

/sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20121011/gcc/testsuite/gcc.dg/graphite/pr42521.c:6:6:

internal compiler error: Abort trap: 6^M

xgcc: internal compiler error: Abort trap: 6 (program cc1)^M



FAIL: gcc.dg/graphite/pr42521.c (internal compiler error)

FAIL: gcc.dg/graphite/pr42521.c (test for excess errors)

Excess errors:

isl_ctx.c:158: isl_ctx freed, but some objects still reference it

/sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20121011/gcc/testsuite/gcc.dg/graphite/pr42521.c:6:6:

internal compiler error: Abort trap: 6

xgcc: internal compiler error: Abort trap: 6 (program cc1)

[Bug c++/54913] [4.8 Regression] '#'indirect_ref' not supported by dump_decl#' is not a member of 'E'

[paolo.carlini at oracle dot com]

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



--- Comment #2 from Paolo Carlini  2012-10-12 
17:13:08 UTC ---

The diagnostic issue is known (PR51413). Can you please figure out when it

started?

[Bug tree-optimization/54855] Unnecessary duplication when performing scalar operation on vector element

[glisse at gcc dot gnu.org]

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



--- Comment #3 from Marc Glisse  2012-10-12 17:08:20 
UTC ---

The following patch gives this loop:

.L7:

subsd%xmm0, %xmm1

subl$1, %eax

addpd%xmm1, %xmm1

jne.L7



I guess I should add the same for mul and div at the same time, but I don't

know if it is the right approach.



--- config/i386/sse.md(revision 192405)

+++ config/i386/sse.md(working copy)

@@ -812,20 +812,38 @@

   (const_int 1)))]

   "TARGET_SSE"

   "@

\t{%2, %0|%0, %2}

v\t{%2, %1, %0|%0, %1, %2}"

   [(set_attr "isa" "noavx,avx")

(set_attr "type" "sseadd")

(set_attr "prefix" "orig,vex")

(set_attr "mode" "")])



+(define_insn "*sse2_vmv2df3"

+  [(set (match_operand:V2DF 0 "register_operand" "=x,x")

+(vec_concat:V2DF

+  (plusminus:DF

+(vec_select:DF 

+  (match_operand:V2DF 1 "register_operand" "0,x")

+  (parallel [(const_int 0)]))

+(match_operand:DF 2 "nonimmediate_operand" "xm,xm"))

+  (vec_select:DF (match_dup 1) (parallel [(const_int 1)]]

+  "TARGET_SSE2"

+  "@

+   sd\t{%2, %0|%0, %2}

+   vsd\t{%2, %1, %0|%0, %1, %2}"

+  [(set_attr "isa" "noavx,avx")

+   (set_attr "type" "sseadd")

+   (set_attr "prefix" "orig,vex")

+   (set_attr "mode" "DF")])

+

 (define_expand "mul3"

   [(set (match_operand:VF 0 "register_operand")

 (mult:VF

   (match_operand:VF 1 "nonimmediate_operand")

   (match_operand:VF 2 "nonimmediate_operand")))]

   "TARGET_SSE"

   "ix86_fixup_binary_operands_no_copy (MULT, mode, operands);")



 (define_insn "*mul3"

   [(set (match_operand:VF 0 "register_operand" "=x,x")

[Bug c++/54912] [4.8 Regression] Non-type argument to alias template is not a constant expression

[paolo.carlini at oracle dot com]

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



Paolo Carlini  changed:



   What|Removed |Added



 CC||jason at gcc dot gnu.org



--- Comment #2 from Paolo Carlini  2012-10-12 
17:07:56 UTC ---

Most likely a Dup of PR54859, also regressed with 191412.

[Bug other/54691] [4.8 Regression] --enable-checking=valgrind doesn't build

[ubizjak at gmail dot com]

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



--- Comment #5 from Uros Bizjak  2012-10-12 17:06:25 
UTC ---

Maybe VALGRIND_DISCARD would come handy here?

[Bug c++/54913] [4.8 Regression] '#'indirect_ref' not supported by dump_decl#' is not a member of 'E'

[redi at gcc dot gnu.org]

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



Jonathan Wakely  changed:



   What|Removed |Added



  Known to work||4.6.3, 4.7.1



--- Comment #1 from Jonathan Wakely  2012-10-12 
17:02:17 UTC ---

Fails with gcc version 4.8.0 20121007 (experimental) (GCC)



The code should be accepted, and the diagnostic should make sense!

[Bug c++/54913] New: [4.8 Regression] '#'indirect_ref' not supported by dump_decl#' is not a member of 'E'

[redi at gcc dot gnu.org]

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



 Bug #: 54913

   Summary: [4.8 Regression] '#'indirect_ref' not supported by

dump_decl#' is not a member of 'E'

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Keywords: rejects-valid

  Severity: normal

  Priority: P3

 Component: c++

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

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





struct Node { };



struct E

{

class K {};

static const K &N;



int f(Node&, const K&);

};



template

struct R : Node

{

R(E &g)

: r(g.f(*this,E::N))

{}



int r;

};





int main()

{

E e;

R n(e);

}





e.cc: In instantiation of 'R::R(E&) [with T = int]':

e.cc:25:15:   required from here

e.cc:15:21: error: '#'indirect_ref' not supported by dump_decl#' is not a member of 'E'

  : r(g.f(*this,E::N))

 ^

[Bug c++/54912] [4.8 Regression] Non-type argument to alias template is not a constant expression

[paolo.carlini at oracle dot com]

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



Paolo Carlini  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2012-10-12

Summary|[C++11] Non-type argument   |[4.8 Regression] Non-type

   |to alias template is not a  |argument to alias template

   |constant expression |is not a constant

   ||expression

 Ever Confirmed|0   |1



--- Comment #1 from Paolo Carlini  2012-10-12 
16:54:53 UTC ---

Confirmed as a regression, 4_7-branch is fine.

[Bug other/54691] [4.8 Regression] --enable-checking=valgrind doesn't build

[hjl.tools at gmail dot com]

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



--- Comment #4 from H.J. Lu  2012-10-12 16:47:58 
UTC ---

Please try git hjl/valgrind branch:



http://gcc.gnu.org/git/?p=gcc.git;a=shortlog;h=refs/heads/hjl/valgrind

[Bug c++/54912] New: [C++11] Non-type argument to alias template is not a constant expression

[lucdanton at free dot fr]

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



 Bug #: 54912

   Summary: [C++11] Non-type argument to alias template is not a

constant expression

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: c++

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

ReportedBy: lucdan...@free.fr





gcc version 4.8.0 20121008 (experimental) with flags



-Wall -pedantic -std=c++11



complains when fed the following program:



template

using Bool = int;



template

void foo()

{

using bar = Bool<(sizeof(T) >= 0)>; // line 7

}



int main()

{

foo();

}



Compiler output:



main.cpp: In substitution of 'template using Bool = int [with bool B =

(sizeof (T) >= 0)]':

main.cpp:7:38:   required from here

main.cpp:7:38: error: integral expression '(sizeof (T) >= 0)' is not constant

 using bar = Bool<(sizeof(T) >= 0)>;

  ^

main.cpp:7:38: error:   trying to instantiate 'template using Bool =

int'



Using the sizeof expression as the non-type parameter of a class template with

the same template parameter list as the alias template is accepted. That same

expression can also be used to initialize e.g. a constexpr bool variable, which

will in fact in turn be accepted as a parameter to Bool.



Previous snapshots of GCC used to accept this kind of code.

[Bug c++/52844] ICE

[paolo.carlini at oracle dot com]

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



Paolo Carlini  changed:



   What|Removed |Added



   Keywords||ice-on-invalid-code

 Status|UNCONFIRMED |NEW

   Last reconfirmed||2012-10-12

 Ever Confirmed|0   |1

[Bug c++/52844] ICE

[paolo.carlini at oracle dot com]

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



--- Comment #5 from Paolo Carlini  2012-10-12 
15:53:36 UTC ---

Thanks guys!

[Bug c++/52844] ICE

[glisse at gcc dot gnu.org]

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



--- Comment #4 from Marc Glisse  2012-10-12 15:52:16 
UTC ---

template < class > struct V { };

template < int... > struct tuple ;

template < int...Is > void f ( V < Is...>) { }

auto g ( ) -> decltype ( f ( V < long >  ( ) ) ) ;

[Bug target/54908] misc regressions on emutls targets remain from dynamic initialization of non-function-local TLS variables

[howarth at nitro dot med.uc.edu]

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



--- Comment #3 from Jack Howarth  2012-10-12 
15:48:47 UTC ---

The patch in comment 2 suppresses the failures on x86_64-apple-darwin12. Note

that I had to move dg-run to the top of

gcc/testsuite/g++.dg/tls/thread_local-cse.C for the addition of "// {

dg-require-effective-target tls_native }" to be honored. It is unfortunate that

the dynamic initialization of non-function-local TLS variables loses us so many

test cases on emutls.

[Bug c++/52844] ICE

[markus at trippelsdorf dot de]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||markus at trippelsdorf dot
   ||de

--- Comment #3 from Markus Trippelsdorf  
2012-10-12 15:47:20 UTC ---
As Dave said the testcase is invalid:

Creduce comes up with:

markus@x4 tmp % cat test.ii
namespace std {
typedef int size_t;
templatestruct A;
}
struct B
{};
templatestruct vector_c
{
  typedef vector_c type;
};
templatestruct range_c : B
{};
templatestruct range_c: vector_c
{};
namespace std {
templateclass tuple;
templatetuple::__type ...>make_tuple();
template
  auto apply_tuple_(F, std::tuple,
vector_c)->decltype(0);
template
  auto apply_tuple(F, std::tuplet)
  -> decltype(apply_tuple_ (0, t, typename range_c::type()));
int x = apply_tuple(0, std::make_tuple);
}

markus@x4 tmp % g++ -std=c++11 -c test.ii
test.ii: In substitution of ‘template decltype
(std::apply_tuple_(0, t, typename range_c::type()))
std::apply_tuple(F, std::tuple) [with F = int; T = {}]’:
test.ii:27:39:   required from here
test.ii:26:51: internal compiler error: in unify_one_argument, at cp/pt.c:15162
sizeof ... (T)>::type()));
   ^
Please submit a full bug report,


markus@x4 tmp % clang++ -std=c++11 -c test.ii
test.ii:22:30: error: template argument for template type parameter must be a
type
vector_c)->decltype(0);
 ^~
test.ii:7:16: note: template parameter is declared here
templatestruct vector_c
   ^
test.ii:27:9: error: no matching function for call to 'apply_tuple'
int x = apply_tuple(0, std::make_tuple);
^~~
test.ii:24:8: note: candidate template ignored: substitution failure [with F =
int, T = <>]: no matching function for call to 'apply_tuple_'
  auto apply_tuple(F, std::tuplet)
   ^
2 errors generated.


markus@x4 tmp % icpc -std=c++11 test.ii
test.ii(2): warning #910: declaration of "size_t" does not match the expected
type "unsigned long"
  typedef int size_t;
  ^

test.ii(22): error: constant "Is" is not a type name
  vector_c)->decltype(0);
   ^

test.ii(22): error: pack expansion does not make use of any argument packs
  vector_c)->decltype(0);
  ^

test.ii(20): warning #2922: constant "Is" cannot be used because it follows a
parameter pack and cannot be deduced from the parameters of function template
"std::apply_tuple_"
  template
   ^

test.ii(27): error: no instance of function template "std::apply_tuple" matches
the argument list
argument types are: (int, )
  int x = apply_tuple(0, std::make_tuple);
  ^

compilation aborted for test.ii (code 2)

[Bug target/54908] misc regressions on emutls targets remain from dynamic initialization of non-function-local TLS variables

[howarth at nitro dot med.uc.edu]

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



--- Comment #2 from Jack Howarth  2012-10-12 
15:44:24 UTC ---

Created attachment 28433

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

patch to suppress dynamic initialization of non-function-local TLS variables

failures on emutls

[Bug c/54907] post increasing a value pointed by p in subexpression of an expression modifying p saves the increased value in the wrong place

[joseph at codesourcery dot com]

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



--- Comment #4 from joseph at codesourcery dot com  2012-10-12 15:40:05 UTC ---

I believe this code is well-defined.



There are two objects modified, p and *p.  p is modified by the 

assignment, and C11 6.5.16#3 says "The side effect of updating the stored 

value of the left operand is sequenced after the value computations of the 

left and right operands.".  For postfix increment, which modifies *p, "The 

value computation of the result is sequenced before the side effect of 

updating the stored value of the operand.".  Each object is modified only 

once, so there is no issue of two side effects on the same object being 

unsequenced.  And the value computation of the RHS, using p, is sequenced 

before p is updated by the assignment; furthermore, 5.1.2.3#2 says "Value 

computation for an lvalue expression includes determining the identity of 

the designated object.".  So I don't think either case of undefinedness in 

6.5#2, "If a side effect on a scalar object is unsequenced relative to 

either a different side effect on the same scalar object or a value 

computation using the value of the same scalar object, the behavior is 

undefined.", applies here.

[Bug c++/33109] ICE: segfault while compiling c++ code

[paolo.carlini at oracle dot com]

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



Paolo Carlini  changed:



   What|Removed |Added



 Status|WAITING |RESOLVED

 Resolution||INVALID



--- Comment #4 from Paolo Carlini  2012-10-12 
15:29:19 UTC ---

Feedback not forthcoming.

[Bug c++/30842] Warning received when private class has hidden visibility

[paolo.carlini at oracle dot com]

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



Paolo Carlini  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 CC|gcc-bugs at gcc dot gnu.org |

 Resolution||INVALID



--- Comment #2 from Paolo Carlini  2012-10-12 
15:26:51 UTC ---

Closing.

[Bug c++/23885] incorrect template two-stage name-lookup

[paolo.carlini at oracle dot com]

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



Paolo Carlini  changed:



   What|Removed |Added



 Status|SUSPENDED   |NEW

 CC|gcc-bugs at gcc dot gnu.org |

  Known to fail||



--- Comment #11 from Paolo Carlini  2012-10-12 
15:16:36 UTC ---

Definitely unsuspending. Is this invalid like PR16635 then?

[Bug c++/52844] ICE

[paolo.carlini at oracle dot com]

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



--- Comment #2 from Paolo Carlini  2012-10-12 
15:06:38 UTC ---

Dave, if we don't reduce the size of the testcase it will take a lot of time

for somebody to look into this. Do you have anything smaller? (creduce is

supposed to work pretty well)

[Bug lto/54911] New: lto-wrapper fails when compiling gcc with -flto -fuse-linker-plugin

[j-frankish at slb dot com]

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



 Bug #: 54911

   Summary: lto-wrapper fails when compiling gcc with -flto

-fuse-linker-plugin

Classification: Unclassified

   Product: gcc

   Version: 4.7.2

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: lto

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

ReportedBy: j-frank...@slb.com





lto-wrapper fails when compiling gcc with "-flto -fuse-linker-plugin" in the

chroot environment for a cross-compiled i486 system - the same thing suceeds in

the chroot environment for a cross-compiled x86_64 system on the same machine

with the same version of gcc



 CFLAGS="-march=i486 -mtune=i686 -Os -pipe" CXXFLAGS="-march=i486 -mtune=i686

-Os -pipe" CC="gcc -flto -fuse-linker-plugin" CXX="g++ -flto

-fuse-linker-plugin" ../gcc-4.7.2/configure --prefix=/usr  --libdir=/usr/lib

--libexecdir=/usr/lib --enable-shared --enable-threads=posix

--enable-__cxa_atexit --enable-c99 --enable-long-long --enable-clocale=gnu

--enable-languages=c,c++ --disable-multilib --disable-libstdcxx-pch

--enable-cloog-backend=isl --with-system-zlib --enable-frame-pointer

--disable-bootstrap



make

...

gcc -flto -fuse-linker-plugin   -march=i486 -mtune=i686 -Os -pipe -DIN_GCC   -W

-Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes

-Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long

-Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition

-Wc++-compat   -DHAVE_CONFIG_H  -o cc1 c-lang.o c-family/stub-objc.o attribs.o

c-errors.o c-decl.o c-typeck.o c-convert.o c-aux-info.o c-objc-common.o

c-parser.o tree-mudflap.o c-family/c-common.o c-family/c-cppbuiltin.o

c-family/c-dump.o c-family/c-format.o c-family/c-gimplify.o c-family/c-lex.o

c-family/c-omp.o c-family/c-opts.o c-family/c-pch.o c-family/c-ppoutput.o

c-family/c-pragma.o c-family/c-pretty-print.o c-family/c-semantics.o

c-family/c-ada-spec.o i386-c.o default-c.o \

  cc1-checksum.o main.o  libbackend.a libcommon-target.a libcommon.a

../libcpp/libcpp.a ../libdecnumber/libdecnumber.a libcommon.a

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

-lcloog-isl -lisl -lppl_c -lppl  -lgmpxx -lmpc -lmpfr -lgmp -rdynamic -ldl  -lz

In file included from ../../gcc-4.7.2/gcc/dse.c:4414:0,

 from insn-automata.c:31491,

 from :3612:

../../gcc-4.7.2/libcpp/lex.c: In function 'search_line_sse2':

../../gcc-4.7.2/libcpp/lex.c:370:15: internal compiler error: in convert_move,

at expr.c:327

Please submit a full bug report,

with preprocessed source if appropriate.

See  for instructions.

lto-wrapper: gcc returned 1 exit status

/usr/local/bin/ld: lto-wrapper failed

collect2: error: ld returned 1 exit status

make[2]: *** [lto1] Error 1

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

In file included from ../../gcc-4.7.2/gcc/dse.c:4524:0,

 from ../../gcc-4.7.2/gcc/var-tracking.c:2286,

 from :3428:

../../gcc-4.7.2/libcpp/lex.c: In function 'search_line_sse2':

../../gcc-4.7.2/libcpp/lex.c:370:15: internal compiler error: in convert_move,

at expr.c:327

Please submit a full bug report,

with preprocessed source if appropriate.

See  for instructions.

lto-wrapper: gcc returned 1 exit status

/usr/local/bin/ld: lto-wrapper failed

collect2: error: ld returned 1 exit status

make[2]: *** [cc1] Error 1

In file included from ../../gcc-4.7.2/gcc/dse.c:4437:0,

 from ../../gcc-4.7.2/gcc/config/i386/i386.c:7135,

 from :3711:

../../gcc-4.7.2/libcpp/lex.c: In function 'search_line_sse2':

../../gcc-4.7.2/libcpp/lex.c:370:15: internal compiler error: in convert_move,

at expr.c:327

Please submit a full bug report,

with preprocessed source if appropriate.

See  for instructions.

lto-wrapper: gcc returned 1 exit status

/usr/local/bin/ld: lto-wrapper failed

collect2: error: ld returned 1 exit status

make[2]: *** [cc1plus] Error 1

rm gcc.pod

make[2]: Leaving directory `/sources/gcc-build/gcc'

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

make[1]: Leaving directory `/sources/gcc-build'

make: *** [all] Error 2





gcc -v

Using built-in specs.

COLLECT_GCC=gcc

COLLECT_LTO_WRAPPER=/usr/local/lib/gcc/i486-pc-linux-gnu/4.7.2/lto-wrapper

Target: i486-pc-linux-gnu

Configured with: ../gcc-4.7.2/configure --prefix=/usr/local

--libexecdir=/usr/local/lib --enable-shared --enable-threads=posix

--enable-__cxa_atexit --enable-c99 --enable-long-long --enable-clocale=gnu

--enable-languages=c,c++ --disable-multilib --disable-libstdcxx-pch

--enable-cloog-backend=isl --with-system-zlib --enable-frame-pointer

Thread model: posix

gcc version 4.7.2 (GCC)

[Bug c++/24449] Unable to declare friend main() from class template

[paolo.carlini at oracle dot com]

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



Paolo Carlini  changed:



   What|Removed |Added



 Status|ASSIGNED|RESOLVED

  Known to work||4.8.0

 Resolution||FIXED

 AssignedTo|paolo.carlini at oracle dot |unassigned at gcc dot

   |com |gnu.org

   Target Milestone|--- |4.8.0



--- Comment #8 from Paolo Carlini  2012-10-12 
14:39:46 UTC ---

Fixed.

[Bug c++/24449] Unable to declare friend main() from class template

[paolo at gcc dot gnu.org]

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



--- Comment #7 from paolo at gcc dot gnu.org  
2012-10-12 14:38:19 UTC ---

Author: paolo

Date: Fri Oct 12 14:38:11 2012

New Revision: 192402



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

Log:

/cp

2012-10-12  Paolo Carlini  



PR c++/24449

* decl.c (grokfndecl): When checking for ::main declarations

use PROCESSING_REAL_TEMPLATE_DECL_P().



/testsuite

2012-10-12  Paolo Carlini  



PR c++/24449

* g++.dg/parse/friend-main.C: New.





Added:

trunk/gcc/testsuite/g++.dg/parse/friend-main.C

Modified:

trunk/gcc/cp/ChangeLog

trunk/gcc/cp/decl.c

trunk/gcc/testsuite/ChangeLog

[Bug c++/53055] ICE in cp_build_indirect_ref, at cp/typeck.c:2836

[paolo.carlini at oracle dot com]

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



Paolo Carlini  changed:



   What|Removed |Added



 Status|NEW |RESOLVED

 CC|marc.glisse at normalesup   |

   |dot org |

 Resolution||FIXED



--- Comment #12 from Paolo Carlini  2012-10-12 
14:35:53 UTC ---

Great. This is fixed anyway.

[Bug c++/54909] gcc does not recognize member function template when identical named pure virtual method exists

[redi at gcc dot gnu.org]

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



--- Comment #2 from Jonathan Wakely  2012-10-12 
14:28:00 UTC ---

The example can be reduced to



struct A

{

template void foo() { } 

};



struct B : A

{

void foo(int) { }

};



int main(int, char**)

{

B b;

b.foo(); /* error */

}



An alternative to adding a using declaration is to qualify the function you

want:



b.A::foo();

[Bug c++/54909] gcc does not recognize member function template when identical named pure virtual method exists

[redi at gcc dot gnu.org]

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



Jonathan Wakely  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||INVALID



--- Comment #1 from Jonathan Wakely  2012-10-12 
14:25:44 UTC ---

This is nothing to do with pure virtual functions, it's just the usual name

hiding rule.



You need to add "using A::foo;" to B to make the name visible.

[Bug c++/53055] ICE in cp_build_indirect_ref, at cp/typeck.c:2836

[glisse at gcc dot gnu.org]

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



Marc Glisse  changed:



   What|Removed |Added



 CC||glisse at gcc dot gnu.org



--- Comment #11 from Marc Glisse  2012-10-12 
14:21:18 UTC ---

(In reply to comment #7)

> Then I'll take care of the column number asap.



Ok, your turn ;-)



(In reply to comment #9)

> I will be happy

> with the text changed to "left-side operand of %<->*%> must a pointer to class

> compatible with the right-side operand",



I went with: "left hand operand of ->* must be a pointer to class, but is a

pointer to member of type ...", the bit about the RHS didn't seem relevant to

this particular error. But you still have a chance to convince Paolo for the

follow-up patch...

[Bug fortran/54880] [OOP] ICE in gfc_create_module_variable, at fortran/trans-decl.c:4013

[janus at gcc dot gnu.org]

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



--- Comment #4 from janus at gcc dot gnu.org 2012-10-12 14:19:37 UTC ---

(In reply to comment #3)

> One way to get rid of the error is to simply remove the assert that causes it

> (which was already constrained by Paul for PR43450). However, I'm not sure if

> that's justified.



At least it does not introduce any regressions in the testsuite.

[Bug c++/53055] ICE in cp_build_indirect_ref, at cp/typeck.c:2836

[glisse at gcc dot gnu.org]

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



--- Comment #10 from Marc Glisse  2012-10-12 
14:14:46 UTC ---

Author: glisse

Date: Fri Oct 12 14:14:37 2012

New Revision: 192401



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

Log:

2012-10-12  Marc Glisse  



PR c++/53055



gcc/c-family/

* c-common.h (enum ref_operator) [RO_ARROW_STAR]: New.



gcc/cp/

* call.c (build_new_op_1): Pass RO_ARROW_STAR to cp_build_indirect_ref.

* typeck.c (cp_build_indirect_ref): Handle RO_ARROW_STAR.



gcc/testsuite/

* g++.dg/pr53055.C: New testcase.





Added:

trunk/gcc/testsuite/g++.dg/pr53055.C   (with props)

Modified:

trunk/gcc/c-family/ChangeLog

trunk/gcc/c-family/c-common.h

trunk/gcc/cp/ChangeLog

trunk/gcc/cp/call.c

trunk/gcc/cp/typeck.c

trunk/gcc/testsuite/ChangeLog



Propchange: trunk/gcc/testsuite/g++.dg/pr53055.C

('svn:eol-style' added)



Propchange: trunk/gcc/testsuite/g++.dg/pr53055.C

('svn:keywords' added)

[Bug other/54691] [4.8 Regression] --enable-checking=valgrind doesn't build

[hjl.tools at gmail dot com]

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



H.J. Lu  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2012-10-12

 CC||hjl.tools at gmail dot com

 Ever Confirmed|0   |1



--- Comment #3 from H.J. Lu  2012-10-12 14:08:08 
UTC ---

PIC detection failed with valgrind:



configure:8446:

/export/build/gnu/gcc-lto-valgrind/build-x86_64-linux/./gcc/xgcc

-B/export/build/gnu/gcc-lto-valgrind/build-x86_64-linux/./gcc/

-B/usr/local/x86_64-unknown-linux-gnu/bin/

-B/usr/local/x86_64-unknown-linux-gnu/lib/ -isystem

/usr/local/x86_64-unknown-linux-gnu/include -isystem

/usr/local/x86_64-unknown-linux-gnu/sys-include  -m32 -c -g -O2 -pthread  -fPIC

-DPIC -DPIC conftest.c >&5

==15652== Invalid read of size 8

==15652==at 0xEF7C94: search_line_sse42(unsigned char const*, unsigned char

const*) (lex.c:464)

==15652==by 0xEF7F48: _cpp_clean_line (lex.c:742)

[Bug rtl-optimization/54910] New: ARM: Missed optimization of very simple ctz function

[linux at horizon dot com]

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



 Bug #: 54910

   Summary: ARM: Missed optimization of very simple ctz function

Classification: Unclassified

   Product: gcc

   Version: 4.7.2

Status: UNCONFIRMED

  Severity: minor

  Priority: P3

 Component: rtl-optimization

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

ReportedBy: li...@horizon.com

  Host: i386

Target: arm-linux-gnueabi





Given the following function:



/* Number of trailing zero bits in x. */

unsigned __attribute__((const))

ctz(unsigned x)

{

static unsigned char const ctz_table[16] = {

4, 0, 1, 0,  2, 0, 1, 0,

3, 0, 1, 0,  2, 0, 1, 0

};

int bit = 28;



if (x << 16)  x <<= 16, bit -= 16;

if (x <<  8)  x <<=  8, bit -=  8;

if (x <<  4)  x <<=  4, bit -=  4;

return bit + ctz_table[x >> 28];

}

And the command line:



arm-linux-gnueabi-gcc-4.7 -W -Wall -O2 -mcpu=arm7tdmi -mthumb-interwork -marm

-S baz.c



I get the following ARM code (-O2, -mthumb-interwork):



.align2

.globalctz

.typectz, %function

ctz:

@ Function supports interworking.

@ args = 0, pretend = 0, frame = 0

@ frame_needed = 0, uses_anonymous_args = 0

@ link register save eliminated.

movsr3, r0, asl #16

moveqr3, r0

movner2, #12

moveqr2, #28

movsr1, r3, asl #8

movner3, r1

subner2, r2, #8

movsr1, r3, asl #4

movner3, r1

ldrr1, .L18

ldrbr0, [r1, r3, lsr #28]@ zero_extendqisi2

subner2, r2, #4

addr0, r0, r2

bxlr

.L19:

.align2

.L18:

.word.LANCHOR0

.sizectz, .-ctz

.section.rodata

.align2

.LANCHOR0 = . + 0

.typectz_table.4122, %object

.sizectz_table.4122, 16

ctz_table.4122:

.byte4, 0, 1, 0, 2, 0, 1, 0, 3, 0, 1, 0, 2, 0, 1, 0

.ident"GCC: (Debian 4.7.2-1) 4.7.2"





What strikes me as strange about this code is that it uses 4-byte pointer

at .L18 to access an 16-byte table at .LANCHOR0.  Why the heck not just put

the table at .L18 directly and replace the ldr with an adr?  Save space and

time.





The thumb code is similar, but also fails to save the link register save,

despite the fact that this is an extremely simple leaf function:



.align2

.globalctz

.code16

.thumb_func

.typectz, %function

ctz:

push{lr}

lslr3, r0, #16

movr2, #12

cmpr3, #0

bne.L8

movr3, r0

movr2, #28

.L8:

lslr1, r3, #8

beq.L9

subr2, r2, #8

movr3, r1

.L9:

lslr1, r3, #4

beq.L10

subr2, r2, #4

movr3, r1

.L10:

ldrr1, .L18

lsrr3, r3, #28

ldrbr0, [r1, r3]

@ sp needed for prologue

addr0, r0, r2

pop{r1}

bxr1

[Bug c++/54909] New: gcc does not recognize member function template when identical named pure virtual method exists

[thomas.prescher at intel dot com]

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

 Bug #: 54909
   Summary: gcc does not recognize member function template when
identical named pure virtual method exists
Classification: Unclassified
   Product: gcc
   Version: 4.7.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: thomas.presc...@intel.com


Created attachment 28432
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28432
test case

Hello,

I've found the following issue:

Assume you have a class A which has a pure-virtual method called foo which
gets one parameter. Furthermore, assume that A implements a template method
also called foo, which expects 0 arguments and has a template depended return
type.
Class B inherits from A and implements foo with one parameter.

When you call foo without parameter on an instance of B, gcc complains that it
expects a parameter, even if the template type is passed.

This is the error message, an example implementation is attached.

main.cc:33:20: error: expected primary-expression before ‘>’ token
main.cc:33:22: error: expected primary-expression before ‘)’ token

[Bug tree-optimization/54855] Unnecessary duplication when performing scalar operation on vector element

[glisse at gcc dot gnu.org]

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



--- Comment #2 from Marc Glisse  2012-10-12 13:41:35 
UTC ---

(In reply to comment #1)

> Does not work for + though, as -0.0 + 0.0 is 0.0.

[...]

> On the tree level we see in-memory v because of the component modification:

> 

>   _7 = BIT_FIELD_REF ;

>   _8 = _7 - 1.0e+0;

>   BIT_FIELD_REF  = _8;

>   v.0_10 = v;

>   v.1_11 = v.0_10 * { 2.0e+0, 2.0e+0 };

>   v = v.1_11;

> 

> so either lowering this differently in the first place or detecting

> this kind of pattern would fix it.



Do you mean that at the tree level v[0] -= 1.0 could be changed to v -= {1.,

0.} ? That's not exactly what Ulrich was suggesting. It could be nice too, but

then we would need a different optimization in the back-end that detects the

special case of a vector subtraction where the second part of one argument is

0, in order to produce the optimal code.



In the x86 md, the sd instruction is represented as:

  [(set (match_operand:VF_128 0 "register_operand" "=x,x")

(vec_merge:VF_128

  (plusminus:VF_128

(match_operand:VF_128 1 "register_operand" "0,x")

(match_operand:VF_128 2 "nonimmediate_operand" "xm,xm"))

  (match_dup 1)

  (const_int 1)))]



which is going to be hard to recognize from:

(insn 26 53 28 4 (set (reg:DF 81 [ D.2546 ])

(vec_select:DF (reg/v:V2DF 73 [ v ])

(parallel [

(const_int 0 [0])

]))) d.c:12 1408 {sse2_storelpd}

 (nil))

(insn 28 26 29 4 (set (reg:DF 82 [ D.2546 ])

(minus:DF (reg:DF 81 [ D.2546 ])

(reg:DF 84))) d.c:12 760 {*fop_df_1_sse}

 (expr_list:REG_DEAD (reg:DF 81 [ D.2546 ])

(nil)))

(insn 29 28 30 4 (set (reg/v:V2DF 73 [ v ])

(vec_concat:V2DF (reg:DF 82 [ D.2546 ])

(vec_select:DF (reg/v:V2DF 73 [ v ])

(parallel [

(const_int 1 [0x1])

] d.c:12 1411 {sse2_loadlpd}

 (expr_list:REG_DEAD (reg:DF 82 [ D.2546 ])

(nil)))



However, since that's only 3 insn, providing an additional define_insn for the

same instruction but with a pattern of vec_select and vec_concat might be

enough for combine.

[Bug target/54908] misc regressions on emutls targets remain from dynamic initialization of non-function-local TLS variables

[howarth at nitro dot med.uc.edu]

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



--- Comment #1 from Jack Howarth  2012-10-12 
13:21:27 UTC ---

I don't know if this is too strict for non-emutls targets but on

x86_64-apple-darwin12, adding...



// { dg-require-effective-target tls_native }



to the failing testcases converts them into unsupported tests. Or will support

for dynamic initialization of non-function-local TLS variables be expanded to

emutls?

[Bug target/54908] New: misc regressions on emutls targets remain from dynamic initialization of non-function-local TLS variables

[howarth at nitro dot med.uc.edu]

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



 Bug #: 54908

   Summary: misc regressions on emutls targets remain from dynamic

initialization of non-function-local TLS variables

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





At r192374, a number of regressions from the introduction of dynamic

initialization of non-function-local TLS variables still remain on emutls

targets like x86_64-apple-darwin12. These include...



FAIL: g++.dg/gomp/tls-5.C -std=c++11 (test for excess errors)

FAIL: g++.dg/tls/thread_local-cse.C (test for excess errors)

WARNING: g++.dg/tls/thread_local-cse.C compilation failed to produce executable

FAIL: g++.dg/tls/thread_local-order1.C (test for excess errors)

WARNING: g++.dg/tls/thread_local-order1.C compilation failed to produce

executable

FAIL: g++.dg/tls/thread_local-order2.C (test for excess errors)

WARNING: g++.dg/tls/thread_local-order2.C compilation failed to produce

executable

FAIL: g++.dg/tls/thread_local2g.C (test for excess errors)

WARNING: g++.dg/tls/thread_local2g.C compilation failed to produce executable

FAIL: g++.dg/tls/thread_local3.C -std=gnu++11 execution test

FAIL: g++.dg/tls/thread_local3g.C -std=gnu++11 (test for excess errors)

WARNING: g++.dg/tls/thread_local3g.C -std=gnu++11 compilation failed to produce

executable

FAIL: g++.dg/tls/thread_local4.C -std=gnu++11 execution test

FAIL: g++.dg/tls/thread_local4g.C -std=gnu++11 (test for excess errors)

WARNING: g++.dg/tls/thread_local4g.C -std=gnu++11 compilation failed to produce

executable

FAIL: g++.dg/tls/thread_local5.C -std=gnu++11 execution test

FAIL: g++.dg/tls/thread_local5g.C -std=gnu++11 (test for excess errors)

WARNING: g++.dg/tls/thread_local5g.C -std=gnu++11 compilation failed to produce

executable

FAIL: g++.dg/tls/thread_local6g.C (test for excess errors)

WARNING: g++.dg/tls/thread_local6g.C compilation failed to produce executable

FAIL: g++.dg/tls/thread_local7g.C (test for excess errors)

UNRESOLVED: g++.dg/tls/thread_local7g.C scan-assembler-not .data



FAIL: libgomp.c++/pr24455.C  -O0  (test for excess errors)

WARNING: libgomp.c++/pr24455.C  -O0  compilation failed to produce executable

FAIL: libgomp.c++/pr24455.C  -O1  (test for excess errors)

WARNING: libgomp.c++/pr24455.C  -O1  compilation failed to produce executable

FAIL: libgomp.c++/pr24455.C  -O2  (test for excess errors)

WARNING: libgomp.c++/pr24455.C  -O2  compilation failed to produce executable

FAIL: libgomp.c++/pr24455.C  -O3 -fomit-frame-pointer  (test for excess errors)

WARNING: libgomp.c++/pr24455.C  -O3 -fomit-frame-pointer  compilation failed to

produce executable

FAIL: libgomp.c++/pr24455.C  -O3 -fomit-frame-pointer -funroll-loops  (test for

excess errors)

WARNING: libgomp.c++/pr24455.C  -O3 -fomit-frame-pointer -funroll-loops 

compilation failed to produce executable

FAIL: libgomp.c++/pr24455.C  -O3 -fomit-frame-pointer -funroll-all-loops

-finline-functions  (test for excess errors)

WARNING: libgomp.c++/pr24455.C  -O3 -fomit-frame-pointer -funroll-all-loops

-finline-functions  compilation failed to produce executable

FAIL: libgomp.c++/pr24455.C  -O3 -g  (test for excess errors)

WARNING: libgomp.c++/pr24455.C  -O3 -g  compilation failed to produce

executable

FAIL: libgomp.c++/pr24455.C  -Os  (test for excess errors)

WARNING: libgomp.c++/pr24455.C  -Os  compilation failed to produce executable

FAIL: libgomp.c++/tls-init1.C  -O  (test for excess errors)

WARNING: libgomp.c++/tls-init1.C  -O  compilation failed to produce executable





The failures all show warnings of the form...



/sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20121011/gcc/testsuite/g++.dg/tls/thread_local-cse.C:15:18:

sorry, unimplemented: dynamic initialization of non-function-local thread_local

variables not supported on this target

[Bug fortran/54880] [OOP] ICE in gfc_create_module_variable, at fortran/trans-decl.c:4013

[janus at gcc dot gnu.org]

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



--- Comment #3 from janus at gcc dot gnu.org 2012-10-12 12:52:02 UTC ---

One way to get rid of the error is to simply remove the assert that causes it

(which was already constrained by Paul for PR43450). However, I'm not sure if

that's justified.





Index: gcc/fortran/trans-decl.c

===

--- gcc/fortran/trans-decl.c(revision 192392)

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

@@ -4006,15 +4006,6 @@ gfc_create_module_variable (gfc_symbol * sym)

   decl = sym->backend_decl;

   gcc_assert (sym->ns->proc_name->attr.flavor == FL_MODULE);



-  /* -fwhole-file mixes up the contexts so these asserts are unnecessary. 

*/

-  if (!(gfc_option.flag_whole_file && sym->attr.use_assoc))

-{

-  gcc_assert (TYPE_CONTEXT (decl) == NULL_TREE

-  || TYPE_CONTEXT (decl) == sym->ns->proc_name->backend_decl);

-  gcc_assert (DECL_CONTEXT (TYPE_STUB_DECL (decl)) == NULL_TREE

-  || DECL_CONTEXT (TYPE_STUB_DECL (decl))

-   == sym->ns->proc_name->backend_decl);

-}

   TYPE_CONTEXT (decl) = sym->ns->proc_name->backend_decl;

   DECL_CONTEXT (TYPE_STUB_DECL (decl)) = sym->ns->proc_name->backend_decl;

   gfc_module_add_decl (cur_module, TYPE_STUB_DECL (decl));

[Bug lto/54898] [4.8 regression] ICE in uniquify_nodes, at lto/lto.c:1898

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 Status|ASSIGNED|RESOLVED

 Resolution||FIXED



--- Comment #8 from Richard Biener  2012-10-12 
12:29:12 UTC ---

Fixed.

[Bug lto/54898] [4.8 regression] ICE in uniquify_nodes, at lto/lto.c:1898

[rguenth at gcc dot gnu.org]

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



--- Comment #7 from Richard Biener  2012-10-12 
12:14:18 UTC ---

Author: rguenth

Date: Fri Oct 12 12:14:03 2012

New Revision: 192397



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

Log:

2012-10-12  Richard Biener  



PR lto/54898

* lto.c (gimple_types_compatible_p_1): Also compare

TYPE_MAIN_VARIANT.

(iterative_hash_gimple_type): Also hash TYPE_MAIN_VARIANT.



Modified:

trunk/gcc/lto/ChangeLog

trunk/gcc/lto/lto.c

[Bug fortran/52143] [OOP] ICE with polymorphic function result in gfc_class_vptr_get

[janus at gcc dot gnu.org]

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



janus at gcc dot gnu.org changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2012-10-12

 CC||janus at gcc dot gnu.org

 Ever Confirmed|0   |1



--- Comment #1 from janus at gcc dot gnu.org 2012-10-12 11:40:49 UTC ---

Note: It works when making g a scalar.

[Bug c/54907] post increasing a value pointed by p in subexpression of an expression modifying p saves the increased value in the wrong place

[redi at gcc dot gnu.org]

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



--- Comment #3 from Jonathan Wakely  2012-10-12 
11:23:52 UTC ---

On the RHS of the assignment *p is modified, not p



The difference in behaviour between gcc and g++ is probably due to

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

[Bug c/54907] post increasing a value pointed by p in subexpression of an expression modifying p saves the increased value in the wrong place

[yangzhe1990 at gmail dot com]

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

--- Comment #2 from yangzhe1990 at gmail dot com 2012-10-12 11:20:39 UTC ---
No, p is not modified twice.

p is modified once,
*p is modified once.

(In reply to comment #1)
> Not a bug p is modified twice without a seqence point the result is undefined
> 
> 
> 
> 
> From: yangzhe1990 at gmail dot com 
> To: gcc-bugs@gcc.gnu.org 
> Sent: Friday, 12 October 2012, 11:10
> Subject: [Bug c/54907] New: post increasing a value pointed by p in
> subexpression of an expression modifying p saves the increased value in the
> wrong place
> 
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54907
> 
>             Bug #: 54907
>           Summary: post increasing a value pointed by p in subexpression
>                     of an expression modifying p saves the increased value
>                     in the wrong place
>     Classification: Unclassified
>           Product: gcc
>           Version: 4.7.1
>             Status: UNCONFIRMED
>           Severity: normal
>           Priority: P3
>         Component: c
>         AssignedTo: unassig...@gcc.gnu.org
>         ReportedBy: yangzhe1...@gmail.com
> 
> 
> #include 
> 
> int main() {
>     char s[] = "ax";
>     char *p = s;
> 
>     printf("s = %s in the beginning.\n"
>           "p is pointed at the %d-th char.\n", s, p - s);
>     //p = p + (*p)++ * 3 + 2 - 'a' * 3; // (1)
>     p += (*p)++ * 3 + 2 - 'a' * 3; // (2)
>     printf("p is moved ahead by %d steps\n", p - s);
>     printf("s = %s after the operation.\n", s);
>     return 0;
> }
> 
> The expected result is "bx". But the output is "axbxxx".
> 
> Maybe in the wrong code, when it saves the value, it lookups the address again
> by *p, but p is modified in the expression.
> 
> As discussed in stackoverflow,
> http://stackoverflow.com/questions/12823663/would-p-p-p-3-c-cause-an-undefined-behavior?answertab=votes#tab-top
> most people think it's a bug of gcc.
> 
> Bug found in gcc 4.4.6, 4.7.1, g++ 4.4.6. g++ 4.7.1 produces the correct
> result.

[Bug tree-optimization/54824] [4.8 Regression] ICE in verify_loop_structure

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 Status|NEW |ASSIGNED

 CC||hubicka at gcc dot gnu.org

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

   |gnu.org |



--- Comment #6 from Richard Biener  2012-10-12 
11:03:55 UTC ---

The issue is how we handle the case of "vanishing" noreturn,

either via LTO symbol merging or via inlining.  We end up with



  if (_12 == 0)

goto ;

  else

goto ;

;;succ:   9

;;10





;;   basic block 9, loop depth 0

;;   Invalid sum of incoming frequencies 214, should be 430

;;pred:   8

;;6

;;succ:





that is a basic-block without a successor.



Code isn't really prepared to do sth sensible with this and we will end up

generating weird code that falls through to wahtever basic-block happens

to be next.



We have code to deal with noreturn appearing out of nowhere, but not

the other way around.



I'll try to plug the hole somewhere.  Honza, any good idea?

[Bug c++/24449] Unable to declare friend main() from class template

[paolo.carlini at oracle dot com]

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



Paolo Carlini  changed:



   What|Removed |Added



 Status|NEW |ASSIGNED

 CC|gcc-bugs at gcc dot gnu.org |

 AssignedTo|unassigned at gcc dot   |paolo.carlini at oracle dot

   |gnu.org |com

  Known to fail||



--- Comment #6 from Paolo Carlini  2012-10-12 
10:56:33 UTC ---

On it.

[Bug c/54907] post increasing a value pointed by p in subexpression of an expression modifying p saves the increased value in the wrong place

[graham.stott at btinternet dot com]

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

--- Comment #1 from graham.stott at btinternet dot com 2012-10-12 10:24:30 UTC 
---
Not a bug p is modified twice without a seqence point the result is undefined




From: yangzhe1990 at gmail dot com 
To: gcc-bugs@gcc.gnu.org 
Sent: Friday, 12 October 2012, 11:10
Subject: [Bug c/54907] New: post increasing a value pointed by p in
subexpression of an expression modifying p saves the increased value in the
wrong place


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

            Bug #: 54907
          Summary: post increasing a value pointed by p in subexpression
                    of an expression modifying p saves the increased value
                    in the wrong place
    Classification: Unclassified
          Product: gcc
          Version: 4.7.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
        Component: c
        AssignedTo: unassig...@gcc.gnu.org
        ReportedBy: yangzhe1...@gmail.com


#include 

int main() {
    char s[] = "ax";
    char *p = s;

    printf("s = %s in the beginning.\n"
          "p is pointed at the %d-th char.\n", s, p - s);
    //p = p + (*p)++ * 3 + 2 - 'a' * 3; // (1)
    p += (*p)++ * 3 + 2 - 'a' * 3; // (2)
    printf("p is moved ahead by %d steps\n", p - s);
    printf("s = %s after the operation.\n", s);
    return 0;
}

The expected result is "bx". But the output is "axbxxx".

Maybe in the wrong code, when it saves the value, it lookups the address again
by *p, but p is modified in the expression.

As discussed in stackoverflow,
http://stackoverflow.com/questions/12823663/would-p-p-p-3-c-cause-an-undefined-behavior?answertab=votes#tab-top
most people think it's a bug of gcc.

Bug found in gcc 4.4.6, 4.7.1, g++ 4.4.6. g++ 4.7.1 produces the correct
result.

[Bug lto/54898] [4.8 regression] ICE in uniquify_nodes, at lto/lto.c:1898

[rguenth at gcc dot gnu.org]

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



--- Comment #6 from Richard Biener  2012-10-12 
10:16:19 UTC ---

What happens is that we merge wchar_t that is a main variant in one TU

with wchar_t that is not a main variant in another TU.



I have a patch.

[Bug c/54907] New: post increasing a value pointed by p in subexpression of an expression modifying p saves the increased value in the wrong place

[yangzhe1990 at gmail dot com]

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



 Bug #: 54907

   Summary: post increasing a value pointed by p in subexpression

of an expression modifying p saves the increased value

in the wrong place

Classification: Unclassified

   Product: gcc

   Version: 4.7.1

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: c

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

ReportedBy: yangzhe1...@gmail.com





#include 



int main() {

char s[] = "ax";

char *p = s;



printf("s = %s in the beginning.\n"

   "p is pointed at the %d-th char.\n", s, p - s);

//p = p + (*p)++ * 3 + 2 - 'a' * 3; // (1)

p += (*p)++ * 3 + 2 - 'a' * 3; // (2)

printf("p is moved ahead by %d steps\n", p - s);

printf("s = %s after the operation.\n", s);

return 0;

}



The expected result is "bx". But the output is "axbxxx".



Maybe in the wrong code, when it saves the value, it lookups the address again

by *p, but p is modified in the expression.



As discussed in stackoverflow,

http://stackoverflow.com/questions/12823663/would-p-p-p-3-c-cause-an-undefined-behavior?answertab=votes#tab-top

most people think it's a bug of gcc.



Bug found in gcc 4.4.6, 4.7.1, g++ 4.4.6. g++ 4.7.1 produces the correct

result.

[Bug target/54902] [4.7 Regression], ICE (segfault) building on arm-linux-gnueabi

[doko at gcc dot gnu.org]

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



Matthias Klose  changed:



   What|Removed |Added



  Known to work||4.8.0



--- Comment #2 from Matthias Klose  2012-10-12 
09:58:46 UTC ---

trunk 20120820 and 20121008 do work.

[Bug fortran/54880] [OOP] ICE in gfc_create_module_variable, at fortran/trans-decl.c:4013

[slayoo at staszic dot waw.pl]

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



--- Comment #2 from Sylwester Arabas  2012-10-12 
09:48:12 UTC ---

Hi,



I've came across it after simply switching the order of module definitions in a

file (i.e. no preprocessor - I've used the preprocessor to simplify the test

case). 



I would then answer: definitely YES! - fixing it might save someone a lot of

time. Due to the ICE, and due the fact that the presence of the .mod file

influences gfortran's behaviour here, figuring out what's wrong is really

tricky and time consuming. 



Sylwester

[Bug target/54902] [4.7 Regression], ICE (segfault) building on arm-linux-gnueabi

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



   Target Milestone|--- |4.7.3



--- Comment #1 from Richard Biener  2012-10-12 
09:37:04 UTC ---

Please also check trunk.

[Bug fortran/54880] [OOP] ICE in gfc_create_module_variable, at fortran/trans-decl.c:4013

[janus at gcc dot gnu.org]

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



janus at gcc dot gnu.org changed:



   What|Removed |Added



 CC||janus at gcc dot gnu.org

Summary|ICE in  |[OOP] ICE in

   |gfc_create_module_variable, |gfc_create_module_variable,

   |at  |at

   |fortran/trans-decl.c:4013   |fortran/trans-decl.c:4013



--- Comment #1 from janus at gcc dot gnu.org 2012-10-12 09:33:27 UTC ---

Huh, the procedure to reproduce the bug is rather strange. However, I can

confirm the error (with 4.7 and trunk). I could even reduce it a bit more:



> cat m1.f95

module solver_2D_m

  use adv_m

  class(adv_t), pointer :: adv

end module



> cat m2.f95

module adv_m

  type :: adv_t

  end type

end module



> cat m12.f95

#include "m1.f95"

#include "m2.f95"



> cat trigger.sh

#!/bin/bash

gfortran-4.8 -c m2.f95

gfortran-4.8 -cpp -c m12.f95





The error on the second line only happens if the module file of 'adv_m' is

present (created by the first line).



The example seems very 'constructed' to me. Does it have any practical

relevance to you?

[Bug fortran/54871] [4.8 regression] gfortran.dg/vector_subscript_1.f90 FAILs

[ebotcazou at gcc dot gnu.org]

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



Eric Botcazou  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2012-10-12

 Ever Confirmed|0   |1



--- Comment #3 from Eric Botcazou  2012-10-12 
09:32:54 UTC ---

Confirmed.

[Bug c++/53099] Internal compiler error on short testcase

[paolo.carlini at oracle dot com]

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



--- Comment #1 from Paolo Carlini  2012-10-12 
09:06:35 UTC ---

Note, for the crash -std=c++11 is required.

[Bug rtl-optimization/46888] missed optimization of zero_extract with constant inputs

[pinskia at gcc dot gnu.org]

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



--- Comment #7 from Andrew Pinski  2012-10-12 
08:50:55 UTC ---

Oh with my current patch, we are able to remove at least one bfi, the first

one.

[Bug rtl-optimization/46888] missed optimization of zero_extract with constant inputs

[pinskia at gcc dot gnu.org]

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



Andrew Pinski  changed:



   What|Removed |Added



  Attachment #28428|0   |1

is obsolete||



--- Comment #6 from Andrew Pinski  2012-10-12 
08:49:35 UTC ---

Created attachment 28431

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

New patch



Still does not fix the ARM case but similar thing can be done for the three

combine case.  It does fix the mips case which I was looking into; though

really there should be only one insert and no shift.

[Bug c++/54091] internal compiler error in class method with many string objects

[paolo.carlini at oracle dot com]

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



Paolo Carlini  changed:



   What|Removed |Added



 Status|UNCONFIRMED |WAITING

   Last reconfirmed||2012-10-12

 Ever Confirmed|0   |1

[Bug fortran/54871] [4.8 regression] gfortran.dg/vector_subscript_1.f90 FAILs

[ro at gcc dot gnu.org]

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



--- Comment #2 from Rainer Orth  2012-10-12 08:41:06 UTC 
---

Created attachment 28430

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

bad assembler output

[Bug fortran/54871] [4.8 regression] gfortran.dg/vector_subscript_1.f90 FAILs

[ro at gcc dot gnu.org]

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



--- Comment #1 from Rainer Orth  2012-10-12 08:40:23 UTC 
---

Created attachment 28429

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

good assembler output

[Bug fortran/54870] gfortran.dg/array_constructor_4.f90 FAILs

[ro at gcc dot gnu.org]

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



Rainer Orth  changed:



   What|Removed |Added



 CC||richard.guenther at gmail

   ||dot com



--- Comment #1 from Rainer Orth  2012-10-12 08:39:33 UTC 
---

A reghunt revealed that this was caused by this patch:



2012-06-06  Richard Guenther  



PR tree-optimization/53081

* tree-data-ref.h (adjacent_store_dr_p): Rename to ...

(adjacent_dr_p): ... this and make it work for reads, too.

* tree-loop-distribution.c (enum partition_kind): Add PKIND_MEMCPY.

(struct partition_s): Change main_stmt to main_dr, add

secondary_dr member.

[...]



It already occurs with a non-bootstrap gfortran and is independent of the

libgfortran.so (built with our without the patch) used.



I'm attaching the assembler outputs.



  Rainer

[Bug c++/52744] bad handling of member (function) pointers in template parameters

[paolo.carlini at oracle dot com]

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



Paolo Carlini  changed:



   What|Removed |Added



 Status|NEW |RESOLVED

 Resolution||FIXED



--- Comment #10 from Paolo Carlini  2012-10-12 
08:32:53 UTC ---

Done.

[Bug c++/52744] bad handling of member (function) pointers in template parameters

[paolo at gcc dot gnu.org]

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



--- Comment #9 from paolo at gcc dot gnu.org  
2012-10-12 08:30:23 UTC ---

Author: paolo

Date: Fri Oct 12 08:30:00 2012

New Revision: 192392



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

Log:

2012-10-12  Paolo Carlini  



PR c++/52744

* g++.dg/cpp0x/pr52744.C: New.



Added:

trunk/gcc/testsuite/g++.dg/cpp0x/pr52744.C

Modified:

trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/46888] missed optimization of zero_extract with constant inputs

[pinskia at gcc dot gnu.org]

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



--- Comment #5 from Andrew Pinski  2012-10-12 
08:23:35 UTC ---

It actually does not work for the arm case but it can be improved to work for

it which I am doing now.

[Bug fortran/40453] [F95] Enhanced (recursive) argument checking

[janus at gcc dot gnu.org]

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



janus at gcc dot gnu.org changed:



   What|Removed |Added



 Status|ASSIGNED|RESOLVED

 Resolution||FIXED



--- Comment #6 from janus at gcc dot gnu.org 2012-10-12 08:21:12 UTC ---

Fixed with r192391. Closing.

[Bug c++/52744] bad handling of member (function) pointers in template parameters

[paolo.carlini at oracle dot com]

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



Paolo Carlini  changed:



   What|Removed |Added



  Known to work||4.8.0

   Target Milestone|--- |4.8.0



--- Comment #8 from Paolo Carlini  2012-10-12 
08:16:45 UTC ---

These are all fixed in mainline. I'm adding a testcase and closing the PR.

[Bug fortran/40453] [F95] Enhanced (recursive) argument checking

[janus at gcc dot gnu.org]

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



--- Comment #5 from janus at gcc dot gnu.org 2012-10-12 08:16:37 UTC ---

Author: janus

Date: Fri Oct 12 08:16:17 2012

New Revision: 192391



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

Log:

2012-10-12  Janus Weil  



PR fortran/40453

* interface.c (check_dummy_characteristics): Recursively check dummy

procedures.



2012-10-12  Janus Weil  



PR fortran/40453

* gfortran.dg/dummy_procedure_9.f90: New.



Added:

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

Modified:

trunk/gcc/fortran/ChangeLog

trunk/gcc/fortran/interface.c

trunk/gcc/testsuite/ChangeLog

[Bug c++/54903] [4.8 Regression] Auto + static in-class constant initalization not working

[mpolacek at gcc dot gnu.org]

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



Marek Polacek  changed:



   What|Removed |Added



 CC||mpolacek at gcc dot gnu.org



--- Comment #2 from Marek Polacek  2012-10-12 
08:12:23 UTC ---

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

[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



  Known to work||4.8.0

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

   |internal compiler error: in |internal compiler error: in

   |vect_get_vec_def_for_operan |vect_get_vec_def_for_operan

   |d, at   |d, at

   |tree-vect-stmts.c:1286  |tree-vect-stmts.c:1286



--- Comment #6 from Richard Biener  2012-10-12 
08:09:54 UTC ---

Fixed on trunk sofar.

[Bug rtl-optimization/46888] missed optimization of zero_extract with constant inputs

[pinskia at gcc dot gnu.org]

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



Andrew Pinski  changed:



   What|Removed |Added



 Status|NEW |ASSIGNED

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

   |gnu.org |



--- Comment #4 from Andrew Pinski  2012-10-12 
08:07:49 UTC ---

Created attachment 28428

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

A third patch



Here is a third patch which improves the code a different way, one which seems

better as combine.c already had the code which is supposed to do the combining

of:

(set (x) (const))

(set (zero_extract (x a b) (const))

But it forgot that x can be a non subreg if we are using a zero extract.



Also it is easy add the case where the second set does not have a const there

and optimize it to a shift followed by an and which gets my testcase too.

[Bug tree-optimization/54894] [4.6/4.7/4.8 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



--- Comment #5 from Richard Biener  2012-10-12 
08:00:47 UTC ---

Author: rguenth

Date: Fri Oct 12 08:00:29 2012

New Revision: 192390



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

Log:

2012-10-12  Richard Biener  



PR tree-optimization/54894

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

Handle over-aligned scalar types properly.



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



Added:

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

Modified:

trunk/gcc/ChangeLog

trunk/gcc/testsuite/ChangeLog

trunk/gcc/tree-vect-stmts.c