[Bug fortran/53015] New: free_pi_tree(): Unresolved fixup is back

[brainschrat at gmx dot de]

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

 Bug #: 53015
   Summary: free_pi_tree(): Unresolved fixup is back
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: brainsch...@gmx.de


Bug 47546 was fixed some time ago, but I get "Internal error - free_pi_tree():
Unresolved fixup" all over the place again, with versions 4.6.2, 4.7.0 and
4.8.0 of gfortran from svn.

I have a project that uses many Fortran 2003 features, like polymorphism,
type-bound procedures etc. Some sub-classes are in different modules, which did
not cause problems before and is supported by the standard. I also use OpenMPI
and PETSc, so there are some preprocessor macros. The code compiles and runs
fine withe the Intel Fortran compiler, which is the only other Fortran compiler
I have access to.

Like in 47546 , the issue is very elusive: Sometimes it happens when compiling
the modules themselves, sometimes when compiling a program that uses the
modules. Sometimes commenting out one arbitrary line of code fixes the error,
and it remains fixed after putting the line in again. Sometimes removing all
modules and object files and re-compiling (even files that remain unchanged)
fixes the error. On some days, I cannot compile my code at all, but using an
different version of gfortran works. But then the issue pops up again after
adding a new line of code.

Because of this, I am not able to provide a test case as I have no clue what
the error means and the rest of the case seems non-deterministic. Maybe someone
can assist me in narrowing down the possibilities.

[Bug c++/38543] [C++0x] Cannot specialize variadic template function

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.8.0

--- Comment #3 from Jason Merrill  2012-04-17 
03:34:04 UTC ---
Fixed for 4.8.

[Bug libffi/53014] [4.8 Regression] libffi failures on mips64-linux-gnu with soft-float

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Target||mips64-linux-gnu
   Target Milestone|--- |4.8.0

--- Comment #1 from Andrew Pinski  2012-04-17 
02:49:03 UTC ---
I have not debugged what is going wrong but I think it is related to the merge
that was done.

[Bug libffi/53014] New: [4.8 Regression] libffi failures on mips64-linux-gnu with soft-float

[pinskia at gcc dot gnu.org]

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

 Bug #: 53014
   Summary: [4.8 Regression] libffi failures on mips64-linux-gnu
with soft-float
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libffi
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: pins...@gcc.gnu.org


=== libffi Summary for unix//-march=octeon+/-mabi=64 ===

# of expected passes813
# of unexpected failures427
# of unsupported tests  55

And in 4.6.1 we had:
=== libffi Summary for unix//-mabi=64 ===

# of expected passes1626
# of unexpected failures8
# of expected failures  10
# of unsupported tests  15

[Bug c/53005] GCC moves the called C function address and parameters to the wrong stack position, when making C-style calling of C functions in a C function with inline assembly code.

[zhao86.scholar at gmail dot com]

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

--- Comment #6 from Lili Zhao  2012-04-17 
02:43:31 UTC ---
Thanks all the same! I'll try on the latest gcc version to see if the bug
reproduce. Thank you!

2012/4/16 manu at gcc dot gnu.org 

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53005
>
> --- Comment #5 from Manuel López-Ibáñez 
> 2012-04-16 11:18:51 UTC ---
> Lili Zhao, I forgot to say, but feel free to reopen this if you can
> reproduce
> the bug with GCC 4.7. Thanks for the report anyway, and sorry we cannot
> help
> you.
>
> --
> 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.
> You reported the bug.
>

[Bug c++/50303] [C++0x] Segfault with variadic template template parameters

[jason at gcc dot gnu.org]

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

--- Comment #6 from Jason Merrill  2012-04-17 
02:29:32 UTC ---
Author: jason
Date: Tue Apr 17 02:29:27 2012
New Revision: 186519

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186519
Log:
PR c++/50303
* pt.c (tsubst_pack_expansion): Use tsubst_expr for template
template parameters.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/variadic128.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/50830] [c++0x] Variadic template, inner class error

[jason at gcc dot gnu.org]

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

--- Comment #9 from Jason Merrill  2012-04-17 
02:29:40 UTC ---
Author: jason
Date: Tue Apr 17 02:29:35 2012
New Revision: 186520

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186520
Log:
PR c++/50830
* pt.c (convert_template_argument): Handle template template
argument packs.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/variadic129.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/38543] [C++0x] Cannot specialize variadic template function

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill  2012-04-17 
02:29:54 UTC ---
Author: jason
Date: Tue Apr 17 02:29:51 2012
New Revision: 186522

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186522
Log:
PR c++/38543
* pt.c (determine_specialization): Instead of comparing the number
of parms, check that tsubst gives the right answer.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/variadic131.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/52008] [C++0x] ICE when adding partial specialization for variadic-templated structure

[jason at gcc dot gnu.org]

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

--- Comment #3 from Jason Merrill  2012-04-17 
02:29:47 UTC ---
Author: jason
Date: Tue Apr 17 02:29:43 2012
New Revision: 186521

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186521
Log:
PR c++/52008
* pt.c (process_partial_specialization): Complain about a partial
specialization with fewer args than primary template parms.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/variadic130.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c
trunk/gcc/testsuite/ChangeLog

[Bug libstdc++/52689] static linking with libstdc++ fails

[bkoz at gcc dot gnu.org]

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

--- Comment #18 from Benjamin Kosnik  2012-04-17 
02:21:29 UTC ---

Patch plus revisions in gcc-4_7-branch.

[Bug other/46770] Replace .ctors/.dtors with .init_array/.fini_array on targets supporting them

[ccoutant at gcc dot gnu.org]

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

Cary Coutant  changed:

   What|Removed |Added

 CC||ppluzhnikov at google dot
   ||com

--- Comment #74 from Cary Coutant  2012-04-17 
01:21:47 UTC ---
We still have an unresolved issue here: we're effectively reversing the order
in which the ctors are run across translation units. While explicitly undefined
by any standard, it was mentioned upthread that this would probably break a lot
of code that depended on ctors for later translation units (e.g., a
statically-linked C++ library) running before those for earlier translation
units. And, in fact, we have been finding lots of such code. We've temporarily
worked around it by configuring GCC to continue to use .ctors sections, and by
turning off --ctors-in-init-array in the linker, but I'd think it would be nice
to fix this.

I'd like to propose a --reverse-init-array option to the linker that would
reverse the contributions to the .init_array section relative to one another
(but not the actual contents of each contribution). With this option, the
.init_array entries for translation unit A would come after those for
translation unit B, when A comes before B on the link command. This would still
conform to the standards, but would provide a more reasonable ordering, since
it is natural to expect initializers for dependent libraries to execute before
those for code that depends on them (as is the case for shared libraries
already).

As I recall the discussions from years ago when we first added .init_array, I
think we would have always preferred to have the dynamic loader execute the
.init_array entries in reverse, but we were trying to preserve the behavior
that had always been observed with the old .init section (which, obviously,
could not execute in reverse). I believe that was the original reason (or at
least part of it) that GCC put ctors in a separate section rather than using
.init or .init_array. Now that we're moving .ctors into .init_array, I think
it's more important to preserve the old behavior of ctors rather than the old
behavior of .init fragments.

HJ, if I add this option to gold, would you add it to ld?

If this is OK with everyone, we can then discuss whether or not the option
should be on by default.

-cary

[Bug target/52941] SH Target: Add support for movco.l / movli.l atomics on SH4A

[kkojima at gcc dot gnu.org]

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

--- Comment #8 from Kazumoto Kojima  2012-04-17 
00:54:00 UTC ---
(In reply to comment #7)
> Created attachment 27173 [details]
> Proposed patch

Looks even better.

> Only one thing ... is it safe to do the
> "@-r15", "@+r15" stuff in the atomic sequence?  I remember there were some
> border cases where things would blow up, but can't recall.  I've also briefly
> checked with atomic vars being on the stack and it looks OK.

I don't know about such restrictions, though my knowledge of
SH4A is very limited.  Perhaps some weired interaction of ll/sc
and cache?  Anyway, if it's a border issue, the patch is OK.
I'd like to pre-approve it.

[Bug bootstrap/52840] bootstrap fails in libstdc++, missing compatibility.lo

[bkoz at gcc dot gnu.org]

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

--- Comment #6 from Benjamin Kosnik  2012-04-17 
00:19:16 UTC ---
Author: bkoz
Date: Tue Apr 17 00:19:12 2012
New Revision: 186517

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186517
Log:
2012-04-16  Bernhard Reutner-Fischer  

PR bootstrap/52840
* src/Makefile.am (build-debug): Do not adjust vpath dir, remove
Makefile.tmp
* src/Makefile.in: Adjust as per above.

2012-04-16  Benjamin Kosnik  

PR libstdc++/52689
* libsupc++/Makefile.am (LTCXXCOMPILE, CXXLINK): Tweak.
* libsupc++/Makefile.in: Regenerated.
* src/Makefile.am (LTCXXCOMPILE, CXXLINK): Tweak.
(libstdc___la_SOURCES): Add in compatiblity files, with content
that varies with -DPIC.
* src/Makefile.in: Regenerated.
* src/c++11/Makefile.am (LTCXXCOMPILE, CXXLINK): Tweak.
* src/c++11/Makefile.in: Regenerated.
* src/c++11/compatibility-atomic-c++0x.cc: Guard with PIC.
* src/c++11/compatibility-c++0x.cc: Same.
* src/c++11/future.cc: Consolidate compatibility bits into..
* src/c++11/mutex.cc: Consolidate compatibility bits into..
* src/c++11/compatibility-thread-cxx0x.cc: ...here. New.
* src/c++98/Makefile.am (LTCXXCOMPILE, CXXLINK): Tweak.
* src/c++98/Makefile.in: Regenerated.
* src/c++98/compatibility-list-2.cc: Guard with PIC.
* src/c++98/compatibility.cc: Tweak comments.


Added:
   
branches/gcc-4_7-branch/libstdc++-v3/src/c++11/compatibility-thread-c++0x.cc
Modified:
branches/gcc-4_7-branch/libstdc++-v3/ChangeLog
branches/gcc-4_7-branch/libstdc++-v3/libsupc++/Makefile.am
branches/gcc-4_7-branch/libstdc++-v3/libsupc++/Makefile.in
branches/gcc-4_7-branch/libstdc++-v3/src/Makefile.am
branches/gcc-4_7-branch/libstdc++-v3/src/Makefile.in
branches/gcc-4_7-branch/libstdc++-v3/src/c++11/Makefile.am
branches/gcc-4_7-branch/libstdc++-v3/src/c++11/Makefile.in
   
branches/gcc-4_7-branch/libstdc++-v3/src/c++11/compatibility-atomic-c++0x.cc
branches/gcc-4_7-branch/libstdc++-v3/src/c++11/compatibility-c++0x.cc
branches/gcc-4_7-branch/libstdc++-v3/src/c++11/future.cc
branches/gcc-4_7-branch/libstdc++-v3/src/c++11/mutex.cc
branches/gcc-4_7-branch/libstdc++-v3/src/c++98/Makefile.am
branches/gcc-4_7-branch/libstdc++-v3/src/c++98/Makefile.in
branches/gcc-4_7-branch/libstdc++-v3/src/c++98/compatibility-ldbl.cc
branches/gcc-4_7-branch/libstdc++-v3/src/c++98/compatibility-list-2.cc
branches/gcc-4_7-branch/libstdc++-v3/src/c++98/compatibility-list.cc
branches/gcc-4_7-branch/libstdc++-v3/src/c++98/compatibility.cc

[Bug libstdc++/52689] static linking with libstdc++ fails

[bkoz at gcc dot gnu.org]

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

--- Comment #17 from Benjamin Kosnik  2012-04-17 
00:19:18 UTC ---
Author: bkoz
Date: Tue Apr 17 00:19:12 2012
New Revision: 186517

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186517
Log:
2012-04-16  Bernhard Reutner-Fischer  

PR bootstrap/52840
* src/Makefile.am (build-debug): Do not adjust vpath dir, remove
Makefile.tmp
* src/Makefile.in: Adjust as per above.

2012-04-16  Benjamin Kosnik  

PR libstdc++/52689
* libsupc++/Makefile.am (LTCXXCOMPILE, CXXLINK): Tweak.
* libsupc++/Makefile.in: Regenerated.
* src/Makefile.am (LTCXXCOMPILE, CXXLINK): Tweak.
(libstdc___la_SOURCES): Add in compatiblity files, with content
that varies with -DPIC.
* src/Makefile.in: Regenerated.
* src/c++11/Makefile.am (LTCXXCOMPILE, CXXLINK): Tweak.
* src/c++11/Makefile.in: Regenerated.
* src/c++11/compatibility-atomic-c++0x.cc: Guard with PIC.
* src/c++11/compatibility-c++0x.cc: Same.
* src/c++11/future.cc: Consolidate compatibility bits into..
* src/c++11/mutex.cc: Consolidate compatibility bits into..
* src/c++11/compatibility-thread-cxx0x.cc: ...here. New.
* src/c++98/Makefile.am (LTCXXCOMPILE, CXXLINK): Tweak.
* src/c++98/Makefile.in: Regenerated.
* src/c++98/compatibility-list-2.cc: Guard with PIC.
* src/c++98/compatibility.cc: Tweak comments.


Added:
   
branches/gcc-4_7-branch/libstdc++-v3/src/c++11/compatibility-thread-c++0x.cc
Modified:
branches/gcc-4_7-branch/libstdc++-v3/ChangeLog
branches/gcc-4_7-branch/libstdc++-v3/libsupc++/Makefile.am
branches/gcc-4_7-branch/libstdc++-v3/libsupc++/Makefile.in
branches/gcc-4_7-branch/libstdc++-v3/src/Makefile.am
branches/gcc-4_7-branch/libstdc++-v3/src/Makefile.in
branches/gcc-4_7-branch/libstdc++-v3/src/c++11/Makefile.am
branches/gcc-4_7-branch/libstdc++-v3/src/c++11/Makefile.in
   
branches/gcc-4_7-branch/libstdc++-v3/src/c++11/compatibility-atomic-c++0x.cc
branches/gcc-4_7-branch/libstdc++-v3/src/c++11/compatibility-c++0x.cc
branches/gcc-4_7-branch/libstdc++-v3/src/c++11/future.cc
branches/gcc-4_7-branch/libstdc++-v3/src/c++11/mutex.cc
branches/gcc-4_7-branch/libstdc++-v3/src/c++98/Makefile.am
branches/gcc-4_7-branch/libstdc++-v3/src/c++98/Makefile.in
branches/gcc-4_7-branch/libstdc++-v3/src/c++98/compatibility-ldbl.cc
branches/gcc-4_7-branch/libstdc++-v3/src/c++98/compatibility-list-2.cc
branches/gcc-4_7-branch/libstdc++-v3/src/c++98/compatibility-list.cc
branches/gcc-4_7-branch/libstdc++-v3/src/c++98/compatibility.cc

[Bug target/52941] SH Target: Add support for movco.l / movli.l atomics on SH4A

[olegendo at gcc dot gnu.org]

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

--- Comment #7 from Oleg Endo  2012-04-17 00:03:19 
UTC ---
Created attachment 27173
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27173
Proposed patch

(In reply to comment #6)
> The patch looks just fine.  I don't mind whether those atomics are
> fully optimized or not ATM.  Programs having atomics in the minor
> loop are pathological in the first place, I think.

I was also concerned about the code size in sync.md...
Anyway, how about the attached patch instead?  It now should do all atomics for
-mhard-atomic.  
I've scrapped the LUT and whatnot and the code size (both generated and in the
compiler) now looks more reasonable.  Only one thing ... is it safe to do the
"@-r15", "@+r15" stuff in the atomic sequence?  I remember there were some
border cases where things would blow up, but can't recall.  I've also briefly
checked with atomic vars being on the stack and it looks OK.

[Bug libstdc++/47762] FAIL: ext/mt_allocator/deallocate_global_thread-1.cc execution test

[paolo.carlini at oracle dot com]

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

--- Comment #5 from Paolo Carlini  2012-04-16 
23:51:45 UTC ---
Oh good. The I suppose that in the 4_7-branch the problem still exists: care to
check if the same patchlet works there too?

[Bug libstdc++/47762] FAIL: ext/mt_allocator/deallocate_global_thread-1.cc execution test

[dominiq at lps dot ens.fr]

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

--- Comment #4 from Dominique d'Humieres  2012-04-16 
23:44:19 UTC ---
> See if, by chance, libstdc++/52604 did the "miracle". I would like that ;)

Yep! At revision 186396, I get for
RUNTESTFLAGS="conformance.exp=deallocate_global_thread* ..."

Running target unix/-m32
FAIL: ext/mt_allocator/deallocate_global_thread-1.cc execution test
FAIL: ext/mt_allocator/deallocate_global_thread-3.cc execution test

=== libstdc++ Summary for unix/-m32 ===

# of expected passes2
# of unexpected failures2

Running target unix/-m64
FAIL: ext/mt_allocator/deallocate_global_thread-1.cc execution test
FAIL: ext/mt_allocator/deallocate_global_thread-3.cc execution test

=== libstdc++ Summary for unix/-m64 ===

# of expected passes2
# of unexpected failures2

=== libstdc++ Summary ===

# of expected passes4
# of unexpected failures4

With the change in revision 186414, I get

=== libstdc++ Summary for unix/-m32 ===

# of expected passes4

=== libstdc++ Summary for unix/-m64 ===

# of expected passes4

=== libstdc++ Summary ===

# of expected passes8

[Bug c/53013] Inconsistent Behaviour with Left Shift Operator.

[john.stevens at f5 dot com]

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

--- Comment #6 from john.stevens at f5 dot com 2012-04-16 23:23:41 UTC ---
Ah, I see.  We are using two different sets of pragmatics, and two different
definitions of the inclusion class of the standard.

Thanks,
John S.

-Original Message-
From: pinskia at gcc dot gnu.org [mailto:gcc-bugzi...@gcc.gnu.org] 
Sent: Monday, April 16, 2012 3:10 PM
To: John Stevens
Subject: [Bug c/53013] Inconsistent Behaviour with Left Shift Operator.

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

--- Comment #4 from Andrew Pinski  2012-04-16
22:10:29 UTC ---
>IOW, "undefined" means the standard deliberately refuses to make a 
>statement
about a real thing, it does not mean that the thing is not real.

That is unspecified behavior and not undefined behavior.

--
Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: --- You reported the bug.

[Bug c++/53012] unrelated friend operators in same namespace interfere with operator resolution outside of namespace

[alphaetapi at hotmail dot com]

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

Adam H. Peterson  changed:

   What|Removed |Added

 CC||alphaetapi at hotmail dot
   ||com

--- Comment #1 from Adam H. Peterson  2012-04-16 
23:22:47 UTC ---
I get the same results here.  I've also determined that the problem doesn't
rely on using operator overloading or #include-ing .  Here's a
program that fails similarly without using either (and in fact has no
#includes):


namespace one {
class A { };
}
void func(const ::one::A& ) { }

namespace two {
class unrelated_a {
friend void func( const unrelated_a& );
};
#if not defined MAKE_IT_WORK
class unrelated_b {
friend void func( const unrelated_b& );
};
#endif

void output( const one::A& val ) {
func(val);
}
}
int main() {
two::output( one::A() );
}



With the above code, I get "'func' was not declared in this scope" inside
output()'s body.  While it's true that func() is not declared in namespace two,
it is in the global scope.  And in fact, apparently it is found if the
definition for class unrelated_b is removed.

[Bug c/53013] Inconsistent Behaviour with Left Shift Operator.

[manu at gcc dot gnu.org]

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

--- Comment #5 from Manuel López-Ibáñez  2012-04-16 
22:44:46 UTC ---
Since we keep repeating the same things over and over again, with the same
links, and having the same arguments, I added a FAQ here: 

http://gcc.gnu.org/wiki/FAQ#My_program_invokes_undefined_behaviour_but...

I want it to be concise, assertive enough, but still polite. Please, feel free
to edit it and improve for future answers.

[Bug target/52941] SH Target: Add support for movco.l / movli.l atomics on SH4A

[kkojima at gcc dot gnu.org]

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

--- Comment #6 from Kazumoto Kojima  2012-04-16 
22:37:31 UTC ---
(In reply to comment #5)
The patch looks just fine.  I don't mind whether those atomics are
fully optimized or not ATM.  Programs having atomics in the minor
loop are pathological in the first place, I think.

[Bug c/53013] Inconsistent Behaviour with Left Shift Operator.

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski  2012-04-16 
22:10:29 UTC ---
>IOW, "undefined" means the standard deliberately refuses to make a statement
about a real thing, it does not mean that the thing is not real.

That is unspecified behavior and not undefined behavior.

[Bug c/53013] Inconsistent Behaviour with Left Shift Operator.

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  2012-04-16 
22:09:26 UTC ---
No, I would respectfully point out you're wrong, read the links in comment 1. 
Undefined behaviour doesn't just mean "the standard omits to mention what
happens" it means *anything* can happen. That includes different behaviour
every time you run the program (think of accessing uninitialized data that
contains random junk values) or setting your monitor on fire or wiping your
hard drive. You should not have *any* expectations of undefined behaviour.

[Bug fortran/49565] character(kind=4) is emitted as DW_ATE_unsigned, not DW_ATE_unsigned_char

[burnus at gcc dot gnu.org]

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

--- Comment #4 from Tobias Burnus  2012-04-16 
22:04:20 UTC ---
See also http://www.dwarfstd.org/ShowIssue.php?issue=120213.1

[Bug fortran/52864] [4.6/4.7/4.8 Regression] Assignment to pointer component for INTENT(IN) dummy argument

[burnus at gcc dot gnu.org]

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

--- Comment #4 from Tobias Burnus  2012-04-16 
21:47:39 UTC ---
Author: burnus
Date: Mon Apr 16 21:47:35 2012
New Revision: 186507

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186507
Log:
2012-04-12  Tobias Burnus  

PR fortran/52864
* expr.c (gfc_check_vardef_context): Fix assignment check for
pointer components.

2012-04-16  Tobias Burnus  

PR fortran/52864
* gfortran.dg/pointer_intent_6.f90: New.


Added:
trunk/gcc/testsuite/gfortran.dg/pointer_intent_6.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/expr.c
trunk/gcc/testsuite/ChangeLog

[Bug c/53013] Inconsistent Behaviour with Left Shift Operator.

[john.stevens at f5 dot com]

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

--- Comment #2 from john.stevens at f5 dot com 2012-04-16 21:47:11 UTC ---
I would respectfully point out that "consistent", and "undefined by the
standard", are two different things.

I can expect consistent behavior that is not defined by the standard, but I
agree that I may not expect that that behavior will be defined by the standard,
nor that it will remain the same from one version to the next, only that the
result generated by the same operation will give the same,
undefined-by-the-standard, but consistent result.

IOW, "undefined" means the standard deliberately refuses to make a statement
about a real thing, it does not mean that the thing is not real.  The
difference here is akin to the difference between Philosophy and Natural
Philosophy (Natural Philosophy being a proper subset of Philosophy that
deliberately refrains from discussing real things that are outside the realm of
Natural Philosophy).

Thanks,
John S.

-Original Message-
From: manu at gcc dot gnu.org [mailto:gcc-bugzi...@gcc.gnu.org] 
Sent: Monday, April 16, 2012 2:17 PM
To: John Stevens
Subject: [Bug c/53013] Inconsistent Behaviour with Left Shift Operator.

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||manu at gcc dot gnu.org
 Resolution||INVALID

--- Comment #1 from Manuel López-Ibáñez  2012-04-16
21:16:48 UTC --- Sorry, you cannot expect consistency from undefined behaviour.
It doesn't work that way: http://c-faq.com/ansi/undef.html

And if you want to know why:
http://www.eskimo.com/~scs/readings/undef.950321.html

--
Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: --- You reported the bug.

[Bug fortran/52916] [4.8 Regression] 481.wrf in SPEC CPU 2006 failed to build

[burnus at gcc dot gnu.org]

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

--- Comment #7 from Tobias Burnus  2012-04-16 
21:38:53 UTC ---
Author: burnus
Date: Mon Apr 16 21:38:49 2012
New Revision: 186506

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186506
Log:
2012-04-16  Tobias Burnus  

PR fortran/52916
* gfortran.dg/public_private_module_3.f90: Use dg-additional-sources
to include public_private_module_4.f90.
* gfortran.dg/public_private_module_4.f90: Skip this test on all
targets


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/public_private_module_3.f90
trunk/gcc/testsuite/gfortran.dg/public_private_module_4.f90

[Bug c++/52849] crash when using subscript operator in decltype argument

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WORKSFORME

--- Comment #4 from Paolo Carlini  2012-04-16 
21:27:43 UTC ---
.

[Bug c++/52849] crash when using subscript operator in decltype argument

[paolo.carlini at oracle dot com]

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

--- Comment #3 from Paolo Carlini  2012-04-16 
21:27:18 UTC ---
Really, 4.4.x is very old, especially in terms of C++11 features. Current
mainline, 4.7.0 and 4.6.x have no problems with the testcase.

[Bug c/53013] Inconsistent Behaviour with Left Shift Operator.

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||manu at gcc dot gnu.org
 Resolution||INVALID

--- Comment #1 from Manuel López-Ibáñez  2012-04-16 
21:16:48 UTC ---
Sorry, you cannot expect consistency from undefined behaviour. It doesn't work
that way: http://c-faq.com/ansi/undef.html

And if you want to know why:
http://www.eskimo.com/~scs/readings/undef.950321.html

[Bug c/53013] New: Inconsistent Behaviour with Left Shift Operator.

[john.stevens at f5 dot com]

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

 Bug #: 53013
   Summary: Inconsistent Behaviour with Left Shift Operator.
Classification: Unclassified
   Product: gcc
   Version: 4.4.5
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: john.stev...@f5.com


In this example:

#include
#include
#include

#define ALL_KEY_BITS(~ (uint32_t) 0)

int
main(
int argc,
char**argv )
{
registeruint32_ti;

printf(
"Size: %d\n",
sizeof( 32LU ) );
printf(
"Mask (<< %lu): 0x%lx\n",
32LU,
ALL_KEY_BITS << 32LU );
i = 32LU;
printf(
"Mask (<< %lu): 0x%lx\n",
i,
ALL_KEY_BITS << i );
}

The result is:

Size: 4
Mask (<< 32): 0x0
Mask (<< 32): 0x

While the above code is undefined by the standard, it would be preferable to
have consistent behaviour between shifting by a constant, or by a variable.

A result of all zero would give the least surprising result; if you start with
an unsigned value with only the top bit set, and shift it left by one, the
result is zero.  Start with one, shift it left by one in a loop where the
iteration count is the number of bits in the data, you get zero.

[Bug c++/53012] unrelated friend operators in same namespace interfere with operator resolution outside of namespace

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-04-16
 Ever Confirmed|0   |1

[Bug c++/53011] ice in verify_loop_structure: bad sizes

[markus at trippelsdorf dot de]

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

--- Comment #2 from Markus Trippelsdorf  
2012-04-16 19:59:38 UTC ---
create_preheader (loop=0x77452440, flags=) at
/home/markus/gcc/gcc/cfgloopmanip.c:1391
1391  latch_edge_was_fallthru = (mfb_kj_edge->flags & EDGE_FALLTHRU) != 0;
(gdb) bt
#0  create_preheader (loop=0x77452440, flags=) at
/home/markus/gcc/gcc/cfgloopmanip.c:1391
#1  0x00607838 in create_preheaders (flags=1) at
/home/markus/gcc/gcc/cfgloopmanip.c:1443
#2  0x0074e417 in loop_optimizer_init (flags=flags@entry=7) at
/home/markus/gcc/gcc/loop-init.c:89
#3  0x0074e4ef in rtl_loop_init () at
/home/markus/gcc/gcc/loop-init.c:210
#4  0x0078dec8 in execute_one_pass (pass=pass@entry=0x1074880) at
/home/markus/gcc/gcc/passes.c:2176
#5  0x0078e225 in execute_pass_list (pass=0x1074880) at
/home/markus/gcc/gcc/passes.c:2231
#6  0x0078e237 in execute_pass_list (pass=0x10748e0) at
/home/markus/gcc/gcc/passes.c:2232
#7  0x0078e237 in execute_pass_list (pass=0x1074cc0) at
/home/markus/gcc/gcc/passes.c:2232
#8  0x00612c69 in tree_rest_of_compilation (node=)
at /home/markus/gcc/gcc/cgraphunit.c:1898
#9  0x006157d2 in cgraph_expand_function (node=0x77412720) at
/home/markus/gcc/gcc/cgraphunit.c:1968
#10 0x00616c28 in cgraph_expand_all_functions () at
/home/markus/gcc/gcc/cgraphunit.c:2033
#11 cgraph_optimize () at /home/markus/gcc/gcc/cgraphunit.c:2724
#12 0x0061749a in cgraph_finalize_compilation_unit () at
/home/markus/gcc/gcc/cgraphunit.c:2809
#13 0x004f1b2f in cp_write_global_declarations () at
/home/markus/gcc/gcc/cp/decl2.c:4072
#14 0x0081fbd8 in compile_file () at /home/markus/gcc/gcc/toplev.c:572
#15 do_compile () at /home/markus/gcc/gcc/toplev.c:1938
#16 toplev_main (argc=13, argv=0x7fffe438) at
/home/markus/gcc/gcc/toplev.c:2014
#17 0x77893675 in __libc_start_main (main=0x5c1b40 , argc=13,
ubp_av=0x7fffe438, init=, fini=, 
rtld_fini=, stack_end=0x7fffe428) at libc-start.c:225
#18 0x00492369 in _start () at ../sysdeps/x86_64/start.S:116

[Bug c++/53011] ice in verify_loop_structure: bad sizes

[markus at trippelsdorf dot de]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||markus at trippelsdorf dot
   ||de

--- Comment #1 from Markus Trippelsdorf  
2012-04-16 19:35:42 UTC ---
Somewhat reduced:

 % cat test.ii
extern "C" class WvFastString;
typedef WvFastString& WvStringParm;
struct WvFastString {
  ~WvFastString();
  operator char* () {}
};
class WvString : WvFastString {};
class WvAddr {};
class WvIPAddr : WvAddr {};
struct WvIPNet : WvIPAddr {
  bool is_default() {}
};
template struct WvTraits_Helper {
  static void release(T *obj) {
delete obj;
  }
};
template struct WvTraits {
  static void release(From *obj) {
WvTraits_Helper::release(obj);
  }
};
struct WvLink {
  void   *data;
  WvLink *next;
  boolautofree;
  WvLink(bool, int) : autofree() {}
  bool get_autofree() {}

  void unlink() {
delete this;
  }
};
struct WvListBase {
  WvLink head, *tail;
  WvListBase() : head(0, 0) {}
};
template struct WvList : WvListBase {
  ~WvList() {
zap();
  }

  void zap(bool destroy = 1) {
while (head.next) unlink_after(&head, destroy);
  }

  void unlink_after(WvLink *after, bool destroy) {
WvLink *next = 0;
T *obj   = (destroy && next->get_autofree()) ? 
   static_cast(next->data) : 0;

if (tail) tail = after;
next->unlink();
WvTraits::release(obj);
  }
};
typedef WvListWvStringListBase;
class WvStringList : WvStringListBase {};
class WvSubProc {
  WvStringList last_args, env;
};
void addroute(WvIPNet& dest, WvStringParm table) {
  if (dest.is_default() || (table != "default")) WvSubProc checkProc;
}

 % g++ -c -O1 test.ii
test.ii: In function ‘void addroute(WvIPNet&, WvStringParm)’:
test.ii:64:1: internal compiler error: Segmentation fault

[Bug c++/41933] [c++0x] lambdas and variadic templates don't work together

[jason at gcc dot gnu.org]

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

--- Comment #8 from Jason Merrill  2012-04-16 
19:21:13 UTC ---
Created attachment 27172
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27172
incomplete patch

Here's the beginning of work to implement this.  A lot more will be needed.

[Bug c++/53012] New: unrelated friend operators in same namespace interfere with operator resolution outside of namespace

[kalaxy at gmail dot com]

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

 Bug #: 53012
   Summary: unrelated friend operators in same namespace interfere
with operator resolution outside of namespace
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: kal...@gmail.com


This code fails to compile because of "error: no match for ‘operator<<’ in
‘std::cout << val’":

#include 

namespace one {
class A { };
}

std::ostream& operator<<(std::ostream& os, const ::one::A& ) {
return os << __PRETTY_FUNCTION__;
}


namespace two {
class unrelated_a {
friend std::ostream& operator<< ( std::ostream& out, const unrelated_a&
);
};

class unrelated_b {
friend std::ostream& operator<< ( std::ostream& out, const unrelated_b&
);
};

void output( const one::A& val )
{
std::cout << val << std::endl;
}
}

int main() {
one::A obj ;
two::output( obj );
return 0;
}


Ways to make it compile as expected:
A) remove either of the two (or both) unrelated class friend operators.
B) Move two::output outside of the two namespace.
C) use clang (not trying to be overly snarky here but being unsure myself if it
should be valid code I compiled it using clang with success.)

I've tried this on 4.6.3 and 4.7 with the same results.
$ g++ -v
Using built-in specs.
COLLECT_GCC=./usr/bin/g++
COLLECT_LTO_WRAPPER=/mnt/gcc-4.7/usr/libexec/gcc/x86_64-unknown-linux-gnu/4.7.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.7.0/configure --prefix=/mnt/gcc-4.7/usr/ :
(reconfigured) ../gcc-4.7.0/configure --prefix=/mnt/gcc-4.7/usr/
--disable-multilib --enable-languages=c++
Thread model: posix
gcc version 4.7.0 (GCC) 


command to reproduce:
./usr/bin/g++ namespace_pain.cpp

compiler output:
namespace_pain.cpp: In function ‘void two::output(const one::A&)’:
namespace_pain.cpp:28:16: error: no match for ‘operator<<’ in ‘std::cout <<
val’
namespace_pain.cpp:28:16: note: candidates are:



alternate command to reproduce:
./usr/bin/g++ namespace_pain.cpp --std=c++11

compiler output for alternate command:
namespace_pain.cpp: In function ‘void two::output(const one::A&)’:
namespace_pain.cpp:28:16: error: cannot bind ‘std::ostream {aka
std::basic_ostream}’ lvalue to ‘std::basic_ostream&&’
In file included from
/mnt/gcc-4.7/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/iostream:40:0,
 from namespace_pain.cpp:1:
/mnt/gcc-4.7/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/ostream:600:5:
error:   initializing argument 1 of ‘std::basic_ostream<_CharT, _Traits>&
std::operator<<(std::basic_ostream<_CharT, _Traits>&&, const _Tp&) [with _CharT
= char; _Traits = std::char_traits; _Tp = one::A]’

[Bug c++/53011] New: ice in verify_loop_structure: bad sizes

[dcb314 at hotmail dot com]

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

 Bug #: 53011
   Summary: ice in verify_loop_structure: bad sizes
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dcb...@hotmail.com


Created attachment 27171
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27171
C++ source code

I just tried to compile the package libwvstreams-4.6.1-4
on gcc-4.8 trunk dated 20120415 on an AMD x86_64 box.

The compiler said

linuxstreams/wvinterface.cc: In member function 'int
WvInterface::delroute(const WvIPNet&, const WvIPAddr&, int, WvStringParm)':
linuxstreams/wvinterface.cc:479:5: error: size of loop 2 should be 0, not 1
 int WvInterface::delroute(const WvIPNet &dest, const WvIPAddr &gw,
 ^
linuxstreams/wvinterface.cc:479:5: error: bb 89 do not belong to loop 2
 int WvInterface::delroute(const WvIPNet &dest, const WvIPAddr &gw,
 ^
linuxstreams/wvinterface.cc:479:5: error: loop 2's header does not belong
directly to it
 int WvInterface::delroute(const WvIPNet &dest, const WvIPAddr &gw,
 ^
linuxstreams/wvinterface.cc:479:5: internal compiler error: in
verify_loop_structure, at cfgloop.c:1567
 int WvInterface::delroute(const WvIPNet &dest, const WvIPAddr &gw,
 ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Preprocessed source code attached. Flag -O2 required.

[Bug c/53010] New: crash due to null ptr deref

[regehr at cs dot utah.edu]

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

 Bug #: 53010
   Summary: crash due to null ptr deref
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: reg...@cs.utah.edu
CC: cheny...@cs.utah.edu


[regehr@dyson r35]$ current-gcc -m32 -O3 small.c -c
small.c: In function 'fn1':
small.c:3:1: internal compiler error: Segmentation fault
 fn1 ()
 ^
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.


[regehr@dyson r35]$ cat small.c
int a, b, c, d, e;
void
fn1 ()
{
d = 0;
for (; d <= 1; d++)
;
for (; a; a--)
e = d | b || c;
}


[regehr@dyson r35]$ current-gcc -v
Using built-in specs.
COLLECT_GCC=current-gcc
COLLECT_LTO_WRAPPER=/uusoc/exports/scratch/regehr/z/compiler-install/gcc-r186501-install/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.8.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --with-libelf=/usr/local --enable-lto
--prefix=/home/regehr/z/compiler-install/gcc-r186501-install
--program-prefix=r186501- --enable-languages=c,c++
Thread model: posix
gcc version 4.8.0 20120416 (experimental) (GCC)

[Bug libstdc++/53006] libstdc++-prettyprinters/shared_ptr.cc FAILs

[tromey at gcc dot gnu.org]

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

--- Comment #2 from Tom Tromey  2012-04-16 18:01:17 
UTC ---
(In reply to comment #0)

> match = self.compiled_rx.match(typename)

> print type(typename)
> 

This is very odd.  The code in context:

typename = self.get_basic_type(val.type)
if not typename:
return None

# All the types we match are template types, so we can use a
# dictionary.
match = self.compiled_rx.match(typename)

If typename is None, we should have taken the "return None" branch.

I tend to agree it is a python problem as you stated in comment #1.

[Bug c++/38543] [C++0x] Cannot specialize variadic template function

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/53009] pointer to static member function of template class is “invalid” as a template argument of another template class

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-04-16
 Ever Confirmed|0   |1

--- Comment #3 from Jonathan Wakely  2012-04-16 
16:53:46 UTC ---
reduced:

template class function_proxy;

template
struct function_proxy
{
static void wrapper(){ }
};

template class member_helper;

template
struct member_helper
{
static void as_free(Class& obj){ }

static void worker(){
//ERROR HERE: template argument 2 is invalid. Not very helpful message.
(void) function_proxy::wrapper;
}
};

struct Test
{
void test(){ }
};

int main()
{
//does not work
member_helper::worker();
}

[Bug c++/52008] [C++0x] ICE when adding partial specialization for variadic-templated structure

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #2 from Jason Merrill  2012-04-16 
16:51:08 UTC ---
This example is problematic because the partial specialization is not more
specialized than the primary template; we should reject it with an error rather
than crashing.

[Bug c++/49152] pretty printer cannot handle iterators and other complex expressions

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |
 AssignedTo|paolo.carlini at oracle dot |unassigned at gcc dot
   |com |gnu.org
Summary|Unhelpful diagnostic for|pretty printer cannot
   |iterator dereference|handle iterators and other
   ||complex expressions

--- Comment #43 from Manuel López-Ibáñez  2012-04-16 
16:26:09 UTC ---
Thanks Paolo. It is nice that by default, we do not print these monsters
anymore. But the pretty-printer is still broken, and the diagnostic is still
broken for -fno-diagnostics-show-caret. So let's keep it around in case someone
decides to fix that or Gabriel changes his mind.

(In any case, I don't expect anyone to fix this any year soon now that it is
not the default anymore, so it should have the lowest priority possible.)

[Bug c++/53009] pointer to static member function of template class is “invalid” as a template argument of another template class

[blaffablaffa at gmail dot com]

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

--- Comment #2 from Lorenzo Pistone  2012-04-16 
16:22:04 UTC ---
I just tested, the problem happens only if the template arguments of
function_proxy are function pointers. More trivial types (int is what I've
tested) just work fine

[Bug c++/53009] pointer to static member function of template class is “invalid” as a template argument of another template class

[blaffablaffa at gmail dot com]

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

--- Comment #1 from Lorenzo Pistone  2012-04-16 
16:09:16 UTC ---
Created attachment 27170
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27170
testcase

[Bug c++/53009] New: pointer to static member function of template class is “invalid” as a template argument of another template class

[blaffablaffa at gmail dot com]

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

 Bug #: 53009
   Summary: pointer to static member function of template class is
“invalid” as a template argument of another template
class
Classification: Unclassified
   Product: gcc
   Version: 4.6.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: blaffabla...@gmail.com


I believe that this bug is somewhat related to #35167: probably g++ thinks that
the address of a static member function of a template class is not a constant
expression, whereas it is. I'm filing a new bug though because the situation
here involves two distinct class templates, the error message is different
("error: template argument 2 is invalid", not helpful at all), and because it's
said in the comments of #35167 that it's fixed if C++11 is used, whereas my
testcase is compiled with and needs C++11 (for variadic templates).

Fails to build with g++ 4.6.2 4.5.4 4.4.6.

[Bug target/52932] AVX2 intrinsic _mm256_permutevar8x32_ps has wrong parameter type

[ubizjak at gmail dot com]

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

Uros Bizjak  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #14 from Uros Bizjak  2012-04-16 16:05:00 
UTC ---
Fixed.

[Bug target/52932] AVX2 intrinsic _mm256_permutevar8x32_ps has wrong parameter type

[uros at gcc dot gnu.org]

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

--- Comment #13 from uros at gcc dot gnu.org 2012-04-16 16:03:55 UTC ---
Author: uros
Date: Mon Apr 16 16:03:51 2012
New Revision: 186500

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186500
Log:
2012-04-16  Uros Bizjak  

Backport from mainline
2012-04-12  Uros Bizjak  

PR target/52932
* config/i386/avx2intrin.h (_mm256_permutevar8x32_ps): Change second
argument type to __m256i.  Update call to __builtin_ia32_permvarsf256.
* config/i386/sse.md (avx2_permvarv8sf): Change operand 1 to V8SI.
(avx2_permvarv8sf, avx2_permvarv8si): Switch operands 1 and 2.
* config/i386/i386.c (bdesc_args) <__builtin_ia32_permvarsf256>:
Update builtin type to V8SF_FTYPE_V8SF_V8SI.
(ix86_expand_vec_perm): Update calls to gen_avx2_permvarv8si and
gen_avx2_permvarv8sf.

testsuite/ChangeLog:

2012-04-16  Uros Bizjak  

Backport from mainline
2012-04-12  Uros Bizjak  

PR target/52932
* gcc.target/i386/avx2-vpermps-1.c (avx2_test): Use __m256i type for
second function argument.
* gcc.target/i386/avx2-vpermps-2.c (init_permps): Update declaration.
(calc_permps): Update declaration.  Calculate result correctly.
(avx2_test): Change src2 type to union256i_d.
* gcc.target/i386/avx2-vpermd-2.c (calc_permd): Calculate result
correctly.


Modified:
branches/gcc-4_7-branch/gcc/ChangeLog
branches/gcc-4_7-branch/gcc/config/i386/avx2intrin.h
branches/gcc-4_7-branch/gcc/config/i386/i386.c
branches/gcc-4_7-branch/gcc/config/i386/sse.md
branches/gcc-4_7-branch/gcc/testsuite/ChangeLog
branches/gcc-4_7-branch/gcc/testsuite/gcc.target/i386/avx2-vpermd-2.c
branches/gcc-4_7-branch/gcc/testsuite/gcc.target/i386/avx2-vpermps-1.c
branches/gcc-4_7-branch/gcc/testsuite/gcc.target/i386/avx2-vpermps-2.c

[Bug c++/50830] [c++0x] Variadic template, inner class error

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2012-04-16
 CC||jason at gcc dot gnu.org
 AssignedTo|unassigned at gcc dot   |jason at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

[Bug c++/49152] Unhelpful diagnostic for iterator dereference

[redi at gcc dot gnu.org]

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

--- Comment #42 from Jonathan Wakely  2012-04-16 
15:47:37 UTC ---
Awesome, thank you very very much, Paolo and Manu.

The example in comment 23 can now be added to
http://gcc.gnu.org/wiki/ClangDiagnosticsComparison ;)

[Bug c++/49152] Unhelpful diagnostic for iterator dereference

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED
 AssignedTo|unassigned at gcc dot   |paolo.carlini at oracle dot
   |gnu.org |com

--- Comment #41 from Paolo Carlini  2012-04-16 
15:36:07 UTC ---
Done.

[Bug c++/49152] Unhelpful diagnostic for iterator dereference

[paolo at gcc dot gnu.org]

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

--- Comment #40 from paolo at gcc dot gnu.org  
2012-04-16 15:32:28 UTC ---
Author: paolo
Date: Mon Apr 16 15:32:22 2012
New Revision: 186499

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186499
Log:
/cp
2012-04-16  Paolo Carlini  

PR c++/49152
* call.c (op_error): Print types; when flag_diagnostics_show_caret
is false print expressions too.
(op_error_string): Add.

/testsuite
2012-04-16  Paolo Carlini  

PR c++/49152
* g++.dg/diagnostic/operator1.C: New.
* g++.dg/ext/label5.C: Adjust.
* g++.dg/ext/va-arg1.C: Likewise.
* g++.dg/other/error20.C: Likewise.
* g++.dg/other/error20.C: Likewise.
* g++.dg/other/error16.C: Likewise.
* g++.dg/other/error10.C: Likewise.
* g++.dg/parse/error30.C: Likewise.
* g++.dg/cpp0x/lambda/lambda-err1.C: Likewise.

Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-err1.C
trunk/gcc/testsuite/g++.dg/ext/label5.C
trunk/gcc/testsuite/g++.dg/ext/va-arg1.C
trunk/gcc/testsuite/g++.dg/other/error10.C
trunk/gcc/testsuite/g++.dg/other/error16.C
trunk/gcc/testsuite/g++.dg/other/error20.C
trunk/gcc/testsuite/g++.dg/parse/error30.C

[Bug c++/50303] [C++0x] Segfault with variadic template template parameters

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug target/51819] [4.7 Regression] Neon wrong code generation, Error: unsupported alignment for instruction -- `vst1.32 {d2[0]},[r0:64]'

[uweigand at gcc dot gnu.org]

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

--- Comment #6 from Ulrich Weigand  2012-04-16 
15:19:47 UTC ---
Author: uweigand
Date: Mon Apr 16 15:19:43 2012
New Revision: 186498

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186498
Log:
2012-04-16  Ulrich Weigand  

PR target/51819
* config/arm/arm.c (arm_print_operand): Fix invalid alignment
hints for 'A' operand types.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/arm.c

[Bug libitm/53008] New: abort in _ITM_getTMCloneSafe

[daveboutcher at gmail dot com]

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

 Bug #: 53008
   Summary: abort in _ITM_getTMCloneSafe
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libitm
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: daveboutc...@gmail.com


Created attachment 27169
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27169
testcase for abort in _ITM_getTMCloneSafe

Abort in _ITM_getTMCloneSafe() within atomic transaction calling a function via
a function pointer.  The abort only appears to happen if the function pointer
is defined as __attribute__((transaction_safe)).  Only happens at -O2 and
above.

Fairly minimal testcase attached.

[Bug middle-end/51255] Using -fwhole-program breaks code which puts values in .ctors or .init_array

[krisztian.kocsis at optimaster dot eu]

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

--- Comment #6 from Krisztian Kocsis  
2012-04-16 14:35:37 UTC ---
I currently know that glibc uses it but don't know who else use it.
In my projects I always use constructor/destructor attributes because with them
I can control the exection order.

[Bug c++/51148] [C++0x] Unexpanded template param packs wrongly accepted in friend class declarations

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.8.0

--- Comment #3 from Jason Merrill  2012-04-16 
14:24:09 UTC ---
Fixed for 4.8.

[Bug c++/51148] [C++0x] Unexpanded template param packs wrongly accepted in friend class declarations

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill  2012-04-16 
14:15:45 UTC ---
Author: jason
Date: Mon Apr 16 14:15:36 2012
New Revision: 186495

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186495
Log:
PR c++/51148
* friend.c (make_friend_class): Call check_for_bare_parameter_packs.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/variadic127.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/friend.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/52976] [4.8 Regression] Revision 186384 breaks the polyhedron tests aermod.f90 and doduc.f90 at -O3 -ffast-math

[rguenther at suse dot de]

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

--- Comment #14 from rguenther at suse dot de  
2012-04-16 13:55:58 UTC ---
On Mon, 16 Apr 2012, vincenzo.innocente at cern dot ch wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52976
> 
> --- Comment #13 from vincenzo Innocente  
> 2012-04-16 13:53:30 UTC ---
> I confirm that "revision 186494" fixed PR53007.
> btw:
> would it be possible to add the revision number to the oyuout of "c++ -v"?
> the current "version id" 
> gcc version 4.8.0 20120416 (experimental) (GCC) 
> does not uniquely identify the content of the build...

It does if you use ./contrib/gcc_update

[Bug tree-optimization/52976] [4.8 Regression] Revision 186384 breaks the polyhedron tests aermod.f90 and doduc.f90 at -O3 -ffast-math

[vincenzo.innocente at cern dot ch]

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

--- Comment #13 from vincenzo Innocente  
2012-04-16 13:53:30 UTC ---
I confirm that "revision 186494" fixed PR53007.
btw:
would it be possible to add the revision number to the oyuout of "c++ -v"?
the current "version id" 
gcc version 4.8.0 20120416 (experimental) (GCC) 
does not uniquely identify the content of the build…

[Bug middle-end/51255] Using -fwhole-program breaks code which puts values in .ctors or .init_array

[hubicka at ucw dot cz]

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

--- Comment #5 from Jan Hubicka  2012-04-16 13:50:35 UTC 
---
How common is this construction in practice?  Adding a warning or making GCC to
imply used attribute is same amount of work - it means teaching GCC about those
and possibly others special purpose sections.  Or alternatively declare all
named sections special purpose and implicitely used.

The code is not conforming any standards.  In past we started taking away
unused
variables/functions that also broke asm constructs and required annotations
without
making an attempt for GCC to parse asm statements.

Section names are easier to parse, indeed, but still the situation is very
symmetric
here.

Honza

[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables

[michael.haubenwallner at salomon dot at]

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

--- Comment #37 from Michael Haubenwallner  2012-04-16 13:29:06 UTC ---
A few more references:
The fix for this one issue is:
https://www-304.ibm.com/support/docview.wss?uid=isg1IZ98134

But this introduces /usr/ccs/bin/as coredump during gcc bootstrap
(strstream.o):
https://www-304.ibm.com/support/docview.wss?uid=isg1IV01126

Just guessing, but maybe the whole thing was introduced by:
https://www-304.ibm.com/support/docview.wss?uid=isg1IZ87535

Based on the filesets shown in the APARs for each AIX release/TL/SP, here's a
list of maybe broken/working AIX levels, although I'm unable to verify for
sure, as the broken machines got the interim fix installed here for IV01126
(supersedes interim fix for IZ98134):

 +--++
 | broken since |  fixed since   |
-+--++
AIX 5.3 TL9  ||
TL10 |  SP6 (1107)  |  |
TL11 |  SP6 (1107)  |   SP8 (1140)   |
TL12 |  SP3 (1107)  |   SP5 (1140)   |
-+--++
AIX 6.1 TL2  ||
TL3  |  SP9 (1112)  |  |
TL4  |  SP9 (1112)  |   SP11 (1140)  |
TL5  |  SP5 (1112)  |   SP7  (1140)  |
TL6  |  SP4 (1112)  |   SP6  (1140)  |
TL7  ||
-+--++
AIX 7.1 TL0  |  SP3 (1115)  |  |
TL1  ||
-+--++

Even if AIX 7.1 TL0 SP4 was released at 1140 too, it doesn't seem to contain
IV01126 - maybe TL0 SP5 will do.

[Bug c++/51148] [C++0x] Unexpanded template param packs wrongly accepted in friend class declarations

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug tree-optimization/53007] [4.8 REGRESSION] ICE verify_ssa failed with -Ofast and lto

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE

--- Comment #1 from Richard Guenther  2012-04-16 
13:22:49 UTC ---
Duplicate.

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

[Bug tree-optimization/52976] [4.8 Regression] Revision 186384 breaks the polyhedron tests aermod.f90 and doduc.f90 at -O3 -ffast-math

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 CC||vincenzo.innocente at cern
   ||dot ch

--- Comment #12 from Richard Guenther  2012-04-16 
13:22:49 UTC ---
*** Bug 53007 has been marked as a duplicate of this bug. ***

[Bug c/52977] [4.8 Regression] internal compiler error: Segmentation fault with `-x c-header' or `-x cxx-header' option

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Guenther  2012-04-16 
13:21:37 UTC ---
Author: rguenth
Date: Mon Apr 16 13:21:30 2012
New Revision: 186494

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186494
Log:
2012-04-16  Richard Guenther  

PR middle-end/52977
* tree.h (VECTOR_CST_NELTS): Adjust.
(struct tree_vector): Add explicit length field.
(make_vector_stat): Declare.
(make_vector): Define.
* tree.c (make_vector_stat): New function.
(build_vector_stat): Use it.
* tree-streamer-in.c (streamer_alloc_tree): Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-streamer-in.c
trunk/gcc/tree.c
trunk/gcc/tree.h

[Bug tree-optimization/53007] New: [4.8 REGRESSION] ICE verify_ssa failed with -Ofast and lto

[vincenzo.innocente at cern dot ch]

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

 Bug #: 53007
   Summary: [4.8 REGRESSION] ICE verify_ssa failed with -Ofast and
lto
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: vincenzo.innoce...@cern.ch


Created attachment 27168
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27168
tar compressed directory  containing the "test case"

I'm sure it was not the case with
gcc version 4.8.0 20120403 (experimental) (GCC) 

being in lto not easy to produce a reduced test case:
attached the whole directory

tar -zxf buggy.tgz
cd buggy
c++ -Ofast *.c 
[innocent@vinavx0 buggy]$ c++ -O3 *.c -flto
[innocent@vinavx0 buggy]$ c++ -Ofast *.c -flto
In file included from :6:0:
kernel.c: In function 'kernel_measureLU':
kernel.c:188:12: error: definition in block 26 follows the use
 double kernel_measureLU(int N, double min_time, Random R)
^
for SSA_NAME: reassocpow.3_161 in statement:
D.2821_127 = reassocpow.3_161 *
6.6662965923251249478198587894439697265625e-1;
kernel.c:188:12: internal compiler error: verify_ssa failed
 double kernel_measureLU(int N, double min_time, Random R)
^
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
lto-wrapper: c++ returned 1 exit status
collect2: error: lto-wrapper returned 1 exit status
[innocent@vinavx0 buggy]$ c++ -v
Using built-in specs.
COLLECT_GCC=c++
COLLECT_LTO_WRAPPER=/afs/cern.ch/user/i/innocent/w2/libexec/gcc/x86_64-unknown-linux-gnu/4.8.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ./configure --prefix=/afs/cern.ch/user/i/innocent/w2
--enable-languages=c,c++,fortran -enable-gold=yes --enable-lto
--with-build-config=bootstrap-lto --with-gmp-lib=/usr/local/lib64
--with-mpfr-lib=/usr/local/lib64 -with-mpc-lib=/usr/local/lib64
--enable-cloog-backend=isl --with-cloog=/usr/local
--with-ppl-lib=/usr/local/lib64 CFLAGS='-O2 -ftree-vectorize -fPIC'
CXXFLAGS='-O2 -fPIC -ftree-vectorize -fvisibility-inlines-hidden -march=native'
-enable-libitm -disable-multilib
Thread model: posix
gcc version 4.8.0 20120416 (experimental) (GCC)

[Bug fortran/51081] Proc-pointer assignment: Rejects valid internal proc, -std=f2008 should mention "F2008"

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-04-16
 Ever Confirmed|0   |1

--- Comment #4 from janus at gcc dot gnu.org 2012-04-16 12:37:26 UTC ---
(In reply to comment #0)
> Compiling with -std=2003 just prints:
> 
>   Error: Internal procedure 'int' is invalid
>  in procedure pointer assignment at (1)

This is of course easily fixed:

Index: gcc/fortran/expr.c
===
--- gcc/fortran/expr.c(revision 186485)
+++ gcc/fortran/expr.c(working copy)
@@ -3444,9 +3444,10 @@ gfc_check_pointer_assign (gfc_expr *lvalue, gfc_ex
   return FAILURE;
 }
   if (attr.proc == PROC_INTERNAL &&
-  gfc_notify_std (GFC_STD_F2008, "Internal procedure '%s' is "
-  "invalid in procedure pointer assignment at %L",
-  rvalue->symtree->name, &rvalue->where) == FAILURE)
+  gfc_notify_std (GFC_STD_F2008, "Fortran 2008: Internal procedure "
+  "'%s' is invalid in procedure pointer assignment "
+  "at %L", rvalue->symtree->name, &rvalue->where)
+  == FAILURE)
 return FAILURE;
 }
   /* Check for F08:C730.  */



An alternative would be to add the correct label automatically inside
'gfc_notify_std', based on the value of 'GFC_STD_*' passed.

[Bug c/53001] -Wfloat-conversion should be available to warn about floating point errors

[manu at gcc dot gnu.org]

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

--- Comment #3 from Manuel López-Ibáñez  2012-04-16 
12:36:59 UTC ---
(In reply to comment #2)
> I should have time to create a patch for this before 4.8 goes into stage 3.  
> Do
> you think it needs a copyright assignment and if so what paperwork would you
> need from my employer?

I am afraid so. See:
https://www.gnu.org/prep/maintain/maintain.html#Legal-Matters

Write to g...@gcc.gnu.org asking for the documents. There are several people
there dealing with this matter. Also, let us know if you find any problems.

[Bug libstdc++/53006] libstdc++-prettyprinters/shared_ptr.cc FAILs

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #1 from ro at CeBiTec dot Uni-Bielefeld.DE  2012-04-16 12:27:06 UTC ---
> Strangely, the same gdb binary works on Solaris 10 with the bundled
> libpython2.6.so, so this might be a bug in that library on Solaris 11.

Indeed when I point gdb at a copy of the Solaris 10 libpython2.6.so on
Solaris 11 via LD_LIBRARY_PATH_64, the test passes as well ;-(  Seems
like a bug in the Solaris 11 libpython, after all.

Rainer

[Bug libstdc++/53006] New: libstdc++-prettyprinters/shared_ptr.cc FAILs

[ro at gcc dot gnu.org]

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

 Bug #: 53006
   Summary: libstdc++-prettyprinters/shared_ptr.cc FAILs
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org
CC: tro...@gcc.gnu.org
  Host: i386-pc-solaris2.11
Target: i386-pc-solaris2.11
 Build: i386-pc-solaris2.11


Since prettyprinters.exp has been enabled recently, the shared_ptr.cc test
FAILs on Solaris 11/x86 only:

FAIL: libstdc++-prettyprinters/shared_ptr.cc print esp
FAIL: libstdc++-prettyprinters/shared_ptr.cc print ewp1
FAIL: libstdc++-prettyprinters/shared_ptr.cc print ewp2
FAIL: libstdc++-prettyprinters/shared_ptr.cc print sp1
FAIL: libstdc++-prettyprinters/shared_ptr.cc print wp1
FAIL: libstdc++-prettyprinters/shared_ptr.cc print wp2

I'm using a 64-bit gdb 7.4 linked with the vendor-supplied libpython2.6.so
(same problem with libpython2.7.so).

In libstdc++.log, I find:

$1 = skipping: 80 return 0;^M
Python Exception  expected string or buffer: ^M
Python Exception  expected string or buffer: ^M
got: $1 = Python Exception  expected string or
buffer: ^M
FAIL: libstdc++-prettyprinters/shared_ptr.cc print esp
skipping: Python Exception  expected string or
buffer: ^M
std::shared_ptr (empty) 0x0^M

Manually running gdb with the equivalent of the generated shared_ptr.gdb file,
I
get:

(gdb) print esp
Python Exception  expected string or buffer: 
Python Exception  expected string or buffer: 
$1 = std::shared_ptr (empty) 0x0

Unfortunately, expect/dejagnu merge stdout and stderr here, causing the mixture
of both streams.

When I set python print-stack full first, I get:

(gdb) print esp
$1 = Traceback (most recent call last):
  File
"/vol/gcc/src/hg/trunk/local/libstdc++-v3/testsuite/../python/libstdcxx/v6/printers.py",
line 777, in __call__
match = self.compiled_rx.match(typename)
TypeError: expected string or buffer

Traceback (most recent call last):
  File
"/vol/gcc/src/hg/trunk/local/libstdc++-v3/testsuite/../python/libstdcxx/v6/printers.py",
line 777, in __call__
match = self.compiled_rx.match(typename)
TypeError: expected string or buffer
std::shared_ptr (empty) 0x0

I cannot really make sense of that (barely knowing python), but if I add

print type(typename)

in printers.py, I find:



Strangely, the same gdb binary works on Solaris 10 with the bundled
libpython2.6.so, so this might be a bug in that library on Solaris 11.

Suggestions?

  Rainer

[Bug tree-optimization/52976] [4.8 Regression] Revision 186384 breaks the polyhedron tests aermod.f90 and doduc.f90 at -O3 -ffast-math

[wschmidt at gcc dot gnu.org]

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

William J. Schmidt  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED
   Target Milestone|4.8.0   |---

--- Comment #11 from William J. Schmidt  
2012-04-16 12:17:48 UTC ---
Fixed.

[Bug c/53001] -Wfloat-conversion should be available to warn about floating point errors

[jjcogliati-r1 at yahoo dot com]

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

--- Comment #2 from Joshua Cogliati  2012-04-16 
12:16:45 UTC ---
Yes, it should also warn for non-constants, and also for other floating
decreases in accuracy such as: 

float foo(double x) {
  return x;
}

I should have time to create a patch for this before 4.8 goes into stage 3.  Do
you think it needs a copyright assignment and if so what paperwork would you
need from my employer?

[Bug tree-optimization/52976] [4.8 Regression] Revision 186384 breaks the polyhedron tests aermod.f90 and doduc.f90 at -O3 -ffast-math

[wschmidt at gcc dot gnu.org]

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

--- Comment #10 from William J. Schmidt  
2012-04-16 12:16:04 UTC ---
Author: wschmidt
Date: Mon Apr 16 12:15:50 2012
New Revision: 186493

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186493
Log:
2012-04-16  Bill Schmidt  

PR tree-optimization/52976
* tree-ssa-reassoc.c (add_to_ops_vec_max_rank): New function.
(undistribute_ops_list): Ops with repeat counts aren't eligible for
undistribution.
(attempt_builtin_powi): Call add_to_ops_vec_max_rank.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-ssa-reassoc.c

[Bug debug/52935] Unnecessary DW_TAG_pointer_type DIEs in C++

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.8.0

--- Comment #2 from Jason Merrill  2012-04-16 
12:08:16 UTC ---
Fixed by

2012-04-11  Jason Merrill  

PR debug/45088
* decl.c (grokdeclarator): Strip the injected-class-name typedef
if we are building a declaration or compound type.

[Bug middle-end/51255] Using -fwhole-program breaks code which puts values in .ctors or .init_array

[krisztian.kocsis at optimaster dot eu]

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

--- Comment #4 from Krisztian Kocsis  
2012-04-16 12:07:19 UTC ---
If it is treated as a user error than a warning should be printed because this
changes the behavior of what is dropped and what is not. People expect that
"used thinds" won't be dropped from the final binary and they treate these
sections as "used things" even if it is technically not true.

[Bug fortran/51081] Proc-pointer assignment: Rejects valid internal proc, -std=f2008 should mention "F2008"

[janus at gcc dot gnu.org]

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

--- Comment #3 from janus at gcc dot gnu.org 2012-04-16 12:01:46 UTC ---
(In reply to comment #1)
> First, my example was incomplete. Secondly, I just realized that gfortran
> rejects the program although I think it is valid (ifort also compiles it):
> 
>   subroutine int2()
>  1
> Error: FUNCTION attribute conflicts with SUBROUTINE attribute in 'int2' at (1)

I only get this with 4.6.3, but with 4.7 and trunk I get:

  subroutine int2()
 1
Error: 'int2' declared INTRINSIC at (1) does not exist


This error message even appears three times and is just as wrong as the other
one.

[Bug c/53001] -Wfloat-conversion should be available to warn about floating point errors

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #1 from Manuel López-Ibáñez  2012-04-16 
11:41:24 UTC ---
(In reply to comment #0)
> This is a request to add a new warning that warns on the subset of 
> -Wconversion
> warnings that involve floating point numbers.  For example, with
> -Wfloat-conversion this would cause a warning:

Should it also warn for non-literals?

int foo(double x)
{
   return x;
}

> I think this could mostly be done by modifying gcc/c-family/c-common.c
> unsafe_conversion_p to add the ability to only warn on conversions where
> REAL_TYPE or REAL_CST are involved.  

Yes, I think it should be easy to implement. You will also need to add a new
option to gcc/c.opt and enable -Wfloat-conversion with -Wconversion (grep for
OPT_Wimplict and how it handles its suboptions).

Unfortunately, I don't have time to work on this, and probably nobody else has,
so you could try to submit a patch: http://gcc.gnu.org/contribute.html

[Bug tree-optimization/52975] Ofast produces not optimized code for vectorized "converted if"

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Guenther  2012-04-16 
11:40:46 UTC ---
Unless we come up with a testcase that is a regression from an earlier release
a backport is unlikely.

[Bug tree-optimization/52975] Ofast produces not optimized code for vectorized "converted if"

[vincenzo.innocente at cern dot ch]

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

--- Comment #5 from vincenzo Innocente  
2012-04-16 11:19:26 UTC ---
indeed.
will it be back-ported to 4.7.1?

btw
I find very "elegant" the
movaps(%rdx,%rax), %xmm0
minps%xmm1, %xmm0
movaps%xmm0, (%rcx,%rax)
produced by -Ofast  for
  for (int j=0; j<100 ; ++j)
xsum[j] = (clus[j] > 0) ? 0 : clus[j];

I suppose it is to ask to much to produce the same for
  for (int j=0; j<100 ; ++j) {
xsum[j] = clus[j];
if (xsum[j] > 0) xsum[j] = 0;
  }
and
  for (int j=0; j<100 ; ++j) {
xsum[j] = 0;
if (clus[j] < 0) xsum[j] = clus[j];

in any case I confirm that now all three forms produces the very same code with
-O3 and -Ofast (for the last two) even for march=corei7 (also avx)

I also tested the three variations for
xsum[j] = clus[j];
if (xsum[j] > cut[j]) xsum[j] = 0;

[Bug c/53005] GCC moves the called C function address and parameters to the wrong stack position, when making C-style calling of C functions in a C function with inline assembly code.

[manu at gcc dot gnu.org]

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

--- Comment #5 from Manuel López-Ibáñez  2012-04-16 
11:18:51 UTC ---
Lili Zhao, I forgot to say, but feel free to reopen this if you can reproduce
the bug with GCC 4.7. Thanks for the report anyway, and sorry we cannot help
you.

[Bug c/53005] GCC moves the called C function address and parameters to the wrong stack position, when making C-style calling of C functions in a C function with inline assembly code.

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||manu at gcc dot gnu.org
 Resolution||INVALID

--- Comment #4 from Manuel López-Ibáñez  2012-04-16 
11:13:28 UTC ---
See: http://gcc.gnu.org/wiki/FAQ#gcc42apple

[Bug c++/39728] diagnostic for private operator= is voluminous and unhelpful

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  2012-04-16 
11:10:07 UTC ---
Maybe the most widely used term is "compiler-generated" but I prefer implicity
defined.

(In reply to comment #2)
> * Do not show "In member function", it clutters the output and it is 
> duplicated
> info because they are already mentioned in the note. 

I'm not sure about this suggestion.  

/home/redi/gcc/4.x/include/c++/4.8.0/bits/ios_base.h: In member function
'std::basic_ios& std::basic_ios::operator=(const
std::basic_ios&)':

This is useful info, it tells me the (implicitly-defined) context in which the
private operator= was needed.

/home/redi/gcc/4.x/include/c++/4.8.0/bits/ios_base.h:791:5: error:
'std::ios_base& std::ios_base::operator=(const std::ios_base&)' is private
 operator=(const ios_base&);
 ^

This is useful, it's the private operator= that was needed, but inaccessible.

In file included from /home/redi/gcc/4.x/include/c++/4.8.0/ios:45:0,
 from /home/redi/gcc/4.x/include/c++/4.8.0/istream:40,
 from /home/redi/gcc/4.x/include/c++/4.8.0/fstream:40,
 from f.cc:1:
/home/redi/gcc/4.x/include/c++/4.8.0/bits/basic_ios.h:64:11: error: within this
context
 class basic_ios : public ios_base
   ^

The caret diagnostic is useless here, because an implictly-defined function has
no location.

[Bug tree-optimization/52975] Ofast produces not optimized code for vectorized "converted if"

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #4 from Richard Guenther  2012-04-16 
11:07:29 UTC ---
Fixed.

.L3:
movaps  clus(%rax), %xmm1
movaps  %xmm2, %xmm0
cmpltps %xmm1, %xmm0
andnps  %xmm1, %xmm0
movaps  %xmm0, xsum(%rax)
addq$16, %rax
cmpq$400, %rax
jne .L3

[Bug tree-optimization/52975] Ofast produces not optimized code for vectorized "converted if"

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Guenther  2012-04-16 
11:03:20 UTC ---
Author: rguenth
Date: Mon Apr 16 11:03:16 2012
New Revision: 186491

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186491
Log:
2012-04-16  Richard Guenther  

PR tree-optimization/52975
* tree-if-conv.c (predicate_bbs): Do not simplify inverted
condition but always mark it with TRUTH_NOT_EXPR.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-if-conv.c

[Bug c++/52763] Warning if compare between enum and non-enum type

[gccrepo...@gmx-topmail.de]

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

--- Comment #5 from Mikka  2012-04-16 11:01:25 UTC 
---
(In reply to comment #4)
> (In reply to comment #3)
> > (In reply to comment #2)
> > > But what about cases such as (val1 == (ONE|TWO)) ?
> > > 
> > > (ONE|TWO) is of type 'int' but that code is correct and shouldn't warn
> > 
> > In my opinion, there should be a warning here, because (ONE|TWO) is not in 
> > the
> > enumeration range (there is no definition for 3).
> 
> It is in range.  For enum { NONE = 0, ONE = 1, TWO = 2 } the standard says the
> values of the enumeration are in the range 0 to 3, e.g. it could be 
> represented
> by a two-bit unsigned integer.  The standard sets the rules, not your opinion
> :)
> 
While the standard says, it should be an integer of this range. It does not
say, that the enumeration-type should be able/used to store other values as the
ones, which are defined. Actually it does say, that there is not conversion
from int to enum. So this means here, that we would compare the enum to an
integer with a value, which we shouldn't be able to store in the enumeration in
the first place. "var = 1;" produces as expected an error, "invalid conversion
from ‘int’ to ‘tEnumType’".

> Also, that would warn for perfectly valid (and very common) uses of 
> enumeration
> types for bitmasks, e.g. std::ios::openmode could be defined as an enumeration
> type and you could say
> 
>if (mode == (std::ios::in|std::ios::out))
> 
> where there is no enumerator defined for in|out, but this code is common and
> should not warn.
> 
Just because it is common, it doesn't mean that it's perfect. In my opinion
this is an abuse of the enumeration here. If this is a bitmask, it should be
implemented this way, using either the c-style unions or c++ bitsets or 
something else (custom class, ...). The name enumeration means we are counting
something, not a bitmask.

E.g. "mode = (std::ios::in|std::ios::out)" only works, because the function "|"
is defined using static_cast. For me this is quite a hint, that it's quite not
perfect, but more an abuse.
> > If it was defined (e.g. typedef enum {NONE = 0, ONE = 1, TWO = 2, THREE = 3}
> > tEnumType), result could again be of the enumeration type and there would 
> > be no
> > warning.
> 
> No, the result would still be an int, ONE|TWO has type int, period.
> 
> I think the warning could be useful in some cases, but it needs to be defined
> much more carefully than simply "warning each time a enumeration type is
> compared to a non enumeration type" as you suggested.
I still think the warning should be there in both cases. It shouldn't be a
default warning, as legacy code would produce too many warnings.

For my solution, from now on I will use "enum class", as it does exactly what I
want. While this is not my optimal solution (forcing at least gcc 4.4 for all
project attendees), it will work, somehow.

[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 #2 from Richard Guenther  2012-04-16 
10:58:06 UTC ---
Looks like a pre-existing bug to me - when we unswitch loops computing
irreducible regions before / after that can lead to inconsistent results.

Loop preserving leads to different loop structure at the beginning of
RTL unswitching compared to the 4.7 branch.

[Bug c++/39728] diagnostic for private operator= is voluminous and unhelpful

[manu at gcc dot gnu.org]

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

--- Comment #4 from Manuel López-Ibáñez  2012-04-16 
10:53:50 UTC ---
(In reply to comment #3)
> Every C++ programmer knows that the compiler implicitly defines special member
> functions, including the copy-assignment operator but I don't really like the
> terminology. C++ doesn't have methods, it has member functions, and the formal
> term in the standard is "implicitly-defined" not synthesized.

Indeed. I would consider obvious to do:

sed -i 's/synthesized method/implicitly-defined member function/g' cp/*.c
cp/*.h

Would Jason pre-approve such a patch?

It doesn't fix the actual verbose output Ian is complaining about, but it is a
small positive step.

[Bug c/53004] Segmentation fault can be overcome with dummy predefined declaration

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #4 from Manuel López-Ibáñez  2012-04-16 
10:48:28 UTC ---
And GCC tells you so:

manuel@gcc12:~$ ~/trunk/186353M/build/gcc/cc1 -Wall tmp.c 
tmp.c:3:6: warning: return type of ‘main’ is not ‘int’ [-Wmain]
 void main()
  ^
tmp.c: In function ‘main’:
tmp.c:8:8: warning: ‘prod_vg’ is used uninitialized in this function
[-Wuninitialized]
   multg(prod_vg);
^

Now that -Wuninitialized is separated from -Wmaybe-uninitialized, maybe it is
time to enable it by default.

[Bug c/53005] GCC moves the called C function address and parameters to the wrong stack position, when making C-style calling of C functions in a C function with inline assembly code.

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  2012-04-16 
10:47:15 UTC ---
Yes.

If you got GCC 4.2 from Apple then you could report the bug to Apple, not here.

We do not support GCC 4.2, so it is pointless to report bugs for that version
here, they won't be fixed.  If you want support here, you need to use a
supported version.

[Bug c++/39728] diagnostic for private operator= is voluminous and unhelpful

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  2012-04-16 
10:44:19 UTC ---
(In reply to comment #1)
>   I think libstdc++ include pathes make the error message useless 

Manu has a patch for that in PR 52974

(In reply to comment #2)
> * What is a "synthesized method"? Where this term comes from? Is this 
> something
> that an average C++ programmer can understand?

Every C++ programmer knows that the compiler implicitly defines special member
functions, including the copy-assignment operator but I don't really like the
terminology. C++ doesn't have methods, it has member functions, and the formal
term in the standard is "implicitly-defined" not synthesized.

[Bug c/38470] value range propagation (VRP) would improve -Wsign-compare

[manu at gcc dot gnu.org]

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

--- Comment #11 from Manuel López-Ibáñez  2012-04-16 
10:43:44 UTC ---
(In reply to comment #10)
> It seems like we could at least add a simple improvement that just checks for
> simple comparisons to 0. That probably catches most code (I often do one set 
> of

You are welcome to try: http://gcc.gnu.org/contribute.html

[Bug c/53004] Segmentation fault can be overcome with dummy predefined declaration

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

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

Andreas Schwab  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||INVALID

--- Comment #3 from Andreas Schwab  2012-04-16 10:37:17 
UTC ---
You are using an uninitialized pointer.

[Bug testsuite/52948] [4.8 Regression] UNRESOLVED: selfassign.c in gcc/g++, one_time_plugin.c in gcc, and dumb_plugin.c in g++

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
URL||http://gcc.gnu.org/ml/gcc-p
   ||atches/2012-04/msg00921.htm
   ||l
 CC||ro at gcc dot gnu.org
 Resolution||FIXED
 AssignedTo|unassigned at gcc dot   |ro at gcc dot gnu.org
   |gnu.org |

--- Comment #5 from Rainer Orth  2012-04-16 10:25:34 UTC 
---
Mine, fixed for 4.8.0.

  Rainer

[Bug c/53005] GCC moves the called C function address and parameters to the wrong stack position, when making C-style calling of C functions in a C function with inline assembly code.

[zhao86.scholar at gmail dot com]

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

--- Comment #2 from Lili Zhao  2012-04-16 
10:17:43 UTC ---
Do you mean we should use a later GCC version?
(In reply to comment #1)
> GCC 4.2 is not supported, please try a current release.

[Bug c/52977] [4.8 Regression] internal compiler error: Segmentation fault with `-x c-header' or `-x cxx-header' option

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Guenther  2012-04-16 
10:15:35 UTC ---
ugh...

#0  0x004d7255 in gt_pch_p_14lang_tree_node (this_obj=0x75bf64c0, 
x_p=0x75bf64c0, op=0x8b1a27 , cookie=0x7fffdb20)
at ./gt-c-decl.h:1448

case TS_VECTOR:
  if ((void *)(x) == this_obj)
op (&((*x).generic.vector.typed.type), cookie);
  {
size_t i0;
size_t l0 = (size_t)(TYPE_VECTOR_SUBPARTS (TREE_TYPE
((tree)&((*x).generic.vector;
for (i0 = 0; i0 != l0; i0++) {
  if ((void *)(x) == this_obj)
op (&((*x).generic.vector.elts[i0]), cookie);
}
  }
  break;

so we relocate TREE_TYPE before accessing it to find the number of elements.

Other than trying to teach gengtype to compute all required lengths before
changing pointers I only see the less efficient solution of repeating the
element count in-line :/

[Bug testsuite/52948] [4.8 Regression] UNRESOLVED: selfassign.c in gcc/g++, one_time_plugin.c in gcc, and dumb_plugin.c in g++

[ro at gcc dot gnu.org]

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

--- Comment #4 from Rainer Orth  2012-04-16 10:14:49 UTC 
---
Author: ro
Date: Mon Apr 16 10:14:40 2012
New Revision: 186490

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186490
Log:
Fix plugin testsuite, remove uses of TODO_dump_func (PR testsuite/52948)

* lib/plugin-support.exp (plugin-test-execute): Properly determine
testcase name.
Use fail, pass instead of unresolved.
Don't log $optstr.

PR testsuite/52948
* g++.dg/plugin/dumb_plugin.c (pass_dumb_plugin_example): Remove
TODO_dump_func.
* g++.dg/plugin/selfassign.c (pass_warn_self_assign): Likewise.
* gcc.dg/plugin/one_time_plugin.c (one_pass): Likewise.
* gcc.dg/plugin/selfassign.c (pass_warn_self_assign): Likewise.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/plugin/dumb_plugin.c
trunk/gcc/testsuite/g++.dg/plugin/selfassign.c
trunk/gcc/testsuite/gcc.dg/plugin/one_time_plugin.c
trunk/gcc/testsuite/gcc.dg/plugin/selfassign.c
trunk/gcc/testsuite/lib/plugin-support.exp

[Bug c/53005] GCC moves the called C function address and parameters to the wrong stack position, when making C-style calling of C functions in a C function with inline assembly code.

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

  Component|c++ |c
Version|unknown |4.2.1
   Severity|major   |normal

--- Comment #1 from Jonathan Wakely  2012-04-16 
10:12:41 UTC ---
GCC 4.2 is not supported, please try a current release.

[Bug middle-end/52939] [4.7/4.8 Regression] ice in gimple_get_virt_method_for_binfo with -O3

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #8 from Martin Jambor  2012-04-16 
10:10:48 UTC ---
Fixed.

[Bug c++/53005] New: GCC moves the called C function address and parameters to the wrong stack position, when making C-style calling of C functions in a C function with inline assembly code.

[zhao86.scholar at gmail dot com]

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

 Bug #: 53005
   Summary: GCC moves the called C function address and parameters
to the wrong stack position, when making C-style
calling of C functions in a C function with inline
assembly code.
Classification: Unclassified
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zhao86.scho...@gmail.com


Created attachment 27167
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27167
C code to reproduce the bug.

When making C-style calling of C functions in a C function with inline assembly
code, GCC moves the called C function address and parameters to the wrong stack
position, which is overwriting the values of other variables in the stack.   
The problem can be reproduced using the C code in the attached.

The exact version of GCC:
4.2.1

The system type:
i686-apple-darwin11

The options given when GCC was configured/built:
/private/var/tmp/llvmgcc42/llvmgcc42-2335.15~25/src/configure
--disable-checking --enable-werror --prefix=/Developer/usr/llvm-gcc-4.2
--mandir=/share/man --enable-languages=c,objc,c++,obj-c++
--program-prefix=llvm- --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/
--with-slibdir=/usr/lib --build=i686-apple-darwin11
--enable-llvm=/private/var/tmp/llvmgcc42/llvmgcc42-2335.15~25/dst-llvmCore/Developer/usr/local
--program-prefix=i686-apple-darwin11- --host=x86_64-apple-darwin11
--target=i686-apple-darwin11 --with-gxx-include-dir=/usr/include/c++/4.2.1