[Bug c++/55773] C++ class object destructors are not called which a static class object in destructor function in a shared library after dlclose is called.

[liuhc001 at gmail dot com]

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



--- Comment #2 from liuhc001 at gmail dot com 2012-12-22 07:44:48 UTC ---

(In reply to comment #1)

> GCC 4.1.2 is very old and has not been maintained for years, please try to

> reproduce this with a current version of GCC.



I try it at 4.4.4 version of GCC. The problem still  exists. I have no more

newer version right now. sorry.

[Bug debug/49951] [4.5/4.6/4.7 Regression] Debug stepping behavior regarding g++ Class destructor has changed for the worse starting at gcc 4.5.0

[pinskia at gcc dot gnu.org]

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



Andrew Pinski  changed:



   What|Removed |Added



 CC||chihin.ko at oracle dot com



--- Comment #18 from Andrew Pinski  2012-12-22 
04:00:07 UTC ---

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

[Bug c++/55785] gcc4.5.2 incorrect line # of caller for destructor

[pinskia at gcc dot gnu.org]

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



Andrew Pinski  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||DUPLICATE



--- Comment #1 from Andrew Pinski  2012-12-22 
04:00:07 UTC ---

This was fixed in 4.5.4 and a dup of bug 49951.



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

[Bug c++/55785] New: gcc4.5.2 incorrect line # of caller for destructor

[chihin.ko at oracle dot com]

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



 Bug #: 55785

   Summary: gcc4.5.2 incorrect line # of caller for destructor

Classification: Unclassified

   Product: gcc

   Version: 4.5.2

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: c++

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

ReportedBy: chihin...@oracle.com





Created attachment 29024

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

c++ test case



platform Solaris intel



build command

/net/gozo/sqe/tools/gcc/4.5.2/intel-S2/bin/g++   002.cc -g



(dbx) stop in stack::~stack

(dbx) run

Running: a.out

(process id 13901)

stopped in stack::~stack at line 73 in file "002.cc"

   73delete bottom;

stack::~stack(this = 0x8044c90) called from function reverse_name



(dbx) where

=>[1] stack::~stack(this = 0x8044c90), line 73 in "002.cc"

  [2] reverse_name(name = 0x80511dc "Honey"), line 77 in "002.cc"  <== should

be line 87

  [3] main(), line 96 in "002.cc"



gcc4.7 does not have this problem.



This is due to gcc4.5.2 compiler generate extra line 77 in line table:



a.out dwarfdump:



0x080510c8  [  84, 0] NS

0x080510e3  [  86, 0] NS

0x080510f4  [  87, 0] NS

0x080510f7  [  77, 0] NS  <== extra line 77

0x08051104  [  88, 0] NS

0x0805110c  [  77, 0] NS  <== extra

0x08051121  [  91, 0] NS



compare the address 0x080510fd of "call ~stack" down below, the extra line 77

in line table, mess up the address/line mapping when doing command "where".



   87 return reverse;

0x080510f4: reverse_name+0x00b4:movl 0xfff0(%ebp),%ebx

0x080510f7: reverse_name+0x00b7:leal 0xffe8(%ebp),%eax

0x080510fa: reverse_name+0x00ba:movl %eax,(%esp)

0x080510fd: reverse_name+0x00bd:call ~stack [ 0x805102a, .-0xd3 ]

0x08051102: reverse_name+0x00c2:movl %ebx,%eax

   88   }

0x08051104: reverse_name+0x00c4:addl $0x0024,%esp

0x08051107: reverse_name+0x00c7:popl %ebx

0x08051108: reverse_name+0x00c8:popl %ebp

0x08051109: reverse_name+0x00c9:ret  

0x0805110a: reverse_name+0x00ca:movl %eax,%ebx

0x0805110c: reverse_name+0x00cc:leal 0xffe8(%ebp),%eax

0x0805110f: reverse_name+0x00cf:movl %eax,(%esp)

0x08051112: reverse_name+0x00d2:call ~stack [ 0x805102a, .-0xe8 ]

0x08051117: reverse_name+0x00d7:movl %ebx,%eax

0x08051119: reverse_name+0x00d9:movl %eax,(%esp)

0x0805111c: reverse_name+0x00dc:call _Unwind_Resume [PLT]   [

0x8050d64, .-0x3b8 ]

   89

[Bug bootstrap/55784] [4.8 regression] declaration of C function 'const char* strsignal(int)' conflicts with /usr/include/string.h:112: error: previous declaration

[pinskia at gcc dot gnu.org]

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



Andrew Pinski  changed:



   What|Removed |Added



   Keywords||build

 Status|UNCONFIRMED |NEW

   Last reconfirmed||2012-12-22

   Target Milestone|--- |4.8.0

 Ever Confirmed|0   |1



--- Comment #1 from Andrew Pinski  2012-12-22 
02:21:11 UTC ---

Confirmed.  The issue is related to gmp.h included from system.h.

[Bug bootstrap/55784] New: [4.8 regression] declaration of C function 'const char* strsignal(int)' conflicts with /usr/include/string.h:112: error: previous declaration

[gerald at pfeifer dot com]

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



 Bug #: 55784

   Summary: [4.8 regression] declaration of C function 'const

char* strsignal(int)' conflicts with

/usr/include/string.h:112: error: previous declaration

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: bootstrap

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

ReportedBy: ger...@pfeifer.com





This happened in the last 24 hours and seems to affect all versions of

FreeBSD (explicitly amd64-unknown-freebsd8.2 and i386-unknown-freebsd10.0):



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

-W -Wall -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic

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

-DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild

-I/scratch2/tmp/gerald/gcc-HEAD/gcc -I/scratch2/tmp/gerald/gcc-HEAD/gcc/build

-I/scratch2/tmp/gerald/gcc-HEAD/gcc/../include -I./../intl

-I/scratch2/tmp/gerald/gcc-HEAD/gcc/../libcpp/include

-I/home/gerald/10-i386/include 

-I/scratch2/tmp/gerald/gcc-HEAD/gcc/../libdecnumber

-I/scratch2/tmp/gerald/gcc-HEAD/gcc/../libdecnumber/dpd -I../libdecnumber

-I/scratch2/tmp/gerald/gcc-HEAD/gcc/../libbacktrace\

-o build/genconstants.o

/scratch2/tmp/gerald/gcc-HEAD/gcc/genconstants.c

In file included from /scratch2/tmp/gerald/gcc-HEAD/gcc/system.h:198,

 from /scratch2/tmp/gerald/gcc-HEAD/gcc/genconstants.c:29:

/usr/include/sys/types.h:187: error: declaration does not declare anything

In file included from /scratch2/tmp/gerald/gcc-HEAD/gcc/genconstants.c:29:

/scratch2/tmp/gerald/gcc-HEAD/gcc/system.h:502: error: declaration of C

function 'const char* strsignal(int)' conflicts with

/usr/include/string.h:112: error: previous declaration 'char* strsignal(int)'

here

gmake[3]: *** [build/genconstants.o] Error 1

gmake[3]: Leaving directory `/scratch2/tmp/gerald/OBJ-1222-0104/gcc'

gmake[2]: *** [all-stage1-gcc] Error 2

gmake[2]: Leaving directory `/scratch2/tmp/gerald/OBJ-1222-0104'

gmake[1]: *** [stage1-bubble] Error 2

gmake[1]: Leaving directory `/scratch2/tmp/gerald/OBJ-1222-0104'

gmake: *** [all] Error 2





The respective lines of /usr/include/sys/types.h are the following:



186 #ifndef _RLIM_T_DECLARED

187 typedef __rlim_trlim_t; /* resource limit */

188 #define _RLIM_T_DECLARED

189 #endif



though I'd focus on the other issue first.

[Bug c++/55783] Warnings instead of compiler errors for narrowing conversions within list-initializations

[redi at gcc dot gnu.org]

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



Jonathan Wakely  changed:



   What|Removed |Added



   Keywords||diagnostic



--- Comment #8 from Jonathan Wakely  2012-12-22 
00:55:31 UTC ---

Comment 6 misinterprets the standard in multiple ways :)



Narrowing conversions do require a diagnostic, but a warning *is* a diagnostic,

so G++ is compliant in this regard, this is not a GNU extension.



Whether the diagnostic should default to a warning or an error or a "pedwarn"

(the category of diagnostic enabled by -pedantic and made into errors by

-pedantic-errors) is debatable, but the current behaviour is the result of a

conscious decision and is not a bug (certainly not Severity=major)

[Bug c++/55783] Warnings instead of compiler errors for narrowing conversions within list-initializations

[david at stellarscience dot com]

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



--- Comment #7 from David Sankel  2012-12-22 
00:42:35 UTC ---

I just realized my above comment doesn't make much sense regarding the

standard. Please disregard. On the other hand it seems like -pedantic should

reject this program, no?

[Bug c++/55783] Warnings instead of compiler errors for narrowing conversions within list-initializations

[david at stellarscience dot com]

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

--- Comment #6 from David Sankel  2012-12-22 
00:33:44 UTC ---
I suppose which gnu extensions are, by default, enabled in the -std=c++11 mode
is up for debate (one which I have no interest in). However, this program still
compiles with "-pedantic".

"-pedantic
   Issue all the warnings demanded by strict ISO C and ISO C++; reject all
   programs that use forbidden extensions"

Allowing for these narrowing conversions would qualify as a forbidden
extension.

Regarding compliance, I think Johnathan's snippet is misleading. Here is the
relevant surrounding text:

  If a program contains a violation of any diagnosable rule or an occurrence of
a construct described in
  this Standard as “conditionally-supported” when the implementation does not
support that construct,
  a conforming implementation shall issue at least one diagnostic message.

I didn't see in the standard where it states that breaking this feature is
"conditionally supported".

However, it does say:

  If a program contains a violation of a rule for which no diagnostic is
required, this International
  Standard places no requirement on implementations with respect to that
program.

Which pretty much allows gcc to do anything it wants with malformed programs.
But as stated above, -pedantic should guarentee rejection.

[Bug c++/55783] Warnings instead of compiler errors for narrowing conversions within list-initializations

[redi at gcc dot gnu.org]

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



--- Comment #5 from Jonathan Wakely  2012-12-22 
00:27:51 UTC ---

(In reply to comment #4)

> The standard only requires that "a conforming implementation shall issue at

> least one diagnostic message"



(This is from 1.4 [intro.compliance] p2)

[Bug c++/55783] Warnings instead of compiler errors for narrowing conversions within list-initializations

[redi at gcc dot gnu.org]

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



Jonathan Wakely  changed:



   What|Removed |Added



   Severity|major   |normal



--- Comment #4 from Jonathan Wakely  2012-12-22 
00:26:10 UTC ---

The standard only requires that "a conforming implementation shall issue at

least one diagnostic message" so compiling the program with a warning is

allowed.  As Andrew said, -Werror=narrowing allows you to make it an error if

you want.



G++ 4.6 gave an error but it was changed to a warning intentionally for 4.7

because many people (myself included) found that narrowing conversions where

one of the most commonly encountered problems when trying to compile large

C++03 codebases as C++11.  Previously well-formed code such as char c[] = { i,

0 }; (where i will only ever be within the range of char) caused errors and had

to be changed to char c[] = { (char)i, 0 }

[Bug c++/55783] Warnings instead of compiler errors for narrowing conversions within list-initializations

[pinskia at gcc dot gnu.org]

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



--- Comment #3 from Andrew Pinski  2012-12-22 
00:15:04 UTC ---

use -Werror=Wnarrowing then

[Bug c++/55783] Warnings instead of compiler errors for narrowing conversions within list-initializations

[david at stellarscience dot com]

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



--- Comment #2 from David Sankel  2012-12-22 
00:13:33 UTC ---

>From what I understand, the standard requires the compiler to reject the

program, not to accept it with a warning.

[Bug c++/55783] Warnings instead of compiler errors for narrowing conversions within list-initializations

[pinskia at gcc dot gnu.org]

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



--- Comment #1 from Andrew Pinski  2012-12-22 
00:06:50 UTC ---

"With -std=c++11, -Wno-narrowing suppresses the diagnostic required by the

standard. Note that this does not affect the meaning of well-formed code;

narrowing conversions are still considered ill-formed in SFINAE context. "

[Bug c++/55783] New: Warnings instead of compiler errors for narrowing conversions within list-initializations

[david at stellarscience dot com]

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

 Bug #: 55783
   Summary: Warnings instead of compiler errors for narrowing
conversions within list-initializations
Classification: Unclassified
   Product: gcc
   Version: 4.7.2
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: da...@stellarscience.com


Created attachment 29023
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29023
Erroneous C++ 2011 program that has a narrowing conversion error.

Narrowing conversions for initializer lists are producing warnings instead of
errors in -std=c++11 mode. See standard 8.5.4 item 3:

  If a narrowing conversion (see below) is required to convert any of the
  arguments, the program is ill-formed.


and item 7:

  A narrowing conversion is an implicit conversion...

  from long double to double or float, or from double to float, except where
the source is a constant
  expression and the actual value after conversion is within the range of
values that can be represented
  (even if it cannot be represented exactly)

Compiling the attached program has the following output with -std=c++11:

test.cpp: In function ‘void f(double)’:
test.cpp:3:26: warning: narrowing conversion of ‘d’ from ‘double’ to ‘float’
inside { } [-Wnarrowing]
test.cpp:3:26: warning: narrowing conversion of ‘d’ from ‘double’ to ‘float’
inside { } [-Wnarrowing]
test.cpp:3:26: warning: narrowing conversion of ‘d’ from ‘double’ to ‘float’
inside { } [-Wnarrowing]

[Bug target/43764] -mrelax-pic-calls fails with complex types

[sje at gcc dot gnu.org]

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



Steve Ellcey  changed:



   What|Removed |Added



 Status|ASSIGNED|RESOLVED

 CC||sje at gcc dot gnu.org

 Resolution||FIXED



--- Comment #4 from Steve Ellcey  2012-12-21 23:56:28 
UTC ---

It looks like this bug was fixed for 4.6 and backported to 4.5 so I am closing

it. I don't see any reason for it still being open.

[Bug middle-end/30996] Performance problem with structure assignment on MIPS

[sje at gcc dot gnu.org]

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



Steve Ellcey  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 CC||sje at gcc dot gnu.org

 Resolution||WORKSFORME



--- Comment #3 from Steve Ellcey  2012-12-21 23:43:57 
UTC ---

Works for me too on ToT.  I do not see any partial loads.  I am going to close

this as unreproducable.  Simon, if you can reproduce this with a newer version

of GCC (4.1 is no longer supported) you can reopen it.  In that case can you

also include information on what options you used (optimization level, endian,

etc.)

[Bug fortran/55763] Issues with some simpler CLASS(*) programs

[burnus at gcc dot gnu.org]

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



--- Comment #6 from Tobias Burnus  2012-12-21 
22:59:27 UTC ---

To the last test case of comment 0:



> gives an ICE (segfault) at

>  vector_comp => field

> 

> 0x62d477 gfc_trans_pointer_assignment(gfc_expr*, gfc_expr*)

> ../../gcc/fortran/trans-expr.c:6523



The problem is that the LHS is:

  expr1->symtree->n.sym->attr.subref_array_pointer



The ICE occurs for:

  gfc_add_modify (&lse.post, GFC_DECL_SPAN(decl), tmp);



The problem is that DECL_LANG_SPECIFIC(decl) is NULL; hence,

DECL_LANG_SPECIFIC(decl)->span causes the ICE.



In principle, gfc_get_symbol_decl takes care of that. However, as the symbol is

a dummy argument, the backend_decl is already set and gfc_get_symbol_decl

returns early.

[Bug ada/53737] [4.7/4.8 regression] Assert_Failure on a generic package with a package as parameter

[ebotcazou at gcc dot gnu.org]

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



Eric Botcazou  changed:



   What|Removed |Added



 Status|NEW |RESOLVED

 Resolution||FIXED



--- Comment #5 from Eric Botcazou  2012-12-21 
22:34:28 UTC ---

Thanks for reporting the problem.

[Bug ada/53737] [4.7/4.8 regression] Assert_Failure on a generic package with a package as parameter

[ebotcazou at gcc dot gnu.org]

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



--- Comment #4 from Eric Botcazou  2012-12-21 
22:33:42 UTC ---

Author: ebotcazou

Date: Fri Dec 21 22:33:36 2012

New Revision: 194688



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

Log:

PR ada/53737

* sem_ch12.adb (Analyze_Associations): Do not check the legality of

actuals for RACW types if this is an internal instantiation for a formal

package with defaulted parameters.



Modified:

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

branches/gcc-4_7-branch/gcc/ada/sem_ch12.adb

[Bug ada/53737] [4.7/4.8 regression] Assert_Failure on a generic package with a package as parameter

[ebotcazou at gcc dot gnu.org]

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



--- Comment #3 from Eric Botcazou  2012-12-21 
22:31:46 UTC ---

Author: ebotcazou

Date: Fri Dec 21 22:31:42 2012

New Revision: 194687



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

Log:

PR ada/53737

* sem_ch12.adb (Analyze_Associations): Do not check the legality of

actuals for RACW types if this is an internal instantiation for a formal

package with defaulted parameters.



Modified:

trunk/gcc/ada/ChangeLog

trunk/gcc/ada/sem_ch12.adb

[Bug tree-optimization/55355] internal compiler error: in tree_low_cst, at tree.c:6415

[jamborm at gcc dot gnu.org]

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



Martin Jambor  changed:



   What|Removed |Added



 Status|ASSIGNED|RESOLVED

 Resolution||FIXED



--- Comment #21 from Martin Jambor  2012-12-21 
22:31:02 UTC ---

Fixed.

[Bug tree-optimization/55355] internal compiler error: in tree_low_cst, at tree.c:6415

[jamborm at gcc dot gnu.org]

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



--- Comment #20 from Martin Jambor  2012-12-21 
22:28:45 UTC ---

Author: jamborm

Date: Fri Dec 21 22:28:40 2012

New Revision: 194686



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

Log:

2012-12-21  Martin Jambor  



PR tree-optimization/55355

* tree-sra.c (type_internals_preclude_sra_p): Also check that

bit_position is small enough to fit a single HOST_WIDE_INT.



* testsuite/g++.dg/torture/pr55355.C: New test.





Added:

branches/gcc-4_6-branch/gcc/testsuite/g++.dg/torture/pr55355.C

Modified:

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

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

branches/gcc-4_6-branch/gcc/tree-sra.c

[Bug tree-optimization/55355] internal compiler error: in tree_low_cst, at tree.c:6415

[jamborm at gcc dot gnu.org]

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



--- Comment #19 from Martin Jambor  2012-12-21 
22:21:20 UTC ---

Author: jamborm

Date: Fri Dec 21 22:21:14 2012

New Revision: 194684



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

Log:

2012-12-21  Martin Jambor  



PR tree-optimization/55355

* tree-sra.c (type_internals_preclude_sra_p): Also check that

bit_position is small enough to fit a single HOST_WIDE_INT.



* testsuite/g++.dg/torture/pr55355.C: New test.





Added:

branches/gcc-4_7-branch/gcc/testsuite/g++.dg/torture/pr55355.C

Modified:

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

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

branches/gcc-4_7-branch/gcc/tree-sra.c

[Bug tree-optimization/55355] internal compiler error: in tree_low_cst, at tree.c:6415

[jamborm at gcc dot gnu.org]

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



--- Comment #18 from Martin Jambor  2012-12-21 
22:06:42 UTC ---

Author: jamborm

Date: Fri Dec 21 22:06:38 2012

New Revision: 194682



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

Log:

2012-12-21  Martin Jambor  



PR tree-optimization/55355

* tree-sra.c (type_internals_preclude_sra_p): Also check that

bit_position is small enough to fit a single HOST_WIDE_INT.



* testsuite/g++.dg/torture/pr55355.C: New test.





Added:

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

Modified:

trunk/gcc/ChangeLog

trunk/gcc/testsuite/ChangeLog

trunk/gcc/tree-sra.c

[Bug driver/55782] New: GCC needs a -shared-libstdc++ option

[ccoutant at gcc dot gnu.org]

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



 Bug #: 55782

   Summary: GCC needs a -shared-libstdc++ option

Classification: Unclassified

   Product: gcc

   Version: 4.6.3

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: driver

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

ReportedBy: ccout...@gcc.gnu.org





The top-level configure for gcc and sources now turns on -static-libstdc++

option, and I need to be able to add an option to turn that back off.

Unfortunately, there is no -shared-libstdc++ option.

[Bug driver/55781] New: -shared-libgcc does not completely undo -static-libgcc

[ccoutant at gcc dot gnu.org]

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



 Bug #: 55781

   Summary: -shared-libgcc does not completely undo -static-libgcc

Classification: Unclassified

   Product: gcc

   Version: 4.6.3

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: driver

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

ReportedBy: ccout...@gcc.gnu.org





In the gold testsuite, I need to link with a shared libgcc, but the top-level

configure now passes in -static-libgcc to all $(COMPILE) and $(CXX_COMPILE)

actions. I tried to undo that by adding -shared-libgcc to the command line, but

it doesn't quite erase the effects of -static-libgcc.



Running gcc without either option gives me these link options:



  .../collect2 ... -lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc ...



Running gcc with both -static-libgcc and -shared-libgcc gives me this:



  .../collect2 ... -lstdc++ -lm -lgcc -lgcc_eh -lc -lgcc -lgcc_eh ...



Reproduced with 4.7 as well.

[Bug rtl-optimization/55672] [4.8 Regression] -fstack-check=generic ICEs in print_reg, at config/i386/i386.c:13868

[vmakarov at gcc dot gnu.org]

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



--- Comment #9 from Vladimir Makarov  2012-12-21 
21:28:51 UTC ---

(In reply to comment #8)

> 

> The difference is

> 

> --- x.s2012-12-18 12:24:17.072888139 -0800

> +++ no-lra.s2012-12-18 12:30:11.419157548 -0800

> @@ -14,7 +14,7 @@ main:

>  subl$8236, %esp

>  orl$0, (%esp)

>  addl$8204, %esp

> -cmpl$4, -40(%ebp)

> +cmpl$4, (%esp)

>  je.L2

>  callabort

>  .L2:

> 

> I think LRA generated code is wrong.  The reason we don't allow

> converting software frame pointer to hardware frame pointer is

> when stack alignment is needed, hardware frame pointer is used

> to save stack pointer.  We can no longer use it for software

> frame pointer.



H.J., thanks for the explanation.  Now I know what to do.  I'll start to work

on the solution after my vacation in 2 weeks.

[Bug middle-end/55775] [4.8 Regression] ICE when building pari

[vmakarov at gcc dot gnu.org]

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



--- Comment #1 from Vladimir Makarov  2012-12-21 
21:20:55 UTC ---

Author: vmakarov

Date: Fri Dec 21 21:20:48 2012

New Revision: 194680



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

Log:

2012-12-21  Vladimir Makarov  



PR middle-end/55775

* lra-assigns.c (improve_inheritance): Do nothing after

LRA_MAX_INHERITANCE_PASSES pass.

* lra-constraints.c (MAX_CONSTRAINT_ITERATION_NUMBER): Rename to

LRA_MAX_CONSTRAINT_ITERATION_NUMBER.  Move to lra-int.h.

(MAX_INHERITANCE_PASSES): Rename to LRA_MAX_INHERITANCE_PASSES.

Move to lra-int.h.

* lra-int.h (LRA_MAX_CONSTRAINT_ITERATION_NUMBER): Move from

lra-constraints.c.

(LRA_MAX_INHERITANCE_PASSES): Ditto.



2012-12-21  Vladimir Makarov  



PR middle-end/55775

* gcc.target/i386/pr55775.c: New test.





Added:

trunk/gcc/testsuite/gcc.target/i386/pr55775.c

Modified:

trunk/gcc/ChangeLog

trunk/gcc/lra-assigns.c

trunk/gcc/lra-constraints.c

trunk/gcc/lra-int.h

trunk/gcc/testsuite/ChangeLog

[Bug c++/55778] Variadic template extension possibly wrong

[redi at gcc dot gnu.org]

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



--- Comment #5 from Jonathan Wakely  2012-12-21 
21:05:36 UTC ---

No. SFINAE only applies if there's a substitution error, which doesn't apply

here. The foo(Args...) overload is viable and deduction succeeds unless the

argument types are not copyable.  To make the other overload viable it must be

declared. Clang gives exactly the same result, this is not a compiler bug. If

you think the language has a defect this is the wrong place to discuss it.

[Bug libfortran/30162] [4.7/4.8 Regression] I/O with named pipes does not work

[tkoenig at gcc dot gnu.org]

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



--- Comment #31 from Thomas Koenig  2012-12-21 
20:50:52 UTC ---

Author: tkoenig

Date: Fri Dec 21 20:50:48 2012

New Revision: 194679



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

Log:

2012-12-21  Thomas Koenig  



PR libfortran/30162

* io/unix.c (raw_tell):  If the lseek is done on a

non-seekable file, return 0.





Modified:

trunk/libgfortran/ChangeLog

trunk/libgfortran/io/unix.c

[Bug c++/55778] Variadic template extension possibly wrong

[koala01 at free dot fr]

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



--- Comment #4 from ph dunski  2012-12-21 19:57:05 UTC 
---

It is what i did ;)



But, i'm really not convicted, because, in my head,  we should have a SFINAE

behaviour which should fall back into the good overloaded version until there

are no more argument :P



Maybe i just forget something from the norm, but it would be coherent to get

this behaviour, no ???

[Bug c++/55778] Variadic template extension possibly wrong

[redi at gcc dot gnu.org]

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



Jonathan Wakely  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||INVALID



--- Comment #3 from Jonathan Wakely  2012-12-21 
19:42:45 UTC ---

(In reply to comment #2)

> I've always heard that the implementation order should not have an impact on

> the final result.

> 

> Am i rong again?



The problem isn't the order the function definitions (i.e. implementations)

appear in, it's the order they are declared in. A function that hasn't been

declared yet can't be called, that's pretty basic:



int f()

{

  return g(); // error

}



int g() { return 0; }



To make you code compile just declare the foo(const std::string&, Args...)

overload before any code needs to call it, so add its declaration before the

definition of foo(int, Args...)

[Bug bootstrap/54128] [4.8 Regression] GCC does not bootstrap on little endian mips due to mis-compare on tree-data-ref.c

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 Status|NEW |RESOLVED

 Resolution||FIXED



--- Comment #17 from Jakub Jelinek  2012-12-21 
19:31:58 UTC ---

Fixed then.

[Bug c++/55778] Variadic template extension possibly wrong

[koala01 at free dot fr]

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



--- Comment #2 from ph dunski  2012-12-21 19:17:05 UTC 
---

(In reply to comment #1)

> (In reply to comment #0)

> > Am i wrong ?

> 

> Yes.  The foo(std::string const&, Args...) overload is not in scope within

> foo(int, Args...) so the call resolves to the foo(Args...) overload.



If you say so ...



But in this case, how is it possible to have a diffrent behavior simply by

switching foo (const std :: string &, Args ..) and foo (int, args ...)

implemented?



If you just try to compile my first test code, you will see that the execution

stops before writing the string, 3 more.



If you go foo (std :: string const &, Args ..) and foo (int, args ...)

implemented in the code, you will see that the execution stops after writing

the string, with argument 2 more.



I've always heard that the implementation order should not have an impact on

the final result.



Am i rong again?

[Bug testsuite/55780] New: effective targets arm_arch_v*_multilib are not strict enough

[janis at gcc dot gnu.org]

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



 Bug #: 55780

   Summary: effective targets arm_arch_v*_multilib are not strict

enough

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: testsuite

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

ReportedBy: ja...@gcc.gnu.org

CC: rearn...@arm.com

Target: arm





The arm_arch_v*_multilib effective targets check that a minimal C program will

execute when compiled for a particular ARM processor, but the test used is an

empty program and the tests that use those checks have more complicated code. 

All of the effective target checks pass using the gdb arm simulator or QEMU,

but some of the ftest-*.c tests then get illegal instructions or hang.



Checks for the ability to run programs on particular hardware should include

code that will only run on that hardware, as is done for effective target whose

keywords end in "_hw_available".

[Bug bootstrap/54128] [4.8 Regression] GCC does not bootstrap on little endian mips due to mis-compare on tree-data-ref.c

[sje at gcc dot gnu.org]

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



--- Comment #16 from Steve Ellcey  2012-12-21 18:54:05 
UTC ---

Author: sje

Date: Fri Dec 21 18:54:00 2012

New Revision: 194676



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

Log:

2012-12-21  Steve Ellcey  



PR bootstrap/54128

* ira.c (build_insn_chain): Check only NONDEBUG instructions for

register usage.



Modified:

trunk/gcc/ChangeLog

trunk/gcc/ira.c

[Bug libgcc/55779] New: Debug program abort on pthread_exit() while using -static-libgcc and -static-libstdc++

[ryang at synopsys dot com]

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



 Bug #: 55779

   Summary: Debug program abort on pthread_exit() while using

-static-libgcc and -static-libstdc++

Classification: Unclassified

   Product: gcc

   Version: 4.7.2

Status: UNCONFIRMED

  Severity: major

  Priority: P3

 Component: libgcc

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

ReportedBy: ry...@synopsys.com





Created attachment 29022

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

The *.i* files



On SUSE 10 SP3, a debug build (-g) thread program abort on ptherad_exit() when

statically link libgcc and libstdc++ (use option -static-libgcc

-static-libstdc++). No issue with optimized build (-O).



GCC version: 4.7.2

System: SUSE 10 SP3, Linux peemt210 2.6.16.60-0.83.2-smp #1 SMP Fri Sep 2

13:49:16 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux



GCC build options/configuration:

ryang@peemt210 RAII> /depot/qsc/QSCI/bin/g++ -v

Using built-in specs.

COLLECT_GCC=/depot/qsc/QSCI/bin/g++

COLLECT_LTO_WRAPPER=/depot/gcc-4.7.2/libexec/gcc/x86_64-suse-linux/4.7.2/lto-wrapper

Target: x86_64-suse-linux

Configured with: ../../src/gcc-4.7.2/configure --prefix=/depot/gcc-4.7.2

--enable-bootstrap --enable-threads=posix --enable-languages=c,c++,fortran

--enable-checking=release --enable-ssp --disable-libssp --with-system-zlib

--enable-__cxa_atexit --enable-libstdcxx-allocator=new

--without-system-libunwind --with-cpu=generic --host=x86_64-suse-linux

--build=x86_64-suse-linux

Thread model: posix

gcc version 4.7.2 (GCC)



Command line to triggers the bug (mttest is the program name):

mttest 2 2



Compiler outputs:

/depot/qsc/QSCI/bin/g++ -I. -Wall -Wextra  -m64 -c  -DSynopsys_Debug

-DSynopsys_suse64 -DSynopsys_linux  -msse2 -mfpmath=sse 

-fno-omit-frame-pointer -fno-dollars-in-identifiers -save-temps -g -o main.o

main.c

/depot/qsc/QSCI/bin/g++ -I. -Wall -Wextra  -m64 -c  -DSynopsys_Debug

-DSynopsys_suse64 -DSynopsys_linux  -msse2 -mfpmath=sse 

-fno-omit-frame-pointer -fno-dollars-in-identifiers -save-temps -g -o

threads_raii.o threads_raii.C

/depot/qsc/QSCI/bin/g++ -I. -Wall -Wextra  -m64 -c  -DSynopsys_Debug

-DSynopsys_suse64 -DSynopsys_linux  -msse2 -mfpmath=sse 

-fno-omit-frame-pointer -fno-dollars-in-identifiers -save-temps -g -o raii.o

raii.C

/depot/qsc/QSCI/bin/g++ -static-libgcc -static-libstdc++  -o mttest main.o

threads_raii.o raii.o -lpthread -lm -ldl

[Bug c++/55778] Variadic template extension possibly wrong

[redi at gcc dot gnu.org]

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



--- Comment #1 from Jonathan Wakely  2012-12-21 
18:37:54 UTC ---

(In reply to comment #0)

> Am i wrong ?



Yes.  The foo(std::string const&, Args...) overload is not in scope within

foo(int, Args...) so the call resolves to the foo(Args...) overload.

[Bug c++/55778] New: Variadic template extension possibly wrong

[koala01 at free dot fr]

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



 Bug #: 55778

   Summary: Variadic template extension possibly wrong

Classification: Unclassified

   Product: gcc

   Version: 4.7.1

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: c++

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

ReportedBy: koal...@free.fr





with the code

#include 

#include 

template

void foo(Args ... args)

{

std::cout<<"stopping with "<

void foo(int i, Args ... args)

{

std::cout<<"using i = "<

void foo(std::string const & s, Args...args)

{

std::cout<<"using the "<(1, 2, 3, 4,5 ,

   "hello", 6, 7 );

return 0;

}



we get a result like

using i = 1, left 7 argument more

using i = 2, left 6 argument more

using i = 3, left 5 argument more

using i = 4, left 4 argument more

using i = 5, left 3 argument more

stopping with 3 unused arguments



but we could expect a result like 



using i = 1, left 7 argument more

using i = 2, left 6 argument more

using i = 3, left 5 argument more

using i = 4, left 4 argument more

using i = 5, left 3 argument more

using the hello string, left 2 argument more

using i = 6, left 1 argument more

using i = 7, left 0 argument more

stopping with 0 unused arguments



just like with the code 



#include 

#include 

template

void foo(int i, Args ... args);

template

void foo(std::string const & s, Args...args);

template

void foo(Args ... args)

{

std::cout<<"stopping with "<

void foo(std::string const & s, Args...args)

{

std::cout<<"using the "<

void foo(int i, Args ... args)

{

std::cout<<"using i = "<(1, 2, 3, 4,5 ,

   "hello", 6, 7 );

return 0;

}



Am i wrong ?

[Bug target/52152] MIPS ELF targets should use dbxelf.h

[sje at gcc dot gnu.org]

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



Steve Ellcey  changed:



   What|Removed |Added



 CC||sje at gcc dot gnu.org



--- Comment #3 from Steve Ellcey  2012-12-21 17:20:57 
UTC ---

Do we care about dbx/stabs on MIPS for any targets?  I recently ran the GCC

testsuite with the mips-mti-elf target and the -mips16 flag using the gdb

simulator.  All tests involving stabs failed (the simulator aborted with a

message about reading unallocated memory) with the -mips16 flag.



Maybe we should remove the use of dbxelf.h from all mips targets and remove 

the define of DBX_DEBUGGING_INFO from mips.h instead of adding dbxelf.h to

the mips elf targets.

[Bug target/55777] New: Inlining nomips16 function into mips16 function can result in undefined builtins

[sje at gcc dot gnu.org]

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



 Bug #: 55777

   Summary: Inlining nomips16 function into mips16 function can

result in undefined builtins

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: target

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

ReportedBy: s...@gcc.gnu.org

Target: mips*-*-*





While looking at the GCC testresults compiled with -mips16 I found that

gcc.target/mips/mips32-dsp-run.c failed.  Further investigation resulted

in this cutdown testcase:





long long a64_r;

unsigned int ui32_a, ui32_b;



__attribute__((nomips16)) int foo() {

a64_r = __builtin_mips_multu (ui32_a, ui32_b);

}



main ()

{

foo();

}





Compiling with -O3 -mips16 results in:



gcc -mips16 -O3 builtin.c

/local/home/sellcey/nightly_full/install-mips-mti-elf/lib/gcc/mips-mti-elf/4.8.0/../../../../mips-mti-elf/bin/ld:

warning: cannot find entry symbol __start; defaulting to 00400098

/tmp/ccrfai7t.o: In function `foo':

builtin.c:(.text+0x10): undefined reference to `__builtin_mips_multu'

collect2: error: ld returned 1 exit status



Inlining a function with the nomips16 attribute into a function that does

not have that attribute seems to be the cause of the problem.

[Bug fortran/55763] Issues with some simpler CLASS(*) programs

[pault at gcc dot gnu.org]

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



--- Comment #5 from Paul Thomas  2012-12-21 16:51:41 
UTC ---

Sorry, I didn't look down the PR - I thought that we were just at the stage of

your opening email :-(



Paul

[Bug gcov-profile/55674] [4.8 Regression] >20% size increase of lto/pgo binaries since r193747

[tejohnson at google dot com]

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



--- Comment #20 from Teresa Johnson  2012-12-21 
16:26:17 UTC ---

On Fri, Dec 21, 2012 at 8:15 AM, hubicka at ucw dot cz

 wrote:

>

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

>

> --- Comment #19 from Jan Hubicka  2012-12-21 16:15:34 
> UTC ---

>> As another data point, in our internal benchmarks I had tried a few

>> values and 99.9% gave the best performance. Just going down to 99.0%

>> reduced the inlining too much, even compared to the old static cutoff

>> count, missing some key inlines and reducing performance.

> this really should not happen too much.  I still think something along the

> following lines

> is desirable.  Does it helps setting more resonable threshold?



I'll give this patch a try and let you know how it affects the

performance I see. But unrolling shouldn't affect inlining, since all

unrolling is after inlining, right?



Thanks,

Teresa



>

> Honza

>

> Index: predict.c

> ===

> *** predict.c(revision 194655)

> --- predict.c(working copy)

> *** maybe_hot_count_p (struct function *fun,

> *** 145,151 

>   {

> ws = find_working_set (PARAM_VALUE (HOT_BB_COUNT_WS_PERMILLE));

> gcc_assert (ws);

> !   min_count = ws->min_counter;

>   }

> return (count >= min_count);

>   }

> --- 145,156 

>   {

> ws = find_working_set (PARAM_VALUE (HOT_BB_COUNT_WS_PERMILLE));

> gcc_assert (ws);

> !

> !   /* We want all counters above ws->min_counter * profile_info->runs

> !  to be safely identified as hot regions.  This may be spoiled

> !  by optimizations such as unrolling that reduce counts of the

> !  body, thus divide by 32.  */

> !   min_count = ws->min_counter / 32;

>   }

> return (count >= min_count);

>   }

>

> --

> Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email

> --- You are receiving this mail because: ---

> You are on the CC list for the bug.

[Bug libstdc++/48881] Dynamic link to libstdc++-6.dll / libgcc_s_sjlj-1.dll produces broken binaries

[ktietz at gcc dot gnu.org]

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



Kai Tietz  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||WORKSFORME



--- Comment #9 from Kai Tietz  2012-12-21 16:26:11 
UTC ---

Well, issue seems to be related to TLS-code of runtime you were using.

With more up-to-date runtime-version this is fixed for all mingw-flavors.

Additionally 4.5.x branch has reached already end of support, so I close this

as works-for-me

[Bug c++/55776] New: -Wshadow generates an incorrect warning with enum classes

[s...@s-e-f-i.de]

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



 Bug #: 55776

   Summary: -Wshadow generates an incorrect warning with enum

classes

Classification: Unclassified

   Product: gcc

   Version: 4.7.2

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: c++

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

ReportedBy: s...@s-e-f-i.de





In C++11 mode, enum classes can generate incorrect -Wshadow warnings:



g++ -Wshadow -std=c++11 test.cpp



typedef int foo;



enum class myenum

{

foo

};



test.cpp:5:2: warning: declaration of 'foo' shadows a global declaration

[-Wshadow]

test.cpp:1:13: warning: shadowed declaration is here [-Wshadow]





Note, that if the typedef and the definition of the enum class are reversed, no

warning is produced.

[Bug gcov-profile/55674] [4.8 Regression] >20% size increase of lto/pgo binaries since r193747

[hubicka at ucw dot cz]

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



--- Comment #19 from Jan Hubicka  2012-12-21 16:15:34 
UTC ---

> As another data point, in our internal benchmarks I had tried a few

> values and 99.9% gave the best performance. Just going down to 99.0%

> reduced the inlining too much, even compared to the old static cutoff

> count, missing some key inlines and reducing performance.

this really should not happen too much.  I still think something along the

following lines

is desirable.  Does it helps setting more resonable threshold?



Honza



Index: predict.c

===

*** predict.c(revision 194655)

--- predict.c(working copy)

*** maybe_hot_count_p (struct function *fun,

*** 145,151 

  {

ws = find_working_set (PARAM_VALUE (HOT_BB_COUNT_WS_PERMILLE));

gcc_assert (ws);

!   min_count = ws->min_counter;

  }

return (count >= min_count);

  }

--- 145,156 

  {

ws = find_working_set (PARAM_VALUE (HOT_BB_COUNT_WS_PERMILLE));

gcc_assert (ws);

! 

!   /* We want all counters above ws->min_counter * profile_info->runs

!  to be safely identified as hot regions.  This may be spoiled

!  by optimizations such as unrolling that reduce counts of the

!  body, thus divide by 32.  */

!   min_count = ws->min_counter / 32;

  }

return (count >= min_count);

  }

[Bug bootstrap/54659] [4.8 Regression] Bootstrap with --disable-nls broken under Windows

[ian at gcc dot gnu.org]

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



--- Comment #12 from ian at gcc dot gnu.org  2012-12-21 
15:59:36 UTC ---

Author: ian

Date: Fri Dec 21 15:59:27 2012

New Revision: 194669



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

Log:

PR bootstrap/54659



compiler: Don't include , now included by go-system.h.



* go-system.h: Don't include .



Modified:

trunk/gcc/go/ChangeLog

trunk/gcc/go/go-system.h

trunk/gcc/go/gofrontend/expressions.cc

trunk/gcc/go/gofrontend/expressions.h

trunk/gcc/go/gofrontend/gogo-tree.cc

trunk/gcc/go/gofrontend/lex.h

trunk/gcc/go/gofrontend/runtime.cc

trunk/gcc/go/gofrontend/statements.cc

trunk/gcc/go/gofrontend/types.cc

[Bug middle-end/55775] [4.8 Regression] ICE when building pari

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



   Target Milestone|--- |4.8.0

[Bug middle-end/55775] New: [4.8 Regression] ICE when building pari

[jakub at gcc dot gnu.org]

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

 Bug #: 55775
   Summary: [4.8 Regression] ICE when building pari
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Keywords: ra
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ja...@gcc.gnu.org
CC: vmaka...@gcc.gnu.org


int *ptr;
int *fn1 (int *);
int fn2 (int, int);
int fn3 (void);
int fn4 (int);

static int
foo (int x, int y, int z)
{
  int b;
  asm ("" : "=a" (b), "=&d" (x) : "0" (y), "1" (x), "mr" (z));
  return x;
}

static int
bar (int x, int y)
{
  int a;
  if (!y)
{
  for (a = 0; a <= (x >> 1); )
;
  a = foo (y, fn2 (2, x), x);
  if (x)
a = x;
  return a;
}
}

static int
baz (int x, int y)
{
  int *a = ptr;
  int t, xk1 = fn3 (), xk = x * xk1;
  for (t = 0; t < xk; t += xk1)
{
  if (fn4 (a[2]))
return -y;
  a = fn1 (a);
}
  return 0;
}

void
test (int x, long y, int z)
{
  int a = fn3 ();
  int b;
  int c = bar (x, z);
  for (b = 0; b <= y; b++)
c = baz (x, c);
  fn2 (c, a);
}

ICEs on x86_64-linux with -O1 -w:
lra_ice.i: In function ‘test’:
lra_ice.i:53:1: internal compiler error: Maximum number of LRA constraint
passes is achieved (30)

 }
 ^
0x90089c lra_constraints(bool)
../../gcc/lra-constraints.c:3334
0x8f12e6 lra(_IO_FILE*)
../../gcc/lra.c:2280
0x8a6d43 do_reload
../../gcc/ira.c:4624
0x8a6f51 rest_of_handle_reload
../../gcc/ira.c:4737
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug lto/54728] [4.8 regression] ICE in input_gimple_stmt, at gimple-streamer-in.c:254

[hubicka at gcc dot gnu.org]

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



--- Comment #10 from Jan Hubicka  2012-12-21 
15:01:29 UTC ---

Created attachment 29021

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

Patch I am testing.

[Bug fortran/55763] Issues with some simpler CLASS(*) programs

[burnus at gcc dot gnu.org]

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



Tobias Burnus  changed:



   What|Removed |Added



 Status|RESOLVED|NEW

   Last reconfirmed||2012-12-21

 Resolution|FIXED   |

 Ever Confirmed|0   |1



--- Comment #4 from Tobias Burnus  2012-12-21 
14:42:56 UTC ---

REOPEN. 'Only' the two issues of the follow up (comment 1) are fixed. None of

the 4 issues of comment 0. (Additionally MOVE_ALLOC for two CLASS(*) variables

fails, which I hadn't tested before.)





(In reply to comment #3)

> Fixed on trunk...

Thanks for fixing the issues quickly!



> blow me if I did not remember to attribute the testcase properly.  Blast!

Well, you have still the chance to do so for the other test cases ;-)

[Bug middle-end/52996] [4.8 Regression] ice in verify_loop_structure, at cfgloop.c:1567

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 Status|ASSIGNED|RESOLVED

 Resolution||FIXED



--- Comment #12 from Richard Biener  2012-12-21 
14:35:07 UTC ---

Fixed.

[Bug bootstrap/54659] [4.8 Regression] Bootstrap with --disable-nls broken under Windows

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 Status|ASSIGNED|WAITING



--- Comment #11 from Richard Biener  2012-12-21 
14:34:57 UTC ---

Should be fixed.  Please check if it works with or without reverting



2012-08-17  Diego Novillo  



PR bootstrap/54281

* configure.ac: Add libintl.h to AC_CHECK_HEADERS list.

* config.in: Regenerate.

* configure: Regenerate.

* intl.h: Always include libintl.h if HAVE_LIBINTL_H is

set.

[Bug middle-end/52996] [4.8 Regression] ice in verify_loop_structure, at cfgloop.c:1567

[rguenth at gcc dot gnu.org]

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



--- Comment #11 from Richard Biener  2012-12-21 
14:34:08 UTC ---

Author: rguenth

Date: Fri Dec 21 14:33:59 2012

New Revision: 194666



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

Log:

2012-12-21  Richard Biener  



PR rtl-optimization/52996

* cprop.c (bypass_block): When loops are to be preserved

do not bypass loop headers.  Revert earlier kludge to remove

loops when doing that.



Modified:

trunk/gcc/ChangeLog

trunk/gcc/cprop.c

[Bug bootstrap/54659] [4.8 Regression] Bootstrap with --disable-nls broken under Windows

[rguenth at gcc dot gnu.org]

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



--- Comment #10 from Richard Biener  2012-12-21 
14:33:19 UTC ---

Author: rguenth

Date: Fri Dec 21 14:33:13 2012

New Revision: 194665



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

Log:

2012-12-21  Richard Biener  



PR bootstrap/54659

* system.h: Include gmp.h.

* tree-ssa-loop-niter.c: Do not include gmp.h here.

* double-int.h: Likewise.

* realmpfr.h: Likewise.



fortran/

* gfortran.h: Do not include gmp.h here.



Modified:

trunk/gcc/ChangeLog

trunk/gcc/double-int.h

trunk/gcc/fortran/ChangeLog

trunk/gcc/fortran/gfortran.h

trunk/gcc/realmpfr.h

trunk/gcc/system.h

trunk/gcc/tree-ssa-loop-niter.c

[Bug fortran/55763] Issues with some simpler CLASS(*) programs

[pault at gcc dot gnu.org]

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



Paul Thomas  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||FIXED



--- Comment #3 from Paul Thomas  2012-12-21 14:32:07 
UTC ---

Fixed on trunk... and blow me if I did not remember to attribute the testcase

properly.  Blast!



Paul

[Bug fortran/55763] Issues with some simpler CLASS(*) programs

[pault at gcc dot gnu.org]

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



--- Comment #2 from Paul Thomas  2012-12-21 14:29:40 
UTC ---

Author: pault

Date: Fri Dec 21 14:29:34 2012

New Revision: 194663



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

Log:

2012-12-21  Paul Thomas  



PR fortran/55763

* match.c (select_type_set_tmp): Return is a derived type or

class typespec has no derived type.

* resolve.c (resolve_fl_var_and_proc): Exclude select type

temporaries from 'pointer'.

(resolve_symbol): Exclude select type temporaries from tests

for assumed size and assumed rank.



2012-12-21  Paul Thomas  



PR fortran/55763

* gfortran.dg/unlimited_polymorphic_4.f03: New test.



Added:

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

Modified:

trunk/gcc/fortran/ChangeLog

trunk/gcc/fortran/match.c

trunk/gcc/fortran/resolve.c

trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/55106] ice: Maximum number of LRA constraint passes is achieved (15)

[vmakarov at gcc dot gnu.org]

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



--- Comment #7 from Vladimir Makarov  2012-12-21 
14:27:51 UTC ---

(In reply to comment #5)

> I'm still hitting this failure when building GMP 5.1.0 for i686-w64-mingw32:

> 

> libtool: compile:  i686-w64-mingw32-gcc -std=gnu99 -DHAVE_CONFIG_H -I.

> -I../../../../src/gmp/mpn -I.. -D__GMP_WITHIN_GMP -I../../../../src/gmp

> -DOPERATION_sbpi1_div_qr -O2 -march=nocona -mtune=core2 -fomit-frame-pointer

> -momit-leaf-frame-pointer -c sbpi1_div_qr.c -o sbpi1_div_qr.o

> div_qr_2u_pi1.c: In function '__gmpn_div_qr_2u_pi1':

> div_qr_2u_pi1.c:67:1: internal compiler error: Maximum number of LRA 
> constraint

> passes is achieved (30)

> 

>  }

>  ^

> Please submit a full bug report,

> with preprocessed source if appropriate.

> 

> The build for x86_64-w64-mingw32 did not encounter this problem. I'm building

> on 64-bit Debian using a self-built linux to Windows cross-compilers.



Could you provide a preprocessed source code.  I'd try to reproduce this.  In

any case, it will be not fixed quickly.  I am on vacation next two weeks. 

Sorry.

[Bug tree-optimization/55334] [4.8 Regression] mgrid regression (ipa-cp disables vectorization)

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 CC||rguenth at gcc dot gnu.org



--- Comment #23 from Richard Biener  2012-12-21 
14:27:18 UTC ---

In fact there are a few dependences we can solve:



191: versioning for alias required: can't determine dependence between

MEM[(real(kind=8)[0:D.1986] *)&x + 20247552B][_20] and

MEM[(real(kind=8)[0:D.1989] *)&x + 37823552B][_20]



from



Creating dr for MEM[(real(kind=8)[0:D.1986] *)&x + 20247552B][_20]

analyze_innermost: success.

base_address: &x

offset from base address: (ssizetype) ((sizetype) (((_7 - stride.11_6)

+ pretmp_791) + pretmp_813) * 8)

constant offset from base address: 20247568

step: 8

aligned to: 8 

base_object: MEM[(real(kind=8)[0:D.1986] *)&x + 20247552B]

Access function 0: {{(stride.9_4 * 2 + pretmp_792) + 2, +,

stride.9_4}_2, +, 1}_3



and



Creating dr for MEM[(real(kind=8)[0:D.1983] *)&x][_20]

analyze_innermost: success.

base_address: &x

offset from base address: (ssizetype) ((sizetype) (((_7 - stride.11_6)

+ pretmp_791) + pretmp_813) * 8)

constant offset from base address: 16

step: 8

aligned to: 8

base_object: MEM[(real(kind=8)[0:D.1983] *)&x]

Access function 0: {{(stride.9_4 * 2 + pretmp_792) + 2, +,

stride.9_4}_2, +, 1}_3



we hit:



  /* If the references do not access the same object, we do not know

 whether they alias or not.  */

  if (!operand_equal_p (DR_BASE_OBJECT (a), DR_BASE_OBJECT (b), 0))

{

  DDR_ARE_DEPENDENT (res) = chrec_dont_know;

  return res;

}



but for the case the access functions are the same we can conclude the

accesses cannot alias if the base_objects cannot alias (danger!  data-ref

does not record an "access size", so with the same access function

but only 1-byte offset in base_object this can lead to false disambiguations,

so it might in the end not be that easy ...)  This size issue is also

why we cannot translate the base_object internal offset into an access

function (see testcases I added for bugs we had there)

[Bug tree-optimization/55334] [4.8 Regression] mgrid regression (ipa-cp disables vectorization)

[hubicka at ucw dot cz]

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



--- Comment #22 from Jan Hubicka  2012-12-21 14:22:28 
UTC ---

> There would be if we had ADD_RESTRICT or something similar.  But we don't 
> right

> now, so supposedly it would be better to avoid such IPA-CP changes if it

> removes restrict for now.

We would also have to disable inlining of functions with restrict parameters

(in mgrid case now both ipa-cp and inliner makes the regressions).  I am not

quite sure it is desirable behaviour.



Honza

[Bug lto/54728] [4.8 regression] ICE in input_gimple_stmt, at gimple-streamer-in.c:254

[hubicka at gcc dot gnu.org]

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



--- Comment #9 from Jan Hubicka  2012-12-21 
14:16:09 UTC ---

When writting symtab_real_symbol_p I made external nodes to not be real symbols

unless they are explicitelly called or refereed. 



The reason is that we keep around virtual extenral functions for possible

devirtualization and I did not want those symbol appear to refereed in

lto-plugin symbol table. While this works well with lto-plugin symbol table

output it does not fare well with the use in lto-symtab.



I am testing patch to separate both predicates.

[Bug tree-optimization/55334] [4.8 Regression] mgrid regression (ipa-cp disables vectorization)

[rguenth at gcc dot gnu.org]

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



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

(In reply to comment #20)

> There would be if we had ADD_RESTRICT or something similar.



I think that would not help as we'd likely propagate constants through it.

But yes, it would be one step closer to preserving it.

[Bug tree-optimization/55334] [4.8 Regression] mgrid regression (ipa-cp disables vectorization)

[jakub at gcc dot gnu.org]

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



--- Comment #20 from Jakub Jelinek  2012-12-21 
14:10:19 UTC ---

There would be if we had ADD_RESTRICT or something similar.  But we don't right

now, so supposedly it would be better to avoid such IPA-CP changes if it

removes restrict for now.

[Bug tree-optimization/55334] [4.8 Regression] mgrid regression (ipa-cp disables vectorization)

[rguenth at gcc dot gnu.org]

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



--- Comment #19 from Richard Biener  2012-12-21 
14:08:24 UTC ---

Btw, one thing to improve would be the excessive number of aliasing runtime

checks the vectorizer currently generates.  That would also help himeno.

What is missing here is conservative merging of tests (thus making them

slightly less precise for the sake of reducing their number).  We

create different tests for, say, R vs. U(I1,  I2,  I3) and R vs.

U(I1-1,I2,  I3).



It's of course not that trivial, otherwise somebody would have done it

already (see vect_prune_runtime_alias_test_list - we only merge equal

range tests and do not try to use a convex hull to cover multiple tests

with one).

[Bug middle-end/55771] Negation and type conversion incorrectly exchanged

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 CC||jakub at gcc dot gnu.org



--- Comment #11 from Jakub Jelinek  2012-12-21 
14:08:19 UTC ---

I'd keep it for FLOAT_TYPE_P -> FLOAT_TYPE_P for now, perhaps premature, but

clearly we don't have any GIMPLE optimization that would do the job (or RTL).

int

foo (double x)

{

  float a = x;

  double b = -x;

  float c = -a;

  float d = b;

  return c == d;

}



int

bar (double x)

{

  return (-(float) x) == ((float) -x);

}



with -O2 -ffast-math, bar is folded into return 1;, foo is quite a lot of code,

although both are equivalent.  If the NEGATE_EXPR case is just removed, then

bar isn't optimized at all either.

[Bug tree-optimization/55334] [4.8 Regression] mgrid regression (ipa-cp disables vectorization)

[rguenth at gcc dot gnu.org]

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



--- Comment #18 from Richard Biener  2012-12-21 
14:01:33 UTC ---

(In reply to comment #17)

> > Nothing to fix for me - it's the IPA-CP decision that pessimizes things.

> Well, replacing parameter by known constant should not pessimize in general...



True, but replacing restrict parameter with sth non-restrict may be.

The language spec allows me to write



void foo (int * restrict p, int * restrict q, int n)

{

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

p[i] = q[n-i];

}



and call it with foo (&a[0], &a[100], n) when I know that with this

particular n it will not alias.



But without knowing 'n' (like in the mgrid case) there is no chance

that we can re-discover this non-aliasing when you propagate &a[0]

and &a[100].

[Bug middle-end/55771] Negation and type conversion incorrectly exchanged

[jakub at gcc dot gnu.org]

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



--- Comment #10 from Jakub Jelinek  2012-12-21 
13:59:29 UTC ---

Yeah, I wonder if that transformation wasn't meant to be guarded by also

FLOAT_TYPE_P (itype), comparing TYPE_PRECISION of a floating type with say

integer type or vector type etc. looks fishy.

[Bug middle-end/55771] Negation and type conversion incorrectly exchanged

[rguenth at gcc dot gnu.org]

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



--- Comment #9 from Richard Biener  2012-12-21 
13:57:40 UTC ---

And as usual - convert.c contains premature optimization (this one hardly

worth) and/or duplicates of fold-const.c.  Thus removing the whole

NEGATE_EXPR case looks like the correct thing to do.



Leaving for christmas, so not me.  Patch pre-approved if you want to

prepare the patch and do the testing.

[Bug middle-end/55771] Negation and type conversion incorrectly exchanged

[rguenth at gcc dot gnu.org]

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



--- Comment #8 from Richard Biener  2012-12-21 
13:55:41 UTC ---

Or rather convert.c:convert_to_real:



  /* Propagate the cast into the operation.  */

  if (itype != type && FLOAT_TYPE_P (type))

switch (TREE_CODE (expr))

  {

/* Convert (float)-x into -(float)x.  This is safe for

   round-to-nearest rounding mode.  */

case ABS_EXPR:

case NEGATE_EXPR:

  if (!flag_rounding_math

  && TYPE_PRECISION (type) < TYPE_PRECISION (TREE_TYPE (expr)))

return build1 (TREE_CODE (expr), type,

   fold (convert_to_real (type,

  TREE_OPERAND (expr, 0;

  break;



that's of course not valid for unsigned x, even when using ufloat, as the

float result is always signed.

[Bug middle-end/55771] Negation and type conversion incorrectly exchanged

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



  Component|c   |middle-end



--- Comment #7 from Richard Biener  2012-12-21 
13:52:36 UTC ---

Ah, indeed - I misremembered a dup that was doing the opposite, converting

-1.0 to unsigned and expecting -1U as result.



It's fold converting (float)(-x) to -(float)x:



float

f1()

{

  unsigned long x = 3;

  return -x;

}

[Bug tree-optimization/55334] [4.8 Regression] mgrid regression (ipa-cp disables vectorization)

[hubicka at ucw dot cz]

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



--- Comment #17 from Jan Hubicka  2012-12-21 13:49:15 
UTC ---

> Nothing to fix for me - it's the IPA-CP decision that pessimizes things.

Well, replacing parameter by known constant should not pessimize in general...



Honza

[Bug rtl-optimization/55686] [4.8 Regression] ICE in assign_by_spills, at lra-assigns.c:1244

[hubicka at ucw dot cz]

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



--- Comment #10 from Jan Hubicka  2012-12-21 13:48:19 
UTC ---

> Honza, any thoughts on this (both the combine vs. strset and local register

> vars vs. string insns)?



Well, Steven's suggestion to track local explicit reg vars in seems resonable,

it

probably could go to crtl and be set at expansion time. We probably could have

locally_fixed_regs regset that contains fixed_regs + the local registers vars?



To be honest I am not exactly sure what has_local_explicit_reg_vars code is

shooting

for. Especially because it seems to be used only in rather rare case of store

sink

so it may be better to simply determine it locally rather than having in cfun.



The strset patterns was really intended for memcpy/memset expansion where we

need

to have stuff in proper registers anyway.  Random matching seems bad idea

indeed.

I would go with the unspec way.



Honza

[Bug c/55771] Negation and type conversion incorrectly exchanged

[ian at airs dot com]

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



Ian Lance Taylor  changed:



   What|Removed |Added



 Status|RESOLVED|NEW

   Last reconfirmed||2012-12-21

 Resolution|INVALID |

 Ever Confirmed|0   |1



--- Comment #6 from Ian Lance Taylor  2012-12-21 13:29:01 
UTC ---

-3UL is not outside the range of float.  -3UL == 0xfffd.  That is

less than FLT_MAX == 3.40282e+38.  It is true that the value can not be

precisely represented in float, but it is not out of range.  So the standard

says that the compiler must pick the nearest representable value, either higher

or lower.

[Bug middle-end/52996] [4.8 Regression] ice in verify_loop_structure, at cfgloop.c:1567

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 Status|REOPENED|ASSIGNED

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



--- Comment #10 from Richard Biener  2012-12-21 
12:55:59 UTC ---

let me take it - bypassing of a loop header is never a good idea unless you

want to jump through hoops as the gimple threading code does.

[Bug target/55774] AVX integer store segfault

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 CC||jakub at gcc dot gnu.org

 Resolution||INVALID



--- Comment #1 from Jakub Jelinek  2012-12-21 
12:53:46 UTC ---

That is user error.  You aren't making sure a and b arrays are sufficiently

aligned, thus you need to use _mm256_loadu_si256 and _mm256_storeu_si256

instead (or make those arrays aligned, e.g. with __attribute__((aligned (32))).

[Bug middle-end/52996] [4.8 Regression] ice in verify_loop_structure, at cfgloop.c:1567

[rguenth at gcc dot gnu.org]

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



--- Comment #9 from Richard Biener  2012-12-21 
12:47:54 UTC ---

Ick, I had



Index: gcc/cprop.c

===

--- gcc/cprop.c (revision 194658)

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

@@ -1554,8 +1554,7 @@ bypass_block (basic_block bb, rtx setcc,

   /* The irreducible loops created by redirecting of edges entering the

 loop from outside would decrease effectiveness of some of the

 following optimizations, so prevent this.  */

-  if (may_be_loop_header

- && !(e->flags & EDGE_DFS_BACK))

+  if (may_be_loop_header)

{

  ei_next (&ei);

  continue;



in my tree ...

[Bug target/55774] New: AVX integer store segfault

[gcc-bugzi...@ben-strasser.net]

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



 Bug #: 55774

   Summary: AVX integer store segfault

Classification: Unclassified

   Product: gcc

   Version: unknown

Status: UNCONFIRMED

  Severity: major

  Priority: P3

 Component: target

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

ReportedBy: gcc-bugzi...@ben-strasser.net





The following code segfaults



#include 



int main(){

unsigned a[8] = {0xu, 0xu, 0xu, 0xu,

0xDEADBEAFu, 0xFAAAu, 0xDEADBEAFu, 0xFAAAu};

unsigned b[8];



__m256i x = _mm256_load_si256((__m256i*)a);

_mm256_store_si256((__m256i*)b, x);

}



when compiled with 



g++ -mavx mini.cpp -o mini && ./mini



The output of g++ -S is



.file"mini.cpp"

.text

.globlmain

.typemain, @function

main:

.LFB707:

.cfi_startproc

pushq%rbp

.cfi_def_cfa_offset 16

.cfi_offset 6, -16

movq%rsp, %rbp

.cfi_def_cfa_register 6

andq$-32, %rsp

subq$40, %rsp

movl$572662306, -40(%rsp)

movl$-1431655766, -36(%rsp)

movl$286331153, -32(%rsp)

movl$858993459, -28(%rsp)

movl$-559038801, -24(%rsp)

movl$-89478486, -20(%rsp)

movl$-559038801, -16(%rsp)

movl$-89478486, -12(%rsp)

leaq-40(%rsp), %rax

movq%rax, 24(%rsp)

movq24(%rsp), %rax

vmovdqa(%rax), %ymm0

vmovdqa%ymm0, -120(%rsp)

leaq-8(%rsp), %rax

movq%rax, 32(%rsp)

vmovdqa-120(%rsp), %ymm0

vmovdqa%ymm0, -88(%rsp)

movq32(%rsp), %rax

vmovdqa-88(%rsp), %ymm0

vmovdqa%ymm0, (%rax)

movl$0, %eax

leave

.cfi_def_cfa 7, 8

ret

.cfi_endproc

.LFE707:

.sizemain, .-main

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

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









My GCC version is: g++ (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3

[Bug middle-end/52996] [4.8 Regression] ice in verify_loop_structure, at cfgloop.c:1567

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 Status|RESOLVED|REOPENED

 CC||jakub at gcc dot gnu.org

 Resolution|FIXED   |



--- Comment #8 from Jakub Jelinek  2012-12-21 
12:31:47 UTC ---

The testcase fails on i686-linux:

/usr/src/gcc/obj479/gcc/xgcc -B/usr/src/gcc/obj479/gcc/

/usr/src/gcc/gcc/testsuite/gcc.dg/torture/pr52996.c -fno-diagnostics-show-caret

-O2 -funswitch-loops -S -o pr52996.s

/usr/src/gcc/gcc/testsuite/gcc.dg/torture/pr52996.c: In function 'fn1':

/usr/src/gcc/gcc/testsuite/gcc.dg/torture/pr52996.c:32:1: error: edge from 18

to 19 should be marked irreducible

/usr/src/gcc/gcc/testsuite/gcc.dg/torture/pr52996.c:32:1: error: basic block 19

should be marked irreducible

/usr/src/gcc/gcc/testsuite/gcc.dg/torture/pr52996.c:32:1: error: edge from 19

to 8 should be marked irreducible

/usr/src/gcc/gcc/testsuite/gcc.dg/torture/pr52996.c:32:1: internal compiler

error: in verify_loop_structure, at cfgloop.c:1582

0x82eec96 verify_loop_structure()

../../gcc/cfgloop.c:1582

0x856db5d unswitch_loops()

../../gcc/loop-unswitch.c:151

0x8558640 rtl_unswitch

../../gcc/loop-init.c:336

Please submit a full bug report,

with preprocessed source if appropriate.

Please include the complete backtrace with any bug report.

See  for instructions.



FAIL: gcc.dg/torture/pr52996.c  -O2  (internal compiler error)

FAIL: gcc.dg/torture/pr52996.c  -O2  (test for excess errors)

FAIL: gcc.dg/torture/pr52996.c  -O3 -fomit-frame-pointer  (internal compiler

error)

FAIL: gcc.dg/torture/pr52996.c  -O3 -fomit-frame-pointer  (test for excess

errors)

FAIL: gcc.dg/torture/pr52996.c  -O3 -fomit-frame-pointer -funroll-loops 

(internal compiler error)

FAIL: gcc.dg/torture/pr52996.c  -O3 -fomit-frame-pointer -funroll-loops  (test

for excess errors)

FAIL: gcc.dg/torture/pr52996.c  -O3 -fomit-frame-pointer -funroll-all-loops

-finline-functions  (internal compiler error)

FAIL: gcc.dg/torture/pr52996.c  -O3 -fomit-frame-pointer -funroll-all-loops

-finline-functions  (test for excess errors)

FAIL: gcc.dg/torture/pr52996.c  -O3 -g  (internal compiler error)

FAIL: gcc.dg/torture/pr52996.c  -O3 -g  (test for excess errors)

FAIL: gcc.dg/torture/pr52996.c  -O2 -flto -flto-partition=none  (internal

compiler error)

FAIL: gcc.dg/torture/pr52996.c  -O2 -flto -flto-partition=none  (test for

excess errors)

FAIL: gcc.dg/torture/pr52996.c  -O2 -flto  (internal compiler error)

FAIL: gcc.dg/torture/pr52996.c  -O2 -flto  (test for excess errors)

[Bug tree-optimization/55334] [4.8 Regression] mgrid regression (ipa-cp disables vectorization)

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 Status|ASSIGNED|NEW

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

   ||gnu.org



--- Comment #16 from Richard Biener  2012-12-21 
12:25:35 UTC ---

Nothing to fix for me - it's the IPA-CP decision that pessimizes things.

[Bug rtl-optimization/55006] [4.8 Regression] aermod.f90 is miscompiled with '-m64 -O2 -funroll-loops' after revision 192526

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 Status|ASSIGNED|RESOLVED

 Resolution||FIXED



--- Comment #16 from Richard Biener  2012-12-21 
12:18:50 UTC ---

This bug has been hijacked multiple times for related stuff it seems.  In

particular aermod works for me on x86_64 now.



Please re-open if the original bug (see $summary) still persists.  Please

open new bugreports for everything else.  Thanks.

[Bug bootstrap/54926] [4.8 Regression] Bootstrap comparison failure for various files in libbacktrace

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 Status|WAITING |RESOLVED

 Resolution||FIXED



--- Comment #14 from Richard Biener  2012-12-21 
12:15:14 UTC ---

I suppose the bootstrap miscompare is fixed.

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

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



   Priority|P3  |P4

[Bug middle-end/54843] [4.8 Regression] ada bootstrap failure on arm-linux-gnueabi

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||FIXED



--- Comment #3 from Richard Biener  2012-12-21 
12:12:49 UTC ---

I suppose this is fixed.  If not please make it reproducible with a cross.

[Bug libstdc++/50160] vector comparison very slow (no overload)

[muhammadali.ca4 at gmail dot com]

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

--- Comment #35 from albcl111  2012-12-21 
11:58:37 UTC ---
Well said….positively enjoying each little bit of it and I have you bookmarked
to check out new stuff you weblog
airlinesplanet
http://www.airlinesplanet.com/

[Bug bootstrap/54659] [4.8 Regression] Bootstrap with --disable-nls broken under Windows

[ebotcazou at gcc dot gnu.org]

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



--- Comment #9 from Eric Botcazou  2012-12-21 
11:57:41 UTC ---

> but of course even better would be to fix the reason for this hack - why

> are those Ada files built with a C++ compiler in the first place?!



Probably because it would be too complex to invoke 2 compilers in the Makefile.

But nobody tried if I recall correctly and volunteers are always welcome.



> Why does it need to wrap _everything_ inside extern "C"??



See prefix.h: because the foreign language interface of the Ada part is

hardcoded for the C language.  This cannot really be changed for the time

being, but if the directives are misplaced, feel free to move them around.

[Bug bootstrap/54659] [4.8 Regression] Bootstrap with --disable-nls broken under Windows

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 Status|UNCONFIRMED |ASSIGNED

   Last reconfirmed||2012-12-21

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

   |gnu.org |

 Ever Confirmed|0   |1



--- Comment #8 from Richard Biener  2012-12-21 
11:42:21 UTC ---

Created attachment 29020

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

patch



Thus, try this patch.  Does it fix the windows issue with --disable-nls?



(do you need to revert the original --disable-nls fix?)

[Bug bootstrap/54659] [4.8 Regression] Bootstrap with --disable-nls broken under Windows

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 CC||ebotcazou at gcc dot

   ||gnu.org



--- Comment #7 from Richard Biener  2012-12-21 
11:35:46 UTC ---

(In reply to comment #4)

> On Fri, 26 Oct 2012, dnovillo at google dot com wrote:

> 

> > 

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

> > 

> > --- Comment #3 from dnovillo at google dot com  
> > 2012-10-26 12:34:53 UTC ---

> > On Fri, Oct 26, 2012 at 8:05 AM, rguenther at suse dot de

> >  wrote:

> > 

> > > Fact is that all this stuff happens because gmp.h is not included

> > > from system.h ...

> > 

> > I broke Ada when I tried it.  I don't remember the details, but it

> > seemed tedious to fix.

> 

> I know ... but it's the only way that is designed to avoid this

> kind of issues.



Trying to see what happens ...



The issue is r176210 wrapping everything in



#ifdef __cplusplus

extern "C" {

#endif



...



#ifdef __cplusplus

}

#endif



_including_ #include statements, including the inclusion of system.h.



That of course is totally bogus.



What it wants is to make sure exports have C linkage (I assume).



A fix is to undo this ... like with the following hack:



Index: gcc/system.h

===

--- gcc/system.h(revision 194658)

+++ gcc/system.h(working copy)

@@ -24,6 +24,11 @@ along with GCC; see the file COPYING3.

 #ifndef GCC_SYSTEM_H

 #define GCC_SYSTEM_H



+/* Undo extern "C" wrappings done by including files (Ada).  */

+#ifdef __cplusplus

+extern "C++" {

+#endif

+

 /* We must include stdarg.h before stdio.h.  */

 #include 



@@ -1051,4 +1056,8 @@ helper_const_non_const_cast (const char

 #define DEBUG_VARIABLE

 #endif



+#ifdef __cplusplus

+}

+#endif

+

 #endif /* ! GCC_SYSTEM_H */



but of course even better would be to fix the reason for this hack - why

are those Ada files built with a C++ compiler in the first place?!  Why

does it need to wrap _everything_ inside extern "C"??



Ada people?

[Bug fortran/55765] Remaining issues with unlimited polymorphic (CLASS(*))

[burnus at gcc dot gnu.org]

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



Tobias Burnus  changed:



   What|Removed |Added



 CC||burnus at gcc dot gnu.org



--- Comment #1 from Tobias Burnus  2012-12-21 
10:52:51 UTC ---

One probably should audit all calls to gfc_find_derived_vtab whether also

CLASS(*) could occur in that context; e.g. TRANSFER comes into my mind.

[Bug c++/55773] C++ class object destructors are not called which a static class object in destructor function in a shared library after dlclose is called.

[redi at gcc dot gnu.org]

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



Jonathan Wakely  changed:



   What|Removed |Added



 Status|UNCONFIRMED |WAITING

   Last reconfirmed||2012-12-21

 Ever Confirmed|0   |1



--- Comment #1 from Jonathan Wakely  2012-12-21 
10:47:54 UTC ---

GCC 4.1.2 is very old and has not been maintained for years, please try to

reproduce this with a current version of GCC.

[Bug c++/55773] New: C++ class object destructors are not called which a static class object in destructor function in a shared library after dlclose is called.

[liuhc001 at gmail dot com]

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

 Bug #: 55773
   Summary: C++ class object destructors are not called which a
static class object in destructor function in a shared
library after dlclose is called.
Classification: Unclassified
   Product: gcc
   Version: 4.1.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: liuhc...@gmail.com


there is a core dump when there is a static class object in
__attribute__((destructor)) function in a shared library after dlclose the
shared library. 
ps: it is a local static class object, not a global static class object. global
static class object seem not cause the problem.

Sample code:
// -
// File main.c
// -
#include 
#include 
#include 

int main()
{
void * hd = dlopen("./so.so", RTLD_NOW);
printf("start\n");
void (*p)() = dlsym(hd,"foo");
p();
dlclose(hd);
printf("end\n");
return 0;
}

// -
// File class.h
// -
#include 
#include 

class Base
{
public:
Base()
{
printf("constructor\n");
}
~Base()
{
printf("destructor\n");
}
private:
};

// -
// File so.c
// -
#include "class.h"
extern "C" void foo()
{
//static Base a; 
}
static void __attribute__((destructor)) enddll( void)
{
static Base a;
}

// --
// compile line in linux
// --
g++ -fpic -shared so.c -o so.so
gcc main.c -ldl

// --
// the result of running 
// --
start
constructor
end
セグメンテーション違反です


i think the reason is that class' destructor be called after shared library be
close. the class' destructor is no in memory. and a core dump happen.

[Bug bootstrap/53866] [4.8 Regression] lto-bootstrap failed at -O3

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||WONTFIX



--- Comment #8 from Richard Biener  2012-12-21 
10:35:49 UTC ---

Please use --disable-werror for non-standard flags / build configs.  We can't

possibly fix all warnings that may appear when you enable random flags.

[Bug middle-end/52996] [4.8 Regression] ice in verify_loop_structure, at cfgloop.c:1567

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



   Keywords||ice-checking

 Status|ASSIGNED|RESOLVED

 Resolution||FIXED



--- Comment #7 from Richard Biener  2012-12-21 
10:33:31 UTC ---

Fixed for this testcase.

[Bug middle-end/52996] [4.8 Regression] ice in verify_loop_structure, at cfgloop.c:1567

[rguenth at gcc dot gnu.org]

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



--- Comment #6 from Richard Biener  2012-12-21 
10:32:51 UTC ---

Author: rguenth

Date: Fri Dec 21 10:32:43 2012

New Revision: 194659



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

Log:

2012-12-21  Richard Biener  



PR tree-optimization/52996

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



Added:

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

Modified:

trunk/gcc/testsuite/ChangeLog

[Bug target/52061] compiler internal error in extract_insn

[jpflori at gmail dot com]

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



Jean-Pierre Flori  changed:



   What|Removed |Added



 CC||jpflori at gmail dot com



--- Comment #1 from Jean-Pierre Flori  2012-12-21 
10:32:10 UTC ---

I can confirm this also happens on the current Cygwin distribution with GCC

4.6.3 bootstrapped with the Cygwin GCC 4.5.3 distributed in the gcc4 package.



I'm trying to build GCC 4.7.2 to see whether the bug is still present there.

[Bug middle-end/52996] [4.8 Regression] ice in verify_loop_structure, at cfgloop.c:1567

[rguenth at gcc dot gnu.org]

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



--- Comment #5 from Richard Biener  2012-12-21 
10:30:54 UTC ---

It no longer reproduces for me ... we no longer unswitch.  But the issue

is certainly latent.

[Bug java/55764] [4.8 Regression] ICE when building frysk

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



   Target Milestone|--- |4.8.0

[Bug tree-optimization/55770] when compiling code with -fwhole-program and -fipa-matrix-reorg,compiler will produce wrong code

[rguenth at gcc dot gnu.org]

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



--- Comment #2 from Richard Biener  2012-12-21 
10:12:24 UTC ---

Yeah, it's very broken - don't use it.

[Bug c/55771] Negation and type conversion incorrectly exchanged

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||INVALID



--- Comment #5 from Richard Biener  2012-12-21 
10:10:38 UTC ---

Yes, this is invalid.

[Bug rtl-optimization/55161] internal compiler error: in schedule_reg_moves, at modulo-sched.c:731

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||FIXED



--- Comment #3 from Richard Biener  2012-12-21 
10:07:50 UTC ---

Fixed.