[Bug bootstrap/51860] [4.7 regression] s390 esa mode bootstrap comparison failure since transactional memory branch merge

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  2012-01-16 
07:17:58 UTC ---
Created attachment 26336
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26336
patch

I believe the problem is that INSN_ADDRESSES of the CALL_INSN is different from
INSN_ADDRESSES of the NOTE_INSN_CALL_ARG_LOCATION that follows it (which is
equal to the next insn).
Will look at this in more detail shortly.

[Bug target/42523] Detection of main() as an entry point when given -ffreestanding

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #2 from Andrew Pinski  2012-01-16 
04:46:44 UTC ---
(In reply to comment #1)
> Related to PR 16470 which mentions this is basically invalid.

woops wrong bug report.  The one I was trying to point to is PR 15037 .  Also
linux can never be a freestanding env so closing this as invalid.

[Bug target/42523] Detection of main() as an entry point when given -ffreestanding

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  2012-01-16 
04:44:59 UTC ---
Related to PR 16470 which mentions this is basically invalid.

[Bug libgcj/51498] make dejagnu work in libjava testsuite with cross-build

[jojelino at gmail dot com]

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

gee  changed:

   What|Removed |Added

Summary|temporary hack to make  |make dejagnu work in
   |dejagnu work in libjava |libjava testsuite with
   ||cross-build

--- Comment #9 from gee  2012-01-16 03:31:27 UTC ---
we need not this patch unless there is difference between host and target
alias.
this patch dealt with such case.

[Bug lto/50616] lto1.exe: internal compiler error: invalid resolution in the resolution file

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Target|i686-pc-mingw32 |
 Status|WAITING |NEW
  Component|target  |lto
  Build|i686-pc-mingw32 |

--- Comment #7 from Andrew Pinski  2012-01-16 
02:52:29 UTC ---
This is a host side issue really.  Anyways we should use uin64_t with PRIx64 so
it is more portable.

[Bug libstdc++/51866] [c++0x][4.7 Regression] unordered_multiset compares moved-out values

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2012-01-16
 CC|fdumont at gcc dot gnu.org  |
 AssignedTo|unassigned at gcc dot   |fdumont at gcc dot gnu.org
   |gnu.org |
   Target Milestone|--- |4.7.0
 Ever Confirmed|0   |1

[Bug libstdc++/51866] [c++0x][4.7 Regression] unordered_multiset compares moved-out values

[paolo.carlini at oracle dot com]

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

--- Comment #3 from Paolo Carlini  2012-01-16 
01:52:47 UTC ---
If we are lucky, this issue is even the same as 51845. Thanks for the neat
testcase.

[Bug libstdc++/51866] [c++0x][4.7 Regression] unordered_multiset compares moved-out values

[roman at binarylife dot net]

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

--- Comment #2 from Roman Kononov  2012-01-16 
01:50:37 UTC ---
it is been bisected...
r183180 is bad
r170936 is good

[Bug target/50616] lto1.exe: internal compiler error: invalid resolution in the resolution file

[i.nixman at gmail dot com]

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

--- Comment #6 from niXman  2012-01-16 01:43:56 UTC 
---
Replacing "%llx" to "%I64x" solves the problem.

http://msdn.microsoft.com/en-us/library/3b2e7499(v=vs.80).aspx

Thanks, niXman.

[Bug libstdc++/51866] [c++0x][4.7 Regression] unordered_set compares moved-out values

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||fdumont at gcc dot gnu.org

--- Comment #1 from Paolo Carlini  2012-01-16 
01:39:55 UTC ---
Please provide details about the specific Rev, thanks.

[Bug libstdc++/51866] New: [c++0x][4.7 Regression] unordered_set compares moved-out values

[roman at binarylife dot net]

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

 Bug #: 51866
   Summary: [c++0x][4.7 Regression] unordered_set compares
moved-out values
Classification: Unclassified
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ro...@binarylife.net


$ cat test.cpp 
#include 
#include 
#include 

struct num {
  int value;
  num(int n) : value(n) {}
  num(num const&)= default;
  num& operator=(num const&) = default;
  num(num&& o)   : value(o.value) { o.value=-1; }
  num& operator=(num&& o){ if (this!=&o) { value=o.value; o.value=-1; }
return *this; }
};

struct num_hash {
  size_t operator()(num const& a)const {
if (a.value<0) std::cout<<"hash of moved value"<

[Bug bootstrap/51860] [4.7 regression] s390 esa mode bootstrap comparison failure since transactional memory branch merge

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  2012-01-16 
00:06:26 UTC ---
Created attachment 26335
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26335
pr51860.ii

Partly reduced testcase.
g++ -O2 -mesa -fcompare-debug pr51860.ii
Unfortunately, delta is quite slow to reduce it even further than this (most
probably because it depends on the inter insn distances to hit the literal pool
insertion at the exact spot).

[Bug fortran/51864] [OOP] ALLOCATE with polymorphic array constructor as SOURCE=

[burnus at gcc dot gnu.org]

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

--- Comment #1 from Tobias Burnus  2012-01-15 
23:25:55 UTC ---
(In reply to comment #0)
> class(t), allocatable :: a(:), b(:), c(:)
> allocate(t2 :: a(3))
> allocate(t2 :: b(5))
> allocate(c(8), source=[ a, b ])

Actually, this part of the program is invalid as Fortran 2008 demands (4.8
Construction of array values):

"The dynamic type of an array constructor is the same as its declared type."

Thus, one can use
 [ a, b ]
but only if both are of the declared and dynamic type "t", cf.

"If type-spec is omitted, each ac-value expression in the array constructor
shall have the same length type parameters; in this case, the declared type and
type parameters of the array constructor are those of the ac-value
expressions."

However, one is still allowed to use:

 [ t2 :: a, b]

in that case, "a" and "b" need to have a declared type "t2" or an extension of
"t2" as declared type - and can have any dynamic type.

"If type-spec appears, it specifies the declared type and type parameters of
the array constructor. Each ac-value expression in the array-constructor shall
be compatible with intrinsic assignment to a variable of this type and type
parameters. Each value is converted to the type parameters of the
array-constructor in accordance with the rules of intrinsic assignment
(7.2.1.3)."

And in 4.3.1.3 CLASS, one finds "type compatible" defined as:

"A polymorphic entity that is not an unlimited polymorphic entity is type
compatible with entities of the same declared type or any of its extensions.
Even though an unlimited polymorphic entity is not considered to have a
declared type, it is type compatible with all entities. An entity is type
compatible with a type if it is type compatible with entities of that type."

[Bug libstdc++/51845] [4.7 regression] 23_containers/unordered_multimap/erase/24061-multimap.cc segfault

[paolo.carlini at oracle dot com]

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

--- Comment #16 from Paolo Carlini  2012-01-15 
23:18:49 UTC ---
I don't think we need a separate PR, for now.

And, on an unrelated note, I'm pretty sure something should show up relatively
easily under Valgrind too even on x86_64-Linux, even -m64 where the testsuite
is clean, something seems plain wrong with memory use.

[Bug c++/40127] Fails to identify template function with default args

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  2012-01-15 
23:16:53 UTC ---
(In reply to comment #0)
> I'm not sure whether argument types can be bound from default arguments in the
> standard,

They can't.

> but if they can't then I should get a diagnostic at the declaration
> of the template.

As Andrew showed, the template isn't invalid and can be called with an explicit
template argument list, so issuing a diagnostic at declaration would be wrong.

> The actual message is cryptic and unhelpful.

Current versions give a great diagnostic:

c.cc: In function ‘int main()’:
c.cc:4:14: error: no matching function for call to ‘foo(int)’
c.cc:4:14: note: candidate is:
c.cc:2:9: note: template void foo(int, void (*)(T*), T*)
c.cc:2:9: note:   template argument deduction/substitution failed:
c.cc:4:14: note:   couldn't deduce template parameter ‘T’

[Bug other/51678] 'make pdf' is broken in libiberty

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||patch
 Status|UNCONFIRMED |NEW
URL||http://gcc.gnu.org/bugzilla
   ||/show_bug.cgi?id=51678
   Last reconfirmed||2012-01-15
 Ever Confirmed|0   |1

--- Comment #2 from Andrew Pinski  2012-01-15 
22:42:31 UTC ---
Confirmed.

[Bug libstdc++/51845] [4.7 regression] 23_containers/unordered_multimap/erase/24061-multimap.cc segfault

[dominiq at lps dot ens.fr]

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

--- Comment #15 from Dominique d'Humieres  
2012-01-15 21:46:37 UTC ---
Between revisions 183030 and 183181,
23_containers/unordered_multiset/erase/24061-multiset.cc has also started to
fail in a similar manner (see
http://gcc.gnu.org/ml/gcc-testresults/2012-01/msg01438.html ):

[karma] libstdc++-v3/testsuite% ./24061-multiset.exe
Assertion failed: (get_nb_bucket_elems(ms1) == ms1.size()), function test01,
file
/opt/gcc/work/libstdc++-v3/testsuite/23_containers/unordered_multiset/erase/24061-multiset.cc,
line 87.
Abort

Should I open another PR for it or is it a kind of duplicate?

[Bug libstdc++/51845] [4.7 regression] 23_containers/unordered_multimap/erase/24061-multimap.cc segfault

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

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

--- Comment #14 from Andreas Schwab  2012-01-15 21:23:06 
UTC ---
The valgrind log refers to the latest version.

[Bug libstdc++/51845] [4.7 regression] 23_containers/unordered_multimap/erase/24061-multimap.cc segfault

[fdumont at gcc dot gnu.org]

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

--- Comment #13 from François Dumont  2012-01-15 
21:13:59 UTC ---
I will have a try with Valgrin but line numbers in the comments here do not
seem to all match the latest hashtable code commited on trunk in revision
183164. This last commit really simplify the code and made the data model more
consistent, it might have fix something. If you could have a try with this
version it would help.

Thanks

[Bug bootstrap/51860] [4.7 regression] s390 esa mode bootstrap comparison failure since transactional memory branch merge

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  2012-01-15 
21:01:23 UTC ---
Well, DEBUG_INSNs aren't in the stream during the reorg anymore, it is about
the NOTE_INSN_VAR_LOCATION and NOTE_INSN_CALL_ARG_LOCATION (apparently the
latter in this testcase) in the stream that make the chunkify code insert it at
different spots.

[Bug rtl-optimization/51821] [4.5/4.6/4.7 Regression] 64bit > 32bit conversion produces incorrect results with optimizations

[ubizjak at gmail dot com]

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

Uros Bizjak  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work|4.4.6   |
 Resolution||FIXED

--- Comment #22 from Uros Bizjak  2012-01-15 20:44:29 
UTC ---
Fixed for 4.4+.

[Bug rtl-optimization/51821] [4.5/4.6/4.7 Regression] 64bit > 32bit conversion produces incorrect results with optimizations

[uros at gcc dot gnu.org]

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

--- Comment #21 from uros at gcc dot gnu.org 2012-01-15 20:38:39 UTC ---
Author: uros
Date: Sun Jan 15 20:38:32 2012
New Revision: 183200

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183200
Log:
PR rtl-optimization/51821
* recog.c (peep2_find_free_register): Determine clobbered registers
from insn pattern.

testsuite/ChangeLog:

PR rtl-optimization/51821
* gcc.dg/pr51821.c: New test.


Added:
branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/pr51821.c
Modified:
branches/gcc-4_4-branch/gcc/ChangeLog
branches/gcc-4_4-branch/gcc/recog.c
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog

[Bug bootstrap/51860] [4.7 regression] s390 esa mode bootstrap comparison failure since transactional memory branch merge

[krebbel at gcc dot gnu.org]

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

--- Comment #3 from Andreas Krebbel  2012-01-15 
20:37:02 UTC ---
(In reply to comment #2)
> Reducing a -fcompare-debug failure on c-common.c with delta.

Thanks for working on this! I already had a quick look. The problem has to do
with the s390 reorg pass having to split the literal pool. The jump over the
literal pool is placed differently with and without debug info.

There are several places where we still use NEXT_INSN or INSN_P what will be
affected by DEBUG_INSNs being present. I'll track this down tomorrow.

no debug info:

L33: 
0x4ff9fc  basrr13, r0 
0x4ff9fe  la  r13, 14(r13)
0x4ffa02  basrr14, r12
0x4ffa04  basrr14, r11
0x4ffa06  j   L34 

0x4ffa0a  noprr7  
L34: 
0x4ffb60  lhi r1, 0
0x4ffb64  icm r1, 3, 0(r2)  

with debug info:

L33: 
0x4ff9fc  basrr13, r0 
0x4ff9fe  la  r13, 18(r13)
0x4ffa02  basrr14, r12
0x4ffa04  basrr14, r11
0x4ffa06  lhi r1, 0   
0x4ffa0a  j   L34 

0x4ffa0e  noprr7  
L34: 
0x4ffb64  icm r1, 3, 0(r2)

[Bug rtl-optimization/51821] [4.5/4.6/4.7 Regression] 64bit > 32bit conversion produces incorrect results with optimizations

[uros at gcc dot gnu.org]

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

--- Comment #20 from uros at gcc dot gnu.org 2012-01-15 20:27:22 UTC ---
Author: uros
Date: Sun Jan 15 20:27:17 2012
New Revision: 183199

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183199
Log:
PR rtl-optimization/51821
* recog.c (peep2_find_free_register): Determine clobbered registers
from insn pattern.

testsuite/ChangeLog:

PR rtl-optimization/51821
* gcc.dg/pr51821.c: New test.


Added:
branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/pr51821.c
Modified:
branches/gcc-4_5-branch/gcc/ChangeLog
branches/gcc-4_5-branch/gcc/recog.c
branches/gcc-4_5-branch/gcc/testsuite/ChangeLog

[Bug bootstrap/51860] [4.7 regression] s390 esa mode bootstrap comparison failure since transactional memory branch merge

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  2012-01-15 
20:25:20 UTC ---
Reducing a -fcompare-debug failure on c-common.c with delta.

[Bug c++/40127] Fails to identify template function with default args

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #1 from Andrew Pinski  2012-01-15 
20:01:35 UTC ---
This code is invalid (and other compilers agree with me).  What type is going
to be chosen for T?  void*, int*, any pointer type?  There is no way the
compiler can deduce the type of T from the arguments.

This code is valid though:
template
voidfoo(int i, void(*f)(T*) = 0, T* a = 0) {}
int  main() {
foo(5);
return 0;
}

AS the compiler does not need to deduce the template argument type.

[Bug fortran/51616] [4.7 Regression] gfortran.dg/quad_2.f90 fails on hppa*-*-hpux*

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #10 from Tobias Burnus  2012-01-15 
19:46:55 UTC ---
(In reply to comment #0)
> Executing on host: [...] hppa2.0w-hp-hpux11.11/./libgfortran/
> FAIL: gfortran.dg/quad_2.f90  -O0  (test for excess errors)

http://gcc.gnu.org/ml/gcc-testresults/2012-01/msg01427.html shows that
4.7.0 20120113 (experimental) [trunk revision 183162] (GCC) testsuite
on hppa64-hp-hpux11.11  has no gfortran failures.

While that's not on hppa2.0 as in the the original report (comment 0), also
happa64 showed the failure, cf.
http://gcc.gnu.org/ml/gcc-testresults/2012-01/msg01078.html

Thus: Closed as fixed. Feel free to reopen if it shows up on hppa2.0.

Thanks again for the report.

[Bug rtl-optimization/51821] [4.5/4.6/4.7 Regression] 64bit > 32bit conversion produces incorrect results with optimizations

[uros at gcc dot gnu.org]

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

--- Comment #19 from uros at gcc dot gnu.org 2012-01-15 19:35:20 UTC ---
Author: uros
Date: Sun Jan 15 19:35:15 2012
New Revision: 183198

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183198
Log:
PR rtl-optimization/51821
* recog.c (peep2_find_free_register): Determine clobbered registers
from insn pattern.

testsuite/ChangeLog:

PR rtl-optimization/51821
* gcc.dg/pr51821.c: New test.


Added:
branches/gcc-4_6-branch/gcc/testsuite/gcc.dg/pr51821.c
Modified:
branches/gcc-4_6-branch/gcc/ChangeLog
branches/gcc-4_6-branch/gcc/recog.c
branches/gcc-4_6-branch/gcc/testsuite/ChangeLog

[Bug debug/7853] gcc reports multiple symbol definitions on the wrong line

[owner at bugs dot debian.org]

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

--- Comment #19 from owner at bugs dot debian.org 2012-01-15 19:27:22 UTC ---
Thank you for the additional information you have supplied regarding
this Bug report.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 Debian GCC Maintainers 

If you wish to submit further information on this problem, please
send it to 159...@bugs.debian.org.

Please do not send mail to ow...@bugs.debian.org unless you wish
to report a problem with the Bug-tracking system.

[Bug debug/7853] gcc reports multiple symbol definitions on the wrong line

[owner at bugs dot debian.org]

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

--- Comment #18 from owner at bugs dot debian.org 2012-01-15 19:24:18 UTC ---
Thank you for the additional information you have supplied regarding
this Bug report.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 Debian GCC Maintainers 

If you wish to submit further information on this problem, please
send it to 159...@bugs.debian.org.

Please do not send mail to ow...@bugs.debian.org unless you wish
to report a problem with the Bug-tracking system.

[Bug debug/7853] gcc reports multiple symbol definitions on the wrong line

[owner at bugs dot debian.org]

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

--- Comment #17 from owner at bugs dot debian.org 2012-01-15 19:21:20 UTC ---
Thank you for the additional information you have supplied regarding
this Bug report.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 Debian GCC Maintainers 

If you wish to submit further information on this problem, please
send it to 159...@bugs.debian.org.

Please do not send mail to ow...@bugs.debian.org unless you wish
to report a problem with the Bug-tracking system.

[Bug other/47733] psignal (int, const? char*) in libiberty/strsignal.h

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||kilobyte at angband dot pl

--- Comment #9 from Andrew Pinski  2012-01-15 
19:18:32 UTC ---
*** Bug 41916 has been marked as a duplicate of this bug. ***

[Bug target/41916] psignal() declaration needs const char*

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE

--- Comment #2 from Andrew Pinski  2012-01-15 
19:18:32 UTC ---
Dup of bug 47733.

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

[Bug debug/7853] gcc reports multiple symbol definitions on the wrong line

[owner at bugs dot debian.org]

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

--- Comment #16 from owner at bugs dot debian.org 2012-01-15 19:18:17 UTC ---
Thank you for the additional information you have supplied regarding
this Bug report.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 Debian GCC Maintainers 

If you wish to submit further information on this problem, please
send it to 159...@bugs.debian.org.

Please do not send mail to ow...@bugs.debian.org unless you wish
to report a problem with the Bug-tracking system.

[Bug debug/7853] gcc reports multiple symbol definitions on the wrong line

[owner at bugs dot debian.org]

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

--- Comment #15 from owner at bugs dot debian.org 2012-01-15 19:15:17 UTC ---
Thank you for the additional information you have supplied regarding
this Bug report.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 Debian GCC Maintainers 

If you wish to submit further information on this problem, please
send it to 159...@bugs.debian.org.

Please do not send mail to ow...@bugs.debian.org unless you wish
to report a problem with the Bug-tracking system.

[Bug debug/7853] gcc reports multiple symbol definitions on the wrong line

[owner at bugs dot debian.org]

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

--- Comment #14 from owner at bugs dot debian.org 2012-01-15 19:12:17 UTC ---
Thank you for the additional information you have supplied regarding
this Bug report.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 Debian GCC Maintainers 

If you wish to submit further information on this problem, please
send it to 159...@bugs.debian.org.

Please do not send mail to ow...@bugs.debian.org unless you wish
to report a problem with the Bug-tracking system.

[Bug tree-optimization/51865] [4.7 Regression] ICE in insert_vi_for_tree, at tree-ssa-structalias.c:2642

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 AssignedTo|unassigned at gcc dot   |jakub at gcc dot gnu.org
   |gnu.org |

--- Comment #7 from Jakub Jelinek  2012-01-15 
19:11:55 UTC ---
Created attachment 26334
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26334
gcc47-pr51865.patch

Untested fix.  If DECL_RESULT has void type, it must have remap_decl called on
it, otherwise we share the same RESULT_DECL between multiple functions.

[Bug debug/7853] gcc reports multiple symbol definitions on the wrong line

[owner at bugs dot debian.org]

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

--- Comment #13 from owner at bugs dot debian.org 2012-01-15 19:09:18 UTC ---
Thank you for the additional information you have supplied regarding
this Bug report.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 Debian GCC Maintainers 

If you wish to submit further information on this problem, please
send it to 159...@bugs.debian.org.

Please do not send mail to ow...@bugs.debian.org unless you wish
to report a problem with the Bug-tracking system.

[Bug debug/7853] gcc reports multiple symbol definitions on the wrong line

[owner at bugs dot debian.org]

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

--- Comment #12 from owner at bugs dot debian.org 2012-01-15 19:06:18 UTC ---
Thank you for the additional information you have supplied regarding
this Bug report.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 Debian GCC Maintainers 

If you wish to submit further information on this problem, please
send it to 159...@bugs.debian.org.

Please do not send mail to ow...@bugs.debian.org unless you wish
to report a problem with the Bug-tracking system.

[Bug target/22473] FAIL: gcc.c-torture/execute/conversion.c execution -O[012]

[danglin at gcc dot gnu.org]

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

John David Anglin  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID

--- Comment #6 from John David Anglin  2012-01-15 
19:04:53 UTC ---
Have kernel patch.

[Bug bootstrap/51860] [4.7 regression] s390 esa mode bootstrap comparison failure since transactional memory branch merge

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-01-15
 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |4.7.0
 Ever Confirmed|0   |1

--- Comment #1 from Jakub Jelinek  2012-01-15 
19:04:00 UTC ---
I can reproduce it with
CC='gcc -m31' CXX='g++ -m31' s390 ../configure --enable-languages=c,c++,fortran
--with-mode=esa

[Bug debug/7853] gcc reports multiple symbol definitions on the wrong line

[owner at bugs dot debian.org]

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

--- Comment #11 from owner at bugs dot debian.org 2012-01-15 19:03:24 UTC ---
Thank you for the additional information you have supplied regarding
this Bug report.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 Debian GCC Maintainers 

If you wish to submit further information on this problem, please
send it to 159...@bugs.debian.org.

Please do not send mail to ow...@bugs.debian.org unless you wish
to report a problem with the Bug-tracking system.

[Bug debug/7853] gcc reports multiple symbol definitions on the wrong line

[owner at bugs dot debian.org]

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

--- Comment #10 from owner at bugs dot debian.org 2012-01-15 19:00:19 UTC ---
Thank you for the additional information you have supplied regarding
this Bug report.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 Debian GCC Maintainers 

If you wish to submit further information on this problem, please
send it to 159...@bugs.debian.org.

Please do not send mail to ow...@bugs.debian.org unless you wish
to report a problem with the Bug-tracking system.

[Bug debug/7853] gcc reports multiple symbol definitions on the wrong line

[owner at bugs dot debian.org]

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

--- Comment #9 from owner at bugs dot debian.org 2012-01-15 18:57:20 UTC ---
Thank you for the additional information you have supplied regarding
this Bug report.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 Debian GCC Maintainers 

If you wish to submit further information on this problem, please
send it to 159...@bugs.debian.org.

Please do not send mail to ow...@bugs.debian.org unless you wish
to report a problem with the Bug-tracking system.

[Bug debug/7853] gcc reports multiple symbol definitions on the wrong line

[owner at bugs dot debian.org]

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

--- Comment #8 from owner at bugs dot debian.org 2012-01-15 18:51:20 UTC ---
Thank you for the additional information you have supplied regarding
this Bug report.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 Debian GCC Maintainers 

If you wish to submit further information on this problem, please
send it to 159...@bugs.debian.org.

Please do not send mail to ow...@bugs.debian.org unless you wish
to report a problem with the Bug-tracking system.

[Bug debug/7853] gcc reports multiple symbol definitions on the wrong line

[owner at bugs dot debian.org]

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

--- Comment #7 from owner at bugs dot debian.org 2012-01-15 18:48:17 UTC ---
Thank you for the additional information you have supplied regarding
this Bug report.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 Debian GCC Maintainers 

If you wish to submit further information on this problem, please
send it to 159...@bugs.debian.org.

Please do not send mail to ow...@bugs.debian.org unless you wish
to report a problem with the Bug-tracking system.

[Bug debug/7853] gcc reports multiple symbol definitions on the wrong line

[owner at bugs dot debian.org]

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

--- Comment #6 from owner at bugs dot debian.org 2012-01-15 18:45:25 UTC ---
Thank you for the additional information you have supplied regarding
this Bug report.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 Debian GCC Maintainers 

If you wish to submit further information on this problem, please
send it to 159...@bugs.debian.org.

Please do not send mail to ow...@bugs.debian.org unless you wish
to report a problem with the Bug-tracking system.

[Bug fortran/51569] documentation on sign intrinsic

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Resolution|FIXED   |WONTFIX

--- Comment #5 from kargl at gcc dot gnu.org 2012-01-15 18:04:04 UTC ---
Update the RESOLVED tag from FIXED to WONTFIX.

[Bug rtl-optimization/51821] [4.5/4.6/4.7 Regression] 64bit > 32bit conversion produces incorrect results with optimizations

[uros at gcc dot gnu.org]

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

--- Comment #18 from uros at gcc dot gnu.org 2012-01-15 18:03:51 UTC ---
Author: uros
Date: Sun Jan 15 18:03:46 2012
New Revision: 183194

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183194
Log:
PR rtl-optimization/51821
* recog.c (peep2_find_free_register): Determine clobbered registers
from insn pattern.

testsuite/ChangeLog:

PR rtl-optimization/51821
* gcc.dg/pr51821.c: New test.


Added:
trunk/gcc/testsuite/gcc.dg/pr51821.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/recog.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/51569] documentation on sign intrinsic

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #4 from kargl at gcc dot gnu.org 2012-01-15 18:03:05 UTC ---
(In reply to comment #0)
> The documentation of the sign intrinsic is a bit misleading when the B 
> argument
> is a signed zero. The explanation in the standard is much more clearer.
> 
> Currently it says
> (http://gcc.gnu.org/onlinedocs/gcc-4.6.2/gfortran/SIGN.html#SIGN):
> "If B\ge 0 then the result is ABS(A), else it is -ABS(A)."
> 
> According to the standard -0.0 is greater than zero. Meaning that according to
> the documentation I would expect:
> sign(1.0,-0.0) = 1.0
> which is not true.
> 
> I would replace the sentence above by what you can find in the standard:

The documentation as written is fine.  It seems that you
are reading 'B \ge 0' in gfortran's documentation as a 
Fortran expression instead of as a mathematical expression.
>From the point of view of mathematics if B = -0., then
B is less than 0.; otherwise, the foundations of calculus
would not apply when taking a limit of a function at 0.
Closing as WONTFIX.

[Bug fortran/51779] gcc 4.6.2 build fails on Mac OS X Lion w/Xcode 4.2, with gfortran erorr

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #12 from kargl at gcc dot gnu.org 2012-01-15 17:38:36 UTC ---
The audit trail indicates that this is not a gfortran.
Closing as INVALID.

[Bug tree-optimization/51865] [4.7 Regression] ICE in insert_vi_for_tree, at tree-ssa-structalias.c:2642

[steven at gcc dot gnu.org]

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

--- Comment #6 from Steven Bosscher  2012-01-15 
17:31:14 UTC ---
(In reply to comment #5)

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

That is the patch here:
http://gcc.gnu.org/ml/gcc-patches/2012-01/msg00510.html

So if someone comes up with a fix for this: Please also test with Ada enabled.

[Bug tree-optimization/51865] [4.7 Regression] ICE in insert_vi_for_tree, at tree-ssa-structalias.c:2642

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|--- |4.7.0

[Bug tree-optimization/51865] [4.7 Regression] ICE in insert_vi_for_tree, at tree-ssa-structalias.c:2642

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  2012-01-15 
17:22:03 UTC ---
/* { dg-do compile } */
/* { dg-options "-O2 -fipa-pta" } */

void fn (const char *, const char *) __attribute__ ((__noreturn__));
int var;

inline void
foo (void)
{
  if (__builtin_expect (var != 0, 0))
fn ("a", "b");
};

void
bar (void)
{
  foo ();
};

void
baz (void)
{
  foo ();
};

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

[Bug tree-optimization/51865] [4.7 Regression] ICE in insert_vi_for_tree, at tree-ssa-structalias.c:2642

[steven at gcc dot gnu.org]

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

Steven Bosscher  changed:

   What|Removed |Added

 CC||steven at gcc dot gnu.org

--- Comment #4 from Steven Bosscher  2012-01-15 
17:12:29 UTC ---
Confirmed also on x86_64-unknown-linux-gnu

[Bug libstdc++/51845] [4.7 regression] 23_containers/unordered_multimap/erase/24061-multimap.cc segfault

[krebbel at gcc dot gnu.org]

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

--- Comment #12 from Andreas Krebbel  2012-01-15 
17:00:42 UTC ---
(In reply to comment #8)
> But ElectricFence should work even on s390 31-bit.  Can you please try that?

I've linked libstdc++ against electric fence. The segfault appears to get
triggered somewhere else then.

gdb ./24061-multimap.exe 
GNU gdb (GDB) Fedora (7.2.50.20110206-18.fc13)
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "s390-redhat-linux-gnu".
For bug reporting instructions, please see:
...
Reading symbols from
/build/gcc-headnew-build/s390-ibm-linux-gnu/libstdc++-v3/testsuite/24061-multimap.exe...done.
(gdb) r
Starting program:
/build/gcc-headnew-build/s390-ibm-linux-gnu/libstdc++-v3/testsuite/24061-multimap.exe
 
[Thread debugging using libthread_db enabled]

  Electric Fence 2.1 Copyright (C) 1987-1998 Bruce Perens.

Program received signal SIGSEGV, Segmentation fault.
_M_get_previous_node (__n=0x77b95ff0, __bkt=10, this=)
at
/build/gcc-headnew-build/s390-ibm-linux-gnu/libstdc++-v3/include/bits/hashtable.h:1175
1175  while (__prev_n->_M_next != __n)
(gdb) bt
#0  _M_get_previous_node (__n=0x77b95ff0, __bkt=10, this=)
at
/build/gcc-headnew-build/s390-ibm-linux-gnu/libstdc++-v3/include/bits/hashtable.h:1175
#1  std::_Hashtable,
std::allocator >, std::pair, std::allocator > const, int>,
std::allocator,
std::allocator > const, int> >,
std::_Select1st,
std::allocator > const, int> >, std::equal_to, std::allocator > >,
std::hash, std::allocator
> >, std::__detail::_Mod_range_hashing, std::__detail::_Default_ranged_hash,
std::__detail::_Prime_rehash_policy, true, false, false>::erase
(this=0x7fffec14, __it=...)
at
/build/gcc-headnew-build/s390-ibm-linux-gnu/libstdc++-v3/include/bits/hashtable.h:1363
#2  0x0040244c in test01 ()
at
/build/gcc-headnew/libstdc++-v3/testsuite/23_containers/unordered_multimap/erase/24061-multimap.cc:81
#3  0x00400a14 in main ()
at
/build/gcc-headnew/libstdc++-v3/testsuite/23_containers/unordered_multimap/erase/24061-multimap.cc:106
(gdb)

[Bug tree-optimization/51865] [4.7 Regression] ICE in insert_vi_for_tree, at tree-ssa-structalias.c:2642

[dominiq at lps dot ens.fr]

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

--- Comment #3 from Dominique d'Humieres  2012-01-15 
16:09:20 UTC ---
Created attachment 26333
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26333
preprocessed testcase

> Please attach preprocessed testcase.

r183091 is OK
r183136 gives the ICE.

[Bug tree-optimization/51865] [4.7 Regression] ICE in insert_vi_for_tree, at tree-ssa-structalias.c:2642

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  2012-01-15 
15:30:58 UTC ---
Please attach preprocessed testcase.

[Bug libstdc++/50982] AIX libstdc++ GTHREADS incompatibility

[redi at gcc dot gnu.org]

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

--- Comment #53 from Jonathan Wakely  2012-01-15 
14:54:16 UTC ---
Then I'm confused - the tests should depend on availability of the same
features as the code, and the code is now compiled on AIX (as we know because
it was failing to build previously.)

If you email me the testsuite/libstdc++.log output I can look at that and have
another go at enabling the tests.

[Bug libstdc++/50982] AIX libstdc++ GTHREADS incompatibility

[dje at gcc dot gnu.org]

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

--- Comment #52 from David Edelsohn  2012-01-15 
14:29:28 UTC ---
I rebuilt with the libstdc++-v3 testsuite patch, but the 30_thread tests did
not run.

[Bug preprocessor/37215] ICE on 'gcc -E -dM -fpreprocessed - < /dev/null'

[patriciak784-gccmainling at yahoo dot de]

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

--- Comment #13 from patriciak784-gccmainling at yahoo dot de 2012-01-15 
14:27:00 UTC ---
(In reply to comment #12)
> On inspecting this more closely, I agree with patriciak784.  The issue isn't
> directly related to the fix of Richard for PR20239.
> 
> So I suggest patch for c-family/c-ppoutput.c as following:
> 
> Index: c-family/c-ppoutput.c
> ===
> --- c-family/c-ppoutput.c   (revision 183106)
> +++ c-family/c-ppoutput.c   (working copy)
> @@ -86,7 +86,7 @@
>  {
>/* A successful cpp_read_main_file guarantees that we can call
>   cpp_scan_nooutput or cpp_get_token next.  */
> -  if (flag_no_output)
> +  if (flag_no_output && pfile->buffer)
>  {
>/* Scan -included buffers, then the main file.  */
>while (pfile->buffer->prev)

I'd welcome if this patch was included in GCC.

[Bug tree-optimization/51865] [4.7 Regression] ICE in insert_vi_for_tree, at tree-ssa-structalias.c:2642

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-01-15
Summary|ICE in insert_vi_for_tree,  |[4.7 Regression] ICE in
   |at  |insert_vi_for_tree, at
   |tree-ssa-structalias.c:2642 |tree-ssa-structalias.c:2642
 Ever Confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  2012-01-15 
14:05:50 UTC ---
Confirmed on powerpc-apple-darwin9 and x86_64-apple-darwin10 with revision
183181. Revision 183001 is OK. The ICE is also triggered with '-O1
-finline-small-functions -finline-functions -fipa-pta -fpartial-inlining' up to
 '-O3 -fipa-pta'. If I set a break point for insert_vi_for_tree, I see it
called several time before reaching:


Breakpoint 1, insert_vi_for_tree (t=, vi=) at ../../work/gcc/tree-ssa-structalias.c:2639
2639{
(gdb) bt
#0  insert_vi_for_tree (t=, vi=) at
../../work/gcc/tree-ssa-structalias.c:2639
#1  0x0001008deb61 in ipa_pta_execute () at
../../work/gcc/tree-ssa-structalias.c:5343
#2  0x00010068d299 in execute_one_pass (pass=0x100da2120) at
../../work/gcc/passes.c:2081
#3  0x00010068db32 in execute_ipa_pass_list (pass=0x100da2120) at
../../work/gcc/passes.c:2448
#4  0x000100399c06 in cgraph_optimize () at
../../work/gcc/cgraphunit.c:2183
#5  0x00010039a90a in cgraph_finalize_compilation_unit () at
../../work/gcc/cgraphunit.c:1327
#6  0x000100020613 in c_write_global_declarations () at
../../work/gcc/c-decl.c:10030
#7  0x000100750640 in toplev_main (argc=4, argv=0x7fff5fbfd808) at
../../work/gcc/toplev.c:573
#8  0x000114d4 in start ()
(gdb) c
Continuing.

pr51865.c:6:1: internal compiler error: in insert_vi_for_tree, at
tree-ssa-structalias.c:2642
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Program exited with code 04.

[Bug c++/51706] default copy assignment incorrectly deleted

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #2 from Jonathan Wakely  2012-01-15 
14:04:58 UTC ---
Agreed.

[Bug tree-optimization/51865] New: ICE in insert_vi_for_tree, at tree-ssa-structalias.c:2642

[g...@denis-excoffier.org]

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

 Bug #: 51865
   Summary: ICE in insert_vi_for_tree, at
tree-ssa-structalias.c:2642
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: g...@denis-excoffier.org


Under MacOSX (x86_64-apple-darwin11.2.0), the new gcc-4.7-20120114 gives ICE
with the following. There was no problem with the preceding snapshots. I've
still not tested under other platforms.

% cat stc.c
// gcc -O -finline-small-functions -finline-functions -fipa-pta
-fpartial-inlining -c stc.c
#include 
void zz0(void);
static int xx0;
void zz0(void) { assert(xx0 == 0); return; };
void zz1(void) { zz0(); return; };
void zz2(void) { zz0(); return; };
%
% gcc -v -O -finline-small-functions  -finline-functions -fipa-pta
-fpartial-inlining -c stc.c
Using built-in specs.
COLLECT_GCC=/tmp/lcl/uxl/gcc/bin/gcc
COLLECT_LTO_WRAPPER=/Users/denis/darlcl/uxl/gcc-4.7-20120114/bin/../libexec/gcc/x86_64-apple-darwin11.2.0/4.7.0/lto-wrapper
Target: x86_64-apple-darwin11.2.0
Configured with: /tmp/lcl/tmp/gcc/gcc-4.7-20120114/configure
--prefix=/tmp/lcl/uxl/gcc-4.7-20120114 --with-local-prefix=/usr/local/here
--enable-languages=c,c++ --disable-multilib
Thread model: posix
gcc version 4.7.0 20120114 (experimental) (GCC) 
COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.7.2' '-O'
'-finline-small-functions' '-finline-functions' '-fipa-pta'
'-fpartial-inlining' '-c' '-v' '-mtune=core2'

/Users/denis/darlcl/uxl/gcc-4.7-20120114/bin/../libexec/gcc/x86_64-apple-darwin11.2.0/4.7.0/cc1
-quiet -v -iprefix
/Users/denis/darlcl/uxl/gcc-4.7-20120114/bin/../lib/gcc/x86_64-apple-darwin11.2.0/4.7.0/
-D__DYNAMIC__ stc.c -fPIC -quiet -dumpbase stc.c -mmacosx-version-min=10.7.2
-mtune=core2 -auxbase stc -O -version -finline-small-functions
-finline-functions -fipa-pta -fpartial-inlining -o /tmp/cct66mxd.s
GNU C (GCC) version 4.7.0 20120114 (experimental) (x86_64-apple-darwin11.2.0)
compiled by GNU C version 4.7.0 20120114 (experimental), GMP version
5.0.2, MPFR version 3.1.0-p4, MPC version 0.9
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
ignoring nonexistent directory
"/Users/denis/darlcl/uxl/gcc-4.7-20120114/bin/../lib/gcc/x86_64-apple-darwin11.2.0/4.7.0/../../../../x86_64-apple-darwin11.2.0/include"
ignoring duplicate directory
"/Users/denis/darlcl/uxl/gcc-4.7-20120114/bin/../lib/gcc/../../lib/gcc/x86_64-apple-darwin11.2.0/4.7.0/include"
ignoring nonexistent directory "/usr/local/here/include"
ignoring duplicate directory
"/Users/denis/darlcl/uxl/gcc-4.7-20120114/bin/../lib/gcc/../../lib/gcc/x86_64-apple-darwin11.2.0/4.7.0/include-fixed"
ignoring nonexistent directory
"/Users/denis/darlcl/uxl/gcc-4.7-20120114/bin/../lib/gcc/../../lib/gcc/x86_64-apple-darwin11.2.0/4.7.0/../../../../x86_64-apple-darwin11.2.0/include"
#include "..." search starts here:
#include <...> search starts here:

/Users/denis/darlcl/uxl/gcc-4.7-20120114/bin/../lib/gcc/x86_64-apple-darwin11.2.0/4.7.0/include

/Users/denis/darlcl/uxl/gcc-4.7-20120114/bin/../lib/gcc/x86_64-apple-darwin11.2.0/4.7.0/include-fixed
 /Users/denis/darlcl/uxl/gcc-4.7-20120114/bin/../lib/gcc/../../include
 /usr/include
 /System/Library/Frameworks
 /Library/Frameworks
End of search list.
GNU C (GCC) version 4.7.0 20120114 (experimental) (x86_64-apple-darwin11.2.0)
compiled by GNU C version 4.7.0 20120114 (experimental), GMP version
5.0.2, MPFR version 3.1.0-p4, MPC version 0.9
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 0bf7ee2f49f6ea7e3844a6dc703323f3
stc.c:7:1: internal compiler error: in insert_vi_for_tree, at
tree-ssa-structalias.c:2642
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug libstdc++/51845] [4.7 regression] 23_containers/unordered_multimap/erase/24061-multimap.cc segfault

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

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

--- Comment #11 from Andreas Schwab  2012-01-15 13:36:39 
UTC ---
Created attachment 26332
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26332
valgrind log

$ valgrind  --log-file=log ./24061-multimap.exe
24061-multimap.exe:
/daten/gcc/gcc-20120113/libstdc++-v3/testsuite/23_containers/unordered_multimap/erase/24061-multimap.cc:99:
void test01(): Assertion `mm1.size() == 0' failed.
Aborted

[Bug middle-end/50325] [4.7 Regression] 76 new fails with rev. 177691

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

  Attachment #25270|0   |1
is obsolete||

--- Comment #29 from Dominique d'Humieres  
2012-01-15 13:31:04 UTC ---
Created attachment 26331
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26331
merged patch

> > Note that reapplying r181405 with the Richard Sandiford's patch at
> > http://gcc.gnu.org/ml/gcc-patches/2011-11/msg02004.html fixes the failures 
> > on
> > powerpc-apple-darwin9 without visible side effect on x86_64-apple-darwin10.

I am attaching the resulting patch for revision 183181. Could it be tested on
the platforms for which revision 181405 caused some failures: i.e., AIX
(comment #12, tested without regression on Darwin), mips-linux-gnu (comment
#18), and SH target when compiling for big endian (comment #19).

> Then let's do that ASAP.

Agreed, but I am not a maintainer nor a reviewer!-)

[Bug fortran/51864] New: [OOP] ALLOCATE with polymorphic array constructor as SOURCE=

[burnus at gcc dot gnu.org]

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

 Bug #: 51864
   Summary: [OOP] ALLOCATE with polymorphic array constructor as
SOURCE=
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bur...@gcc.gnu.org


See also http://gcc.gnu.org/ml/fortran/2012-01/msg00147.html

The following program causes gfortran to ICE with a segfault. The program
compiles with NAG f95 5.1 and crayftn 7.1 - though it segfaults at run time.

I think the program is valid F2003/F2008.

type t
  integer :: i = 5
end type t
type, extends(t) :: t2
  integer :: j = 6
end type t2

class(t), allocatable :: a(:), b(:), c(:)
allocate(t2 :: a(3))
allocate(t2 :: b(5))
!allocate(c, source=[ a, b ]) ! F2008, PR 44672
allocate(c(8), source=[ a, b ])
! c = [ a, b ] ! F2008, PR 43366
select type(c)
  type is(t)
print '(8(i2))', c%i
  type is(t2)
print '(8(i2))', c%i
print '(8(i2))', c%j
end select
end

[Bug c++/51706] default copy assignment incorrectly deleted

[daniel.kruegler at googlemail dot com]

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

Daniel Krügler  changed:

   What|Removed |Added

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

--- Comment #1 from Daniel Krügler  
2012-01-15 12:46:47 UTC ---
(In reply to comment #0)
> If a move constructor is defined, then the copy assignment operator is 
> deleted,
> even if a copy constructor is defined.
> 
> In the n3092 draft, it is:
> 12.8 "Copying and moving class objects" [class.copy], paragraphs 20,25
> which doesn't say move constructors should affect copy assignment.

Note that n3092 is outdated, the last C++11 draft was n3290 and I'm referring
to it in the following.

The compiler is correct to declare the copy assignment operator as deleted in
this case, see [class.copy] p18:

"If the class definition does not explicitly declare a copy assignment
operator, one is declared implicitly. If the class definition declares a move
constructor or move assignment operator, the implicitly declared copy
assignment operator is defined as deleted; [..]"

I suggest to close this bug as INVALID.

[Bug target/51784] PIC register not correctly preserved in nested funcs / with non-local goto

[jakub at gcc dot gnu.org]

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

--- Comment #34 from Jakub Jelinek  2012-01-15 
12:05:20 UTC ---
(In reply to comment #33)

1) the define_expand isn't needed, just name the define_insn_and_split pattern
as "nonlocal_goto_receiver".

2) it should split always, either to nothing if nothing is needed, or to the
set_got_* plus adjust, so use "#" as the pattern

3) length attribute doesn't make sense for always split insn

4) the split condition should be && epilogue_completed

5) to determine if you need to load the pic register or not, you should match
what
the prologue expansion does, try
(pic_offset_table_rtx
  && (df_regs_ever_live_p (REAL_PIC_OFFSET_TABLE_REGNUM)
  || crtl->profile))
probably also anded with && !current_function_is_leaf - non-local goto receiver
in leaf functions doesn't make much sense and certainly doesn't need to restore
PIC pointer, plus it will simplify it (for leaf functions we sometimes decide
to use a different register as pic pointer instead of %ebx).

[Bug target/51784] PIC register not correctly preserved in nested funcs / with non-local goto

[iains at gcc dot gnu.org]

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

--- Comment #33 from Iain Sandoe  2012-01-15 11:25:31 
UTC ---
Created attachment 26330
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26330
second (non working) go

I'm finding this moderately hard.

I understand what you're suggesting that I should do - but between gccint.pdf,
looking at other .md files and so on there is really rather scarce information
-- trial & error is not a productive way forward .. so I'm still a bit stuck.

The attached does the right thing with the testcase - it inserts the restore
when PIC is used and not when it isn't.

But the compiler fails to bootstrap because eh_personality.cc in the c++
library seems to cause the insert of the nonlocal_rx (for eh) but then, somehow
the initial use of the pic register is optimized away .. and thus we end up
with a load of "L03$pd" can't be undefined...

... so ... how can I ensure that the test of "uses_pic_" is only done after
optimization?

(or any other help would be welcome).

[Bug target/51784] PIC register not correctly preserved in nested funcs / with non-local goto

[iains at gcc dot gnu.org]

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

--- Comment #32 from Iain Sandoe  2012-01-15 11:16:42 
UTC ---
Created attachment 26329
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26329
test code

firstly, apropos comment #22 and #23.

If you build this test case under linux (or darwin), -fpic -O0

.. you will see that the prologue of x does not save ebx.  However it is used
in y ... and to quote function.h "the exit block is reachable directly from a
nonlocal label".  So I think my comment #22 stands.

[if you build the testcase -O0 -fpic -DUSEPIC, then x uses the pic reg and all
is OK].

this could be fixed thus (but you might well have a better place/way to fix
it):


Index: gcc/config/i386/i386.c
===
--- gcc/config/i386/i386.c(revision 183180)
+++ gcc/config/i386/i386.c(working copy)
@@ -8698,7 +8698,8 @@ ix86_save_reg (unsigned int regno, bool maybe_eh_r
   && (df_regs_ever_live_p (REAL_PIC_OFFSET_TABLE_REGNUM)
   || crtl->profile
   || crtl->calls_eh_return
-  || crtl->uses_const_pool))
+  || crtl->uses_const_pool
+  || cfun->has_nonlocal_label))
 return ix86_select_alt_pic_regnum () == INVALID_REGNUM;

   if (crtl->calls_eh_return && maybe_eh_return)

[Bug inline-asm/51863] invlpg with -masm=intel generates memory operand size error in assembly stage

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #4 from Andrew Pinski  2012-01-15 
10:08:04 UTC ---
(In reply to comment #3)
> > What GCC is doing is correct in that it outputs the byte/word/dword
> > correctly for -masm=intel.
> But why for -masm=intel and not for -masm=att (the default)?

Because that is how the constraint works.  In intel style, size prefix is part
of the memory and not the instruction.  That is mov with the size being in the
operand vs mov[lwqb] which says the size.

[Bug inline-asm/51863] invlpg with -masm=intel generates memory operand size error in assembly stage

[th020394 at gmail dot com]

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

Tyler Hardin  changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |

--- Comment #3 from Tyler Hardin  2012-01-15 
08:49:26 UTC ---
(In reply to comment #2)
> I think you should use:
> asm("invlpg %0" :: "r"(pointer_to_page) : "memory");
> Instead.
invlpg only accepts memory operands. But, if I adapt your idea just a little,
it works:
asm("invlpg [%0]" :: "r"(pointer_to_page) : "memory");

It would be nice if it would work without having to trick the compiler (telling
it I'm using a register but actually referencing memory), but it works now,
that's all I care about. Thanks.

> What GCC is doing is correct in that it outputs the byte/word/dword
> correctly for -masm=intel.
But why for -masm=intel and not for -masm=att (the default)?

[Bug inline-asm/51863] invlpg with -masm=intel generates memory operand size error in assembly stage

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #2 from Andrew Pinski  2012-01-15 
08:27:04 UTC ---
I think you should use:
asm("invlpg %0" :: "r"(pointer_to_page) : "memory");
Instead.  What GCC is doing is correct in that it outputs the byte/word/dword
correctly for -masm=intel.

[Bug middle-end/51848] GCC is not able to vectorize when a constant value is also added to the sum of array expression inside a loop.

[irar at il dot ibm.com]

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

Ira Rosen  changed:

   What|Removed |Added

 CC||irar at il dot ibm.com

--- Comment #2 from Ira Rosen  2012-01-15 08:06:09 UTC 
---
We don't recognize this as reduction because we look for:

 a1 = phi < a0, a2 >
 a3 = ...
 a2 = operation (a3, a1)

and here we have

 a1 = phi < a0, a2 >
 a3 = ...
 a4 = operation (a3, a1)
 a2 = a4 + 1