[Bug target/56309] -O3 optimizer generates conditional moves instead of compare and branch resulting in almost 2x slower code

[ubizjak at gmail dot com]

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



Uros Bizjak  changed:



   What|Removed |Added



 Target||x86

 Status|UNCONFIRMED |NEW

   Last reconfirmed||2013-02-14

 CC||hjl.tools at gmail dot com,

   ||ubizjak at gmail dot com

 Ever Confirmed|0   |1



--- Comment #4 from Uros Bizjak  2013-02-14 08:16:26 
UTC ---

(In reply to comment #0)



> When an unsigned long long parameter to a function is passed by reference

> instead of by value the result is a dramatic almost 2x improvement in speed

> when compiled with -O3.  Given that the function is inlined this is 
> unexpected.

>  Upon closer inspection it was found that the code generated is quite

> different, as if passing the parameter by value enables an optimization (use 
> of

> x86 conditional moves) that backfires, possibly by suffering an unexpected

> stall in the processor.



This is due to x86 processor deficiency (HW bug?) with cmove insns. Please see

explanations in PR53346 and PR54073.



There is no solution (yet?), compiler should probably detect this situation and

avoid conversion to cmove.

[Bug ada/56316] New: [4.8 Regression] bootstrap with ada on mingw fails in ada/gcc-interface/trans.c

[rai...@emrich-ebersheim.de]

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



 Bug #: 56316

   Summary: [4.8 Regression] bootstrap with ada on mingw fails in

ada/gcc-interface/trans.c

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: ada

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

ReportedBy: rai...@emrich-ebersheim.de

  Host: *-w64-mingw32

Target: *-w64-mingw32

 Build: *-w64-mingw32





gcc trunk rev. 195803



g++ -c   -g -DIN_GCC   -fno-exceptions -fno-rtti -fasynchronous-unwind-tables

-W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual  -Wmissing-format-attribute

-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings   -DHAVE_CONFIG_H

-I.. -I. -Iada -I../../../src/gcc-4.8.0/gcc -I../../../src/gcc-4.8.0/gcc/ada

-I../../../src/gcc-4.8.0/gcc/../include -I./../intl

-I../../../src/gcc-4.8.0/gcc/../libcpp/include

-I/SCRATCH/tmp.kPrCLMNzhZ/install/include

-I/SCRATCH/tmp.kPrCLMNzhZ/install/include

-I/SCRATCH/tmp.kPrCLMNzhZ/install/include 

-I../../../src/gcc-4.8.0/gcc/../libdecnumber

-I../../../src/gcc-4.8.0/gcc/../libdecnumber/bid -I../libdecnumber

-I../../../src/gcc-4.8.0/gcc/../libbacktrace -DCLOOG_INT_GMP

-I/SCRATCH/tmp.kPrCLMNzhZ/install/include

-I/SCRATCH/tmp.kPrCLMNzhZ/install/include 

../../../src/gcc-4.8.0/gcc/ada/gcc-interface/trans.c -o ada/trans.o 

../../../src/gcc-4.8.0/gcc/ada/gcc-interface/trans.c: In function 'tree_node*

Pragma_to_gnu(Node_Id)':

../../../src/gcc-4.8.0/gcc/ada/gcc-interface/trans.c:1267:42: error:

'LOOP_STMT_NO_UNROLL' was not declared in this scope

../../../src/gcc-4.8.0/gcc/ada/gcc-interface/trans.c:1271:39: error:

'LOOP_STMT_UNROLL' was not declared in this scope

../../../src/gcc-4.8.0/gcc/ada/gcc-interface/trans.c:1275:42: error:

'LOOP_STMT_NO_VECTOR' was not declared in this scope

../../../src/gcc-4.8.0/gcc/ada/gcc-interface/trans.c:1279:39: error:

'LOOP_STMT_VECTOR' was not declared in this scope

gmake[3]: *** [ada/trans.o] Error 1 





That's introduced in January.

[Bug target/56309] -O3 optimizer generates conditional moves instead of compare and branch resulting in almost 2x slower code

[ubizjak at gmail dot com]

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



--- Comment #5 from Uros Bizjak  2013-02-14 08:22:33 
UTC ---

For reference, some quotes from Honza:



-- PR54073--

The decision on whether to use cmov or jmp was always tricky on x86

architectures. Cmov increase dependency chains, register pressure (both values

needs to be loaded in) and has long opcode. So jump sequence, if well

predicted, flows better through the out-of-order core. If badly predicted it

is, of course, a disaster. I think more modern CPUs solved the problems with

long latency of cmov, but the dependency chains are still there.



[...]



We should do something about rnflow. I will look into that.

The usual wisdom is that lacking profile feedback one should handle non-loop

branhces as inpredctable and loop branches as predictable, so all handled by

ifconvert fals to the first category. With profile feedback one can see branch

probability and if it is close to 0 or REG_BR_PROB_BASE tread the branch as

predictable. We handle this with predictable_edge_p parameter passed to

BRANCH_COST (that by itself is a gross, but for years we was not able to come

with something saner)

-- /PR54073 --



-- PR53046 --

Well, as I wrote to the other PR, the main problem of cmov is extension of

dependency chain.  For well predicted sequence with conditional jump there is

no update of rbs so the loop executes faster, because the

loads/stores/comparisons executes "in parallel". The load in the next iteration

can then happen speculatively before the condition from previous iteration is

resolved. With cmov in it, there is dependence on rbx for all the other

computations in the loop.



I guess there is no localy available information suggesting suggesting that the

particular branch is well predictable, at least without profile feedback (where

we won't disable the conversion anyway).



[...]

-- /PR53046 --

[Bug target/56309] -O3 optimizer generates conditional moves instead of compare and branch resulting in almost 2x slower code

[ubizjak at gmail dot com]

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



--- Comment #6 from Uros Bizjak  2013-02-14 08:27:52 
UTC ---

(In reply to comment #5)

> -- PR53046 --

> [...]

> -- /PR53046 --



Actually, PR53346.

[Bug ada/52123] [4.7/4.8 Regression] gcc bootstrap with ada fails on mingw target

[ktietz at gcc dot gnu.org]

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



--- Comment #11 from Kai Tietz  2013-02-14 08:45:16 
UTC ---

Author: ktietz

Date: Thu Feb 14 08:45:09 2013

New Revision: 196046



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

Log:

2013-02-14  Rainer Emrich  



PR target/52123

* adaint.c (__gnat_check_OWNER_ACL): Cast from pointer via

SECURITY_DESCRIPTOR *.

(__gnat_set_OWNER_ACL): Cast from DWORD to ACCESS_MODE.

(__gnat_portable_spawn): Fix cast to char* const*.

(add_handle): Cast from pointer via void **.

(add_handle): Cast from pointer via int *.

(__gnat_locate_exec_on_path): Cast from pointer via TCHAR *.

(__gnat_locate_exec_on_path): Cast from pointer via char *.

* initialize.c (append_arg): Cast from pointer via LPWSTR.

(__gnat_initialize): Cast from pointer via LPWSTR.

* seh_init.c (__gnat_SEH_error_handler): Cast from pointer via FARPROC.

* tracebak.c: Cast from pointer via FARPROC.



Modified:

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

branches/gcc-4_7-branch/gcc/ada/adaint.c

branches/gcc-4_7-branch/gcc/ada/initialize.c

branches/gcc-4_7-branch/gcc/ada/seh_init.c

branches/gcc-4_7-branch/gcc/ada/tracebak.c

[Bug ada/56316] [4.8 Regression] bootstrap with ada on mingw fails in ada/gcc-interface/trans.c

[rai...@emrich-ebersheim.de]

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



--- Comment #2 from Rainer Emrich  2013-02-14 
08:52:19 UTC ---

-BEGIN PGP SIGNED MESSAGE-

Hash: SHA1



Am 14.02.2013 09:46, schrieb charlet at gcc dot gnu.org:

> I would suggest always checking with current trunk before opening these

> PRs since this was fixed on 2013-02-06 (revision 195805).

Sorry, for the noise!



Rainer



> 

> Arno

> 



-BEGIN PGP SIGNATURE-

Version: GnuPG v1.4.10 (MingW32)

Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/



iQEcBAEBAgAGBQJRHKWLAAoJEB3HOsWs+KJbIQYIAIhzM7VNeLAg/KO7hGKXVD0+

pjVUyUsKPCn/bsvVohWP99T127Oy99B6zznBWRNTpzoCbn1Vf5o93zPiimk4DJrQ

EhFfeSE9eNXaVwbyLtnjuP5+yHOLgzgoSE/Othz2LWMCazwWWKiFMTuK+ITiDHZT

Y+JrpajOZEeX3YdMwaq30/gUQ2b7/6Y0rbS5bCsI/fCz2zbPCy/Xf24cj+Jzj5Ad

3/p13HmrfZ1SaggNl6qxzJkzT24olyVypR4V1P6OJp6/Bjhe2eY9l6qdpv6R14iz

IOuPqdAN/qTzKHF9aP8jliuPV297f8ZJ64VEmpHUctjSCyCvjSRGTWa/ehwORKc=

=a5/r

-END PGP SIGNATURE-

[Bug lto/50494] gcc.dg/vect/vect-reduc-2char.c fails spuriously on ppc with -flto

[rguenther at suse dot de]

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



--- Comment #16 from rguenther at suse dot de  
2013-02-14 08:56:12 UTC ---

On Wed, 13 Feb 2013, ebotcazou at gcc dot gnu.org wrote:



> 

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

> 

> --- Comment #14 from Eric Botcazou  2013-02-13 
> 22:13:42 UTC ---

> > In LTO:

> > 

> >   /* If this variable belongs to the global constant pool, retrieve the

> >  pre-computed RTL or recompute it in LTO mode.  */

> >   if (TREE_CODE (decl) == VAR_DECL && DECL_IN_CONSTANT_POOL (decl))

> > {

> >   SET_DECL_RTL (decl, output_constant_def (DECL_INITIAL (decl), 1));

> >   return;

> > 

> > but obviously output_constant_def when just getting DECL_INITIAL cannot

> > honor any special alignment requirements of decl.  It will simply get

> > a new decl with standard alignment.

> > 

> > We know decl is already the decl associated with the constant, so we

> > should just re-use it.

> 

> Why does the alignment of a DECL_IN_CONSTANT_POOL matter here exactly?



Because as it is seen as a regular VAR_DECL by optimizers the

vectorizer (well, IPA increase-alignment in this case) chooses to

bump its alignment to be able to use aligned vector moves.



Thus we need to honor the increased DECL_ALIGN when outputting the

constant pool, otherwise we generate wrong-code.

[Bug ada/56316] [4.8 Regression] bootstrap with ada on mingw fails in ada/gcc-interface/trans.c

[charlet at gcc dot gnu.org]

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



Arnaud Charlet  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 CC||charlet at gcc dot gnu.org

 Resolution||FIXED



--- Comment #1 from Arnaud Charlet  2013-02-14 
08:46:33 UTC ---

This was an unintended change, reverted right away.



I would suggest always checking with current trunk before opening these PRs

since

this was fixed on 2013-02-06 (revision 195805).



Arno

[Bug middle-end/56242] [4.8 Regression] libjava/classpath/gnu/javax/swing/text/html/parser/support/textPreProcessor.java:175:0: ICE: Segmentation fault

[vries at gcc dot gnu.org]

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



--- Comment #6 from vries at gcc dot gnu.org 2013-02-14 09:11:06 UTC ---

> New version of the patch, the previous one did PATTERN (PATTERN ()). I'm

> bootstrapping this now on x86_64, and will test it on mips.



Bootstrapped and reg-tested on x86_64. Build and reg-tested on mips. No issues

found.

[Bug lto/50494] gcc.dg/vect/vect-reduc-2char.c fails spuriously on ppc with -flto

[ebotcazou at gcc dot gnu.org]

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



--- Comment #17 from Eric Botcazou  2013-02-14 
09:18:46 UTC ---

> Because as it is seen as a regular VAR_DECL by optimizers the

> vectorizer (well, IPA increase-alignment in this case) chooses to

> bump its alignment to be able to use aligned vector moves.

> 

> Thus we need to honor the increased DECL_ALIGN when outputting the

> constant pool, otherwise we generate wrong-code.



I see, thanks.  Perhaps the safest solution is to prevent IPA from increasing

the alignment if DECL_IN_CONSTANT_POOL, as initializations of aggregate objects

are presumably not supposed to happen in hot spots.

[Bug c++/56317] New: inheriting constructor fails to move brace-initialized object

[potswa at mac dot com]

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

 Bug #: 56317
   Summary: inheriting constructor fails to move brace-initialized
object
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: pot...@mac.com


Although p{} in the example below is an rvalue, I get an error "cannot bind ‘p’
lvalue to ‘p&&’."

It does compile if I don't use braces, and change p{} to p().

struct p {};
struct b { b( p && ) {} };
struct d : b { using b::b; };

d o( p{} );


In the original, full program, it doesn't mention a value category, and
changing the braces to () doesn't work around the issue.

[Bug c++/56317] inheriting constructor fails to move brace-initialized object

[potswa at mac dot com]

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



--- Comment #1 from David Krauss  2013-02-14 09:35:12 
UTC ---

(But, perfect forwarding equivalent to the inheriting constructor semantic does

work around the issue.)

[Bug fortran/56138] Deferred-length character RESULT: ICE in gfc_add_modify_loc

[burnus at gcc dot gnu.org]

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



--- Comment #9 from Tobias Burnus  2013-02-14 
09:37:58 UTC ---

Author: burnus

Date: Thu Feb 14 09:37:53 2013

New Revision: 196047



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

Log:

2013-02-14  Paul Thomas  

Tobias Burnus  



PR testsuite/56138

* trans-decl.c (gfc_get_symbol_decl): Fix deferred-length

results for functions without extra result variable.



Revert:

2013-01-30  Tobias Burnus  



PR fortran/56138

* trans-decl.c (gfc_trans_deferred_vars): Fix deferred-length

results for functions without extra result variable.



2013-02-14  Dominique d'Humieres  

Tobias Burnus  



PR testsuite/56138

* gfortran.dg/allocatable_function_7.f90: New.





Added:

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

Modified:

trunk/gcc/fortran/ChangeLog

trunk/gcc/fortran/trans-decl.c

trunk/gcc/testsuite/ChangeLog

[Bug c++/56317] inheriting constructor fails to move brace-initialized object

[redi at gcc dot gnu.org]

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



Jonathan Wakely  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||DUPLICATE



--- Comment #2 from Jonathan Wakely  2013-02-14 
09:56:15 UTC ---

dup of PR 56285



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

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

[redi at gcc dot gnu.org]

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



Jonathan Wakely  changed:



   What|Removed |Added



 CC||potswa at mac dot com



--- Comment #4 from Jonathan Wakely  2013-02-14 
09:56:15 UTC ---

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

[Bug fortran/56138] Deferred-length character RESULT: ICE in gfc_add_modify_loc

[burnus at gcc dot gnu.org]

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



Tobias Burnus  changed:



   What|Removed |Added



 Status|ASSIGNED|RESOLVED

 Resolution||FIXED



--- Comment #10 from Tobias Burnus  2013-02-14 
10:09:31 UTC ---

Should now be really FIXED.

[Bug go/56171] syscall FAILs on Solaris

[ro at gcc dot gnu.org]

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



--- Comment #9 from Rainer Orth  2013-02-14 10:11:11 UTC 
---

Created attachment 29448

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

proposed patch for __xnet_ socket functions



This works fine in the 32-bit case, but for 64-bit (both sparc and x86) needed

one further adjustment: the 64-bit tests were failing like this:



  amd64:



--- FAIL: TestPassFD (0.09 seconds)

:0: child process ReadAll: "", ; want "Hello from child process!\n"

FAIL

FAIL: syscall



  sparcv9:



--- FAIL: TestPassFD (0.28 seconds)

passfd_test.go:102: child process ReadAll: "", ; want "Hello from

child process!\n"

FAIL

FAIL: syscall



(Btw., need to check why filename and line number aren't detected on x86...)



It turned out that as on Darwin, we always need 32-bit alignment.  The attached

patch does just that and allows the syscall to pass on both 32- and 64-bit

Solaris/SPARC and x86.



  Rainer



2013-02-13  Rainer Orth  



PR go/5617

* go/syscall/sockcmsg_unix.go: Import "runtime".

(cmsgAlignOf): Enforce 32-bit alignment on Solaris.

* go/syscall/socket.go (bind, connect, socket, socketpair)

(getsockopt, sendto, recvmsg, sendmsg): Move ...

* go/syscall/socket_posix.go: ... here.

New file.

* go/syscall/socket_xnet.go: New file.

* Makefile.am (syscall_socket_os_file): New variable.

(go_base_syscall_files): Use it.

* Makefile.in: Regenerate.

[Bug fortran/56204] [4.8 regression] gfortran.dg/quad_[23].f90 FAIL on Solaris 9/x86

[ro at CeBiTec dot Uni-Bielefeld.DE]

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



--- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE  2013-02-14 10:13:03 UTC ---

> --- Comment #4 from Tobias Burnus  2013-02-13 
> 12:06:02 UTC ---

> Thanks for testing. It looks as if it should have been FIXED by the committed

> patch. Please re-open if the issue still occurs.



The test now passes on i386-pc-solaris2.9, i386-pc-solaris2.10, and

sparc-sun-solaris2.11.



Thanks.

Rainer

[Bug fortran/56318] New: [4.6/4.7/4.8 Regression] Wrong result with MATMUL of PARAMETER

[burnus at gcc dot gnu.org]

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



 Bug #: 56318

   Summary: [4.6/4.7/4.8 Regression] Wrong result with MATMUL of

PARAMETER

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





Reported by Alberto Luaces at

http://gcc.gnu.org/ml/fortran/2013-02/msg00074.html



The code below should print the following - and it does with GCC 4.1/4.3/4.4

and NAG f95:

   0.333   0.000   0.000

   0.000   0.333   0.000

   0.000   0.000   0.000



However, with GCC 4.5/4.6/4.7/4.8, it prints:

   0.333   0.000   0.000

   0.000   0.000   0.333

   0.000   0.000   0.000





SUBROUTINE mass_matrix

  DOUBLE PRECISION,PARAMETER::m1=1.d0

  DOUBLE PRECISION,DIMENSION(3,2),PARAMETER::A1=reshape([1.d0,0.d0, 0.d0, &

   0.d0,1.d0, 0.d0],[3,2])

  DOUBLE PRECISION,DIMENSION(2,2),PARAMETER::Mel=reshape([1.d0/3.d0, 0.d0, &

   0.d0, 1.d0/3.d0],[2,2])



  DOUBLE PRECISION,DIMENSION(3,3)::MM1



  MM1=m1*matmul(A1,matmul(Mel,transpose(A1)))

  print '(3f8.3)', MM1

  if (any (abs (MM1 &

- reshape ([1.d0/3.d0, 0.d0,  0.d0,  &

0.d0,  1.d0/3.d0, 0.d0,  &

0.d0,  0.d0,  0.d0], &

   [3,3])) > epsilon(1.0d0))) &

call abort ()

END SUBROUTINE mass_matrix



program name

  implicit none

  call mass_matrix

end program name

[Bug fortran/56318] [4.6/4.7/4.8 Regression] Wrong result with MATMUL of PARAMETER

[burnus at gcc dot gnu.org]

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



Tobias Burnus  changed:



   What|Removed |Added



 CC||burnus at gcc dot gnu.org

   Target Milestone|--- |4.6.4

[Bug middle-end/56314] Please allow per-function specification of register conventions

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



   Keywords||missed-optimization, ra

 Status|UNCONFIRMED |NEW

   Last reconfirmed||2013-02-14

 CC||vmakarov at gcc dot gnu.org

  Component|other   |middle-end

 Ever Confirmed|0   |1



--- Comment #3 from Richard Biener  2013-02-14 
10:29:27 UTC ---

Confirmed.

[Bug rtl-optimization/48133] [4.6/4.7 Regression] ICE: in get_loop_body, at cfgloop.c:831 with -O -funroll-loops -fthread-jumps -fno-tree-ch

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 Status|RESOLVED|REOPENED

  Known to work||4.8.0

 Resolution|FIXED   |

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

   |ICE: in get_loop_body, at   |in get_loop_body, at

   |cfgloop.c:831 with -O   |cfgloop.c:831 with -O

   |-funroll-loops  |-funroll-loops

   |-fthread-jumps -fno-tree-ch |-fthread-jumps -fno-tree-ch



--- Comment #17 from Richard Biener  2013-02-14 
10:34:01 UTC ---

Doesn't it still fail with 4.6 and 4.7? ... yes, at least with 4.7.

[Bug debug/56307] FAIL: gcc.dg/tree-ssa/pr55579.c scan-tree-dump esra "Created a debug-only replacement for s"

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 CC||jamborm at gcc dot gnu.org



--- Comment #1 from Richard Biener  2013-02-14 
10:34:33 UTC ---

Possibly again a callee-copy issue.

[Bug lto/50494] gcc.dg/vect/vect-reduc-2char.c fails spuriously on ppc with -flto

[rguenther at suse dot de]

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



--- Comment #18 from rguenther at suse dot de  
2013-02-14 10:41:07 UTC ---

On Thu, 14 Feb 2013, ebotcazou at gcc dot gnu.org wrote:



> 

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

> 

> --- Comment #17 from Eric Botcazou  2013-02-14 
> 09:18:46 UTC ---

> > Because as it is seen as a regular VAR_DECL by optimizers the

> > vectorizer (well, IPA increase-alignment in this case) chooses to

> > bump its alignment to be able to use aligned vector moves.

> > 

> > Thus we need to honor the increased DECL_ALIGN when outputting the

> > constant pool, otherwise we generate wrong-code.

> 

> I see, thanks.  Perhaps the safest solution is to prevent IPA from increasing

> the alignment if DECL_IN_CONSTANT_POOL, as initializations of aggregate 
> objects

> are presumably not supposed to happen in hot spots.



It's also done by the vectorizer pass (for -fno-section-anchors).

I believe it's wrong to not honor DECL_ALIGN of decl in



  /* If this variable belongs to the global constant pool, retrieve the

 pre-computed RTL or recompute it in LTO mode.  */

  if (TREE_CODE (decl) == VAR_DECL && DECL_IN_CONSTANT_POOL (decl))

{

  SET_DECL_RTL (decl, output_constant_def (DECL_INITIAL (decl), 1));

  return;



which is what happens here.  Thus, if we say DECL_IN_CONSTANT_POOL

decls may not have their alignment changed we should assert that

(but my patch just honors DECL_ALIGN and avoids creation of yet

another DECL_IN_CONSTANT_POOL decl ...).  After all we also

use DECL_ALIGN information if anybody inspects the address

(which may happen if we elide the local static to the initializer

if we can see it is never changed - I suppose we cannot do that

at the moment)



Btw, if properly aligned the block-move can use vector code as well

(not sure if any target does that though).



Richard.

[Bug bootstrap/56311] gcc/include-fixed/stdio.h: In function ‘_func’: gcc/include-fixed/stdio.h:135:3: error: expected declaration specifiers before ‘__extension__’

[devurandom at gmx dot net]

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



--- Comment #2 from devurandom at gmx dot net 2013-02-14 10:44:25 UTC ---

P.S: I am willing to debug this further on my own, but I need some help.



My first guess is that the files in include-fixed are system headers, which are

somehow mangled with sed or a similar tool. Where does that happen and with

what intend?

[Bug fortran/56318] [4.6/4.7/4.8 Regression] Wrong result with MATMUL of PARAMETER

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



   Priority|P3  |P4

 Status|UNCONFIRMED |NEW

   Last reconfirmed||2013-02-14

 CC||jakub at gcc dot gnu.org

 Ever Confirmed|0   |1



--- Comment #1 from Jakub Jelinek  2013-02-14 
11:02:22 UTC ---

Started with http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148243

[Bug bootstrap/56311] gcc/include-fixed/stdio.h: In function ‘_func’: gcc/include-fixed/stdio.h:135:3: error: expected declaration specifiers before ‘__extension__’

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

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



--- Comment #3 from Andreas Schwab  2013-02-14 11:05:32 
UTC ---

See fixincludes/inclhack.def, it looks like this is from hackname =

hpux10_stdio_declarations, and select = "^#[ \t]*define _iob[ \t]*__iob" needs

to be made more strict so that it doesn't match "#define _iob __iob_func()".

[Bug fortran/56318] [4.6/4.7/4.8 Regression] Wrong result with MATMUL of PARAMETER

[burnus at gcc dot gnu.org]

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



Tobias Burnus  changed:



   What|Removed |Added



   Keywords||missed-optimization



--- Comment #2 from Tobias Burnus  2013-02-14 
11:29:55 UTC ---

Simplified test case:



!

integer, parameter :: A(3,2) = reshape([1,2,3,4,5,6],[3,2])

integer, parameter :: B(2,3) = reshape([1,1,1,1,1,1],[2,3])

integer, parameter :: m1 = 1



print '(3i3)', m1*matmul(A,B)

end

!



Expected:

  5  7  9

  5  7  9

  5  7  9



Actual result:

  9 12  8

  9 12  8

  4  6  8







a) BUG 1: The matrix is not always simplified





The "m1*" is crucial. When gfc_simplify_matmul is called initially, it returns

NULL as  "is_constant_array_expr (matrix_a)" is false.



The "m1*" causes a re-evaluation of the RHS expression, namely in

gfc_simplify_expr:

  for (ap = p->value.function.actual; ap; ap = ap->next)

if (gfc_simplify_expr (ap->expr, type) == FAILURE)



That converts an EXPR_VARIABLE with flavor FL_PARAMETER into an EXPR_ARRAY,

which can then be processed by calling gfc_simplify_matmul







b) BUG 2: matmul gives the wrong result

[Bug libitm/53113] Build fails in x86_avx.cc if AVX disabled but supported by as (Solaris & Linux)

[szarpaj at grubelek dot pl]

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



szarpaj at grubelek dot pl changed:



   What|Removed |Added



 CC||szarpaj at grubelek dot pl



--- Comment #6 from szarpaj at grubelek dot pl 2013-02-14 11:47:31 UTC ---

I think I got the same error. This is on Gentoo Linux (some parts of emerge

--info below, maybe revelant).





libtool: compile:  /var/tmp/portage/sys-devel/gcc-4.7.1/work/build/./gcc/g++

-B/var/tmp/portage/sys-devel/gcc-4.7.1/work/build/./gcc/ -nostdinc++

-nostdinc++ -I/var/tmp/portag

e/sys-devel/gcc-4.7.1/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu

-I/var/tmp/portage/sys-devel/gcc-4.7.1/work/build/x86_64-pc-linux-gnu/libstdc++-v

3/include

-I/var/tmp/portage/sys-devel/gcc-4.7.1/work/gcc-4.7.1/libstdc++-v3/libsupc++

-I/var/tmp/portage/sys-devel/gcc-4.7.1/work/gcc-4.7.1/libstdc++-v3/include/backward

-I/v

ar/tmp/portage/sys-devel/gcc-4.7.1/work/gcc-4.7.1/libstdc++-v3/testsuite/util

-L/var/tmp/portage/sys-devel/gcc-4.7.1/work/build/x86_64-pc-linux-gnu/libstdc++-v3/src

-L/var/tmp

/portage/sys-devel/gcc-4.7.1/work/build/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs

-B/usr/x86_64-pc-linux-gnu/bin/ -B/usr/x86_64-pc-linux-gnu/lib/ -isystem

/usr/x86_64-pc-linu

x-gnu/include -isystem /usr/x86_64-pc-linux-gnu/sys-include -DHAVE_CONFIG_H -I.

-I/var/tmp/portage/sys-devel/gcc-4.7.1/work/gcc-4.7.1/libitm

-I/var/tmp/portage/sys-devel/gcc-4

.7.1/work/gcc-4.7.1/libitm/config/linux/x86

-I/var/tmp/portage/sys-devel/gcc-4.7.1/work/gcc-4.7.1/libitm/config/linux

-I/var/tmp/portage/sys-devel/gcc-4.7.1/work/gcc-4.7.1/lib

itm/config/x86

-I/var/tmp/portage/sys-devel/gcc-4.7.1/work/gcc-4.7.1/libitm/config/posix

-I/var/tmp/portage/sys-devel/gcc-4.7.1/work/gcc-4.7.1/libitm/config/generic

-I/var/tmp

/portage/sys-devel/gcc-4.7.1/work/gcc-4.7.1/libitm -Wall -pthread -Werror -mavx

-std=gnu++0x -funwind-tables -fno-exceptions -fno-rtti -fabi-version=4

-march=nocona -mno-sse3

-O2 -pipe -D_GNU_SOURCE -MT x86_avx.lo -MD -MP -MF .deps/x86_avx.Tpo -c

/var/tmp/portage/sys-devel/gcc-4.7.1/work/gcc-4.7.1/libitm/config/x86/x86_avx.cc

 -fPIC -DPIC -o .libs/

x86_avx.o

depbase=`echo printf/mul_1.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`;\

/bin/sh ./libtool --tag=CC   --mode=compile

/var/tmp/portage/sys-devel/gcc-4.7.1/work/build/./gcc/xgcc

-B/var/tmp/portage/sys-devel/gcc-4.7.1/work/build/./gcc/ -B/usr/x86_64-p

c-linux-gnu/bin/ -B/usr/x86_64-pc-linux-gnu/lib/ -isystem

/usr/x86_64-pc-linux-gnu/include -isystem /usr/x86_64-pc-linux-gnu/sys-include 

  -DHAVE_CONFIG_H -I. -I/var/tmp/port

age/sys-devel/gcc-4.7.1/work/gcc-4.7.1/libquadmath -g -march=nocona

-mno-sse3 -O2 -pipe  -m32 -MT printf/mul_1.lo -MD -MP -MF $depbase.Tpo -c -o

printf/mul_1.lo /var/tmp/p

ortage/sys-devel/gcc-4.7.1/work/gcc-4.7.1/libquadmath/printf/mul_1.c &&\

mv -f $depbase.Tpo $depbase.Plo

libtool: compile:  /var/tmp/portage/sys-devel/gcc-4.7.1/work/build/./gcc/xgcc

-B/var/tmp/portage/sys-devel/gcc-4.7.1/work/build/./gcc/

-B/usr/x86_64-pc-linux-gnu/bin/ -B/usr/x

86_64-pc-linux-gnu/lib/ -isystem /usr/x86_64-pc-linux-gnu/include -isystem

/usr/x86_64-pc-linux-gnu/sys-include -DHAVE_CONFIG_H -I.

-I/var/tmp/portage/sys-devel/gcc-4.7.1/work

/gcc-4.7.1/libquadmath -g -march=nocona -mno-sse3 -O2 -pipe -m32 -MT

printf/mul_1.lo -MD -MP -MF printf/.deps/mul_1.Tpo -c

/var/tmp/portage/sys-devel/gcc-4.7.1/work/gcc-4.7.1/

libquadmath/printf/mul_1.c  -fPIC -DPIC -o printf/.libs/mul_1.o

/var/tmp/portage/sys-devel/gcc-4.7.1/work/gcc-4.7.1/libitm/config/x86/x86_avx.cc:83:1:

error: '_ITM_TYPE_M256' does not name a type

/var/tmp/portage/sys-devel/gcc-4.7.1/work/gcc-4.7.1/libitm/config/x86/x86_avx.cc:83:1:

error: '_ITM_TYPE_M256' does not name a type

/var/tmp/portage/sys-devel/gcc-4.7.1/work/gcc-4.7.1/libitm/config/x86/x86_avx.cc:83:1:

error: '_ITM_TYPE_M256' does not name a type

/var/tmp/portage/sys-devel/gcc-4.7.1/work/gcc-4.7.1/libitm/config/x86/x86_avx.cc:83:1:

error: '_ITM_TYPE_M256' does not name a type

/var/tmp/portage/sys-devel/gcc-4.7.1/work/gcc-4.7.1/libitm/config/x86/x86_avx.cc:83:1:

error: variable or field '_ITM_WM256' declared void

/var/tmp/portage/sys-devel/gcc-4.7.1/work/gcc-4.7.1/libitm/config/x86/x86_avx.cc:83:1:

error: '_ITM_TYPE_M256' was not declared in this scope

/var/tmp/portage/sys-devel/gcc-4.7.1/work/gcc-4.7.1/libitm/config/x86/x86_avx.cc:83:1:

error: 'ptr' was not declared in this scope

/var/tmp/portage/sys-devel/gcc-4.7.1/work/gcc-4.7.1/libitm/config/x86/x86_avx.cc:83:1:

error: '_ITM_TYPE_M256' was not declared in this scope

/var/tmp/portage/sys-devel/gcc-4.7.1/work/gcc-4.7.1/libitm/config/x86/x86_avx.cc:83:1:

error: variable or field '_ITM_WaRM256' declared void

/var/tmp/portage/sys-devel/gcc-4.7.1/work/gcc-4.7.1/libitm/config/x86/x86_avx.cc:83:1:

error: '_ITM_TYPE_M256' was not declared in this scope

/

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

[ysrumyan at gmail dot com]

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



--- Comment #11 from Yuri Rumyantsev  2013-02-14 
12:03:37 UTC ---

I did measurements of 3 possible fixes:



1. Comment out 2 patterns related to type sinking.

2. Comment out 1st pattern only.

3. Prohibit type sinking if source type (of def_arg1) is short type.



Measuremnets were done on eembc 2.0 suite at base optset and they showed that

the 3rd fix is more profitable for x86 in 32-bit mode.



Since I hear nothing from the code owner I assume that we will add new target

hook returning true/false for type sinkning in the both patterns that will

anaylze the source type and likely destination type of operand.



Richard, what is your opinion?

[Bug c++/56319] New: call to implicitly-deleted copy constructor accepted

[wlodzimierz.lipert at gmail dot com]

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



 Bug #: 56319

   Summary: call to implicitly-deleted copy constructor accepted

Classification: Unclassified

   Product: gcc

   Version: unknown

Status: UNCONFIRMED

  Severity: major

  Priority: P3

 Component: c++

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

ReportedBy: wlodzimierz.lip...@gmail.com





Hi,



GCC compiles following code. Copying of tuple of rvalues returned by:

std::forward_as_tuple, should not be allowed because it is ill formed.

(clang++ properly detects the problem and report an error.)

/**/

template 

struct TupleIndices

{};



template<

unsigned int I,

typename IndexTuple,

typename... Types>

struct MakeTupleIndices_;



template<

 unsigned int I,

 unsigned int... Indices,

 typename T,

 typename... Types>

struct MakeTupleIndices_, T, Types...>

{

typedef typename MakeTupleIndices_,

Types...>::type type;

};



template<

unsigned int I,

unsigned int... Indices>

struct MakeTupleIndices_ >

{

typedef TupleIndices type;

};



template

struct MakeTupleIndices : public MakeTupleIndices_<0, TupleIndices<>, Types...>

{};

/**/

void bar(int)

{

}



template 

void fooImpl(std::tuple args, TupleIndices)

{

bar(std::forward(std::get(args))...);

}



template 

void foo(std::tuple args)

{

fooImpl(args, typename MakeTupleIndices::type());

}

/**/

enum

{

id = 1

};



int main()

{

foo(std::forward_as_tuple(id));

return 0;

}

/**/



Wlodzimierz.

[Bug lto/50494] gcc.dg/vect/vect-reduc-2char.c fails spuriously on ppc with -flto

[rguenth at gcc dot gnu.org]

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



--- Comment #19 from Richard Biener  2013-02-14 
12:24:26 UTC ---

Author: rguenth

Date: Thu Feb 14 12:24:12 2013

New Revision: 196050



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

Log:

2013-02-14  Richard Biener  



PR lto/50494

* varasm.c (output_constant_def_1): Get the decl representing

the constant as argument.

(output_constant_def): Wrap output_constant_def_1.

(make_decl_rtl): Use output_constant_def_1 with the decl

representing the constant.

(build_constant_desc): Optionally re-use a decl already

representing the constant.

(tree_output_constant_def): Adjust.



Modified:

trunk/gcc/ChangeLog

trunk/gcc/varasm.c

[Bug lto/50494] gcc.dg/vect/vect-reduc-2char.c fails spuriously on ppc with -flto

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 Status|ASSIGNED|RESOLVED

 Resolution||FIXED

   Target Milestone|--- |4.8.0



--- Comment #20 from Richard Biener  2013-02-14 
12:25:02 UTC ---

Fixed for 4.8.

[Bug go/56320] New: Several libgo tests FAIL on 64-bit Solaris/x86

[ro at gcc dot gnu.org]

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



 Bug #: 56320

   Summary: Several libgo tests FAIL on 64-bit Solaris/x86

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: go

AssignedTo: i...@airs.com

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

  Host: i386-pc-solaris2.1[01]

Target: i386-pc-solaris2.1[01]

 Build: i386-pc-solaris2.1[01]





With syscall fixed, only 3 libgo testsuite failures remain on 64-bit

Solarix/x86:



Running target unix/-m64

FAIL: os

FAIL: net/http

FAIL: net/http/cgi



Running the os test manually gives



p=0xfd7fedfdf000

fatal error: runtime_lfstackpush: invalid pointer



goroutine 1 [running]:



:0



:0



:0



:0



:0



:0



:0



:0



:0



:0

main.main

   

/var/gcc/regression/trunk/10-gcc/build/i386-pc-solaris2.10/amd64/libgo/gotest2372/test/_testmain.go:71



:0



:0



:0



The two others show different errors in libgo.log, but running them manually

shows the same issue with runtime_lfstackpush, so all three may be related.

I suppose it's best to first fix the os test and only look at the others in

more detail if they prove unrelated.



  Rainer

[Bug c++/56319] implicit copy constructor is not deleted when it is ill formed

[redi at gcc dot gnu.org]

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



Jonathan Wakely  changed:



   What|Removed |Added



   Severity|major   |normal



--- Comment #1 from Jonathan Wakely  2013-02-14 
12:32:31 UTC ---

reduced:



#include 



template 

void fooImpl(std::tuple args)

{

}



template 

void foo(std::tuple args)

{

fooImpl(args);

}



enum E { id };



int main()

{

foo(std::forward_as_tuple(id));

return 0;

}

[Bug c++/56319] implicit copy constructor is not deleted when it is ill formed

[redi at gcc dot gnu.org]

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



--- Comment #2 from Jonathan Wakely  2013-02-14 
12:36:56 UTC ---

Reduced to remove  dependency



template

struct tuple

{

T t;

};



template

tuple forward_as_tuple(Types&&... t) noexcept

{

return tuple{ static_cast(t)... };

}



template 

void fooImpl(tuple args)

{

}



template 

void foo(tuple args)

{

fooImpl(args);

}



enum E { id };



int main()

{

foo(forward_as_tuple(id));

return 0;

}

[Bug c++/56319] [DR 1051] implicit copy constructor is not deleted for type with rvalue reference member

[redi at gcc dot gnu.org]

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



Jonathan Wakely  changed:



   What|Removed |Added



   Keywords||accepts-invalid

 Status|UNCONFIRMED |NEW

   Last reconfirmed||2013-02-14

Summary|implicit copy constructor   |[DR 1051] implicit copy

   |is not deleted when it is   |constructor is not deleted

   |ill formed  |for type with rvalue

   ||reference member

 Ever Confirmed|0   |1



--- Comment #3 from Jonathan Wakely  2013-02-14 
12:45:16 UTC ---

And a minimal form:



struct T { int&& i; };

T t { 1 };

T tt = t;



This should be rejected by [class.copy]/11, this was DR 1051



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

[Bug fortran/56318] [4.6/4.7/4.8 Regression] Wrong result with MATMUL of PARAMETER

[mikael at gcc dot gnu.org]

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



Mikael Morin  changed:



   What|Removed |Added



 CC||mikael at gcc dot gnu.org



--- Comment #3 from Mikael Morin  2013-02-14 
12:55:29 UTC ---

(In reply to comment #2)

> b) BUG 2: matmul gives the wrong result:



Here is a fix for that.  It gives the expected results of comment #0 and

comment #2.  Untested otherwise.



diff --git a/simplify.c b/simplify.c

index f7401e9..dcf3e89 100644

--- a/simplify.c

+++ b/simplify.c

@@ -3873,7 +3873,7 @@ gfc_simplify_matmul (gfc_expr *matrix_a, gfc_expr

*matrix_b)

 {

   result_rows = mpz_get_si (matrix_a->shape[0]);

   result_columns = mpz_get_si (matrix_b->shape[1]);

-  stride_a = mpz_get_si (matrix_a->shape[1]);

+  stride_a = mpz_get_si (matrix_a->shape[0]);

   stride_b = mpz_get_si (matrix_b->shape[0]);



   result->rank = 2;

[Bug ada/52123] [4.7/4.8 Regression] gcc bootstrap with ada fails on mingw target

[ktietz at gcc dot gnu.org]

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



--- Comment #12 from Kai Tietz  2013-02-14 13:04:15 
UTC ---

Author: ktietz

Date: Thu Feb 14 13:04:10 2013

New Revision: 196051



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

Log:

2013-02-14  Rainer Emrich  



PR target/52123

* tracebak.c: Cast from pointer via FARPROC.



Modified:

trunk/gcc/ada/ChangeLog

trunk/gcc/ada/tracebak.c

[Bug tree-optimization/56321] New: ICE:segfault in midend for -funsafe-math-optimizations -O3

[ktkachov at gcc dot gnu.org]

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

 Bug #: 56321
   Summary: ICE:segfault in midend for -funsafe-math-optimizations
-O3
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ktkac...@gcc.gnu.org
CC: jgreenha...@gcc.gnu.org, wschm...@linux.vnet.ibm.com
Target: arm-none-eabi, x86_64-unknown-linux-gnu


Created attachment 29449
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29449
ICE triggers for -O3 -funsafe-math-optimizations

Attached test case triggers a segfault in the midend.

Observed on both arm-none-eabi and x86_64-unknown-linux-gnu

gcc -O3 -funsafe-math-optimizations test.c -S
test.c: In function ‘foo’:
test.c:1:7: internal compiler error: Segmentation fault
 float foo(int n)
   ^
0x8f4e45 crash_signal
../../gcc-fsf/gcc/toplev.c:332
0x84b7bc execute_function_todo
../../gcc-fsf/gcc/passes.c:1967
0x84da0d execute_todo
../../gcc-fsf/gcc/passes.c:1999
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.


Bisection showed r186567 introduced the problem.
It seems that the reassoc code tries to do something wrong with __builtin_pow*

[Bug tree-optimization/56321] ICE:segfault in midend for -funsafe-math-optimizations -O3

[mpolacek at gcc dot gnu.org]

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



Marek Polacek  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2013-02-14

 CC||mpolacek at gcc dot gnu.org

  Known to work||4.7.3

   Target Milestone|--- |4.8.0

 Ever Confirmed|0   |1

  Known to fail||4.8.0



--- Comment #1 from Marek Polacek  2013-02-14 
13:52:16 UTC ---

Confirmed.

[Bug middle-end/56242] [4.8 Regression] libjava/classpath/gnu/javax/swing/text/html/parser/support/textPreProcessor.java:175:0: ICE: Segmentation fault

[dave.anglin at bell dot net]

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



--- Comment #7 from dave.anglin at bell dot net 2013-02-14 13:56:13 UTC ---

Patch fixes ICE on hppa2.0w-hp-hpux11.11.  Testsuite running...

[Bug tree-optimization/56321] [4.8 Regression] ICE:segfault in midend for -funsafe-math-optimizations -O3

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  2013-02-14 
13:58:06 UTC ---
Better backtrace:
X.c: In function ‘foo’:
X.c:1:7: internal compiler error: Segmentation fault
 float foo(int n)
   ^
0xa40775 crash_signal
/home/marek/src/gcc/gcc/toplev.c:332
0xc058cb gimple_code
/home/marek/src/gcc/gcc/gimple.h:1146
0xc06844 gimple_nop_p
/home/marek/src/gcc/gcc/gimple.h:4872
0xc09498 verify_use
/home/marek/src/gcc/gcc/tree-ssa.c:755
0xc09fa1 verify_ssa(bool)
/home/marek/src/gcc/gcc/tree-ssa.c:1011
0x95e667 execute_function_todo
/home/marek/src/gcc/gcc/passes.c:1967
0x95d991 do_per_function
/home/marek/src/gcc/gcc/passes.c:1701
0x95e781 execute_todo
/home/marek/src/gcc/gcc/passes.c:1999

[Bug c++/55232] [C++11] ICE with -Wunused-parameter for unused parameter pack using qualified dependent name

[jason at gcc dot gnu.org]

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



Jason Merrill  changed:



   What|Removed |Added



 Status|NEW |ASSIGNED

 CC||jason at gcc dot gnu.org

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

   |gnu.org |



--- Comment #9 from Jason Merrill  2013-02-14 
14:03:11 UTC ---

This test crashes with no warning flags; the crash happens when trying to print

the diagnostic context.



struct vector

{

typedef int value_type;

};



template< class U, class... T >

struct X

{

void push_back( typename T::value_type ... vals )

{

  U::asoeuth;

}

};



int main()

{   

  X< int, vector > x;

  x.push_back( 0 );

}

[Bug tree-optimization/56321] [4.8 Regression] ICE:segfault in midend for -funsafe-math-optimizations -O3

[mpolacek at gcc dot gnu.org]

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



--- Comment #3 from Marek Polacek  2013-02-14 
14:06:36 UTC ---

And yeah, with -fno-tree-reassoc -> no ICE.

[Bug go/56322] New: text/template and testing/quick FAIL on 32-bit Solaris/SPARC

[ro at gcc dot gnu.org]

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



 Bug #: 56322

   Summary: text/template and testing/quick FAIL on 32-bit

Solaris/SPARC

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: go

AssignedTo: i...@airs.com

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

  Host: sparc*-*-solaris2.*

Target: sparc*-*-solaris2.*

 Build: sparc*-*-solaris2.*





There are two remaining libgo tests that FAIL on 32-bit Solaris/SPARC, and they

seem to be related:



Running target unix

FAIL: text/template



Abort



#0  0xff25a440 in _lwp_kill () from /lib/libc.so.1

#1  0xff203d90 in raise () from /lib/libc.so.1

#2  0xff1db55c in abort () from /lib/libc.so.1

#3  0xfdf9d800 in __go_unwind_stack ()

at /vol/gcc/src/hg/trunk/local/libgo/runtime/go-unwind.c:179

#4  0xfdf9aefc in __go_panic (arg=...)

at /vol/gcc/src/hg/trunk/local/libgo/runtime/go-panic.c:84

#5  0xfe010adc in reflect.Type.N13_reflect.Value (

v.pointer=v.pointer@entry=0xde25ad70)

at /vol/gcc/src/hg/trunk/local/libgo/go/reflect/value.go:1543

#6  0x0002b448 in template.call (fn=..., args=...) at funcs.go:196

#7  0x00058a38 in ?? ()

#8  0x00058a38 in ?? ()

Backtrace stopped: previous frame identical to this frame (corrupt stack?)



FAIL: testing/quick



Illegal Instruction



I couldn't get a useful stacktrace out of gdb 7.5, so I'm using dbx and mdb

instead to get at least some information:



t@2 (l@2) signal ILL (illegal opcode) in (unknown) at 0x2ba24

0x0002ba24: illtrap  0x8

(dbx) where

current thread: t@2

  [1] 0x2ba24(0xdd800550, 0xff2fe1fc, 0x2b608, 0xff302780, 0x0, 0xdde2b6c0), at

0x2ba24 

  [2] 0x2ba1c(0xfe264728, 0xdde2b724, 0x60, 0xd, 0x2b608, 0x2ba10), at 0x2ba1c 

  [3] 0xfe265328(0xdde2b798, 0x9fc06204, 0x2b608, 0xdd800560, 0x50,

0x81c7e008), at 0xfe265328 

  [4] call(0x197b4, 0x14204, 0x8, 0x8, 0xdd800560, 0xdd800568), at 0xfdf9b600 

  [5] Value(0xdde2b904, 0xdde2b880, 0xdde2b910, 0x1, 0xdde2b848, 0xdde454d0),

at 0xfe0165c8 

  [6] Value(0xdde45340, 0xdde2ba68, 0xdde2b9d8, 0xdd800538, 0xdde2bafc,

0xdde45410), at 0xfe016e7c 

  [7] CheckEqual(0xfe50d7b4, 0x1, 0x2b368, 0x197b4, 0x0, 0x1a118), at 0x17154 

  [8] TestCheckEqual(0xddc19ae0, 0x8, 0x5, 0xfe5e7ed8, 0x14204, 0x197b4), at

0x14624 

  [9] testing.$thunk10(0xdd8004f0, 0xdde2c000, 0xddc10060, 0xdd800470,

0xdd8004e8, 0xdde2bf2f), at 0xfe047b14 

  [10] kickoff(0x0, 0xdd803d40, 0x0, 0x20, 0xddc13400, 0xff0c04e8), at

0xfdfa85a8 



mdb: stop on SIGILL

mdb: target stopped at:

0x2ba24:illtrap   0x8

> $c

0x2ba24(fe264728, dde2b724, 60, d, 2b608, 2ba10)

0xfe265328(dde2b798, 9fc06204, 2b608, dd800540, 50, 81c7e008)

libgo.so.3.0.1`reflect.call+0x1dc(197b4, 14204, 8, 8, dd800540, dd800548)

libgo.so.3.0.1`reflect.call.N13_reflect.Value+0xb20(dde2b904, dde2b880,

dde2b910

, 1, dde2b848, dde464b0)

libgo.so.3.0.1`reflect.Call.N13_reflect.Value+0x94(dde46320, dde2ba68, dde2b9d8

, dd800518, dde2bafc, dde463f0)

testing_quick.CheckEqual+0x1fc(fe50d7b4, 1, 2b368, 197b4, 0, 1a118)

testing_quick.TestCheckEqual+0x248(ddc19ae0, 8, 5, fe5e7ed8, 14204, 197b4)

libgo.so.3.0.1`testing.$thunk10+0x11c(dd8004f0, dde2c000, ddc10060, dd800470, 

dd8004e8, dde2bf2f)

libgo.so.3.0.1`kickoff+0x44(0, dd803d40, 0, 20, ddc13400, ff1404e8)

libc.so.1`__makecontext_v2+0x11c(0, 0, 0, 0, 0, 0)



  Rainer

[Bug go/56324] New: exp/locale/collate/build FAILs on 64-bit Solaris/SPARC

[ro at gcc dot gnu.org]

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



 Bug #: 56324

   Summary: exp/locale/collate/build FAILs on 64-bit Solaris/SPARC

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: go

AssignedTo: i...@airs.com

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

  Host: sparc*-*-solaris2.*

Target: sparc*-*-solaris2.*

 Build: sparc*-*-solaris2.*





One of two remaining libgo failures on 64-bit Solaris/SPARC is



Running target unix/-m64

FAIL: exp/locale/collate/build



panic: runtime error: index out of range [recovered]

panic: runtime error: index out of range



#0  __go_runtime_error (i=i@entry=0)

at /vol/gcc/src/hg/trunk/local/libgo/runtime/go-runtime-error.c:59

#1  0x000100010ff0 in

exp_locale_collate_build.Add.pN32_exp_locale_collate_build.Builder

(b=b@entry=0xc20041de60, runes=..., colelems=..., variables=...)

at builder.go:167

#2  0x00010001e190 in build.newBuilder (t=t@entry=0xc2004342d0, ducet=...)

at builder_test.go:67

#3  0x0001c388 in exp_locale_collate_build.TestSimplify (

t=0xc2004342d0) at builder_test.go:164

#4  0xfff677c76904 in testing.tRunner (test=0xc200433230, 

t.param=)

at /vol/gcc/src/hg/trunk/local/libgo/go/testing/testing.go:310

#5  testing.$thunk10 (__go_thunk_parameter=0xc200429e30)

at /vol/gcc/src/hg/trunk/local/libgo/go/testing/testing.go:422

#6  0xfff677be7198 in kickoff ()

at /vol/gcc/src/hg/trunk/local/libgo/runtime/proc.c:369

#7  0x7ed5b238 in __makecontext_v2 () from /lib/64/libc.so.1



  Rainer

[Bug c++/56323] New: [C++11] cannot compile inherited constructor for typedef'ed base class

[t-gcc-bugzilla at snowelm dot com]

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



 Bug #: 56323

   Summary: [C++11] cannot compile inherited constructor for

typedef'ed base class

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: c++

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

ReportedBy: t-gcc-bugzi...@snowelm.com





Consider the following code that uses inherited constructor from a typedef'ed

type:





struct A {

A(int i);

};



typedef A B;



struct C : B {

using B::B; // compile error by gcc

};



struct D : B {

using B::A; // this is compiled as inherited constructor

};



C c(0);

D d(0);





I believe that C should be valid, while D should be reported as invalid. 

However I cannot find anything about this problem in the C++11 standard...



In template programming, using inherited constructor is sometimes virtually

impossible, as in the following example.





struct A {

A(int i);

};



template 

struct E {

typedef T type;

};



template 

struct F : E::type {

using E::type::type; // error: E::type is a typedef

};



F f(0);

[Bug tree-optimization/56321] [4.8 Regression] ICE:segfault in midend for -funsafe-math-optimizations -O3

[wschmidt at gcc dot gnu.org]

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



William J. Schmidt  changed:



   What|Removed |Added



 CC||wschmidt at gcc dot gnu.org



--- Comment #4 from William J. Schmidt  2013-02-14 
14:42:10 UTC ---

I'll have a look shortly.  I see it marked as a 4.8 regression even though this

work was done in 4.7.  Does the test pass on 4.7?

[Bug c++/56323] [C++11] cannot compile inherited constructor for typedef'ed base class

[redi at gcc dot gnu.org]

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



Jonathan Wakely  changed:



   What|Removed |Added



   Keywords||rejects-valid

 Status|UNCONFIRMED |NEW

   Last reconfirmed||2013-02-14

 CC||jason at gcc dot gnu.org

 Ever Confirmed|0   |1



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

I think [class.qual]/2 says both C and D are valid.



C is valid because it is a using-declaration that is a member-declaration and

the name specified after the nested-name-specifier is the same as the

identifier in the last component of the nested-name-specifier.



D is valid because the name specified after the nested-name-specifier is the

injected-class-name of A.



In both cases the using-declaration names the constructor, so it declares a set

of inheriting constructors.

[Bug tree-optimization/56321] [4.8 Regression] ICE:segfault in midend for -funsafe-math-optimizations -O3

[wschmidt at gcc dot gnu.org]

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



--- Comment #5 from William J. Schmidt  2013-02-14 
14:43:29 UTC ---

Actually I might be wrong about that, now that I think about it -- probably

this was done in 4.8.  It seems longer ago than that. ;)

[Bug target/56309] -O3 optimizer generates conditional moves instead of compare and branch resulting in almost 2x slower code

[ysrumyan at gmail dot com]

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



Yuri Rumyantsev  changed:



   What|Removed |Added



 CC||ysrumyan at gmail dot com



--- Comment #7 from Yuri Rumyantsev  2013-02-14 
14:49:31 UTC ---

My 2 cents.



We can enhance if conversion phase in gcc by analyzing conditional jump

probablity and if we have skewed hammock do not perform transformation. In

general it requires to use profiling but for this specific example we can use

so called "static profiler", e.g. in our example we have 

if (tmp >= imax) 

where imax = 1 << 32, i.e. huge conastant. For such conditions we can assume

that this branch is likely not-taken and reject if-conversion of such hammock.



Other possiblity is implement support for __builtin_expect in gcc but it

requires source code changing too.

[Bug target/56309] -O3 optimizer generates conditional moves instead of compare and branch resulting in almost 2x slower code

[arturomdn at gmail dot com]

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



--- Comment #8 from arturomdn at gmail dot com 2013-02-14 15:53:15 UTC ---

It is possible (just a guess) that the extra compare is causing an interlock in

the processor since the first cmov is issued speculatively and the condition

won't be confirmed until the first compare has executed.  Someone from Intel

could tell us exactly why the original sequence is so disastrous and suggest an

alternative that still uses cmov and is better than jmp.



I wonder if instead of emitting this sequence



   shr$0x20,%rdi

   and$0x,%ecx  

   cmp%r8,%rdx  

   cmovbe %r11,%rdi 

   add$0x1,%rax 

   cmp%r8,%rdx  

   cmovbe %rdx,%rcx 



it would do this instead



   shr$0x20,%rdi

   and$0x,%ecx  

   add$0x1,%rax 

   cmp%r8,%rdx  

   cmovbe %r11,%rdi 

   cmovbe %rdx,%rcx

[Bug c++/56326] New: g++.dg/gomp/tls-wrap4.C and g++.dg/tls/thread_local-wrap4.C FAIL on Solaris 9/x86

[ro at gcc dot gnu.org]

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



 Bug #: 56326

   Summary: g++.dg/gomp/tls-wrap4.C and

g++.dg/tls/thread_local-wrap4.C FAIL on Solaris 9/x86

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: c++

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

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

  Host: i386-pc-solaris2.9

Target: i386-pc-solaris2.9

 Build: i386-pc-solaris2.9





Two g++.dg tests FAIL on Solaris 9/x86 with Sun as, where emutls is used:



FAIL: g++.dg/gomp/tls-wrap4.C scan-assembler-not _ZTW1i@PLT

FAIL: g++.dg/tls/thread_local-wrap4.C scan-assembler-not _ZTW1i@PLT



In the first case, the relevant diff between the as (emutls) and gas (native

tls)

versions is



-.LCFI2:

-   call.LPR3

-   addl$_GLOBAL_OFFSET_TABLE_, %ebx

-   call_ZTW1i@PLT

+   call_ZTW1i



I think I even tried a gas build with --disable-tls on Linux/x86_64, but there

the test didn't fail, so I'm not sure it's a emutls/native tls issue at all.



  Rainer

[Bug c++/56326] g++.dg/gomp/tls-wrap4.C and g++.dg/tls/thread_local-wrap4.C FAIL on Solaris 9/x86

[ro at gcc dot gnu.org]

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



--- Comment #1 from Rainer Orth  2013-02-14 15:55:42 UTC 
---

Created attachment 29450

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

tls-wrap4.s assembler output with as (emutls)

[Bug c++/56326] g++.dg/gomp/tls-wrap4.C and g++.dg/tls/thread_local-wrap4.C FAIL on Solaris 9/x86

[ro at gcc dot gnu.org]

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



--- Comment #2 from Rainer Orth  2013-02-14 15:56:30 UTC 
---

Created attachment 29451

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

tls-wrap4.s assembler output with gas (native tls)

[Bug target/56309] -O3 optimizer generates conditional moves instead of compare and branch resulting in almost 2x slower code

[arturomdn at gmail dot com]

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



--- Comment #9 from arturomdn at gmail dot com 2013-02-14 16:00:49 UTC ---

I found in the Intel optimization guide an example of this idiom of comparing

once and issuing two cmov back-to-back... so the problem isn't the two cmov,

but possibly introducing the 2nd compare that splits them.



not_equal:

   movzx eax, BYTE PTR[esi+edx]

   movzx edx, BYTE PTR[edi+edx]

   cmp eax, edx

   cmova eax, ONE

   cmovb eax, NEG_ONE

   jmp ret_tag



Taken from example 10-16 of

http://www.intel.com/content/dam/doc/manual/64-ia-32-architectures-optimization-manual.pdf

[Bug bootstrap/56327] New: [4.8 Regression] Revision 196009 breaks bootstrap on x32

[hjl.tools at gmail dot com]

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

 Bug #: 56327
   Summary: [4.8 Regression] Revision 196009 breaks bootstrap on
x32
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com


On x32, revision 196009 gave

In file included from
/export/gnu/import/git/gcc/libsanitizer/interception/interception.h:20:0,
 from
/export/gnu/import/git/gcc/libsanitizer/interception/interception_type_test.cc:15:
/export/gnu/import/git/gcc/libsanitizer/sanitizer_common/sanitizer_internal_defs.h:221:72:
error: size of array ‘assertion_failed__34’ is negative
 typedef char IMPL_PASTE(assertion_failed_##_, line)[2*(int)(pred)-1]
^
/export/gnu/import/git/gcc/libsanitizer/sanitizer_common/sanitizer_internal_defs.h:215:30:
note: in expansion of macro ‘IMPL_COMPILER_ASSERT’
 #define COMPILER_CHECK(pred) IMPL_COMPILER_ASSERT(pred, __LINE__)
  ^
/export/gnu/import/git/gcc/libsanitizer/interception/interception_type_test.cc:34:1:
note: in expansion of macro ‘COMPILER_CHECK’
 COMPILER_CHECK(sizeof(OFF_T) == sizeof(off_t));
 ^
make[7]: *** [interception_type_test.lo] Error 1
make[7]: *** Waiting for unfinished jobs

The problem is in libsanitizer/interception/interception.h:

#ifdef __APPLE__
typedef __sanitizer::u64 OFF_T;
#else
typedef __sanitizer::uptr OFF_T;
#endif

On x32, off_t is 64 bit and uptr is 32 bit.

[Bug c++/56328] New: Explicit instantiation of inline function template works for base template, fails for specialized template

[michael.schlottke at sloede dot com]

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



 Bug #: 56328

   Summary: Explicit instantiation of inline function template

works for base template, fails for specialized

template

Classification: Unclassified

   Product: gcc

   Version: 4.7.2

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: c++

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

ReportedBy: michael.schlot...@sloede.com





Why does the compiler treat a specialized template differently from the base

template when it comes to explicit instantiation of inline function templates?

The following code gives a linker error, unless the second "inline" (see AAA)

is removed. In any case, this seems to be a problem of the compiler, not the

linker.







main.cpp



template  void f(int src);



int main(int, char** )

{

  f<1>(456);

  f<2>(789);

}





template.cpp



template  void f(int src);



template  inline

void f(int src){ (void)0; }



template <> inline /* AAA */

void f<2>(int src) { (void)0; }



template void f<1>(int);

template void f<2>(int);









Command used:

/pds/opt/gcc-4.7-2/bin/g++ main.cpp template.cpp







Error message:

/tmp/cc42UAxE.o: In function `main':

main.cpp:(.text+0x1f): undefined reference to `void f<2>(int)'

collect2: error: ld returned 1 exit status







g++ -v:

Using built-in specs.

COLLECT_GCC=/pds/opt/gcc-4.7-2/bin/g++

COLLECT_LTO_WRAPPER=/aia/opt/gcc-4.7-2/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.7.2/lto-wrapper

Target: x86_64-unknown-linux-gnu

Configured with: /pds/opt/install/gcc//gcc-4.7.2/configure

--prefix=/pds/opt/gcc-4.7-2 --enable-threads=posix

Thread model: posix

gcc version 4.7.2 (GCC)

[Bug c++/56323] [C++11] cannot compile inherited constructor for typedef'ed base class

[jason at gcc dot gnu.org]

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



Jason Merrill  changed:



   What|Removed |Added



 Status|NEW |ASSIGNED

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

   |gnu.org |

[Bug target/56309] -O3 optimizer generates conditional moves instead of compare and branch resulting in almost 2x slower code

[arturomdn at gmail dot com]

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



--- Comment #10 from arturomdn at gmail dot com 2013-02-14 16:43:23 UTC ---

Might be worth mentioning here what I said in the stackoverflow answer, that in

this particular case the entire conditional branch can be avoided because it is

redundant.



This code



if (tmp >= imax) {

carry = tmp >> numbits;// < A

tmp &= imax - 1;// < B

} else {

carry = 0;// < C

}



can be reduced to



carry = tmp >> numbits;

tmp &= imax - 1;



Proof:

1) numbits is 32

2) imax is 1ULL << 32 so lower 32 bits are zero

3) imax - 1 is 0x (see 2)

4) if tmp >= imax then tmp has bits set in upper 32 bits

5) otherwise if tmp < imax then tmp does not have bits set in upper 32 bits

6) statement "A" is equivalent to "C" when tmp < imax (because of 4)

7) statement "B" is a NOP when tmp < imax (because of 3 and 5)

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

[vmakarov at redhat dot com]

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



Vladimir Makarov  changed:



   What|Removed |Added



 CC||vmakarov at redhat dot com



--- Comment #29 from Vladimir Makarov  2013-02-14 
16:48:24 UTC ---

(In reply to comment #28)

> (In reply to comment #27)

> > (In reply to comment #26)

> > > You are right, your suggestions is what I sketched in comment #21 as 
> > > choices 1

> > > or 2.  Sorry for my unclear expalanation of what was actually happening.

> > > 

> > > I don't have a problem with making sel-sched have extra checks when 
> > > renaming

> > > registers before reload, which will make us notice a not obvious extra

> > > dependence and avoid renaming properly, as now we've figured out these

> > > dependences don't follow immediately from the RTL.  I just want an extra

> > > opinion on whether such unexpected dependencies arising when a target 
> > > (hard)

> > > register is replaced by a pseudo register should be normal within GCC, or 
> > > do we

> > > attribute such dependencies only to the register pressure scheduling 
> > > mode. 

> > > FWIW, I would rather agree with the latter than with the former.

> > 

> > I guess you can not fully assume that dependencies are created only from RTL

> > data flow.  There are cases (besides pressure sensitive scheduling case

> > mentioned here) when dependencies are still created for other reasons 
> > different

> > from RTL data flow.  I'd look at the dependencies as constraints resulting 
> > in

> > correct and *desirable* insn schedule.  Although overwhelming majority of 
> > them

> > are created from RTL data flow analysis.

> 

> I agree with you in general, it's just this case of having extra dependencies

> because an LHS hard register was substituted to a pseudo is non-intuitive to

> me.  I am not aware of other similar cases when the "other dependency reasons"

> you mention kick in after such transformation. 



For example, additional dependencies can be created when queues are too long to

speed up insn scheduling in some patalogical cases.  The probability that it

happens is small but it still happens and selective scheduler can crash in this

case too.



> So I'll try going with the

> minimal fix of tracking only this particular case (of newly created implicit

> clobbers) in the selective scheduler.

> 

> Btw, does the code calculating implicit clobbers via

> ira_implicitly_set_insn_hard_regs were planned just for the pressure sensitive

> scheduling or also for the general case?  It looks like it is needed for the

> former but it is calculated for the latter.



It was done to solve (or at least decrease the probability) reload crashes

(reload can not find a spill register) when the first insn scheduling is used.

[Bug bootstrap/56327] [4.8 Regression] Revision 196009 breaks bootstrap on x32

[hjl at gcc dot gnu.org]

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



--- Comment #1 from hjl at gcc dot gnu.org  2013-02-14 
16:54:07 UTC ---

Author: hjl

Date: Thu Feb 14 16:54:01 2013

New Revision: 196054



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

Log:

OFF_T: Merged from upstream r175140



PR bootstrap/56327

* interception/interception.h (OFF_T): Merged from upstream

r175140.



Modified:

trunk/libsanitizer/ChangeLog

trunk/libsanitizer/interception/interception.h

[Bug target/56309] -O3 optimizer generates conditional moves instead of compare and branch resulting in almost 2x slower code

[steven at gcc dot gnu.org]

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



Steven Bosscher  changed:



   What|Removed |Added



 CC||steven at gcc dot gnu.org



--- Comment #11 from Steven Bosscher  2013-02-14 
16:59:04 UTC ---

(In reply to comment #8)

> I wonder if instead of emitting this sequence

> 

>shr$0x20,%rdi

>and$0x,%ecx

>cmp%r8,%rdx

>cmovbe %r11,%rdi

>add$0x1,%rax

>cmp%r8,%rdx

>cmovbe %rdx,%rcx

> 

> it would do this instead

> 

>shr$0x20,%rdi

>and$0x,%ecx

>add$0x1,%rax

>cmp%r8,%rdx

>cmovbe %r11,%rdi

>cmovbe %rdx,%rcx



GCC fails to do so because the flags are clobbered between the two

cmovs, preventing code motion to group the two cmovs:



  197: r116:DI={(gtu(flags:CC,0))?r125:DI:r233:DI}

  199: {r110:DI=r110:DI+0x1;clobber flags:CC;}

  201: flags:CC=cmp(r124:DI,r235:DI)

  202: r221:DI={(gtu(flags:CC,0))?r126:DI:r124:DI}



If you do this change manually in your code (compile with -S, "fix"

the .s file and assemble it), does that speed up your code?

[Bug target/56309] -O3 optimizer generates conditional moves instead of compare and branch resulting in almost 2x slower code

[steven at gcc dot gnu.org]

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



--- Comment #12 from Steven Bosscher  2013-02-14 
17:10:02 UTC ---

A bit more clear with insn 195 added:



  195: flags:CC=cmp(r124:DI,r235:DI)

  197: r116:DI={(gtu(flags:CC,0))?r125:DI:r233:DI}

  199: {r110:DI=r110:DI+0x1;clobber flags:CC;}

  201: flags:CC=cmp(r124:DI,r235:DI)

  202: r221:DI={(gtu(flags:CC,0))?r126:DI:r124:DI}



insns 195 and 201 compute the same condition but GCC can't eliminate

the comparison in insns 201 because insn 199 clobbers the flags (i.e.

destroys the result from insn 195).



As for speed, of course I can measure that myself:



--- by-val-O3.s.orig2013-02-14 18:06:56.0 +0100

+++ by-val-O3.s 2013-02-14 18:07:23.0 +0100

@@ -357,9 +357,8 @@

shrq$32, %rdi

cmpq%r8, %rdx

cmovbe  %r11, %rdi

-   addq$1, %rax

-   cmpq%r8, %rdx

cmovbe  %rdx, %rcx

+   addq$1, %rax

cmpq%rbp, %rax

movq%rcx, -8(%rsi,%rax,8)

jne .L50



unmodified: Took 14.31 seconds total.

modified:   Took 13.04 seconds total.



So re. comment #9: it's not the problem but it'd be a small improvement.

[Bug tree-optimization/56309] -O3 optimizer generates conditional moves instead of compare and branch resulting in almost 2x slower code

[steven at gcc dot gnu.org]

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



Steven Bosscher  changed:



   What|Removed |Added



   Keywords||missed-optimization

  Component|target  |tree-optimization



--- Comment #13 from Steven Bosscher  2013-02-14 
17:26:08 UTC ---

$ g++ --version

g++ (GCC) 4.7.2 ...

$ g++ -O3 -std=c++11 by-val-O3.ii ; ./a.out

Took 14.31 seconds total.

$ g++ -O3 -std=c++11 by-val-O3.ii -fvect-cost-model ; ./a.out

Took 14.31 seconds total.

$ g++ -O3 -std=c++11 by-val-O3.ii -fno-tree-vectorize ; ./a.out

Took 10.25 seconds total.

[Bug tree-optimization/56309] -O3 optimizer generates conditional moves instead of compare and branch resulting in almost 2x slower code

[arturomdn at gmail dot com]

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



--- Comment #14 from arturomdn at gmail dot com 2013-02-14 17:30:54 UTC ---

I also did the experiment, with the same results... it got faster but not as

fast as the version with

conditional branch instead of conditional moves:



./by-ref-O3

Took 6.65 seconds total.



./by-val-O3 

Took 11.64 seconds total.



./by-val-fixed-O3 

Took 9.94 seconds total.



--- by-val-O3.s 2013-02-14 11:27:28.109856000 -0600

+++ by-val-fixed-O3.s   2013-02-14 11:11:07.312317000 -0600

@@ -679,13 +679,12 @@

shrq$32, %rdi

.loc 4 25 0

andl$4294967295, %ecx

+   addq$1, %rax

cmpq%r8, %rdx

cmovbe  %r11, %rdi

 .LVL43:

.loc 4 29 0

-   addq$1, %rax

 .LVL44:

-   cmpq%r8, %rdx

cmovbe  %rdx, %rcx

 .LVL45:

.loc 4 21 0

[Bug tree-optimization/56309] -O3 optimizer generates conditional moves instead of compare and branch resulting in almost 2x slower code

[ubizjak at gmail dot com]

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



--- Comment #15 from Uros Bizjak  2013-02-14 17:34:15 
UTC ---

(In reply to comment #13)

> $ g++ --version

> g++ (GCC) 4.7.2 ...

> $ g++ -O3 -std=c++11 by-val-O3.ii ; ./a.out

> Took 14.31 seconds total.

> $ g++ -O3 -std=c++11 by-val-O3.ii -fvect-cost-model ; ./a.out

> Took 14.31 seconds total.

> $ g++ -O3 -std=c++11 by-val-O3.ii -fno-tree-vectorize ; ./a.out

> Took 10.25 seconds total.



This is red herring, see PR53346c11:



--q--

You are right. -ftree-vectorize implies -ftree-loop-if-convert and this option

makes all the difference!

--/q--



Please try wiht -ftree-vectorize -fno-tree-loop-if-convert.

[Bug tree-optimization/56309] -O3 optimizer generates conditional moves instead of compare and branch resulting in almost 2x slower code

[arturomdn at gmail dot com]

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



--- Comment #16 from arturomdn at gmail dot com 2013-02-14 17:42:55 UTC ---

With -ftree-vectorize -fno-tree-loop-if-convert flags it generated this for the

loop in question:



.L39:

movq%rdi, %rdx

addq(%rsi,%rax,8), %rcx

imulq   (%r9,%rax,8), %rdx

addq%rcx, %rdx

xorl%ecx, %ecx

cmpq%r10, %rdx

jbe .L38

movq%rdx, %rcx

andl$4294967295, %edx

shrq$32, %rcx

.L38:

addq$1, %rax

cmpq%r8, %rax

movq%rdx, -8(%rsi,%rax,8)

jne .L39



And it executed fast:



./by-val-O3-flags

Took 6.74 seconds total.

[Bug tree-optimization/56309] -O3 optimizer generates conditional moves instead of compare and branch resulting in almost 2x slower code

[ubizjak at gmail dot com]

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



--- Comment #17 from Uros Bizjak  2013-02-14 17:49:46 
UTC ---

(In reply to comment #16)



> And it executed fast:

> 

> ./by-val-O3-flags

> Took 6.74 seconds total.



The solution to all these PRs is trivial: kill -ftree-loop-if-convert on x86,

until infrastructure to detect possible stalls is implemented. This decision

needs lots of benchmarking, though.

[Bug bootstrap/55644] bootstrap-lto fails on current trunk (with and without profiledbootstrap)

[matt at use dot net]

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



--- Comment #7 from Matt Hargett  2013-02-14 18:00:57 UTC 
---

Sorry, but wouldn't that be "papering over bugs"? I'm confounded by the

attitude around bootstrap failures, regardless of the basic supported options

being used: -O3 with LTO and profile-use. This combination has been in use in 3

different companies I have worked with, since 4.6.x. If it's not a supported

configuration to the point where an FSF GCC release can't bootstrap itself

consistently without wrong-code/diagnostic false positives, then I'll just plan

on sticking to vendor branches -- something I don't want to do since I would

prefer not to have another EGCS situation.



Let me know how to proceed with these classes of issues.

[Bug tree-optimization/56309] -O3 optimizer generates conditional moves instead of compare and branch resulting in almost 2x slower code

[ubizjak at gmail dot com]

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



--- Comment #18 from Uros Bizjak  2013-02-14 18:23:12 
UTC ---

Following patch is a big hammer approach to the problem, intended only for

benchmarking



--cut here--

Index: common/config/i386/i386-common.c

===

--- common/config/i386/i386-common.c(revision 195988)

+++ common/config/i386/i386-common.c(working copy)

@@ -710,6 +710,8 @@

 /* Turn off -fschedule-insns by default.  It tends to make the

problem with not enough registers even worse.  */

 { OPT_LEVELS_ALL, OPT_fschedule_insns, NULL, 0 },

+/* Turn off -ftree-loop-if-convert by default.  */

+{ OPT_LEVELS_ALL, OPT_ftree_loop_if_convert, NULL, 0 },



 #ifdef SUBTARGET_OPTIMIZATION_OPTIONS

 SUBTARGET_OPTIMIZATION_OPTIONS,

--cut here--



OTOH, it looks that on x86, the only problematic insns are scalar integer cmov

instructions. With some (machine dependant ?) pass inserted at the right spot

in the sequence of passes, appropriate cmovs can be decomposed back to jumps,

for some yet unknown definition of "appropriate".

[Bug target/56309] -O3 optimizer generates conditional moves instead of compare and branch resulting in almost 2x slower code

[ubizjak at gmail dot com]

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



Uros Bizjak  changed:



   What|Removed |Added



  Component|tree-optimization   |target



--- Comment #19 from Uros Bizjak  2013-02-14 18:35:05 
UTC ---

Back to "target" component.

[Bug c++/56328] Explicit instantiation of inline function template works for base template, fails for specialized template

[pinskia at gcc dot gnu.org]

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



--- Comment #1 from Andrew Pinski  2013-02-14 
18:44:41 UTC ---

(In reply to comment #0)

> Why does the compiler treat a specialized template differently from the base

> template when it comes to explicit instantiation of inline function templates?



Simple answer, inline functions have to appear in every TU that they are used.

[Bug bootstrap/55644] bootstrap-lto fails on current trunk (with and without profiledbootstrap)

[hjl.tools at gmail dot com]

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



--- Comment #8 from H.J. Lu  2013-02-14 18:47:12 
UTC ---

-O3 and -fprofile-use turn on optimizations like -funroll-loops which

trigger false positive warnings.

[Bug c++/56329] New: Segmentation fault on simple invalid code with variadic template specialisation

[jmetcalfe at acm dot org]

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



 Bug #: 56329

   Summary: Segmentation fault on simple invalid code with

variadic template specialisation

Classification: Unclassified

   Product: gcc

   Version: 4.7.2

Status: UNCONFIRMED

  Severity: minor

  Priority: P3

 Component: c++

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

ReportedBy: jmetca...@acm.org





Created attachment 29452

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

Test case causing seg fault



Attached test case causes "spec.cpp:5:8: internal compiler error: Segmentation

fault:



Version: 4.7.2 

Configured with:  ../configure --enable-languages=c,c++,fortran

--disable-checking --disable-multilib --disable-multiarch --disable-nls

--enable-lto --enable-libstdcxx-time

Target:  x86_64-unknown-linux-gnu



Command line: g++ -std=c++0x spec.cpp

[Bug middle-end/54582] gap in FORTIFY checking of buffer lengths

[dcb314 at hotmail dot com]

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



--- Comment #14 from David Binderman  2013-02-14 
19:06:54 UTC ---

Created attachment 29453

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

C++ source code



Old version understood about a dozen formats, this 

later version understands 34 formats.



Next version will understand some field widths.

[Bug bootstrap/56311] gcc/include-fixed/stdio.h: In function ‘_func’: gcc/include-fixed/stdio.h:135:3: error: expected declaration specifiers before ‘__extension__’

[devurandom at gmx dot net]

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



--- Comment #4 from devurandom at gmx dot net 2013-02-14 19:45:33 UTC ---

Created attachment 29454

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

gcc-4.7.2-inclhack-hpux10_stdio_declarations.patch



Attached patch fixes the issue for me. Someone with a HP-UX 10 system should

probably test it, though!



I added an $ anchor to the end of the match, to exclude the __iob_func() line

that MinGW seems to use. If there is anything (e.g. a comment) after __iob on

HP-UX 10, this will obviously fail! (But then it might have created bad code

before, too.)

[Bug tree-optimization/56321] [4.8 Regression] ICE:segfault in midend for -funsafe-math-optimizations -O3

[wschmidt at gcc dot gnu.org]

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



--- Comment #6 from William J. Schmidt  2013-02-14 
20:11:32 UTC ---

Odd.  Reassociation makes a correct and profitable transformation into



foo (int n)

{

  double _2;

  double _5;

  double _6;

  double _7;

  double _8;

  float _9;



  :

  _2 = (double) n_1(D);

  _6 = _2 * 6.6662965923251249478198587894439697265625e-1;

  _7 = _6 + 2.0e+0;

  _5 = _7 * _2;

  _8 = _5;

  _9 = (float) _8;

  return _9;



}



but somehow verify_ssa() thinks the last statement (return _9;) contains a use

of the undefined SSA name _4.



Will continue to investigate later.

[Bug c++/56319] [DR 1051] implicit copy constructor is not deleted for type with rvalue reference member

[daniel.kruegler at googlemail dot com]

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

Daniel Krügler  changed:

   What|Removed |Added

 CC||daniel.kruegler at
   ||googlemail dot com

--- Comment #4 from Daniel Krügler  
2013-02-14 20:36:52 UTC ---
Seems to be a dup of bug 55017

[Bug c++/56328] Explicit instantiation of inline function template works for base template, fails for specialized template

[redi at gcc dot gnu.org]

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



--- Comment #2 from Jonathan Wakely  2013-02-14 
20:39:53 UTC ---

The foo<2> specialization is not declared in main.cpp before it would be

needed, so the program is ill-formed, no diagnostic required, according to

[templ.expl.spec]/6.



Also, the following paragraph is relevant:

"When writing a specialization, be careful about its location, or to make it

compile will be such a trial as to kindle its self-immolation."

[Bug target/55941] [4.8 Regression] Strange copy of double (in struct) to stack

[rth at gcc dot gnu.org]

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



Richard Henderson  changed:



   What|Removed |Added



 Status|NEW |ASSIGNED

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

   |gnu.org |



--- Comment #3 from Richard Henderson  2013-02-14 
20:40:34 UTC ---

Mine.

[Bug c++/56328] Explicit instantiation of inline function template works for base template, fails for specialized template

[redi at gcc dot gnu.org]

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



--- Comment #3 from Jonathan Wakely  2013-02-14 
20:45:35 UTC ---

Also, [basic.def.odr]: "An inline function shall be defined in every

translation unit in which it is odr-used." and [dcl.fct.spec] "If a function

with external linkage is declared inline in one translation unit, it shall be

declared inline in all translation units in which it appears; no diagnostic is

required."



To fix the program you need to declare the explicit specialization in main.cpp

and neither foo nor foo<2> can be inline unless they're defined in both

translation units.

[Bug c++/55017] [C++11] Rvalue-reference member should cause copy constructor to be deleted, but still declared

[redi at gcc dot gnu.org]

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



Jonathan Wakely  changed:



   What|Removed |Added



 CC||wlodzimierz.lipert at gmail

   ||dot com



--- Comment #2 from Jonathan Wakely  2013-02-14 
20:47:27 UTC ---

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

[Bug c++/56319] [DR 1051] implicit copy constructor is not deleted for type with rvalue reference member

[redi at gcc dot gnu.org]

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



Jonathan Wakely  changed:



   What|Removed |Added



 Status|NEW |RESOLVED

 Resolution||DUPLICATE



--- Comment #5 from Jonathan Wakely  2013-02-14 
20:47:27 UTC ---

Thanks, Daniel



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

[Bug c++/55017] [DR 1051] [C++11] Rvalue-reference member should cause copy constructor to be deleted, but still declared

[redi at gcc dot gnu.org]

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



Jonathan Wakely  changed:



   What|Removed |Added



Summary|[C++11] Rvalue-reference|[DR 1051] [C++11]

   |member should cause copy|Rvalue-reference member

   |constructor to be deleted,  |should cause copy

   |but still declared  |constructor to be deleted,

   ||but still declared



--- Comment #3 from Jonathan Wakely  2013-02-14 
20:48:50 UTC ---

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

[Bug c++/56329] Segmentation fault on simple invalid code with variadic template specialisation

[redi at gcc dot gnu.org]

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



Jonathan Wakely  changed:



   What|Removed |Added



   Keywords||ice-on-invalid-code

 Status|UNCONFIRMED |RESOLVED

 Resolution||DUPLICATE

  Known to fail||4.7.3



--- Comment #1 from Jonathan Wakely  2013-02-14 
21:08:19 UTC ---

Trunk gives an error not an ICE:



t.cc:5:8: error: partial specialization is not more specialized than the

primary template because it replaces multiple parameters with a pack expansion

 struct MyClass {};

^

t.cc:2:8: note: primary template here

 struct MyClass;

^



I think this is a dup of PR 52008



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

[Bug c++/52008] [Core/1495] ICE when adding partial specialization for variadic-templated structure

[redi at gcc dot gnu.org]

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



Jonathan Wakely  changed:



   What|Removed |Added



 CC||jmetcalfe at acm dot org



--- Comment #19 from Jonathan Wakely  2013-02-14 
21:08:19 UTC ---

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

[Bug middle-end/55478] [devirt] trunk fails inline-devirt test #4

[matt at use dot net]

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



--- Comment #11 from Matt Hargett  2013-02-14 21:27:54 UTC 
---

Attached is an updated version of the tests Maxim committed to the google/4_7

branch. The only difference is that more of the tests are xfail'd than in the

older google branch.



We could unset the xfail for inline-devirt-4.C if we set it to -O3, but I'd

rather track the fact the test hasn't passed at -O2 since the patches Maxim

proposed ~2 years ago due to various (possibly nested) regressions in other

areas.

[Bug middle-end/55477] [devirt] trunk fails inline-devirt tests #2 and and #3 whereas they pass in google/4_7

[matt at use dot net]

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



--- Comment #7 from Matt Hargett  2013-02-14 21:28:33 UTC 
---

Created attachment 29455

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

diff against trunk adding new testcases

[Bug sanitizer/56330] New: [4.8 Regression] ICE: verify_gimple failed: gimple_bb (stmt) is set to a wrong basic block with -fsanitize=address

[zsojka at seznam dot cz]

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



 Bug #: 56330

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

(stmt) is set to a wrong basic block with

-fsanitize=address

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: sanitizer

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

ReportedBy: zso...@seznam.cz

CC: do...@gcc.gnu.org, dvyu...@gcc.gnu.org,

ja...@gcc.gnu.org, k...@gcc.gnu.org





Created attachment 29456

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

autoreduced testcase



I am not sure if this should be marked as a regression - the code doesn't

compile in 4.7, but used to older revisions of 4.8.



Compiler output:

$ gcc -fsanitize=address testcase.c 

testcase.c: In function 'foo':

testcase.c:10:1: error: gimple_bb (stmt) is set to a wrong basic block

 foo (void)

 ^

__builtin_memcmp (&s.a, &empty, 200);



testcase.c:10:1: error: gimple_bb (stmt) is set to a wrong basic block

return;



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

0xa528bc verify_gimple_in_cfg(function*)

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

0x93f177 execute_function_todo

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

0x93fa97 execute_todo

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

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:

r196044 - crash

r195931 - OK

[Bug sanitizer/56330] [4.8 Regression] ICE: verify_gimple failed: gimple_bb (stmt) is set to a wrong basic block with -fsanitize=address

[mpolacek at gcc dot gnu.org]

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



Marek Polacek  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2013-02-14

 CC||mpolacek at gcc dot gnu.org

   Target Milestone|--- |4.8.0

 Ever Confirmed|0   |1



--- Comment #1 from Marek Polacek  2013-02-14 
22:03:06 UTC ---

Confirmed.

[Bug target/56214] [4.8 Regression] FAIL: gcc.c-torture/execute/20050121-1.c compilation, ICE

[jsm28 at gcc dot gnu.org]

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



Joseph S. Myers  changed:



   What|Removed |Added



   Priority|P3  |P2

[Bug libstdc++/56267] [4.7/4.8 Regression] unordered containers require Assignable hash function

[jsm28 at gcc dot gnu.org]

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



Joseph S. Myers  changed:



   What|Removed |Added



   Priority|P3  |P2

[Bug tree-optimization/56321] [4.8 Regression] ICE:segfault in midend for -funsafe-math-optimizations -O3

[jsm28 at gcc dot gnu.org]

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



Joseph S. Myers  changed:



   What|Removed |Added



   Priority|P3  |P2

[Bug fortran/56224] [4.8 Regression] gfortran -fopenmp cannot find omp_lib.h

[tkoenig at gcc dot gnu.org]

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



--- Comment #5 from Thomas Koenig  2013-02-14 
22:13:38 UTC ---

Author: tkoenig

Date: Thu Feb 14 22:13:26 2013

New Revision: 196058



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

Log:

2013-02-14  Thomas Koenig  



PR fortran/56224

* gfortran.h (gfc_add_include_path):  Add boolean argument

for warn.

* scanner.c (gfc_add_include_path):  Pass along warn argument

to add_path_to_list.

* options.c (gfc_post_options):  Add true warn argument to

gfc_add_include_path.

(gfc_handle_module_path_options):  Likewise.

(gfc_handle_option): Also gfc_add_include_path for intrinsic

modules, without warning.





Modified:

trunk/gcc/fortran/ChangeLog

trunk/gcc/fortran/gfortran.h

trunk/gcc/fortran/options.c

trunk/gcc/fortran/scanner.c

[Bug ada/56331] New: Gnatprep returns zero on error.

[bj...@xn--rombobjrn-67a.se]

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



 Bug #: 56331

   Summary: Gnatprep returns zero on error.

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: ada

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

ReportedBy: bj...@xn--rombobjrn-67a.se





Created attachment 29457

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

proposed fix



When Gnatprep encounters errors in its input it deems its output file worthless

and deletes it, but returns an exit code of zero. It should return a nonzero

value so that it can function correctly in scripts and makefiles.

[Bug target/56309] -O3 optimizer generates conditional moves instead of compare and branch resulting in almost 2x slower code

[steven at gcc dot gnu.org]

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



--- Comment #20 from Steven Bosscher  2013-02-14 
22:17:23 UTC ---

(In reply to comment #12)

> --- by-val-O3.s.orig2013-02-14 18:06:56.0 +0100

> +++ by-val-O3.s 2013-02-14 18:07:23.0 +0100

> @@ -357,9 +357,8 @@

> shrq$32, %rdi

> cmpq%r8, %rdx

> cmovbe  %r11, %rdi

> -   addq$1, %rax

> -   cmpq%r8, %rdx

> cmovbe  %rdx, %rcx

> +   addq$1, %rax

> cmpq%rbp, %rax

> movq%rcx, -8(%rsi,%rax,8)

> jne .L50

> 

> unmodified: Took 14.31 seconds total.

> modified:   Took 13.04 seconds total.

> 

> So re. comment #9: it's not the problem but it'd be a small improvement.



FWIW this comes from not eliminating the condition expression in

the conditional moves that ifcvt creates:



  tmp_97 = tmp_93 > 4294967295 ? tmp_95 : tmp_93;

  carry_105 = tmp_93 > 4294967295 ? carry_94 : 0;



I'm surprised this form is allowed at all, I'd expect we only allow

is_gimple_reg() for a COND_EXPR_COND in a RHS context.



Anyway -- separate problem.

[Bug sanitizer/56330] ICE: verify_gimple failed: gimple_bb (stmt) is set to a wrong basic block with -fsanitize=address

[steven at gcc dot gnu.org]

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



Steven Bosscher  changed:



   What|Removed |Added



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

   |verify_gimple failed:   |gimple_bb (stmt) is set to

   |gimple_bb (stmt) is set to  |a wrong basic block with

   |a wrong basic block with|-fsanitize=address

   |-fsanitize=address  |



--- Comment #2 from Steven Bosscher  2013-02-14 
22:22:57 UTC ---

A regression is when something worked in an older GCC release but

does not work anymore. ASAN is new in GCC 4.8 so this bug is not

a regression.

[Bug tree-optimization/56321] [4.8 Regression] ICE:segfault in midend for -funsafe-math-optimizations -O3

[wschmidt at gcc dot gnu.org]

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



William J. Schmidt  changed:



   What|Removed |Added



 Status|NEW |ASSIGNED

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

   |gnu.org |



--- Comment #7 from William J. Schmidt  2013-02-14 
22:27:21 UTC ---

I see.  The problem is a memory VUSE on the return statement that no longer has

a def.  The VDEF was associated with the __builtin_pow statement that was

expanded.  Looks like I need to release the SSA name.  Working on a fix.